undefined | Better HN

0 points0x014y ago0 comments

Yeah, looks like some kind of z-fighting issue?

0 comments

5 comments · 3 top-level

talmand14y ago· 2 in thread

If it runs in software without some sort of z-buffer then you'll get z-fighting. It's the same problem that's been around forever when running 3D in software. Hardware acceleration would help with this but I'm not up-to-speed on the current state of browser support for hardware rendering.

If there's interest in playing with such technologies then I suggest reading up on z-fighting because if you understand why it happens then you can attempt to work around it. There are lots of old tips and tricks that still apply today.

hkolek14y ago

It is my understanding that z-fighting occurs when the depth buffer has not enough resolution (due to floating point math). How is that related to whether it's hardware accelerated or not? You can easily get z-fighting with hardware acceleration.

talmand14y ago

Well, granted this is my experience, but if done properly you would rarely see this sort z-fighting in hardware acceleration. Usually when I saw that it was because of two surfaces trying to exist on the same plane regardless of orientation. Which I believe is what you are describing.

Thinking it over I may be incorrect in referring to this in the way I have. The issue I'm seeing is the back-to-front rendering (I'm assuming this is what the example is doing) of a smaller object being displayed on top of larger object and the renderer getting confused on the draw order.

Edit: ghusbands points out my confusion below

Granted, I'm not a 3D programmer but I built enough levels for 3D engines back in the day to have to be aware of these issues to design around them. This is all from memory so I could be totally off but this what it seems to me.

recursive14y ago

I was under the impression that z-fighting was a result of floating point rounding errors when two depth values are very close together. The clipping errors I'm seeing don't seem to be correlated with surfaces that are very close in depth.

ghusbands14y ago

There seems to be confusion in this thread, caused by this message. Z-fighting is specifically caused by very near, parallel/co-planar polygons having similar z values, which is not the observed issue with the page. The issue with the page is more akin to rendering using the painter's algorithm but sporadically sorting incorrectly.

j / k navigate · click thread line to collapse