I'm still messing with the new possibilities Ardor3D terrain system adds to the pool, meanwhile I've finally ported my special micro heightmap based tile to terrain batching system to Ardor3D. It was a bit of a work, but now that I've taken care of a heap of other smaller things in the code, static parts are starting to look like they should. :) With further help from Josh and Rikard @ ardor3d I could integrate new things and resolve bounding volume issues. Now culling is working perfectly, and thus FPS rocketed to around those values I was used to under jME2, or even higher. Also I'm experiencing very good stability, so far no native part crashes neither on my Intel GPU nor the ATi GPU notebook. The memory it needs to load the initial state isn't bigger than it was with jme2, maybe even less.
After porting the old tile to terrain system I had for jme2, i'm starting to think about combining the GeometryClipmapTerrain of ardor3d with my terrain system, that way I can prevent my head from a series of aches related to object placament and such... Well, you can check the screenshot of the current state of the art - in the background you can spot how the new clipmap terrain fits (not too nicely yet) with the old detailed terrain in the foreground.
If I can manage to combine these too, we'll have the best of both worlds, new and old: almost infinite view distance for the terrain (at least the mountains and plains even if not the trees and buildings) plus the detailed view of the surroundings. The FPS / memory hit is not high/minimal with the ClipmapTerrain so far, so it's worthy to try.
Friday, 12 March 2010
Static parts are starting to look quite right!
Labels:
3d,
ardor3d,
hardcoding,
testing
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment