Native ports and actual content tools

For the past month I have been porting my C# library to C++, so that I can distribute my tool to friends for testing and increase the performance slightly. That I need a native library just so that I can share with friends has to do with me being a tad bit paranoid with my clever solution and how easy it is to decompile the C# bytecode.

The increase in performance is also noticeable, and I can also see differences with the generated LLVM binaries and the ones compiled with MSVC. My Windows desktop has a an i5 intel processor, vs my Macbook Pro which has an i7 intel processor, and for one test where I am actually doing CSG stuff, the slower CPU is running the test about 25% faster than the faster CPU that is running the same code but compiled with LLVM. So, there is indeed strengths with the MSVC running on its own native Windows OS that the LLVM is missing on my more powerful MacBook.

I created some basic tests to see where my native implementation was outperforming the C# JIT compiled Mono stuff.

I did most of these comparisons on my Macbook Pro.

  • Large unbalanced tree creation was ~2x faster for the native library.
  • Reading a flatbuffer file of about 1MB with and creating the data structures from it was ~8x faster with the native implementation.
  • Map and dictionary lookups ~10x faster.
  • Creating plane meshes for polygonal primitives was around ~5x more performant.
  • Computing the CSG operation between a dense sphere and a cube was around ~3 – 4x more efficient, the better numbers were found on the windows machine with the lower spec CPU. Thanks to MSVC.

So, the interface between the two libraries is basically a command queue for the CSG operator to perform, and can return a “Flatbuffer” of polygons for the C# game code to churn into triangles for Unity when it wants to display the results.

But all of this magic needs to come into some sort of a visual result. And to make good use of it, I have been trying to create a set of tools to make the basic 3D tiles to paint and layout with. Trying to keep things simple and easy to use, but still flexible, so that the user does not have to make a lot of context switches between modes, align cameras and planes, find buttons and adjust sliders and numbers. Make it function more like a fun mechanic in a computer game than some dry and rigid DCC application.


Trying to use the same grid for all configurations. In the case of creating a box shape, you define a silhouette, then in another area(which I need to make more defined) is where you would sketch out the vertical profile of the shape and be able to create a instances within that 3×3 grid array. Then one would apply those new shapes to the previous shapes created and do any CSG operation between them. Where each tile is restricted within one square unit.

Then, this would become your active brush which then can be used to paint into the actual scene.

Need to have the two phases of the application working together so that I can finally start creating large and interesting models with it. Getting very close to that part, and when I finally do, I can start letting friends play with it as well.

Well, other responsibilities are calling, and I will attend to this again, later today or tomorrow morning.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s