JMonkey Dual Marching Cubes

<cite>@phr00t said:</cite> We have to be given commit rights.. I'm jvight at the usual gmail dot com. I don't necessarily see whats wrong with posting here about it? :|
Okay, if you have questions simply ask. The variables and methods are mostly the same in both projects. I splitted the getValue method of the OctreeNode into getValue for the density and getGradient for the gradient of the position. Besides I added the calculateNormalsNew boolean in the IsoSurface. If this variable is true the Gradient(Normal) for the Triangle will be generated new by getting the informations from the source. Otherwise gradients which gets passed through the methods are used which is the way the Ogre Project is doing it, but this makes some mistakes here.

Thanks for the commit rights & for the info. Iā€™m working on some other stuff at the moment, but this is on my to-do list. Iā€™m hoping to get this in for 3089 & Iā€™ll likely do some crazy processing & memory optimizations with it :stuck_out_tongue:

I would be happy if someone could help me fixing this bug:
http://i.imagebanana.com/img/06c5hvxq/bug.jpg

I looked through the whole code if I made a mistake porting something but I didnt find anything.

Good to see that someone else is working on some voxel smoothing algo. Unfortunately i am really really busy since a year and i have no time to work on my game project.
Last time i tried to implement the transvoxel algo since it would solve the LOD problem nicely. http://www.terathon.com/voxels/
But if i remember correctly i failed implementing the transition cells.

<cite>@ogerlord said:</cite> I would be happy if someone could help me fixing this bug: http://i.imagebanana.com/img/06c5hvxq/bug.jpg

I looked through the whole code if I made a mistake porting something but I didnt find anything.

Iā€™m just starting to get to thisā€¦ hopefully I can help you out here.

Unfortunately, I have to hack this up quite a bit. All of my terrain generation volume functions work on doubles & Vector3d objects for starters :expressionless:

Code also looks like it makes heavy use of the garbage collectorā€¦ lots of new vector3 objects being created. Should try and re-use some objects or avoid them all together (e.g. pass 3 floats/doubles instead of a newly created vector3 object).

When everything is working I will try to optimize the code. Besides java is fast and although I create tons of ā€œuselessā€ vectors it is not that slow.

Why do you use doubles?

<cite>@ogerlord said:</cite> When everything is working I will try to optimize the code. Besides java is fast and although I create tons of "useless" vectors it is not that slow.

The slowness wonā€™t show up in the average FPS, it will instead show up as random pauses when the garbage collector tries to clean up all those ā€œuselessā€ vectors. In a small demo program, that isnā€™t such a problemā€¦ in my commercial first-person shooter, it is. I generally disagree with the whole ā€œmake it work, optimize laterā€ thingā€¦ since people generally never get around to optimizing (because, hey, it isnā€™t that slow!).

Why do you use doubles?

I have an endless open-worldā€¦ I donā€™t want things to start getting funky when/if players reach a location where floating point numbers are not entirely accurate anymore. Not sure how big of a problem this really is, but it is something Iā€™ve done in 3079 & 3089 as a preventative measureā€¦

It may take awhile to get this code working with mineā€¦ :expressionless:

<cite>@phr00t said:</cite> Code also looks like it makes heavy use of the garbage collector... lots of new vector3 objects being created. Should try and re-use some objects or avoid them all together (e.g. pass 3 floats/doubles instead of a newly created vector3 object).

Modern Java compilers use Escape Analysis and other tricks to make many short lived objects the same cost as scalar types.

You can do a lot of optimizations by just controlling the scope of your objects, instead of reusing or getting rid of them.

1 Like
<cite>@aaronperkins said:</cite> Modern Java compilers use Escape Analysis and other tricks to make many short lived objects the same cost as scalar types.

You can do a lot of optimizations by just controlling the scope of your objects, instead of reusing or getting rid of them.

Interesting.

I always use the Java profiler to measure memory & CPU usageā€¦ if I see a spike in memory usage somewhere, it is usually from a rogue ā€œnew Vector3f()ā€ I was creating every frame or for every generation call etc.

<cite>@phr00t said:</cite> I have an endless open-world... I don't want things to start getting funky when/if players reach a location where floating point numbers are not entirely accurate anymore. Not sure how big of a problem this really is, but it is something I've done in 3079 & 3089 as a preventative measure...

It may take awhile to get this code working with mineā€¦ :expressionless:

The decision to move to double shouldnā€™t be taken lightly. JME3 uses floats for everything. When you move to doubles you immediately make your code incompatible with the rest of the JME3 ecosystem.

This has been discussed before on these forums and I agree there is generally nothing doubles can solve that a good data structure using floats canā€™t also solve.

@phr00t said: Interesting.

I always use the Java profiler to measure memory & CPU usageā€¦ if I see a spike in memory usage somewhere, it is usually from a rogue ā€œnew Vector3f()ā€ I was creating every frame or for every generation call etc.

You also need to check the other stats about the objectā€¦ generations it survived, etcā€¦ These objects are generally reclaimed for free. If you see GC pauses then it is from something else.

1 Like
<cite>@aaronperkins said:</cite> The decision to move to double shouldn't be taken lightly. JME3 uses floats for everything. When you move to doubles you immediately make your code incompatible with the rest of the JME3 ecosystem.

This has been discussed before on these forums and I agree there is generally nothing doubles can solve that a good data structure using floats canā€™t also solve.

Almost everything in 3089 works on floats, but there is a UniversePosition for the main player & a WorldOffset for terrain generation that operates with doubles. This way, large numbers get put into those doubles & the ā€œfloating pointā€ world stays centered @ 0, 0, 0. However, one thing that does need to be friendly with doubles is terrain generation, so the volume function can take very large numbers and still return precise values. Iā€™m trying to just modify the VolumeSource function in this code, but it is going to take a bit of workā€¦

@aaronperkins said: The decision to move to double shouldn't be taken lightly. JME3 uses floats for everything. When you move to doubles you immediately make your code incompatible with the rest of the JME3 ecosystem.

This has been discussed before on these forums and I agree there is generally nothing doubles can solve that a good data structure using floats canā€™t also solve.

Yes, as a general rule, I suggest using doubles for position of game objects but continue to use floats for actual geometryā€¦ and then make the geometry camera relative.

1 Like

If youā€™re incurring the cost of conversion between the scenegraphā€™s floats and some other data type for the game simulation, why not use longs?
More bits of accuracy, and you donā€™t want to see the decimal point float anyway because that means loss of precision.

The only reason NOT to do that I can imagine would be using oneā€™s own for-doubles build of native Bullet.
I hear that that would be pointless in practice though.

Soā€¦ whereā€™s the catch?

I started developing on Android (DroidCraft etc.), so I learned to develop with fewer resources. The #1 performance tip was to avoid creating unnecessary objects because ā€œobject creation is never freeā€:

http://developer.android.com/training/articles/perf-tips.html

The simple fact is, to get the best performance out of the garbage collector, you give it the fewest objects to manage. It is good to know some compiler optimizations exist, but Iā€™m sure they work best when the developer also makes a conscious effort to reduce object allocations. It is also best to develop with that in mind, instead of trying to go back and optimize later (since we know how rarely that happens).

Iā€™m still experimenting with this code, but my needs for 3089 & strict performance requirements might make it difficult to contribute to a ā€œgeneral purposeā€ repositoryā€¦ if I can contribute something, I will.

<cite>@toolforger said:</cite> If you're incurring the cost of conversion between the scenegraph's floats and some other data type for the game simulation, why not use longs? More bits of accuracy, and you don't want to see the decimal point float anyway because that means loss of precision.

The only reason NOT to do that I can imagine would be using oneā€™s own for-doubles build of native Bullet.
I hear that that would be pointless in practice though.

Soā€¦ whereā€™s the catch?

floats are probably good enough, and I know doubles are good enough. Much easier to convert the doubles to floats (which are offset) that jme3/bullet needs.

Well, as long as it is not working 100% I think it is most important to finish it firstā€¦

<cite>@ogerlord said:</cite> Well, as long as it is not working 100% I think it is most important to finish it first....

Yeah, working is far more important than being fast :stuck_out_tongue: Just saying, it is good advice to incorporate efficient coding practices while finishing it the first time.

@phr00t said: I started developing on Android (DroidCraft etc.), so I learned to develop with fewer resources. The #1 performance tip was to avoid creating unnecessary objects because "object creation is never free":

Yes, we were specifically talking about on desktop. The android garbage collector sucks donkey ass in comparison so all bets are off.

1 Like