Hacker News new | past | comments | ask | show | jobs | submit login

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



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.


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.


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.


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.


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.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: