Cool. I don’t want to put too much stuff here now, I’ll put images up tomorrow to show it in action.
How close to paged geometry is it?
It’s PG light; the core functionality and a few tweaks. Its running very “close to metal”, relying heavily on jME, and I hope to keep it that way. I’m not aiming for cutting-edge optimization etc. in my code, I’m focusing on functionality; delegating most optimization stuff to the API.
Would grass be modelled?
Yes. Very much like much like PGs grassloader does it - a custom mesh of quads with grass textures on them, distributed either uniformly or through a density map. I’m working on the mesh model now (pretty much copying and pasting from PG) - the density map code is already in place.
Probably gonna use a different alpha fade method then the one in PG tho (it requires a crap-load of depth checks).
Could I use a static mesh for terrain?
Well, yes. Assuming you have an easy way of getting specific height values of your mesh you could do it right away. My current implementation uses terrain data to define a “planting zone”. That could theoretically be any box with a center, a width, a height, and an array of floating point values for y coords. At the moment its running much like PG’s “Treeloader2D”, you could say.
I am working on a “Treeloader3D”, which would be the simple way of solving it for small, static terrains/scenes. With that you can place trees and stuff in an editor and then import the scene, but still use the optimization features of the loader. In fact, Ogitor already works exactly like that with the real PG.