5 ms·
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. H
by talmand 15y ago
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.
- hkolek 15y agoIt 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.
- talmand 15y agoWell, 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.