@fabsterpal said: That's not as disturbing as the blocky effect when you move the camera on XZ.Edit: Couldn’t you change the water filter to apply the translation? The only issue is that might (probably will) cause the same problems as moving the camera (not sure).
Yes to the applying a translation. Maybe to the other… I’d have to see. There may be some period where things repeat and then it might be ok to reset the position based on that without disturbing the repeat.
@loopies said: This is awesome!You make most of us look like idiots diddling with sticks and rocks :D.
Aw, shucks. Well, it’s funny because I’m making sticks and rocks, basically. 
I’m giving the code away so everyone can play, though. We can all make the same sticks and rocks.
@pspeed said: There is no reason that it can't be supported. I don't know that I will add it but the code doesn't really care. Meaning: modifiable terrain should be as easy as changing the value in the density field and telling the zone to rebuild.The pager assumes flat earth… so it’s a pretty struct x,y,z grid.
However, the trees and grass can face any direction… in fact, the grass and trees already do lean based on their terrain location. So the mesh supports it… but the pager is locked into y up.
And for texturing, texture splatting like in the SDK? Or?
@haze said: And for texturing, texture splatting like in the SDK? Or?
I personally needed purely generative terrain. So I personally hadn’t planned on adding texture splatting. Someone else could always add it.
Actually, that being said, I always have ideas running around in the back of my head so who knows? For example, in tight clumps of trees I’d really like to be able to have fallen leaves splatted on the terrain there or to otherwise change the terrain texture under the trees/plants. So maybe.
Wow, great progress on this project, it looks very nice, impressive!
Your projects are really amazing and these articles are very helpful to newcomers like me, and even more experienced users. It helps me at least have some understanding of how things work. Keep up the great work.
So, it took a lot of juggling… but I finally got ground atmospherics into the IsoSurfaceDemo. I hope to release another version soon.
Step 1 was making the new SimFX library that now has the SkyState and the related atmospheric stuff, including a base ScatteredLighting.j3md which is just a fork of lighting.j3md with scattering added.
Step 2 was then converting SimArboreal over to use the SkyState from SimFX and to augment the four tree materials with the scattering parameters and calls to the scattering glsllib.
Step 3, finally, was integrating all of this into the IsoSurfaceDemo… to include switching to the new shared SkyState, LightingState, etc…
Here are some pics without scattering and with scattering: (Note: none of the post-proc effects are enabled.)
And a shot of early morning lighting… note the nice post-dawn tinting in the second pic:
The effect with these settings is subtle but I think it’s effective.
That’s some real nice work there @pspeed 
@zarch said: That's some real nice work there @pspeed :)
Thanks. Hopefully an update here soon.
So, I’ve posted a new release:
https://simsilica-tools.googlecode.com/svn/trunk/IsoSurfaceDemo/release/IsoSurfaceDemo-Windows.zip
https://simsilica-tools.googlecode.com/svn/trunk/IsoSurfaceDemo/release/IsoSurfaceDemo-Linux.zip
https://simsilica-tools.googlecode.com/svn/trunk/IsoSurfaceDemo/release/IsoSurfaceDemo-MacOSX.zip
Controls are still the same as in this post:
http://hub.jmonkeyengine.org/forum/topic/isosurface-demo-dev-blog-experiment/page/2/#post-289215
In this version I have added 4 different types of trees with full LOD. They are batched right now. I’ve been trying to stay compatible with JME Stable for as long as possible. The next release of the IsoSurface stuff will probably be built against JME trunk so that I can take advantage of instancing.
The other feature I added was the ground atmospherics. You have to turn them on in the “ground” tab. With that, I also added a ground disc which kind of takes up the gap between where the water stops and the horizon. It looks better than a black bar but not much… works much better without water but then you won’t have water. 
On the “dev blog” side, I spent about 10 hours on Saturday hunting around for ‘leaks’ in the paging system. The tree layers rebuild themselves on the fly as LOD tile ranges change. The state tracking in the Pager/Builder was a little too naive for this and there were some instances where zones weren’t getting released properly.
On the one hand, this is not a classic leak as the garbage collector will eventually catch them. On the other hand, I’ve tried really hard to have the zones free their meshes as they don’t need them anymore. So having zones go unreleased meant mesh buffers were hanging around longer than needed. I suspected that this was a major source of the OutOfMemory errors that I was receiving.
So after a lot of counting, state tracking, etc. I finally fixed all of the issues in the pager/builder. It’s internal state tracking is way more explicit now and can easily be transferred to a state diagram. The bottom line is: while there may still be bugs lurking in there my confidence in the state management and life cycle is 1000x greater than it was. For one thing, as I said, it’s provable on paper now (where it was hard to do before). And for another thing, the explicit state tracking also comes with a whole bunch of new errors being thrown if things end up in a wonky state. The last three state bugs I fixed on Saturday night were because of typo-level mistakes and finding them was instant precisely because of the new error handling. For something this core to everything, it’s kind of worth it in the long run.
At any rate, it turned out that there was also at least one memory “leak” in the TreeZone, too.
The kicker to this story: even with all of the memory and state fixes, I still get OutOfMemory errors when wandering around long enough. And when I do, I’m not even close to the limits. My suspicions are that this may be OS related at this point. I’ve given the app 768 meg of direct memory and I’ve seen it run out at 300 with the process total not even exceeding 500 (including the regular heap). So either I’m hopelessly fragging the heap or this Windows XP 32 bit instance just decides to stop giving the app more RAM at some point. There is strong evidence to suggest that is the case… namely that when I run the app on a fresh reboot it tends to run fine.
Anyway, hopefully your luck running it for extended periods will be better than mine.
And finally, a couple screen shots:
I love it.
No OOM error and I played quite some time.
This is looking fantastic! Lush, natural and the scenes look like you’ve been pouring lots of time in them! I love those sun rays in the last picture, although I don’t see the sun. How were they created?
@memonick said: This is looking fantastic! Lush, natural and the scenes look like you've been pouring lots of time in them! I love those sun rays in the last picture, although I don't see the sun. How were they created?
Thanks.
If you mean nehon’s pic then the sun is right here:
You can almost see the edge of it.
The rays come from the light scattering filter.
Very nice work! @pspeed I’ve been following and reading your stuff for a while now. Really impressive how this is all procedural.
I got some pretty good results without shadows, with around 150 FPS with all settings enabled (at default values) except for shadows and ssao while not looking at the sun. The FPS dropped to about 120-130 while looking at the sun with Light Scattering enabled.
Without all the settings enabled (disabling post and atmospherics), I get around 230 FPS.
With shadows and ssao and all the settings, I got 38-45 FPS while flying around.
Anti-Aliasing didn’t make much of a difference in FPS for me for some reason, normally it drops the FPS much lower than it should so generally disable it.
I was using fullscreen at 1920x1080 resolution on Windows 8.1.
Computer’s specs (Yes, it’s a laptop, MSI Dominator GT70 2PC):
CPU: Core i7-4810MQ
GPU: Nvidia GTX870M
RAM: 16GB
Overall, I have to say, really, really impressive work you have here, it’s truly amazing how good it looks, it’s comparable to AAA-terrain out there, and not to mention, they don’t even use procedural terrain.
With all the effects enabled with shadows and ssao, it’s still more than playable at 45 FPS.
Keep up the amazing work!
EDIT: Oh, and I forgot to mention, no Out of Memory errors over here, I was flying around for quite some time, the memory usage never went over 300MB max.
Wow. Shows what a better graphics card can do. With everything enabled (except SSAO) I get around 19-30 FPS these days.
And thanks for the kind words.
re: the OutOfMemory errors… you won’t really see them because the app keeps running. I should probably add some indicator that they are happening. Sometimes the app recovers but mostly this will manifest as missing terrain or an entire chunk of missing vegetation where there really should be vegetation. Though in all cases, eventually mine gets to the point where terrain stops updating at all… so you guys probably would have noticed something by now if you were experiencing the issue.
When I switch to instancing the memory issues will go away, though. I’ll even be able to keep all of the LOD levels around for free.
139-144 fps with standard setting @ 1920x1080x32
20-31 / 29 -49 with max setting
and if i rotate it drops to 21 fps
nice work!!! keep going 
I failed to run the latest demo for Linux using onboard graphics, expected as this one has an obsolete GPU. Looking to try it in my gamer PC (when my little bro stop abusing it).
The demo actually runs, and shows the statistics, for example FPS is around 50, but I cannot see the terrain, only solid colors. Initially I thought I was inside the terrain and needed to move backward or upward, but I concluded It was due to my obsolete GPU. Intel GMA X4500.
As I am very interested in procedural terrain and voxel maps I will be here for a while. Waiting for future updates.
Sorry it failed to run on your graphics (ahem) card.
I think the next major update will be instancing for the trees. I need to start actually using it in a game or get back to different projects.
I tried to keep the demo compatible with JME stable for as long as possible. The next update will likely be against trunk.
…at the moment I’m going some experiments with using the density field for super-simplistic collision detection… mostly so we can walk instead of fly if we want to. If that bears fruit then I may post an update with it prior to working on instancing.
Played with physics a little more tonight. Code still isn’t checked in but I made a video:
I can already imagine a character walking on top of that terrain. And with that come some ideas for a game.
I see the MeshGenerator interface has a method named buildMesh that returns a Mesh object. I didn’t found it yet but I think that mesh will in time go to a Geometry object. May be that you are building a RigidBodyControl using that mesh to create a CollisionShape? That is how I’m Physicallizing my terrain in my voxels experiment, using the Mesh object that results from decoding a chunk of the map, but your previous comment suggests you are doing something more complex than that.
Looks amazing with a NVidia GTX650 and Windows 7.