<div dir="auto"> There should be an option to convert binary vertex and index data to ASCII, if only during authoring.</div><div dir="auto"><br></div><div dir="auto">Remember that Joe/designers like to tweak.</div><div dir="auto"><br></div><div dir="auto">I find that converting JSON through JavaScript massively increases precision, but i haven’t looked at why yet.  Maybe JSON/JavaScript numerical libraries should be responsible for keeping precise, accurate numbers, perhaps by storing alternate encodings for I/O and computation.</div><div dir="auto"><br></div><div dir="auto">One can always convert to EXI and back, to serve ASCII purposes.</div><div dir="auto"><br></div><div dir="auto">John </div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 10, 2023 at 12:36 PM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com">michalis.kambi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)">We use optional scientific notation (with exponent) when writing<br>
numbers in CGE/view3dscene. To be precise, we use a formatting option<br>
that outputs either a scientific or decimal notation, whichever is<br>
shorter. The scientific notation is not that much shorter to win<br>
usually.<br>
<br>
As for round-trips: you must have maximum precision to have reliable<br>
round-trips, I believe :) Otherwise you will always discover use-cases<br>
when you loose some digits, and they will be important for someone.<br>
<br>
glTF does what is obvious, and I'd say X3D should follow, this is<br>
something I'd like to work on for X3D 4.1 (<br>
<a href="https://github.com/michaliskambi/x3d-tests/wiki/Binary-meshes" rel="noreferrer" target="_blank">https://github.com/michaliskambi/x3d-tests/wiki/Binary-meshes</a> ).<br>
Namely, the floats in per-vertex data are always stored as binary.<br>
Only the floats like material parameters are stored as text in JSON.<br>
<br>
X3D binary encoding is one solution here, but it is not wide-spread,<br>
e.g. I hope zero hope that Blender exporter would output X3D binary<br>
encoding someday (there's too many other critical issues in Blender<br>
X3D exporter). And X3D binary encoding doesn't make data interleaved,<br>
so it doesn't solve the issue of effectively delivering it to GPU.<br>
<br>
"keep numbers and arrays as strings" -- no, this really wouldn't help<br>
with anything. The X3D browser has to parse the text to numbers at<br>
some point, to process the points, upload them to GPU etc. Right now<br>
the bottleneck of reading real-life X3D is always, in my experience,<br>
"your code effectively has to make million of text-to-float<br>
conversions". I believe this is a bottleneck regardless of the<br>
programming language, 1000 * 1000 calls to text-to-float is always<br>
going to be much slower than reading binary data (where you say "this<br>
is my pointer to 1000 * 1000 * 4 bytes, just copy there the contents<br>
of this file").<br>
<br>
Regards,<br>
Michalis<br>
<br>
pt., 10 lut 2023 o 18:57 John Carlson <<a href="mailto:yottzumm@gmail.com" target="_blank">yottzumm@gmail.com</a>> napisał(a):<br>
><br>
> Not sure how feasible this is with Pascal, etc.   Perhaps consider scientific or engineering notation with exponents.<br>
><br>
> In most cases i see, extending precision significantly increases file size, and makes it harder to do round trips.<br>
><br>
> I don’t know if there’s a JavaScript or Python solution for this.<br>
><br>
> Perhaps we should not implement number types in our synthesized programs, and keep numbers and arrays as strings.   Then we have to ask what is done in glTF.<br>
><br>
> John<br>
><br>
> On Fri, Feb 10, 2023 at 7:13 AM Michalis Kamburelis <<a href="mailto:michalis.kambi@gmail.com" target="_blank">michalis.kambi@gmail.com</a>> wrote:<br>
>><br>
>> Thanks, and sorry for a delay in answering!<br>
>><br>
>> The "description" field has been added to texture nodes and few more,<br>
>> as you can see in another thread on x3d-public :)<br>
>><br>
>> As for digits precision when saving: it's not so easy, in general it's<br>
>> (one of) the problems that come from X3D using text representation for<br>
>> floats in per-vertex data. Namely, if we cut the saved numbers to 4<br>
>> decimal places, I'm 90% sure that I will get a valid bugreport from<br>
>> someone:<br>
>><br>
>> """<br>
>> Hey, my stuff no longer works! My models (in glTF, X3D, whatever) have<br>
>> vertexes at coordinates like Z = 0.00001, 0.00002, 0.00003. And now,<br>
>> after processing and saving to X3D using your tools, they are all<br>
>> equal zero, resulting in bugs (things start to fight in Z buffer).<br>
>> """<br>
>><br>
>> Surely we could add a configuration option for it, but it feels<br>
>> counter-productive, when my recommendation to everyone would be still<br>
>> "use the maximum precision, to be safe". I would add a feature that I<br>
>> explicitly say should not be used.<br>
>><br>
>> In the end, the longer text representation for numbers only hurts the<br>
>> file size. And I don't believe we can really fix it by outputting less<br>
>> digits. The right solution is storing per-vertex data in a binary<br>
>> blob, when each float is binary 4 bytes, so it's<br>
>><br>
>> - efficient storage<br>
>> - efficient reading by X3D implementation to a "float[] array", no<br>
>> need for text parsing.<br>
>><br>
>> Regards,<br>
>> Michalis<br>
>><br>
>><br>
>><br>
>><br>
>> śr., 28 gru 2022 o 21:00 Brutzman, Donald (Don) (CIV)<br>
>> <<a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a>> napisał(a):<br>
>> ><br>
>> > Hi Michalis. Joe and I are really enjoying the many excellent features of view3dscene.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Here are some suggested refinements and improvements.<br>
>> ><br>
>> ><br>
>> ><br>
>> > View3dscene converter: round off significant digits, rather than 10+ decimal places.  (For example, suggested values in HAnim spec go to 4 decimal places.<br>
>> ><br>
>> ><br>
>> ><br>
>> > View3dscene: note that we have added ‘description’ field to many nodes in X3D4, including ImageTexture.<br>
>> ><br>
>> > 1 warnings:<br>
>> > X3D: Unknown X3D field name (unhandled X3D XML attribute) "description" in node "ImageTexture"<br>
>> > Scene URL: "C:\x3d-code\<a href="http://www.web3d.org" rel="noreferrer" target="_blank">www.web3d.org</a>\x3d\content\examples\HumanoidAnimation\Skin\JoeSkeletonSkinSiteSaluteWalk.x3d".<br>
>> > Use "File->View Warnings" menu to view these warnings again.<br>
>> ><br>
>> ><br>
>> ><br>
>> > Coming soon: import test of three models in HAnim Motion specification.<br>
>> ><br>
>> > <a href="https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/MotionDataAnimation.html" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19774/V2.0/MotionDataAnimation/MotionDataAnimation.html</a><br>
>> ><br>
>> ><br>
>> ><br>
>> > Again thanks for great work.<br>
>> ><br>
>> ><br>
>> ><br>
>> > all the best, Don<br>
>> ><br>
>> > --<br>
>> ><br>
>> > Don Brutzman  Naval Postgraduate School, Code USW/Br        <a href="mailto:brutzman@nps.edu" target="_blank">brutzman@nps.edu</a><br>
>> ><br>
>> > Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA    +1.831.656.2149<br>
>> ><br>
>> > X3D graphics, virtual worlds, Navy robotics https:// <a href="http://faculty.nps.edu/brutzman" rel="noreferrer" target="_blank">faculty.nps.edu/brutzman</a><br>
>> ><br>
>> ><br>
>><br>
>> _______________________________________________<br>
>> x3d-public mailing list<br>
>> <a href="mailto:x3d-public@web3d.org" target="_blank">x3d-public@web3d.org</a><br>
>> <a href="http://web3d.org/mailman/listinfo/x3d-public_web3d.org" rel="noreferrer" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br>
</blockquote></div></div>