camera and large worlds

[Granyte]

In my aplication i have a VERY large world for now i use a scaling where 1 irrlicht unit = 1 KM now the issue seem to comes from the near value wich cause several item to seem like cut in half when they are to close from the camera

now i tryed to play with the setnearvalue() function but no avail except causing some serious zfighting issue it does nothing usefull

any one has an idea how to fix this or where the issue comes from so i can dig to fix it

[REDDemon]

That's the correct way. Every 3D game will clip items wich are partial nearest than the near plane (see Frustum view examples on the net). There's no point trying to resolve that. a screen shot is needed if that's not your problem. Only possible way is to try to keep the camera far from that items (because keeping items away from the camera will move them.. still possible to do also if it is unsensed ).

[Granyte]

ya i know that normaly it's an expected featur only the issue is that the near plane seem to be 3-4 units a head of the camera and as such cut many many items in half in my application where the camera will sometime be 0.001 unit from an item and expect it to be rendered properly

so that's why i played with the near value but it did not give me a proper result

[CuteAlien]

Do you mean it already clips objects before they reach the near plane? As REDDemon said - please make a screenshot to describe the problem.
And yeah, z-fighting depends on the distance between near- and far-clipping planes and will especially get worse if you give the near-plane a very short distance. Just try not to let your camera get that close to objects (give it a larger collision radius).

[Granyte]

this image preatty much sums the issue and why i though the problem lied with the near plane wich is probably by default at a value like 1 the problem is that the way my world is scaled many object will be at 0.001 unit from the camera hopping to be rendered properly because 0.001 is actualy one meter away from the camera

[CuteAlien]

Hm yeah - sorry but extreme close distances for camera to objects + extreme large distance between near and far plane is a problem in today's 3D hardware. One value affecting the z-clipping is SIrrlichtCreationParameters::ZBufferBits, I have never experimented with that but you could try a 24-bit or 32-bit depth-buffer there. Still - try to make your near-buffer as far away as possible to remove z-fighting problems. Maybe you can adapt the planes based on the height of your view? So you could look very far when heigh-up (where close polygons shouldn't be) and clip earlier when near the floor.
Or you can fake the stuff that is extreme far instead somehow (render some mountains in a texture used for the skybox or something like that - not really sure what the commonly used trick here is - take a look at a few other similar games and try to figure out what tricks they use, you can often see that stuff once you know what you're looking for).

[Granyte]

most of the similar games use a logarithmic zbuffer to avoid these issues i will need to try to build one at some point in the future but i though i should try to figure the near plane issue befor

after trying to set the zbuffer to 32 bit i went on and tryed to make the camera near plane 0.001

Code: Select all

camera->setFarValue(249598.0f);
camera->setNearValue(0.001);

and here is the od result the planet is completely gone



EDIT: i forgot tthe "f" at the end of 0.001f


EDIT2: it works up to 0.01f but 0.001f just give me a blank planet

also at this point there are zfighting issue .... with the skybox anyway that's not really important i just don't get the planet gone issue


EDIT after a good read on zbuffers it would seem that since irrlicht does not suport dx10 i just ran my self into a wall because there is no way to manipulate the Zbuffer all the work is simply done in the fixed pipline

[Mel]

The problem with the ZFight comes mainly from the near plane value. The best thing you can do with it is to keep the near plane set to 1, and modify, mainly, the far plane. If you are using the SVN version of Irrlicht, there is a matrix4 method that allows you to build a projective matrix that sets the far plane at infinite.

[Granyte]

thanks for the sugestion i just put the values back to an other scale so that 0.1 is a meter so for now i can handle having my camera cutting 10 meter but i'm encountering crashes that i can't explain the debuger goes into assembly so i guess it's bullet physic not liking the uber hudge numbers


after some one finaly explained me how to build bullet in double precision mode i got it to partialy work

and yet again that only to slam my self in an other wall since it seem that because irrlicht use 32bit floating point even if bullet is able to perfectly handle the amount of precision irrlicht cannot display it correctly


right now i get zfighting artifact even really close to the camera(with the near plane at 1) and my various object seem to be jumping around because irrlicht trunc the precision from bullet when displaying i guess i'm starting to understand why no one wanna use realistic scale when using planets in game

[ACE247]

Generally I'd say 1 Irrlicht unit to 1Kilometer is a bit extreme!
I use 1 Irrlicht unit as 1 meter and I haven't had any problems so far, even with seriouly large scenes and Bullet Physics.
You'd propably be best of rescaling everything.

[WaxyChicken]

I'd like to second what Ace247 has said.

My project currently has a 500,000 unit map (500k x 500k)
i have 1irr unit = approx 1 foot.
so the map is (500000 feet = 94.6969697 mile ) approx 100 x 100 miles.
or
(500000ft = 152.4 km) = 152.4x152.4

no problems.

You may consider doing the following:
1 - slightly larger scale (like 1ir unit = 1DM or 1ir unit = 1M)
2 - compensate the distance
3 - when best results are found for clipping distance on the far plane then learn the fog tricks to hide rough cuts at the distance.

[Granyte]

what i mean by large world is that i have a full solar system in one single scene that's why i can't use any units smaller then km for 1 irrlicht unit using larger units mean a single planet would cause zfighting issue because it require the far plane to be way to far only to have a decent rendering from orbit


for that reason using fog does not solve the issue cause it would mean far away worlds would be covered in fog wich kinda break the idea of building a planet renderer in the first place


maybe i can get way with 1 irrlicht unit to be 100 meter but 1 irrlicht unit be 1 meter that's not likely to work

[ACE247]

You're making it to real scale????
SO Mars is like ~300million km away???
You'd be best of having a limited geometry reander distance and then from a certain range just replace it with a billboard impostor entity at infinity distance as if it where part of a skybox(You probably use a milky way star map skybox for the background?)

[Granyte]

i'm actualy thinking about reducing the distance between planets by 10 if not 100x cause curently all that distane is not doing any good but ya if i can i'm going for real scale

but ya billboard impostor are planed and ill attack it if i can just fit one single planet propely in the renderer

edit after givig a shot at a couple test and i tough what if i was doing it all wrong what if the renderer never needed to actualy needed to have anything in the same coordinate space as the physic engine what if i could use a coordinate space centered around the camera to minimize the floating point issue around the camera so ill give it a go and see how well it does

[Granyte]

sorry for double post but is there a proper way to obtain a matrix that would convert world coordinate to the local coordinate space of a object like a camera?

i know that when setting shaders we can call

Code: Select all

core::matrix4 invWorld = driver->getTransform(video::ETS_WORLD);
                invWorld.makeInverse();

but i guess that this is only valid in the shader constant setup