Many games need to have a world larger than what float precision can reliable provide. One way to handle this with JME is to use doubles instead and then adjust the world around the camera and keep the camera at 0,0,0. I think that an AppState (in the JME core) that could handle this would be useful. I don’t want to go through the effort of writing this if there is very little interest, however. If there is interest I intend to submit something like this as a pull reqest.
I think it could work something like this (please provide feedback (especially on the class names)):
public void simpleInitApp(){
LargeSceneGraphAppState sg = new LargeSceneGraphAppState();
sg.setViewDistance(16384); //any scene graph objects further than this are not rendered -- it is recommended that fog be added
stateManager.attach(sg);
Geometry geometry = new Geometry(/*...*/);
//configure geometry material, etc. here
geometry.setLocalTranslation(0, 0, 0); //items in the LargeSceneGraph must be at 0,0,0. LSGSpatials and LSGNodes are used to move it to other locations
LSGSpatial wrapper = new LSGWrapper("ExampleSpatial", geometry); //acts as a wrapper for a spatial but supports doubles
wrapper.setLocalTranslation(new Vector3d(8192, 0, 8192)); //Vector3d is just like a Vector3f except it uses doubles
LSGNode node = new LSGNode("ExampleNode"); //LSGBatchNode may also be available, LSGNode extends LSGSpatial
node.attachChild(wrapper);
sg.addLSGSpatial(node); //an unlimited number of nodes may be added, LSGSpatials may also be added directly
sg.setCameraPosition(new Vector3d(8192, 3, 8192)); //the "real" camera is always kept at 0,0,0
}
I don’t agree with this. I was mainly writing it with a Minecraft-type game in mind. It would be easy enough to have a Chunk object that then adds and removes LSGSpatials as needed. Using such an AppState would remove the need for the programmer to worry about tranasforming these Chunk spatial locations each frame (or when a player crosses a chunk boundary to improve performance – something I would almost certainly implement if I were to make this).
That being said, if there is some way to make it less game-specific I would probably be willing to write that as well.
Thanks for the link – but I haven’t gotten to the point to switch my game over to doubles. I am, however, nearing it so I’ll definitely keep your library in mind.
But the player will already be managing the chunks immediately around the player… it’s just a setLocalTranslation() call to move them.
I have lots of code that works this way and none of it needs to be double aware except the actual game objects and the code that generates the chunks. Everything is in float after that.
…and for game objects, their position is interpolated and is zone-relative… which just happens to coincide with chunks.
JME doesn’t need to include every single thing any developer anywhere might want. It’s called “feature bloat”.
From what I understand “feature bloat” is only bad if it uses extra resources (which this wouldn’t unless it was being used, which any developer implementing it themselves would consume anyway) or it makes maintaining the project significantly more difficult (which it doesn’t since it would mostly be a collection of setLocalTranslation() calls and math, both of which are very unlikely to change and would cause much bigger issues if they did).
Extra code is always an extra maintenance burden… and really how hard is the math?
float xChunkRelative = (float)(xd % gridSize);
…slightly more logic if you need to support negative coordinates.
I will note: Mythruna (the public release) is float-based even at the game object level… though everything is positioned relative to the local node for the ‘chunk’… it all works plenty fine out to 1 million meters. Physics starts to get squishy at 60,000 meters or so. At 1 million meters you can’t even move.
…but rendering was never an issue.
Each zone manages the objects in it and they create the nodes relative to the zone’s root node. Cross a boundary just adjusts the zones’ root nodes (there are only a few). Object movement does math similar to the above to find the chunk relative location. Basically, one small static utility method.
The new engine doesn’t even need to do this because physics itself is done zone-relative and all updates are pushed as zone-relative floats. It’s waaaaay better.
Has there ever been an issue with players going out this far during normal gameplay or is this something you calculated or discovered via some sort of teleport command?