Project 130: Computational Fluid Dynamics: Instancing, Spherical Mapping, and Real Time Updating

I have made significant progress on the Fluid Dynamics simulation, and I feel that I am coming close to a point where I can release the software. I haven't decided whether to charge for it or release it for free yet, or even where I will release it, but I still have quite a bit of debugging and optimisation to do.

The first update to the software is Real Time updating. Before, all of the variables controlling the simulation were in code, requiring a rebuild of the engine to alter anything. Now, they can be changed from the level editor in real time. This is clearly a vital feature, and one that I had intended to include from the start.

The second update is that I made some changes to the texture coordinate code. I was using a very simplistic approach, which was causing noticeable stretching of the texture on the metablobs. I have since added support for spherical texture mapping. The texture coordinates now take the form: (Obtained from here)

 

u = aSin(x)/PI+0.5

v = aSin(y)/PI+0.5

 

This is still much simpler than Triplaner texturing, but I feel that the results with the water shader are much better, with much less stretching. It does not seem to work with the other materials I have created, however. I have made a Lava, Tar, and Mud material using T3D's built in material editor and some custom textures, and the textures do not seem to show up at all with the spherical mapped coordinates. I will probably have to use both systems, and swap between the two depending on which material the user has chosen.

Finally, I have made the simulation completely object-oriented. It was running using global variables, which made testing and debugging easier, but it is now all class and object based, which means I can have as many instances of the fluid simulation running as I want simply by adding another Fluid Simulation object to the world usign the level editor, and each object can have completely different properties, materials, etc.


This has led me to what I feel is the final problem in the project, which is that of optimisation. Even with just two fluid systems in the scene, the framerate is very low. Granted, this was using a debug build, which is noticeable slower than the release build, but I will still need to spend some time researching optimisation techniques for the underlying marching cubes algorithm that powers the metablobs. I have considered multithreading the simulation, and have researched this possibility. I will probably try it, and see if there is much of an improvement in framerate.


You must be a member of this blog to see the comments. Log in now!