[x3d-public] Normal node precision

[Andreas Plesch]

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.

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).

-Andreas


On Wed, May 6, 2020 at 10:37 AM vmarchetti at kshell.com <vmarchetti at kshell.com>
wrote:

> 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
> https://www.web3d.org/documents/specifications/19775-1/V3.3/index.html ,
> single precision is described as requiring at least 6 (decimal) digits of
> precision. So a sensible specification for the normal vector data would be
>
> 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]
>
> 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.
>
>
>
> On May 6, 2020, at 9:49 AM, Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
> I guess there are no immediate opinions on the requirement that normals
> need to be normalized to a length of 1.0.
>
> How should a x3d browser process a normal with a length of 1.5 ?
>
> A vote ? on:
>
> a) give up. Invalidate the X3D. But what about a length of 1.01 ?
> 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.
> 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.
>
> I pick b).
>
> Cheers, -Andreas
>
>
>
> On Tue, Apr 28, 2020 at 12:53 PM Andreas Plesch <andreasplesch at gmail.com>
> wrote:
>
>> Looking at improving the pythonocc x3d generation, we came about the
>> requirement in X3D that normals need to be normalized to unit length:
>>
>>
>> https://www.web3d.org/documents/specifications/19775-1/V3.3/Part01/components/rendering.html#Normals
>>
>> However, the spec. is silent on how precisely that requirement needs
>> to be met. Is it required to be as precise as floats allow ? As an
>> example, consider
>>
>> (0.9, 0.43588989435, 0)
>>
>> This vector has unit length given float precision limits.
>>
>> Would
>>
>> (0.9, 0.43589, 0)
>>
>> still be considered legal although it has a length of 1.00000004605 ?
>>
>> Does the X3D validator check for this requirement ?
>>
>> Thanks, Andreas
>> --
>> Andreas Plesch
>> Waltham, MA 02453
>>
>
>
> --
> Andreas Plesch
> Waltham, MA 02453
> _______________________________________________
> x3d-public mailing list
> x3d-public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
>
>
>

-- 
Andreas Plesch
Waltham, MA 02453
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/pipermail/x3d-public_web3d.org/attachments/20200506/73555e06/attachment-0001.html>