Rendering artifacts?
by Bill Vee · in Torque Game Engine Advanced · 04/30/2008 (8:31 pm) · 17 replies
I didn't have this problem in 1.0.3.
The view distance is set to 70000.
Close up to the terrain everything looks fine but when at a good distance strange artifacts appear.
The odd thing is if the editor is open it renders correctly.
The only thing in the scene is the atlas terrains and the watersphere.
I have tested against the waterblock as well and it produces pretty much the same effect.
This is an image with the editor closed.
This image is with the editor opened.
This video shows how it appears with and without the editor opened.
I tried stepping thru the code to see exactly what happens when the editor is opened but after an hour I just ended up with a headache.
Anyone got an idea why it looks fine with the editor open?
The view distance is set to 70000.
Close up to the terrain everything looks fine but when at a good distance strange artifacts appear.
The odd thing is if the editor is open it renders correctly.
The only thing in the scene is the atlas terrains and the watersphere.
I have tested against the waterblock as well and it produces pretty much the same effect.
This is an image with the editor closed.
This image is with the editor opened.
This video shows how it appears with and without the editor opened.
I tried stepping thru the code to see exactly what happens when the editor is opened but after an hour I just ended up with a headache.
Anyone got an idea why it looks fine with the editor open?
#2
I tried every thing in that post just now except the code mod.
I will try the code mod when I get a chance.
05/01/2008 (3:39 am)
No luck.I tried every thing in that post just now except the code mod.
I will try the code mod when I get a chance.
#3
The artifacting appears to be a z-buffer problem of some sort.
Obviously something is getting turned on/off when the editor is opened then turned off/on when it is closed.
05/01/2008 (6:28 am)
I only had a few minutes to read the thread before going to work but it appears the code mods mentioned have already been made by 1.7.0 release.The artifacting appears to be a z-buffer problem of some sort.
Obviously something is getting turned on/off when the editor is opened then turned off/on when it is closed.
#5
Struggled with what was the problem till 12:00am then went to bed.
5:30 am got up read post, kinda made since about DRL and Bloom , tested them, didn't help.
When I scanned the thread you posted I seen there was code and assumed it was something to try.
Made the first reply and hurrided off to work.
I later read the thread completely and seen I had made a false assumption.
Other than DRL and Bloom something else is happing as well when the editor opens/closes.
FSAA makes no difference either.
05/01/2008 (10:36 am)
I figured that out later, thats what my second reply was about.Struggled with what was the problem till 12:00am then went to bed.
5:30 am got up read post, kinda made since about DRL and Bloom , tested them, didn't help.
When I scanned the thread you posted I seen there was code and assumed it was something to try.
Made the first reply and hurrided off to work.
I later read the thread completely and seen I had made a false assumption.
Other than DRL and Bloom something else is happing as well when the editor opens/closes.
FSAA makes no difference either.
#6
05/01/2008 (10:49 am)
That certainly seems like a bug. I will look into this and see what I can find out. Thanks! 
#8
You are on the right track here. When you open the editor it changes your visible distance (usually to something farily short by default). A lower visible distance will increase the precision of your z-buffer since it has less distance to test against in its 32-bits of data (btw...make sure you are running in 32-bit mode) which in turn helps with the z-fighting that is occurring with your polygons.
My recommendation would be to also lower your visible distance (Sky) in the actual mission to match the results you like in the editor.
05/01/2008 (5:37 pm)
Quote:
The artifacting appears to be a z-buffer problem of some sort.
Obviously something is getting turned on/off when the editor is opened then turned off/on when it is closed.
You are on the right track here. When you open the editor it changes your visible distance (usually to something farily short by default). A lower visible distance will increase the precision of your z-buffer since it has less distance to test against in its 32-bits of data (btw...make sure you are running in 32-bit mode) which in turn helps with the z-fighting that is occurring with your polygons.
My recommendation would be to also lower your visible distance (Sky) in the actual mission to match the results you like in the editor.
#9
Due to a typo I set the view distance for the editor unbelievably high
$pref::Editor::visibleDistance = "700000";
in my Sky the visibleDistance = "70000";
If I set them to the higher 700000 I get no visible difference.
Same if I set it to the lower 70000.
I assume you mean 32 bit depth. If so it is set to 32.
$pref::Video::BitsPerPixel = "32";
It still has the same artifacts while not in the editor.
As a matter of fact while in the editor it seem to render a whole lot "cleaner" on large objects at a long distance.
BTW . I tested the 700000 visibleDistance to see if it is rendering out to that distance.
I got so far away from the planet it appeared to be a dot made of just a couple of pixels.
The whole time while in the editor no artifacts appeared.
05/01/2008 (9:03 pm)
@Matt FairfaxDue to a typo I set the view distance for the editor unbelievably high
$pref::Editor::visibleDistance = "700000";
in my Sky the visibleDistance = "70000";
If I set them to the higher 700000 I get no visible difference.
Same if I set it to the lower 70000.
I assume you mean 32 bit depth. If so it is set to 32.
$pref::Video::BitsPerPixel = "32";
It still has the same artifacts while not in the editor.
As a matter of fact while in the editor it seem to render a whole lot "cleaner" on large objects at a long distance.
BTW . I tested the 700000 visibleDistance to see if it is rendering out to that distance.
I got so far away from the planet it appeared to be a dot made of just a couple of pixels.
The whole time while in the editor no artifacts appeared.
#10
Your visible distance should be no more than 2K-3K else you'll get the z fighting with the water surface.
This is a general problem with 32bit zbuffers... there just isn't enough precision for extremely far view distances. You must use tricks to hide the artifacts and fake the long distance.
05/02/2008 (3:19 pm)
700000 is a crazy number... it probably is ignoring it somewhere and defaulting to something else internally.Your visible distance should be no more than 2K-3K else you'll get the z fighting with the water surface.
This is a general problem with 32bit zbuffers... there just isn't enough precision for extremely far view distances. You must use tricks to hide the artifacts and fake the long distance.
#11
Ok that makes perfect since.
The thing that still got me confused is why it looks the way I want it to when the editor is open.
The only thing I could find is in
smVisibleDistance is 700000 and the nearplane will equate to 140.
Which explains why when in the editor anything close to the camera gets clipped.
Is the nearplane the reason why there are no render artifacts while in the editor?
I also tried setting the sky's view distance as low as 10000 and well before the planet gets clipped the artifacts appear. As a matter of fact they appear well before you get the whole planet in frame.
I don't necessarily need the watersphere but I was using it as a basis for an atmospheric shader effect and it seems I won't be able to go that route now.
Just to recap the z fighting that is happening is basically the engine trying to determine which object should get rendered first.
So if the watersphere code were to be integrated into the atlas render code then the 2 meshes,1 for terrain geometry and 1 for atmosphere/watersphere, would not exhibit this z fighting behavior no matter the viewdistance?
05/02/2008 (7:36 pm)
@TomOk that makes perfect since.
The thing that still got me confused is why it looks the way I want it to when the editor is open.
The only thing I could find is in
bool EditTSCtrl::processCameraQuery(CameraQuery * query)
{
......
GameConnection* connection = dynamic_cast<GameConnection *>(NetConnection::getConnectionToServer());
if (connection)
{
if (connection->getControlCameraTransform(0.032f, &query->cameraMatrix))
{
query->farPlane = getMax(smVisibleDistance, 50.0f);
[b]query->nearPlane = query->farPlane/5000.0f;[/b]
query->fov = mDegToRad(90.0f);
......smVisibleDistance is 700000 and the nearplane will equate to 140.
Which explains why when in the editor anything close to the camera gets clipped.
Is the nearplane the reason why there are no render artifacts while in the editor?
I also tried setting the sky's view distance as low as 10000 and well before the planet gets clipped the artifacts appear. As a matter of fact they appear well before you get the whole planet in frame.
I don't necessarily need the watersphere but I was using it as a basis for an atmospheric shader effect and it seems I won't be able to go that route now.
Just to recap the z fighting that is happening is basically the engine trying to determine which object should get rendered first.
So if the watersphere code were to be integrated into the atlas render code then the 2 meshes,1 for terrain geometry and 1 for atmosphere/watersphere, would not exhibit this z fighting behavior no matter the viewdistance?
#12
Yes - your zbuffer is not linear. In truth, it's not really even a z buffer - its a "Z/W buffer". Because of this design it has much more precision close up, and precision drops off the farther out you get. Pushing your near plane out (even by a few units) will significantly increase the precision farther out.
It's always a good idea to push your near plane out as far as you can without causing clipping issues.
05/02/2008 (8:30 pm)
Quote:Is the nearplane the reason why there are no render artifacts while in the editor?
Yes - your zbuffer is not linear. In truth, it's not really even a z buffer - its a "Z/W buffer". Because of this design it has much more precision close up, and precision drops off the farther out you get. Pushing your near plane out (even by a few units) will significantly increase the precision farther out.
It's always a good idea to push your near plane out as far as you can without causing clipping issues.
#13
Well after messing around with GameProcessCameraQuery and adjusting query->nearPlane I see what you mean.
Setting it to 1.1 instead of 0.1 made all the difference.
Setting it to 10 virtually remove the artifacts at most distances but as expected objects near the camera were getting clipped.
Even though this adjustment fixes my long range problems it is unacceptable as far as gameplay is concerned.
I think I will have to try something else.
05/02/2008 (9:37 pm)
@ Jaimi McEntireWell after messing around with GameProcessCameraQuery and adjusting query->nearPlane I see what you mean.
Setting it to 1.1 instead of 0.1 made all the difference.
Setting it to 10 virtually remove the artifacts at most distances but as expected objects near the camera were getting clipped.
Even though this adjustment fixes my long range problems it is unacceptable as far as gameplay is concerned.
I think I will have to try something else.
#14
Not sure how applicable this is to your project. But it seems your issue is when your at planetary distances. So just make the distant planets render first with a near clip of 100 or whatever... then render everything else with your ideal tight near clip distance.
05/04/2008 (12:56 pm)
@Bill - An old trick is to render stuff that won't get really really close first (usually the environment), then change the near clip to 0.1 and render the really close stuff (the player model). Not sure how applicable this is to your project. But it seems your issue is when your at planetary distances. So just make the distant planets render first with a near clip of 100 or whatever... then render everything else with your ideal tight near clip distance.
#15
How would that work when I go from far away to up close to the planet?
I would need to get close to the planet so I would need to be able to change the nearplane on the fly.
See if this pseudo codes looks right.
camera.distance is just a variable showing the distance from the camera to the planet.
05/04/2008 (3:43 pm)
@ Tom - Hmmm... Thats an interesting idea.How would that work when I go from far away to up close to the planet?
I would need to get close to the planet so I would need to be able to change the nearplane on the fly.
See if this pseudo codes looks right.
GuiTSCtrl *tsCtrl;
tsCtrl = dynamic_cast<GuiTSCtrl*>( Sim::findObject("PlayGui") );
CameraQuery query;
tsCtrl->processCameraQuery( &query )
if(camera.distance>9000)
{
GFX->setFrustum( mRadToDeg(query.fov),
F32(resolution.x) / F32(resolution.y ),
query.nearPlane, query.farPlane );
}
else
{
GFX->setFrustum( mRadToDeg(query.fov),
F32(resolution.x) / F32(resolution.y ),
[b]140[/b], query.farPlane );
}camera.distance is just a variable showing the distance from the camera to the planet.
#16
Your code above should work fine for a single planet.
The best fix would require some rearrangement of the the main rendering loop. You would need to split the visible objects into two lists... the near object list and the far object list. Render the far objects with the larger near clip, then change the near clip and render the near objects. Objects moving from one list to another shouldn't suffer any visual differences. As long as you render the closer objects last you shouldn't need to clear zbuffer.
05/05/2008 (7:59 am)
When you change the near plane you shouldn't see any visual change in rendering (that is unless something is clipping against it). So changing it on the fly should be just fine.Your code above should work fine for a single planet.
The best fix would require some rearrangement of the the main rendering loop. You would need to split the visible objects into two lists... the near object list and the far object list. Render the far objects with the larger near clip, then change the near clip and render the near objects. Objects moving from one list to another shouldn't suffer any visual differences. As long as you render the closer objects last you shouldn't need to clear zbuffer.
Torque Owner Redacted