<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Thanks Leonard for your insightful comments.</div><div><br></div><div>Leonard Daly wrote:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">... [Christopher wrote]</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> InfinitePlane, on the other hand, is not so similar to existing<br>
> structures. Basing InfinitePlane on ObscenelyLargeRectangle would be<br>
> imperfect, as would basing it on a half-invisible cube map. Perhaps<br>
> only a very specialized rendering implementation would be appropriate<br>
> for such a primitive.<br>
<br>
You can't use "ObscenelyLargeRectangle" because the vertices will be<br>
beyond the far clipping plan. This will cause the geometry to not be<br>
there. Also lighting calculations are based on vertices (and center<br>
point). If you have any gradation of lighting over the surface, it won't<br>
show. It would be better to tile the "virtual" plan out to the far<br>
clipping plane. There is no sense going much beyond that because it<br>
would never show, though going a bit beyond so there is always<br>
"something" there is useful.<br></blockquote><div><br></div><div>Yes. You are right. The mesh based InfinitePlane proxy would need to be tiled and limited in actual range. When the viewer camera moves, the plane geometry might need to move too, but without altering the apparent location of the texture coordinates. I don't relish the idea of implementing such a thing.</div><div><br></div><div>My custom InfinitePlane renderer does not respect the far clip plane, because InfintePlane bridges the gap between "background image" and local geometry. The InfinitePlane display extends all the way to the horizon. Past the far clip plane, the depth buffer gets populated with the maximum value 1.0. I render the InfinitePlane with glDepthFunc(GL_LEQUAL), so it would paint over the previously rendered skybox or background, but behind any items lying between the viewer and the plane.</div><div><br></div><div>I suspect that InfinitePlane, if accepted as part of the X3D spec, should be an optional advanced node that some compliant players should not be required to implement.</div><div><br></div><div>I should mention that the custom rendering of all my parametric primitives, from spheres to planes, cannot be rendered with per-vertex lighting, because there are no such vertices, and no little triangles to interpolate.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> At this point I'd like to begin experimenting with existing browsers<br>
> that support X3D. Are there any written in python?<br>
<br>
The list of X3D players (open and otherwise) is at<br>
<a href="http://www.web3d.org/x3d/content/examples/X3dResources.html#Applications" rel="noreferrer" target="_blank">http://www.web3d.org/x3d/<wbr>content/examples/X3dResources.<wbr>html#Applications</a><br>
<br>
I don't know of any written in Python. X3DOM and Cobweb are written in<br>
JavaScript so that they can run in the browser. C/C++/C# is another<br>
frequent language. There are a couple written in Java.<br>
<br>
<br>
Leonard Daly<br></blockquote><div><br></div><div>The various lists of X3D players includes some obsolete or difficult to obtain programs. I did eventually get FreeWrl to run on my computer. I'm tempted to start rolling my own open source viewer in python; with one version for the desktop, and another for virtual reality headsets; both sharing the same back end. Where can I get more information about X3D compliance testing for viewers? I doubt I'll ever actually apply for certification, but I'd like to use the tests nonetheless.</div><div><br></div><div>Christopher</div><div><br></div></div></div></div>