The video posted in another thread doesn’t seem to have these issues though, is the code I am using just out of date or something?
Also, on a slightly different topic, are there plans to be able to edit a terrain grid in the IDE so that objects can easily be placed on a huge large terrain but still have it split into manageable chunks? If not, is there a known trick for doing this sort of thing, aside from programatically placing all the assets?
Theres currently some issues with the GridTerrain, but most of them should be solved in the latest stable update for 3.0beta. Support for GridTerrain in the editor is planned as well, yeah.
Does that show the “issues” you expect? Not complaining of course, it’s beta after all, I just didn’t find anyone else mentioning it so I thought it was just me:)
Yea there’s a little bug with the LODControl when it interacts with TerrainGrid. I will try and fix it within the next few days.
I want TerrainGrid to be the default terrain implementation in the SDK/IDE, but there are tricks to it. In time it will get in there. As for grouping all objects to the grid, well you can look at TerrainGrid.java and see how it does it (although it might be a little confusing).
Support for GridTerrain in the editor is planned as well, yeah.
Awesome, thanks! btw I can recommend looking at how this is implemented in esenthel editor, it has a pretty neat way of allowing realtime editing of a giant terrain grid.
@monkeychops said:
I can recommend looking at how this is implemented in esenthel editor, it has a pretty neat way of allowing realtime editing of a giant terrain grid.
Thanks for the hint but we avoid looking at other tools too strongly to avoid going after a certain way of doing things which might not fit to jME3. Just "copying" another tool will never make the software better than that other tool (or only marginally) and going after whats there and needed in jME3 already brought us some interesting solutions in the SDK as well as the engine.
@Sploreg said:
Yea there's a little bug with the LODControl when it interacts with TerrainGrid. I will try and fix it within the next few days.
I want TerrainGrid to be the default terrain implementation in the SDK/IDE, but there are tricks to it. In time it will get in there. As for grouping all objects to the grid, well you can look at TerrainGrid.java and see how it does it (although it might be a little confusing).
This thread talks about paging geometry.
Wow, you guys have faster customer support than any commercial company :)
I think the large terrain thing is the last barrier on my team being able to choose JME3 for our project, so really great if you find a solution that works.
All of the changes would be in the SDK in the TerrainEditorController and TerrainEditorTopComponent classes. They mostly interact with the Terrain interface, so swapping out the type of terrain isn’t a big deal. What is needed is are new controls and tools around adding and removing grid tiles. The painting tools would have to be modified to write to different alpha maps, which are stored outside of the Terrain interface, so more work needs to be done with them to specifically work with grids.
The trickiest part is handling the “center of the map”. For “infinite” worlds the origin centers around the camera, for regular worlds the camera moves around. Changing it either way is a drastic change to how all plugins and components work in the SDK. I don’t think we will be having a fully infinite world editor, there are just too many gotchas and different ways to implement that. A fixed, but large, world we can do no problem.
As for loading spatials with the grid terrain (ie. bringing in other scenery as the terrain gets loaded when you move across the world), we would need to establish a core method for doing this, and I don’t see that on the drawing board. Again because there would be many ways to implement it and finding one way that would work for the most people is not realistic, and probably not the best use of our time.
There is a bit of a timing issue with this too. Adding TerrainGrid as the default terrain in the editor will probably have to be a 3.1 feature since 3.0beta as it is right now is largely feature-frozen to get it as stable as possible. That being said, an external plugin could be made to implement all of this without having rely on jme release versions.
@Sploreg: There is the AssetLinkNode, it could easily be used for this w/o saving all the data with it…
I generally agree though that a full “world editor” is not in the interest of the SDK, it would restrict the feature set too much, jME3 just is not “one dimensional” enough (like Unity) to accommodate for all the ways jME3 can be used. Maybe there can be specialized plugins for certain uses though. The API of the SDK is open (though still not final yet).
I see you have fixed the tearing issue in the latest updates… so cool!
Is there a way to increase the view distance so that it loads 2 tiles ahead instead of just 1? The terrain seems large but you can’t see distant hills until you reach them.
I agree with what you say about not restricting the focus of the engine too much, although I do think a good terrain is important and a key part of many games - in fact I can’t think of a single big-name game engine SDK that doesn’t have a terrain-centric editor. Even with the terrain mesh taken away, the ability to move through a large scene and have meshes paged in and out is going to be pretty useful.
For the game I’m making personally I don’t need an infinite terrain… it just has to be able to scale to a play area of a few kilometers in the world.
If not possible to implement an infinite terrain editor, I wonder if it could be possible to edit one tile at a time…cut the heightmap image into say 9 squares, then just draw the top left one in the editor. Lock the height map of the connected edges in the editor to prevent alignment issues when terraforming and it should be possible to edit the individual squares in exactly the same way and then they can join up in the grid. Better still, show the immediate neighbours also in the editor, but only the current square in the centre is editable until we switch the live square?
Anyway, for my game I am thinking of making a little purpose-specific editor which allows multiuser editing. If the TerrainGrid can provide the necessary hooks for editing the heightmap, splatting and persisting programmatically I am sure that would be sufficient for most users.
P.S. Thank you for all your hard work on this, you are creating so many exciting possibilities
Lets not call it “infinite”, but “very large” instead
Actually in the last day @normen has made great progress in adding more flexible serialization to TerrainGrid. I’m starting to plug it into the SDK, so soon there should be large world editing.
As for multi-user editing, this should allow that too. Although you could still overwrite each other’s tiles, you have to be careful to work in different areas and commit frequently.
