[x3d-public] gltf distance attenuation [was glTF compatibility]

[Andreas Plesch]

Super. I agree, I think we are on the same track.

Just a correction, it should read 'adopting the gltf numerator' rather
than denominator because that is the difference in the math for
distance attenuation.

Perhaps the simplest solution would be a single SFBool 'punctual'
field for lights, default false, which turns on and off glTF punctual
light behavior in all respects. The details for 'on' could be left to
the browser with a recommendation to follow the glTF spec. if it
becomes an ISO spec.

Another detail separate from attenuation is that for comparative PBR,
intensities need to be multiplied by Pi because PBR divides
intensities by Pi in the shader math for the Lambert contribution
whereas X3D does not. I am not sure if it means that for X3D punctual
lights the glTF imported intensities should be automatically
multiplied by Pi for X3D conversion. But doing that would make gltf
scenes with lights appear too bright in x3d browsers. On the other
hand not doing that makes punctual light less bright for
PhysicalMaterial compared to regular Material. Hm, it might mean that
it becomes necessary to carefully scope lights in mixed scenes.

Let's look at an example. We inlined or imported a gltf with punctual
lights. The scene looks good compared to other gltf viewers.

Now we add a Shape with regular Material which is affected by the
imported light. For simplicity, it has only diffuseColor. It has a
certain brightness which is noted. (Probably pretty bright).

Now we add a Shape with PhysicalMaterial with only baseColor and full
roughness, no metallicity to mimic the regular Material. It will be
much less bright than the regular Material but fits with the imported
gltf scene.

For good compatibility, does that mean that regular Shapes mixed with
physical Shapes should have their color intensities adapted/toned down
? Or that they need to have their own scoped lights ?

Another way to think about this is simply that a scene with two
inlines, one gltf, one regular x3d, using shared global lights, should
still look good but probably currently have differing brightness.

Apologies, this is confusing but is unfortunately important to
consider and I cannot think of an 'automatic' solution. The first step
may be to have more mixed test scenes.

Finally, of note is the mentioning of intensity units in the glTF
extension spec. There is an extremely involved and long discussion on
a Github issue about that. I think the conclusion was these units are
really intended as  'unitless' but try to make sense of PBR
implementations which apply more or less the same set of computations
to RGB values (after potential color space conversion) as an 'industry
standard'.

-Andreas

On Mon, Sep 4, 2023 at 8:32 AM Michalis Kamburelis
<michalis.kambi at gmail.com> wrote:
>
> Fantastic, thank you for doing this.
>
> Sorry for not giving a more substantial answer, I have in TODO to read
> everything from this thread and "Need for colorspaceConversion field
> in ImageTexture, glTF compatibility" , and think what to do (both in
> CGE/view3dscene, and what change we should propose to X3D 4.1). From a
> quick glance, it seems we have a consensus and we could just align to
> glTF easily in some aspects.
>
> So, I'll post a more detailed thoughts ~next week, but for now: just
> wanted to send thanks :) Great job!
>
> Regards,
> Michalis
>
>
> pon., 4 wrz 2023 o 06:51 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
> >
> > https://github.com/x3dom/x3dom/issues/1259#issuecomment-1704585434
> >
> > has a few plots which show similarities and differences for default
> > x3d and gltf point light attenuation.
> >
> > The default parameters for x3d are 1,0,0 and radius=100.
> > The default parameters for gltf are 0,0,1 and radius=infinite
> >
> > The plots show attenuation for these default settings with the x3d
> > math and the gltf math.
> > For the radius=infinite case the gltf and x3d maths boil down to the
> > same, so no differences..
> > For short distances (0 to 10) there are essentially no differences
> > between the different maths.
> > For large distances (close to 100), there are differences between gltf
> > and x3d maths. x3d has a step for 1,0,0 and a small step for 0,0,1.
> > gltf maths produces smooth falloffs for both 1,0,0 and 0,0,1. The
> > largest differences occur for 1,0,0 between 60m and 100m distance
> > where gltf generates significant attenuation and darker scenes, and
> > x3d does not..
> >
> > Is the impact of adopting the gltf denominator acceptable for x3d ?
> >
> > One way to check is to look through the large example archive for
> > examples with point or spotlights (not too many) with default
> > attenuation (most of those) and see if any shapes are more than 50m
> > away from the light. The first part should be possible with some
> > grepping but the second part is difficult and probably requires a
> > quick manual check.
> >
> > Andreas
> >
> > > > 2. As for attenuation and spot cutoff: Indeed glTF math is a bit different.
> > > >
> > > > Personally: I'm OK with
> > > >
> > > > - adding fields to change the math to follow glTF.
> > > >
> > > > - Or just change X3D spec to follow glTF equations. At these points,
> > > > glTF equations are just better IMHO, more realistic, and the X3D
> > > > equations are simpler and just followed what old OpenGL ancient
> > > > fixed-function pipeline could do. It would indeed change how things
> > > > look, but I think it would be a change for better.
> > > >
> > > > I would not want to have different attenuation / spot behavior for
> > > > Material versus PhysicalMaterial. Conceptually (when describing it to
> > > > humans) and technically (when implementing) this seems a bit
> > > > unexpected. Material versus PhysicalMaterial should not determine
> > > > light attenuation or spot light beam falloff, they should be
> > > > independent IMHO (and they are independent now).
> > >
> > > Yes, attenuation should not be related to the kind of Material. I was
> > > thinking about that only as a way to not break anything.
> > >
> > > I tend to agree that just changing the spec. for attenuation is
> > > acceptable. But others may disagree since there are users of
> > > SpotLight. It may come down to how different the defaults look.
> > >
> > > Let's see. For distance attenuation, there could be a combined
> > > equation which preserves the x3d parameters in the denominator and
> > > adds the glTF range/radius transition in the numerator. I think this
> > > could work.



-- 
Andreas Plesch
Waltham, MA 02453