<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-size: 13px;color: rgb(0, 0, 0);font-family: arial,sans-serif;"><br>> The question becomes, can I expect a single browser to
generate identical pixels between runs, and if not, how is
testing done?<br><br>Identical renderings between runs is only a problem if your tool(s) don't follow the spec in authoring and rendering. Bigger problem is duplicates between versions. For both of these cases of course the tool author must include a set of 'standard' tests that are run frequently maybe with community inputs. Even bigger is expecting exact same performance between two independent browsers. X3D helps in this by maintaining a set of 'standard' examples that hopefully follow the spec and provide a viz of the result as played in a tool that has demonstrated some knowledge of the spec, <br><br>But a main purpose of X3D is to provide a way to produce totally documented human-readable data sets that describe structure and parameters of the scene. This is the X3D authortime. For those of little faith, then X3D also defines a runtime that can be used to validate the technical accuracy and completeness of the described scene. <br><br>> Do they get the X3D blessing because they implement the format (?)<br><br>I would vote Yes, the tool gets the blessing if the tool can provide an authortime for X3D content. <br>That is, this tool understands the abstract and concrete language and scenegraph hierearchies of X3D. <br><br>> or is there an image standard that they much match, and who is doing the checking? <br><br>As a product developer, or scene developer you do the checking. At least 'till you get a user base. Then they do the testing along with you. <br>For the benefit of the realtime 3D community web3dc maintains a fairly complete example set. As for the future then the X3D methods of encoding a realistic, repeatable, and transportable author-defined simulation spacetime along with realistic, repeatable, and transportable objects with behaviors to interact within that environment. <br><br>> I'm laughing too. X3D appears to be a joke.<br><br>That is the great thing about X3D. The more and deeper you look the more you will laugh. <br>I guarantee you will laugh your ass off when you get something you create running. <br><br>You don't have to build your own browser for this, but you can. <br>You don't have to totally build your own scene from scratch, but you can.<br>You don't have to leverage the knowledge of interactive realtime 3D professionals to define appropriate scenegraph and realtime data structures, but you can. <br><br>> Here's the possible scenario, I have a vendor that says they meet the
standard, but have wildly different renderings between runs. <br><br>I can assure you that Web3D Consortium and the X3D working group are looking for examples like you describe so bring it on out here. Believe it or not, this kind of example can probably be created and thus can happen. Demo or Die!! We want to see these things since they always bringing some mirth into the situation. And since we have a choice of free tools and examples that probably get very close to some structure that is showing the problem, we can usually use some analysis techniques to find a problem in the tool or maybe even the standard. <br><br>So, for the problem of figuring out which is a 'correct' rendition of a scene, then it gets a lot easier when the community can help in producing an evaluation. I think the more you play with realtime interactive 3D, then the more you will see that it provides a firm base for realtime authoring and rendering standards.<br><br>I want to see that example because part of the joy is finding the actual 'correct' or acceptable production from the various runs. The only thing better is when we find unexplained differences between different tools running the same scene. But really, unless you are pushing the standard beyond its limits, you are not likely to find these opportunities to contribute to the clarity and completeness of the X3D standard. If that is the case, well the X stands for extensible. <br><br>> Here's the possible scenario, I have a vendor that says they meet the
standard, but have wildly different renderings between runs. <br><br>And the problem is that you think your code is great while the toolmaker that says they meet the standard is saying it must be your code? Next, you are getting no cooperation from the toolmaker to resolve the problem? Finally, you bring it to this list and get no support from our 3D community to mod your code of find another tool that works for you? Well, now you can at least break a grin, because that sequence does not happen and never has happened. <br><br>Good Luck, Thanks for your concerns, and All Best, <br>Joe<br><br><br><blockquote style="padding-left: 5px; margin-left: 0px; border-left: #0000ff 2px solid; font-weight: normal; font-style: normal; text-decoration: none; font-size: 10pt; font-family: arial,sans-serif; color: black;">-----Original Message-----
<br>From: John Carlson <yottzumm@gmail.com>
<br>Sent: Oct 18, 2017 9:55 AM
<br>To: Greg Couch <gregc@cgl.ucsf.edu>
<br>Cc: X3D Graphics public mailing list <x3d-public@web3d.org>
<br>Subject: Re: [x3d-public] rendering the X3D standard...is it extensive enough
<br><br><div dir="auto">Here's the possible scenario, I have a vendor that says they meet the standard, but have wildly different renderings between runs. Do they get the X3D blessing because they implement the format, or is there an image standard that they much match, and who is doing the checking? Is it automated? It would seem not. What use is a standard which can't be verified?<div dir="auto"><br></div><div dir="auto">Yes, I am aware of the X3D resources thumbnails, I'm just wondering about any standard certification of browser renderings.</div><div dir="auto"><br></div><div dir="auto">I'm laughing too. X3D appears to be a joke.</div><div dir="auto"><br></div><div dir="auto">John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 18, 2017 12:45 PM, "John Carlson" <<a target="_blank" href="mailto:yottzumm@gmail.com">yottzumm@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">The question becomes, can I expect a single browser to generate identical pixels between runs, and if not, how is testing done?<div dir="auto"><br></div><div dir="auto">Thanks,</div><div dir="auto"><br></div><div dir="auto">John</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 18, 2017 12:31 PM, "Greg Couch" <<a target="_blank" href="mailto:gregc@cgl.ucsf.edu">gregc@cgl.ucsf.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/18/2017 08:53 AM, John Carlson wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I am wondering if the X3D standard is complete or extensive enough to provide for pixel perfect equality between browsers. This is important for archiving. Has this been a goal?<br>
<br>
Thanks,<br>
<br>
Johb<br>
</blockquote>
<br>
Thanks for the laugh. The OpenGL/Vulkan/Direct3D/etc. specifications have never required pixel perfect equality between graphics cards, so it has not ever been a goal AFAIK. Are they close? Yes, very close, but not pixel perfect. The great thing about X3D is that you're archiving the description of the scene not the image of the scene.<br>
<br>
HTH,<br>
<br>
Greg<br>
</blockquote></div></div>
</blockquote></div></div>
</x3d-public@web3d.org></gregc@cgl.ucsf.edu></yottzumm@gmail.com></blockquote></div></body></html>