<div dir="ltr">This makes sense. I think that definition corresponds to choice a). A drawback of a clear but stricter requirement is that it could lead to encouraging inflated file sizes where normals have 6 decimal places although 2 or 3 would suffice for a quality rendering.<div><br></div><div>So another idea would be to remove the requirement of 'SHALL' in the spec. but instead state that non-normalized normals can lead to imprecise rendering. I think that corresponds to choice b).</div><div><br></div><div>-Andreas</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2020 at 10:37 AM <a href="mailto:vmarchetti@kshell.com">vmarchetti@kshell.com</a> <<a href="mailto:vmarchetti@kshell.com">vmarchetti@kshell.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: break-word;">Since the Normal node data is defined as MFVec3f type, which is vectors based on "single-precision floating points", and in section 5.3.5 <a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/index.html" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/index.html</a> , single precision is described as requiring at least 6 (decimal) digits of precision. So a sensible specification for the normal vector data would be<div><br></div><div>abs( sqrt( n[0]*n[0] + n[1]*n[1] + n[2]*n[2]) - 1.0) <= 1.0e-6  , must be satisfied for each normal vector n with components n[i]</div><div><br></div><div>I judge it would be useful to include this in the specification. I don't judge it would be appropriate to specify what browsers should do for non-normalized normal vectors. This is the classic problem for software developers about hardest engineering factor, and that is users and the the mistakes they make -- and by users I mean content authors who don't properly prepare their models. Individual browsers need to make the tradeoff between accepting bad input and providing quality output; given that this tradeoff also depends on the target market.</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On May 6, 2020, at 9:49 AM, Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:</div><br><div><div dir="ltr">I guess there are no immediate opinions on the requirement that normals need to be normalized to a length of 1.0.<div><br></div><div>How should a x3d browser process a normal with a length of 1.5 ?</div><div><br></div><div>A vote ? on:</div><div><br></div><div>a) give up. Invalidate the X3D. But what about a length of 1.01 ?</div><div>b) use as is but proceed in the processing of shading as if it is of length 1.0. May lead to rendering artefacts but I think this is the expected behaviour.</div><div>c) normalize the normal to 1.0 internally. I guess that is what the requirement tries to avoid browsers have to do but browser may already do it anyways for sanity reasons.</div><div><br></div><div>I pick b).</div><div><br></div><div>Cheers, -Andreas</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 28, 2020 at 12:53 PM Andreas Plesch <<a href="mailto:andreasplesch@gmail.com" target="_blank">andreasplesch@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Looking at improving the pythonocc x3d generation, we came about the<br>
requirement in X3D that normals need to be normalized to unit length:<br>
<br>
<a href="https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#Normals" rel="noreferrer" target="_blank">https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#Normals</a><br>
<br>
However, the spec. is silent on how precisely that requirement needs<br>
to be met. Is it required to be as precise as floats allow ? As an<br>
example, consider<br>
<br>
(0.9, 0.43588989435, 0)<br>
<br>
This vector has unit length given float precision limits.<br>
<br>
Would<br>
<br>
(0.9, 0.43589, 0)<br>
<br>
still be considered legal although it has a length of 1.00000004605 ?<br>
<br>
Does the X3D validator check for this requirement ?<br>
<br>
Thanks, Andreas<br>
-- <br>
Andreas Plesch<br>
Waltham, MA 02453<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div>
_______________________________________________<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" target="_blank">http://web3d.org/mailman/listinfo/x3d-public_web3d.org</a><br></div></blockquote></div><br></div></div></blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Andreas Plesch<br>Waltham, MA 02453</div></div></div>