Monday, back to work. Whole day very focused on some major code rewrite. Something I started Friday.
I have this M3D module that I use for handling 3D at the data-base level (no rendering, although I wrote some PC renderers that use M3D). Basically I use this library to handle basic geometry. Vertices with color, skinning, texture, normals. Triangles and strips. making strips, converting strips back to triangles, removing unused materials, sort the data as to remove state changes for rendering. Also some experiments on mesh complexity reduction and so on.
Basically it’s the interface that I use to handle parsed data from file formats like XSI and 3DS.
For this rewrite I wanted to try and approach C++. It’s actually an experiment in itself. For the time being, my main concern with C++ is writing style more than performance, as I think I can already handle performance well enough.
My current style is base dont he following rules, that I need to verify with time.

Let’s say I have an scene, an object and a group. For every scene there are N objects and for every object there are M groups. A group is practically a 3D mesh. So, an object is a collection of meshes (plus other things that I’ll leave out for now).
In M3D, I have m3d_object_t, m3d_scene_t and so on. Functions have prefixes that indicate their scope. They are basically like C++ methods. So, functions that operate on m3d_object_t structure will all start with m3d_object_. For example: m3d_object_scale( m3d_object_t *op ). For the scene then it’s m3d_scene_scale( m3d_scene_t *sp ).
And here start the troubles with C++. m3d_object_scale( op ) would become op->scale(), m3d_scene_scale( sp ) becomes sp->scale( sp ). And so on for groups and all the rest.
Now, while this is neat, at the practical level, it turns a nightmare when I need to find out exactly where in any piece of code I scale the scene or I scale an object. This is especially important for libraries such as this, that are used by a number of different programs.
My current solution is to use a shorter prefix. So, for the class m4d_scene_c I have sp->m4s_scale(). m4d is the library name, m4s stands for an m4d Scene.
This allows me to keep track of where I scale a scene, an object or a group.

Then it comes the issue of the private methods and additional modules. For private methods, it’s probably OK to lose the prefix. They aren’t supposed to be used externally anyway. I’m still not sure though.
In any case, C++ forces to have a lot of private methods, some have a specific domain and some sort of prefix is still probably useful.
Let’s say that I have a separate CPP file for welding close vertices of a group. In the file I will put the m4g_weldverts() method, but also some private functions. In C i would declare those static and forget about them. In C++ I need to declare them into the class, so it can get a bit more confusing.
The solution for now is to use some sort of prefix. In this case, a function that is strictly used by the m4d_weldverts() would be called, for example, weldverts_flag_weldable_verts(). Basically with the weldverts_ prefix.

Still, I sort of hate the idea of having to declare the private methods, but we’ll see how it goes.

It’s almost 3AM.. zzzzzzzzzzzzz

Posted by Davide Pasca in Uncategorized