Lumberyard, like Unreal and CryEngine, is a team designed engine.
While it’s true that one person can make a game with them, it can take too long to have a game that uses a lot of the features the engine provides. When you have a team of developers with different skill sets (programmer, UI, 3D, art, design, etc.) things become way easier and projects work better.
Unity, on the other hand, is designed more towards one-man developers and small teams (with big teams things can get really ugly really fast if attention is not paid). The advantage offered is fast prototyping and little programming skills are required to make games. The disadvantage is that since it’s a monolithic system that runs many things that you may never need in your game, the games can become resource hogs fast no matter how efficient your code is.
I learned my lessons that there is always a catch with “AAA” engines.
64bit double? are you serious? It is pretty much irrelevant. If you need that precision your doing it wrong. And well adding it won’t fix much either. Non linear rounding errors are still going to bite you if they are already an issue with single precision.
If you want large worlds you do something like the rather old java3d did. Have a base and offset.
Well, an argument could be made for JME doing transforms in double so you could get away with local offsets.
As it stands, the only approach available for large worlds is to render everything camera relative and therefore build your offsets into your locations before handing it to the scene graph. If we did transforms in double then you wouldn’t have to do that… you could partition your world and have everything local to those nodes. The transforms would take care of making camera-local floats for you as part of the regular view transform.
But really, everyone’s performance would suffer for this… especially android I think. (In desktop Java, it’s not too bad actually.)
Anyway, camera-relative world views have a half dozen or so other benefits so in general its worth doing anyway… then the double thing doesn’t come up.
Is there a TestCameraRelativeWorldViews.java or similar? I’m really interested in this because I soon will start my next Planet-project and thus am very interested in this large-worlds-stuff. I’m sure there are some tutorials somewhere on the web. But if anybody has a good tutorial or even jME code - Ogli would be happy…
I doubt that it’s particularly easy to encapsulate well into a single class test case.
The general idea is that your game world is actually in double and that you are only constructing a nearby view for the particular player. When you construct that nearby view, you just make all values relative to some local origin (sometimes the camera). You move the world around the camera instead of moving the camera in the world.
For paged grids (whether 2.5 D or 3D), I tend to opt for a hybrid approach where the camera moves within its grid cell but the grid itself is always relative to that camera cell. JME is less efficient if you move the root node every frame so it’s better to only do that when you cross the grid boundary and have to reset all the surrounding cells anyway.
