I think this is the SDK getting confused. If you turn off “compile on save” then ant will always build them and then you shouldn’t get these errors.
The SDK’s built in compiler really sucks and somehow gets very confused. Sometimes it will also generate bad code so I always instinctively turn it off now.
Edit: I mean that the SDK will show you the errors but if you turn off “compile on save” in the compiler settings for your projects then at least you can build and run from the SDK. The editors will just show erroneous redlines on some things that they clearly inherit from their base classes but somehow don’t realize they have.
Thanks, after a lot of playing around with the code and other modules I agree, and will try it that way.
I’ve got a nice-looking version of this running using Simplex noise as a heightfield rather than the full 3D noise function you are using. It gives a more minecraft-y look, but smoother. I’m happy to share it if you want - the Simplex noise code is public domain from the creator, Stefan Gufstason. I’m struggling with figuring out what your code would like to see as a density for ‘above ground’. Basically my density function returns this:
so that if the location is greater than the noise function I return a very ‘undense’ value, otherwise I return the density function. This works great in free-flying mode, but when I try to walk around the terrain I’m getting interpenetrations and lots of bad behavior. Any insight into the correct way to make this density function behave?
In reverse order:
-your screen shot didn’t work. I guess it’s better if you use a proper image hosting service like imgur so that you can avoid landing pages.
-the value can kind of be thought of as the distance inside the surface or whatever… where 0 happens to be the ‘surface’. So it gets higher as you go in and less as you go away (unless I have that backwards but I don’t think so). If your noise represents an elevation then just return noise - loc.y
-I also use a heightmap style fractal (it’s a layering of a few fractals and is the same basic set that I use for Mythruna in fact) for the frog game I’m working on posted about elsewhere (but not open source).
Thank you Paul. I’m new to JME, your own libraries, as well as this forum so some teething pains are still happening. I’m very appreciative of all your hard work getting this together and open-sourcing the content. It makes excellent learning material!
I’ve got my own version of your code running well and am going to slowly try adding features of my own to it. In no particular order I want to get these basics running and had a question on the first one in the list that I think will help with many of the other items:
Deformable terrain (the obvious ‘dig’ and ‘build’ options). This seems very straightforward and I’ve implemented a dig method based on raycasting from eye to terrain. I’m starting by caching changes to the density function within my own density volume and returning those changes instead of the density function’s own values. In principle I think this should work though it might be more efficient to modify the pre-built chunks themselves. In practice I’m struggling with how to re-build the landscape and colliders, etc. on-the-fly. Where in the Pager or IsoTerrainZone is the right place to insert this rebuilding process do you think? It also seems a little dicey to rebuild the terrain the character is standing upon along with children (grass, trees, etc.) in a separate thread. Seems like it may need to be a blocking call. Is this even feasible to do fast enough if there is a lot of building going on?
Cleaned up code and more efficiency for more features - flowers, different trees and bushes, etc. Right now creating these are a pretty big performance hit as well as a hassle.
Incorporate simple new creatures, pathfinding, and AI.
Voronoi noise for creating varying biomes
Pickable terrain - the intent is to select lines or squares of terrain across the landscape with the mouse for future deformation (think zoning in SimCity)
Noise(?) zones for differing materials and differing levels - sand near the water’s edge, etc. This could be handled with the trilinear material generation, but I’d like to have actual digging yield actual rock, sand, etc. for re-use later.
Serialization/saving - Do you have a view on whether (using your code approach) it is better to save any pre-created chunks or just to let the system rebuild them from scratch using the density function and any user-created changes? In practice this is pretty low priority.
I will probably eventually cache the blocks in my own games but I try to see how far I can get without it because I think it’s cleaner and safer overall.
I haven’t implemented rebuilding yet in the pager but it is on my to-do list. Since the zones can now self-rebuild as the view moves, the hooks should all be there… it may just be a matter of exposing the right method.
For the “clutter” (trees, rocks, plants, etc.) in my own game, I ended up having one paging layer that just generates the placement data that other layers use. So it generates all of the clutter, makes sure they don’t overlap, etc. in a terrain mesh accurate way… then other layers like a grass layer, tree layer, etc. are their own child grids that have the clutter grid as their parent. This lets me chop them up into different sizes. So the clutter grid uses the same grid spacing as the terrain grid but grass uses a much smaller one (with only 1 zone border around) while trees use a larger one with LOD and rocks use something in between those.
Plants and flowers will be done similarly. For my approach, biomes would be an input to this clutter generation layer as part of clutter selection.
I’ve also implemented a better density collider that actually reconstructs the triangles to provide triangle accurate collision info (for spheres, though it could be extended). I will likely contribute that back when I’ve hardened it a bit more.
Thanks Paul. I’m reverse-engineering the Pager and Zone code and it’s a tough slog. It seems as though to implement deformable terrain the following needs to happen:
I get back a mesh object from the eye->raycast hit test. The mesh objects of name ‘landGeometry[x][y][z]’ are the specific targets for deformation.
From a mesh I need to find my way to an actual Zone object that needs to be rebuilt. In practice this may be too slow and painful to redraw. Maybe the mesh needs to be manipulated directly, but this seems problematic for a number of reasons.
Getting the zone relating to a mesh is the tricky bit. Nothing is exposed in the IsoSurfaceDemo besides the TerrainState and the Builder. I also exposed the Pager and ZoneFactory in TerrainState, but neither has the data I need encapsulated. Beyond that, it’s quite hard to drill into either of these and retrieve any useful land information in a systematic manner. As you noted, there is no exposed interface for this, and I’ve been hard-pressed to find something to expose in PagedGrid that would provide what I need, starting from a mesh.
You need to deform the density field. The change of the density field then needs to propagate up. It’s not about zones when you make the change because that ‘voxel’ that you are changing could belong to up to eight different zones or even none at all (if it’s not currently in view for some reason). This implies that there is some kind of change notification thing needed… where changes to the density volume notify listeners, perhaps based on location. (though frankly there aren’t that many zones active at one time so it may be ok to have them ignore changes that don’t affect them).
Yeah, deforming the density field (basically overriding its return value from a cached array) was the first thing I did, but the part about it propagating up is tricky - I don’t know how to trigger a propagation. I’ve tried to remove and rebuild the local world cell to no effect, but it’s still early days.
Anyway, here’s a screen shot - looks lovely so far.
Congratulations to the author one of the most beautiful scenes ever seen …
I tried to run code but give error console line 180 in Main… new ScreenshotAppState("", System.currentTimeMillis())
no suitable constructor found for ScreenshotAppState(String,long)
constructor ScreenshotAppState.ScreenshotAppState(String) is not applicable
(actual and formal argument lists differ in length)
constructor ScreenshotAppState.ScreenshotAppState() is not applicable
(actual and formal argument lists differ in length)
@GluckOs said:
Congratulations to the author one of the most beautiful scenes ever seen ..
I tried to run code but give error console line 180 in Main..
new ScreenshotAppState("", System.currentTimeMillis())
no suitable constructor found for ScreenshotAppState(String,long)
constructor ScreenshotAppState.ScreenshotAppState(String) is not applicable
(actual and formal argument lists differ in length)
constructor ScreenshotAppState.ScreenshotAppState() is not applicable
(actual and formal argument lists differ in length)
That code must be written against a newer (unreleased) JME, I guess… or at least that class. I tried to build everything against the release version but I think I’d already hacked that class locally to actually be useful and not overwrite previous screen shots all the time. I should fix it but I don’t have time right now.
@pspeed said:
That code must be written against a newer (unreleased) JME, I guess... or at least that class. I tried to build everything against the release version but I think I'd already hacked that class locally to actually be useful and not overwrite previous screen shots all the time. I should fix it but I don't have time right now.
@pspeed said:
In the mean time, if you are super-motivated, you could check the project out and try to build it yourself (without that line or whatever).
I’m trying, but I’m new in jme3 but I program for 4 years. I am having difficulty…
I do not know if I can get results… maybe too advanced for me
