LDView is written in C++, and the current parser was written over 20 years ago (before "modern" C++), so anybody trying to read its code might have issues. However, its parser works like this at a high level:
When a user opens a file, the LDLMainModel is asked to read it, and it first reads the whole thing in, creating its array of file lines. After that is done, it then goes through the array and asks each one to parse the data. For most line types, that just means loading the data in. For example, the triangle line scans in the three points. For the model line type, it does that, but then for the model itself it populates an LDLModel object. First, it checks the loaded models dictionary to see if that model has already been loaded. If it has, it just bumps up the reference counter and hooks onto it. If not, it loads the file (using the same code as from the main file), which then repeats the process above. (Oh, it first checks to make sure there isn't an infinite loop, like a->b->c->a. If there's an infinite loop, it generates an error.)
LDView splits the logical loading (above) from the data needed to render the model. All of the above loads the LDraw file into memory, but it's not in a format that is suitable for rendering. It then walks through the loaded data and transfers it into structures more suitable for rendering. So, for example, each model will then have a bunch of triangles all grouped together in one contiguous array that's in the proper format for rendering. And, like the loader above has LDLModelLine and LDLModel (deduped), the renderer has TRESubModel and TREModel (deduped). The TRESubModel contains information about the transformation, while TREModel contains the rest. And if you have an LDraw file with 500 instances of 3001.dat, there will be 500 3001-specific TRESubModel instances, but only one 3001-specific TREModel instance.
There are many ways to write a program, and I wrote this over two decades ago, so I'm sure if I were writing it today it would be very different. So the above is simply meant to be an overview of how LDView works. Feel free to make us of the information any way you see fit (including ignoring it all).
- The top level is a LDLMainModel object that contains information that is only needed at the top level. This is a subclass of the LDLModel object.
- The LDLModel object represents a single LDraw file. It basically contains a list of LDLModelLine objects.
- LDLFileLine is the base class for the various different LDraw line types. In the case of LDView, these are LDLCommentLine, LDLEmptyLine, LDLUnknownLine, LDLModelLine, LDLLineLine, LDLConditionalLineLine, LDLQuadLine, and LDLTriangleLine. (There are some other classes in between to group various ones.)
- Each "line" object knows how to parse the text in the corresponding line of the LDraw file, and extract the information. So, for example, the LDLModelLine scans in all the parameters in a type 1 line in an LDraw file.
When a user opens a file, the LDLMainModel is asked to read it, and it first reads the whole thing in, creating its array of file lines. After that is done, it then goes through the array and asks each one to parse the data. For most line types, that just means loading the data in. For example, the triangle line scans in the three points. For the model line type, it does that, but then for the model itself it populates an LDLModel object. First, it checks the loaded models dictionary to see if that model has already been loaded. If it has, it just bumps up the reference counter and hooks onto it. If not, it loads the file (using the same code as from the main file), which then repeats the process above. (Oh, it first checks to make sure there isn't an infinite loop, like a->b->c->a. If there's an infinite loop, it generates an error.)
LDView splits the logical loading (above) from the data needed to render the model. All of the above loads the LDraw file into memory, but it's not in a format that is suitable for rendering. It then walks through the loaded data and transfers it into structures more suitable for rendering. So, for example, each model will then have a bunch of triangles all grouped together in one contiguous array that's in the proper format for rendering. And, like the loader above has LDLModelLine and LDLModel (deduped), the renderer has TRESubModel and TREModel (deduped). The TRESubModel contains information about the transformation, while TREModel contains the rest. And if you have an LDraw file with 500 instances of 3001.dat, there will be 500 3001-specific TRESubModel instances, but only one 3001-specific TREModel instance.
There are many ways to write a program, and I wrote this over two decades ago, so I'm sure if I were writing it today it would be very different. So the above is simply meant to be an overview of how LDView works. Feel free to make us of the information any way you see fit (including ignoring it all).