Hmm… maybe you could place the top/bottom fringes manually and then autogenerate the rest using terrain height tests.
1 Like
I like that idea a lot, right now I only have the tops and bottom fringes placed, so that would be be a much better way to make the space in between follow the shape of the cliff, and easier, rather than placing rows of nodes in between and fixing the mesh to fit the mountain side by trial and error. Thanks for the idea 
1 Like
No worries. Good luck with it if you decide to go that route. I think you can probably get decent results without doing much of anything fancy, but there are lots of modifications you could make to that basic scheme if you need something more, like adaptive subdivisions to fit sudden changes in terrain, etc. 
We also use nifty GUI. From jME 3.0 
At this point we rewritten half of rendering and layout in it 
To render 3D models we have added a custom renderer that does it. It actually works pretty neatly that way and pretty simple. Screen sizing is hell, yeah, we wanted to do like you did, but then reworked some stuff in ScalableRenderDevice.
I almost did that, but I really want to release this year and that was a step too far for me. I’m somewhat tempted to gut nifty and rework it as a jme specific lib after I release Spoxel. Did you get your implementation working with batching or did you just skip over that?
Nah we don’t use batching. Even tho GUI gets pretty complex in our game, it’s not a big concern right now. We will work out batching when we need it At this point it’s more our code than not 