This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Most rendering systems use a depth buffer to render. In order to render across browsers with a reasonable expectation of reproducable results the spec needs to say what values to use for zNear and zFar when computing either an orthographic or perspective matrix.
Could you explain this in more detail, perhaps with links to sources that explain the concepts you're talking about? The spec already defines the meaning of perspective matrices pretty clearly, I think. What's an example of markup whose rendering is unclear in the current spec?
When you create a perspective matrix 4 things are needed 1) The desired field of view 2) The aspect ratio of the display (supplied by the browser) 3) The location of the near clip plane usually called zNear 4) The location of the far clip plane usually called zFar The perspective setting only has 1 input, so how does it decide #1, #3 and #4 above. They are all independent settings. Here's 2 problems that come up from not being able to set them. http://frbouvi.free.fr/flightsim/fgfs_near_problem_4.jpg This happens when zNear is too far for the given scene and view. A similar problem happens when zFar is too near. http://en.wikipedia.org/wiki/Z-fighting This happens when the range between zNear and zFar is too small
(In reply to comment #2) > When you create a perspective matrix 4 things are needed > > 1) The desired field of view > 2) The aspect ratio of the display (supplied by the browser) > 3) The location of the near clip plane usually called zNear > 4) The location of the far clip plane usually called zFar > > The perspective setting only has 1 input, so how does it decide #1, #3 and #4 > above. They are all independent settings. The perspective function in the spec is precisely defined as a 4x4 matrix. This definition requires only one parameter. I don't know how it gets mapped to 3D graphics APIs in practice, but in theory it's defined in terms of linear algebra, which gives precise results. > Here's 2 problems that come up from not being able to set them. > > http://frbouvi.free.fr/flightsim/fgfs_near_problem_4.jpg > > This happens when zNear is too far for the given scene and view. A similar > problem happens when zFar is too near. Can you give examples of HTML markup that exhibit this kind of problem? > http://en.wikipedia.org/wiki/Z-fighting > > This happens when the range between zNear and zFar is too small The spec doesn't say how precisely z-coordinates have to be interpreted. If you try a test-case: data:text/html,<!doctype html> <div style="transform-style:preserve-3d"> <div style="position:absolute;height:100px;width:100px; background:lime"></div> <div style="position:absolute;height:100px;width:100px; background:red;transform:translateZ(-0.01px)"></div> </div> Then in Firefox 13.0a1 on my desktop, setting the translateZ() value as small as -0.009px shows a green square (you have to add transform:translate(0) or something to the first div too for some reason). In Chrome 18 dev on my laptop, up to -0.002px works. Those are the only two browsers that implement preserve-3d yet. Exactly how much precision is needed is not currently defined. In practice, if things render distinctly at 0.01px apart, it should be fine for most effects, I'd think. If you can give real-world test-cases where browsers differ significantly because this is undefined, that would be a good reason for us to define things better. In the event that two elements have the same z-index, the spec says that they render in the usual CSS way -- normally, the later element renders on top. For instance: data:text/html,<!doctype html> <div style="transform-style:preserve-3d"> <div style="position:absolute;height:100px;width:100px; background:red;transform:translateZ(10px)"></div> <div style="position:absolute;height:100px;width:100px; background:lime;transform:translateZ(10px)"></div> </div> This should render as a green square, and does in both the browsers that support preserve-3d. So I *think* the answer to your question is: authors are not given control over zNear and zFar. It's up to browsers to pick them so as to make everything work as well as possible. If browsers do a bad job at this, the answer is probably to fix the browser to do a better job. But if you can give specific HTML pages that show problems in browsers because of this, that would be useful data.
Since there's been no reply, I'm resolving this NEEDSINFO for now. Please reopen if you can clarify what needs to change in the current spec. Thanks.