Irrlicht Engine

Hi,
sorry to ask this question again, but this time i do it explicitely, because in the past i got no answer.

I would like to move the world relatively to the camera. To maybe make things a little easier, without terrain (i don't know if terrain is a special case, but we can ignore it first).

I was thinking about creating a dummy scene node directly beneath root and then linking all objects to this dummy node. The camera would have to be a "special" camera which does not move/rotate but instead calculates the (inverse) transformation for the dummy node. Then all the rest should move/rotate accordingly. Would that be right or wrong or plain silly?

Another point would be to "link" this behaviour to a physics engine. With Bullet there is a way because there you can set the "world-center" and hopefully you are done with it. Maybe this even would be easier, because you FIRST tell Bullet to move/rotate all objects relatively and THEN you apply the results to each object in your scenegraph (assuming all objects are known to the physics engine).

Would be great if someone could help, preferably with small code snippets. And it would be even greater if this behaviour could be integrated into Irrlicht (as in Ogre - there it is a flag you can set and the rest is done by the engine). I have heard it's not without problems (e.g. animations) so probably it's not easy, but nevertheless i would like to understand the problem.

You might try adding the whole world as childs to the camera.
Can you tell why you want to do that? Maybe we have more ideas then.

Avoiding floating point errors on long distances (you know - my long awaited space game, hehe).

> You might try adding the whole world as childs to the camera.

Yes - but then i still would have to write my own camera controller to "backtransform" the world
around it, and i don't know how to link THAT to a physics engine.

By the way - Irrlicht is written with templates; would it be possible to compile it with "double"
instead of "float" or would it screw up everything? If yes, then why templates are used?
(I know there are some places where hard-coded parameters are used (e.g. 'epsilon' in
comparisons) but that could be corrected).

Using doubles everywhere instead of floats is probably not possible.

Maybe you don't need different distances at the same time? Let's say you want to move to planets - then you can use another coordinate system while on the way than you have when you get there. So basically you work with segments which are each near 0 and swap between them at some point.

Ahumpf - i never get a straight answer to this problem.
I am not interested in segments or other stuff, only keeping the camera in the center of my world.
Let's just say i want to UNDERSTAND it and how to DO it with Irrlicht.

You have a fixed camera then. So you don't have to think about camera code at all as it doesn't do anything special anymore except looking at the same point constantly. Instead you start moving around every node in the world. Which means you will have an additional transformation for all nodes. You can do that by adding a parent node and moving that basically in the opposite of your movement directions. Or you can do the same with your own matrix which you move/roate around and then transform all your nodes through that matrix each time you move. In terms of speed the matrix solution is probably a little faster.

> Instead you start moving around every node in the world.
Exactly!
But HOW?

> You can do that by adding a parent node ...
Yes - how about this damn DummyScenenode as a "root" to all objects in my world (what about the background?) which has no terrain but mainly spacecraft and maybe a planet and/or some asteroids to make things visually more interesting.

> In terms of speed the matrix solution is probably a little faster.
Why? A "root" node moving/rotating in the opposite direction would be more "elegant" and would automatically force all children to move/rotate accordingly (that's what a scenegraph is made for). In terms of 'number of calculations' it should be the same.

MAYBE there even is another way: with Bullet you can set the center or origin of your world. If all objects in your world are also Bullet objects (static or dynamic) you "only" have to shift that into the other direction, Bullet makes the calculations and you receive the results from Bullet and apply them to the Irrlicht objects. I don't know if this also works with rotation; if not, we can forget about this idea.

Sorry, you have to figure out the moving code yourself (moving is easy - moving and rotation while origin changes... would have to think about it and probably experiment a little).

The reason I suppose a matrix might be better in this case is that it sounds like you do all that stuff to avoid problems with large number ranges and floats. When using a root-node you still have those ranges as the relative positions of the nodes are not changen. So you likely don't avoid any problems (whatever the problems really are ... you didn't tell that yet). While with a matrix the nodes would now really be positioned around 0. So they have small numbers (matrix would be the only one with big numbers, but that probably doesn't matter).

Start simple, make a 2d side scroller game, in one version you move the camera by X, in the other version you move everything by -X.

Then make a "look around the sky box game". You just rotate by K degrees the box in one version, or you just rotate the camera by -K degrees in the other version. (around 1 axis only, multiple axis may cause unwanted problems)

This is just to get you a feeling of the problem: what the user see is the movement wich can be measured or from user point of view (camera) or from universe point of view.

You need of course to know how to move the camera in irrlicht and how to move the world (I assume you know that stuff, if not specify that). Then what you need is the inverse of the matrix of the camera transform.

What you need is the transform you "would apply to camera" (Roto/scale/translation), invert that matrix and instead of transforming the camera, transform the universe by that matrix.

note that AT SOME POINT YOU NEED TO CHUNK THE UNIVERSE IN SOME WAY (not because you are moving the universe instead of the camera, but because "FLOAT" is very limited for infinite universe) just forget using "double".

> You need of course to know how to move the camera in irrlicht
Yes,

> and how to move the world
NOOOOO!

THATS'S exactly the point and my original question.

Segments and chunks and whatever come later.

Ok here's the explaination, if you move the camera (camera is a ISceneNode), you also move ALL CHILDREN attached to that camera: try to make a camera looking from (0,0,0) to (100,0,0) and then create a Cube scene node position it at (50,0,0) and make it a child of the camera. You will see the cube always at same position on the screen when you move the camera because the cube is moved along with the camera, that's how a scene graph work (that's really basic stuff of irrlicht and many other 3d game engines).

In irrlicht you tipically have a Root Scene Node, camera is a child of Root, and also all other nodes. When a node moves, all its children move with him.
so you need
1 Camera scene node (make its parent the rootSceneNode)
1 Universe scene node ( an empty scene node, its parent is still the root ^^)

Every scene node that you want to move with the universe should just be a child of Universe scene node

AT THIS POINT you should try to make the simple games I mentioned before using always 1 Camera and 1 Universe (translation only and rotation only), and try to add children both to Camera and Universe and see what happens.

When you are comfortable enough and you understan what happens you are HALF way to make your game.

-----
Another solution is just to keep a LIST of all universe objects, and update manually their position from your code (wich is I would choose for a unlimited universe)

@REDDemon: I think he get's that part. What he wants is the reverse - camera still and moving the world. And that is indeed a little bit more tricky. I just gave it a quick try, but giving up now.

@AReichl: Only hint I have - it's probably a little easier when you save all original position for your nodes and work with that. At least that way you don't get errors which add up over time. I gave it a quick shot, but also couldn't figure out the rotations. And well .. coded already rather long for my day-job today, so giving up now. Translations work - but I guess you got that far yourself: http://pastie.org/10342604

NOW we are talking! Thanks to both of you. I always need a "quick start" to get going.
Like planing holiday - i never know where to go, but if my girlfriend chooses the target, i do the rest, hehe.

> 1 Universe scene node ( an empty scene node, its parent is still the root ^^)
EXACTLY what i had in mind. You mention an "empty scene node", but what about this ominous "dummy scene node"?
That's MADE for transformations.

> Another solution is just to keep a LIST of all universe objects ...
> it's probably a little easier when you save all original positions for your nodes and work with that.
Probably - specially because i am thinking about storing them as 'int' ( there is an interesting article about this problem with the title "if you use 'double' you have not understood the problem" ).

> At least that way you don't get errors which add up over time.
Have NOT thought about this problem yet.

I would like to mention that moving the origin of your world to reduce floating point problems is not bound to space games. Also on huge terrains it's used.

By the way - i have collected LOTS of articles about this problem.
If you are interested, i can try to find the links and post them here.

This one for example is a video that shows how they solved it in "Kerbal Space Program (made with Unity):

https://www.youtube.com/watch?v=mXTxQko-JH0

It's a combination of ALL techiques ( moving origin, segmentation, layers [= multiple cameras with different near/far values] and scaling of objects very far away ).

CuteAlien: what i would like to do is check all templates ( vector, matrix, quaternion, ... ) if they can be used for type 'double'. Not necessarily inside the engine ( that would require a lot of rework ), but outside of it. I already found some places where parameters are hardcoded ( e.g. epsilon for comparisons ), and of course and that violates the idea of templates. Would that be of interest for the engine?

I know you reported the the epsilon comparisons already. They are on my todo-list (together with > 100 other open tasks...). The other thing is - the templates generally describe the type used internally to save the variables. But the type used for the calculations is kinda undefined in Irrlicht. So sometimes we use the template parameter while at other times we use doubles. And in some places like getting normals for vectors with integers we really should have additional functions or have a function that accepts templates (returning a nomal parameter with <s32> never makes sense).

So maybe having template parameter per function to describe the internal type used for calculations and setting them by default to the template paramter used for the class might work (really haven't tried if that works...). But we should careful not to go completely overboard with templates or we end up with fat executables for all the different template instantiations (happens sometimes when working with boost...).