Seems to be a Z buffer problem, somehow. I'm not familiar with what you're using there, though, so I probably can't really help.
Joey
2009-04-22 08:52:00
+1
A:
A:
Do you have multiple overlayed textures and/or polygons?
From here it looks like the problem you get when you have exactly coincident surfaces, but floating point errors mean that you don't consistently see the right one.
Alnitak
2009-04-22 08:57:56
Close... that was the problem I had half an hour ago!
Assembler
2009-04-22 09:02:02
Or duplicate polygons/vertices on the same exact spot, usually after copy/paste-ing stuff ^^
Oskar Duveborn
2009-04-22 11:53:03
+8
A:
We called it "z-fighting" - but a more common term is z-ordering or z-buffer problems.
I'll try and explain the problem without diagrams 1st.
3D renderers work by drawing the polygons from back to front. It does this by assigning each polygon to one of a discrete number of positions. This works for most scenes.
You get a problem when there aren't enough slots to be able to decide which polygon is in front of another.
To solve it - it will depend on your application, but there are a number of things which should be common to all:
- Make sure the bounding box of the world is as small as possible.
- Increase the colour depth of your display. Both OpenGL and Direct3D can tie the number of z slots to the resolution of the display.
- Increase the number/decrease the size of your triangles. Smaller triangles are going to be less affected by this - but will decrease the performance as there are more to draw.
If you are running on Windows you should set the desktop to the highest colour resolution. You application might pick that up as the default to use.
Can you switch between OpenGL and Direct3D rendering? If so then try both, one might give better results than the other.
ChrisF
2009-04-22 08:58:03
Assembler
2009-04-22 10:02:39
A better term is z-buffer problems. 2 might be independent of your modelling system - are you running on Windows? If so set it at the desktop level and see if that helps.
ChrisF
2009-04-22 11:26:54
I don't follow the talk about back to front at all ... If actually using a Z Buffer, there's no need to sort the polygons. The Z buffer will resolve for each pixel which polygon should be in front. Except when the difference between two polygons is too small, which is when you get Z fighting.
unwind
2009-04-22 11:35:07
The back to front drawing is how the z-buffer actually works. Nowadays this is all hidden in the graphics drivers, but when I started you had to know about these things.
ChrisF
2009-04-22 11:40:47
ChrisF answers this question as if PV3D uses hardware renderer, which is not the case. PV3D is a software renderer which exploits flash's architecture. There is no Z buffer, hence there is no Z fighting. Option 3 helped because it's a way to hide linear tex-mapping interpolation. See my answer to see it in action.
LiraNuna
2009-04-22 21:15:09
@LiraNuna - Fair enough - though as all other software renderers I've come across have used Z-buffers, I thought I was safe making that assumption
ChrisF
2009-04-22 21:19:55
Thanks! it's not quite actually the issue though, I think... with PV3D the materials have a precise:Boolean setting to work around this... I tried turning it on and off but the problem persisted.
Assembler
2009-04-22 09:36:00
You can see a demo of how to overcome this here: http://www.papervision3d.org/demos/LinearMapping/
LiraNuna
2009-04-22 21:09:25
Yeah this is a different issue, but also an important one when dealing with papervision.
Matt Rix
2009-08-11 15:50:15
+1
A:
Looks to me more like a decal that went wrong rather than z-fighting. Z-fighting usually has some jagged edges. The projection matrix for that particular triangle might be wrong (considering that the extent of the problem depend on the camera position).
grivei
2009-04-22 10:46:22