Ok, after I pulled my little managed library out and am looking at the fallout, I think it would be simpler to keep to the flatbuffer interfaces for the time being until I have everything working as before.
There were a couple of other places that were affected, such as a library container and a caching mechanic for that library.
So, an item is created from a set of CSG commands. Basically a small file of what primitive to spawn, their color and position and what CSG operation to apply. A stack based command system.
The result of that operation is a PlaneMesh. Which is a structure that holds a BSP tree, a PlaneSurface and some minor additional items. Basically the resultant volume from the CSG output.
But for rendering I have to convert this PlaneMesh to a PolygonMesh. Which effectively just computes the vertices, fixes the t-vertices and collects the color and material information into a small class that maps easily to any type of mesh object.
The CSG files are like the source files, PlaneMesh like the compiled .object files and the final PolygonalMesh as a runtime executable.
Having 3 stages seems to complicate things, but not a lot though.
I am just thinking if I am over complicating things, but on the other hand, the process of converting the CSG operations to a PlaneMesh is the most expensive one.
Converting a PlaneMesh to a PolygonalMesh is not as expensive, but the post processing step of fixing the t-vertices can be expensive, depending on the size and complexity.
The CSG operations, can include other CSG operation files, like references to other objects that then get included in the process of creating that object. Like you created a box with a hole, and you would like to reuse it in another set of creation, you could just reference that CSG object to reuse that shape.
The PlaneMesh is never referenced by the CSG ops directly because you can’t guarantee that the result of the quantization after a rotation of the vertex data will still return a water tight mesh and without self intersections or holes. So, if you want to change the rotation and scale of an object, you would be forced to recompute the item from source.
Having these layers of output will minimize the source data, speed up the re-creation of polygonal data and speed up the load of polygons for a scene. Feels a bit over-engineered at the moment, but caching things for operations that can be expensive, seems like the right thing to do.
You can always recreate all the data form the sources. Just like you do with programming sources. And with the output, such as the compiled solids, you can produce single tiles from them, or you can combine them into a larger model that is combined of many tiles that have then been merged into one solid polygonal piece.
Now, I am just wondering if I should just have my own little text format for the command strings or should I use a valid .json representation. The CSG library support .json that is supplied by the flatbuffers library. So, if I use that format for the commands, i can reuse the persistence mechanics to construct the actual command objects for me.
Yay.
V 