Moving world around camera performance options question

I am about to implement a “move world around camera” model on the client so that the camera is always at 0,0,0 translation and the world moves around it. I have two approaches and I am not sure which is optimal in terms of performance.

Approach #1:
When the camera moves don’t move the actual camera but keep the new location in a separate Vector3f buffer then take the root node’s translation and subtract the camera’s virtual position.

Approach #2: Since I already have an entity system and a separate control for each visible entity, store the camera virtual location like in approach #1 and in each entity’s control’s controlUpdate() method set the spatial’s translation with getSpatial().getLocalTranslation().subtractLocal(virtualCameraTranslation) … of course all entities will hang off of the root node.

Anyone know which is faster? I have a theory that approach #2 will be faster. If you have a better approach please let me know as well.

In JME, it’s technically most optimal to use a hybrid approach. (Not much more… but it’s also not harder to implement so why not?)

Given a world that’s divided into zones, let the camera move within the zone: camera.setLocation(playerLoc.subtract(centerZone.location)

Then when crossing a zone boundary, you already have to reset everything anyway so go ahead and move the zones’ roots. (You should have a root node per zone, after all.)

Whenever a node (or hierarchy) moves, JME must recalculate its bounding shapes. The overhead for moving the root node every frame is small but measurable. I’ve found it better to just do it when doing the zone shift. (I’m 99.9% sure this is what I did in my isosurface demo, also… but I definitely do it in the newer Mythruna engine. The old Mythruna engine, the public one, always has the camera at 0,0,0.)

@pspeed to the rescue again! Thanks for the cool way of doing it. Good thing I am already using your network code :wink: