Camera navigation far from origin

Started by mt_sabao, April 08, 2009, 09:31:10 AM

Previous topic - Next topic

mt_sabao

Ok, here comes another question ( ::) thanks for the patience), this comes as result of this project: http://forums.planetside.co.uk/index.php?topic=6030.0 but decided to post on a new thread because this might be easier for someone finding it in the future, as search didn't reveal anything.

ok, what happens is the following. I'm using a light source instead of the sun, which is placed at (0, 0 ,0), so my planet(s) are located very far from the origin. Now, if you notice, TG's camera navigation in the viewport is exponencial. When we mouse scroll close to the surface of the planet (by default at origin) the camera moves slowly, and then as one moves farther away, it moves in bigger amounts (which makes sense of course). But what happens now, is that i'm trying to navigate close to the surface of a planet which is far from the origin and i can't!  ??? am i missing something or this is impossible, due to the fact of being far from the origin the camera will always move in huge increments?
Thanks in advance
Luis



ps: for those wondering why i can't just put my planet close to the origin, is that i want to fly from on planet to the other, which is on the "other side" of the star. The only way i could do this is having a light at (0,0,0) and the planets in their correct positions as with a normal sun you can't have planets one "the other side" (outer orbits as regards to the planet i'm on).

Anyways, if all else fails, i can freeze my system and translate the coordinates of everything so that my planet sits at (0,0,0)  :-\

mt_sabao

arg this is driving me nuts. Started a fresh scene to test behaviour far from origin. default scene, moved planet to 6.378e+08 (original is 6.378e+06). Managed to move my camera close to the surface of the planet (it reads VHeight 7m) and this is what i get, left is default full render, right what i have in viewport...  ??? is this a bug, is this why it's hard to navigate close close to the surface while far from the origin?


mt_sabao

moved the planet back to the default location, and this is now what i have (well, unsurprisingly). again left default full render, right viewport...  :-\


cyphyr

I think your best bet here would be not to animate in terragen at all!
If you set up analogous planets in another 3d animation package you should have far greater control over your cameras movements and location. Then export the camera movement in a format that you can convert to a .chan file and import that file to your cameras motion channels. Of course this method allows no fine tuning in terragen, you'll have to go back to your initial 3d animation package for that but I think it would be worth it.
Good luck
richard
www.richardfraservfx.com
https://www.facebook.com/RichardFraserVFX/
/|\

Ryzen 9 5950X OC@4Ghz, 64Gb (TG4 benchmark 4:13)

mt_sabao

Quote from: cyphyr on April 08, 2009, 12:04:59 PM
I think your best bet here would be not to animate in terragen at all!
If you set up analogous planets in another 3d animation package you should have far greater control over your cameras movements and location. Then export the camera movement in a format that you can convert to a .chan file and import that file to your cameras motion channels. Of course this method allows no fine tuning in terragen, you'll have to go back to your initial 3d animation package for that but I think it would be worth it.
Good luck
richard

Hi Richard, thanks. Yes from what I've been reading it looks like that's what I'll have to do. But at this point I was just trying to setup my scene without any results... If can't even see thesurface of my planets far from the origin...

Matt

#5
It's not possible to render millimeter size details when you're hundreds of thousands of kilometres from the origin. This problem is not unique to Terragen.

Regarding camera movement, you can choose a new focus point by pressing the Pick Focus Point button and then clicking on a polygon in the 3D Preview. The Pick Focus Point button is labelled 'FP' in the Beta or has a target/sights icon in 2.0. Or you can activate this mode with Shift-F as long as the 3D Preview currently has focus.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

mt_sabao

Quote from: Matt on April 08, 2009, 11:10:04 PM
It's not possible to render millimeter size details when you're hundreds of thousands of kilometres from the origin. This problem is not unique to Terragen.

??? hm, bummer. But what does this mean exactly then, the level of detail you can represent decays with a function of distance to the origin or at some point it simply goes kaput?
Shouldn't there be a way to prevent this, or at least i mean preventing the mess you see in image above, some warning to the user maybe?

Quote from: Matt on April 08, 2009, 11:10:04 PM
Regarding camera movement, you can choose a new focus point by pressing the Pick Focus Point button and then clicking on a polygon in the 3D Preview. The Pick Focus Point button is labelled 'FP' in the Beta or has a target/sights icon in 2.0. Or you can activate this mode with Shift-F as long as the 3D Preview currently has focus.

Matt

Ok thanks Matt.

Matt

#7
It's due to the way real numbers are represented by computers using 'floating point' representation. You can represent very large values but you sacrifice absolute accuracy in those large numbers. There are ways to avoid this but they probably require more memory and/or longer render times.

There may be more efficient ways to deal with this more intelligently, e.g. by having the renderer re-center the scene automatically... but we haven't attempted it yet.

Many of the shaders also have problems with very large numbers - in fact this is a pretty difficult problem for us to solve completely.

The way to avoid this problem as a user is to decide in advance where you want the most detail and centre your scene around that point.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

chaps

Hello,
Matt's explanation is quite convincing. The consequence is that you shoul reverse the problem:
    keep the camera near the origin,
    move the planets and sun light during animation to simulate the camera movement

I never did any animation in TG, so I don't know how to do that, I guess that the better way should be to add the displacement nodes at the top of your planets and light network definitions.

Good luck,

Pascal.

rcallicotte

Decimal types are more accurate than floats, but then I guess this presents a problem.  Not sure how this is a problem, but maybe I don't have enough understanding to wrap around this.
So this is Disney World.  Can we live here?

neuspadrin

basically in some of the most recent patch notes:

Precision of values in .tgd and .tgc files increased to 10 signficicant figures (was 6).

So terragen is only accurate to 10 significant figures, then it starts to cut details.

What does this mean?

1234567891 is a possible number, but without any decimals you loose some detail from that.

12.34567891 is another possible number, but this time its close, but you get a lot more detail because you have so many decimal places.

what happens when you want to make something super big? it gets multplied by 10^something.

example:
123456789123456789123456789 in terragen (due to 10 sig figs) would be 1.234567891 * 10^17 = 1.234567891e+17.  now you may be going but you said decimals mean details, but the thing is these decimals arn't really details, not even really decimals, as that number is supposed to be multiplied by 10^17.  So basically, what happened is:
123456789123456789123456789
turns into
123456789100000000000000000

see the detail lost now in those 0's?

rcallicotte

@neuspadrin - I was talking about programming types.  Decimal is a more accurate type in C and C# than float.  Floats tend to lose their accuracy in high mathematical situations, some of which can happen when you render a scene in TG2.
So this is Disney World.  Can we live here?

neuspadrin

well same here, sig figs is significant with how the floating points are used.   it boils down to how floats are stored as binary in the memory and such, as floats are represented as a decimal multiplied by a power.


also, another idea on how to fix the problem.  perhaps instead of animating the camera during the between period, you animate the planet to move itself closer to the origin? its a tad bit tricker, but would allow you to get the same effect of the planet moving towards the camera as it would be camera moving towards planet, and thus able to move the low detail planet towards the origin and gain detail again.