[x3d-public] Fog and Background

Michalis Kamburelis michalis.kambi at gmail.com
Thu Sep 28 11:58:34 PDT 2023


The case of dynamically modifying the content is interesting.

Hm, I don't yet have an answer "how to address it without any pain in
X3D spec", but I know what I would recommend to use in Castle Game
Engine / view3dscene: Namely, we allow to use shader effects on a
Background node, and thus modify the background color using GLSL. Thus
you can change the color by changing some GLSL uniform -- always fast,
and it is fully customizable (how to apply this color).

It looks like this:
https://github.com/castle-engine/darkest-before-dawn/blob/master/data/level/1/level1_final.x3dv#L63

As you can see, we expose uniform float "morning" and using this, the
author can control how much does the color change.

Throughout that game, the game code (from Pascal) changes the
"morning" value from 0 to 1.

The Background rendering is affected by this trivial GLSL code:

"""
uniform float morning;
void PLUG_fragment_modify(inout vec4 fragment_color)
{
  fragment_color.rgb *= mix(vec3(1.0), vec3(1.5, 1.5, 3.0), morning);
}

"""

I am not proposing to add this to spec, as the whole "Effect" idea may
be hard to implement for everyone. (Though FreeWRL implements it too,
but I don't know if it allows them for Background.)

Regards,
Michalis



czw., 28 wrz 2023 o 20:26 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
>
> Thanks, very good points, also bringing up visibilityRange. I tend to
> agree with option A).
>
> What is considered least surprising does depend on your existing
> perspective in the first place. For example, the existing behaviour of
> not applying fog to background was actually what turned out to be most
> surprising to some since it does not match the actual experience of
> real fog. This just reinforces that we should be clear in the spec.
>
> I am also hesitant to change anything but let's consider the use case
> of a nice panoramic cube map background of mountains and a blue sky in
> a morning scene with fog.
>
> An artist could preapply some level of fog to the cube map images, and
> use the Fog node for shapes in the scene.
>
> Then, during the day it gets warmer and the fog lifts. It is easy to
> switch off Fog for the shapes but we would also need to replace the
> background completely. So we could have a stack of backgrounds to bind
> to but we may want to do this gradually.
>
> I think this would be a use case where applying fog to the background
> and being able to adjust the max. intensity of fog would be quite
> useful. Full backward compatibility could be accomplished, so no
> surprises there.
>
> How should we approach such a use case ?
>
> -Andreas
>
> On Thu, Sep 28, 2023 at 11:54 AM Michalis Kamburelis
> <michalis.kambi at gmail.com> wrote:
> >
> > I think we should clarify the spec -- Fog doesn't affect Background,
> > so option A.
> >
> > Other options are nice, but then we'd make a decision for graphic
> > designers, and there are various possible valid ways to go -- they
> > depend on specific scene.
> >
> > - Some people may want background to essentially become a solid color
> > matching fog. This makes sense. It also means that Background node
> > contents would not really matter. (option B) I think it would be
> > surprising to do it automatically -- instead users can already achieve
> > this behavior by repeating in Background node the same color as in
> > Fog.
> >
> > - As you say, it is possible to blend Background with Fog (option D).
> > But this is a graphical decision, it means that a "skyline" (where
> > shapes, that are possibly 100% fog color when at far distance, change
> > into background) is very clearly visible. And it may be good (e.g. when
> > your scene has a good "skyline", e.g. city skyscrapers) and sometimes
> > not (when your scene has a nonsense "skyline", and you wanted to hide
> > it using Fog; e.g. if you cull distant geometry using
> > NavigationInfo.visibilityRange).
> >
> >     I imagine that e.g. sometimes (when scene has a nonsense
> > "skyline", e.g. because of culling) graphic artists can do something
> > better. Like a gradient at the bottom of Background matching fog color
> > 100%, and only changing at the zenith.
> >
> > So, all these options make sense for some scenes. We should leave the
> > decision to graphic artists and in X3D behave with "least surprise", I
> > think. Option A thus (Fog only affects Shapes) seems best.
> >
> > Regards,
> > Michalis
> >
> >
> >
> >
> > czw., 28 wrz 2023 o 17:28 Andreas Plesch <andreasplesch at gmail.com> napisał(a):
> > >
> > > The question came up if global Fog should affect the background sky
> > > and ground, in addition to scene  objects/shapes.
> > >
> > > The spec. talks about Fog only in relation to objects with a defined
> > > distance to the avatar:
> > >
> > > https://www.web3d.org/specifications/X3Dv4Draft/ISO-IEC19775-1v4-IS.proof/Part01/components/environmentalEffects.html
> > >
> > > So I think most browsers ignore global Fog for rendering Background.
> > >
> > > Of course, in reality fog would exist in any direction, not just in
> > > front of scene objects.
> > >
> > > So global Fog, in principle, should apply in any look direction even
> > > if there are no Shapes, it appears.
> > >
> > > One problem is that background would need to be considered to be
> > > placed at a very large distance with the effect that blending in the
> > > Fog color means effectively replacing all of the Background with the
> > > Fog color. For real, dense fog this is probably the desired effect but
> > > for light fog, one still would likely want to see through the fog even
> > > at large distances.
> > >
> > > Would it make sense to introduce a maximum fog intensity/opacity at
> > > the range field distance ?
> > >
> > > But given that perhaps the main purpose of fog is to hide distant
> > > objects so that they do not need to be rendered, perhaps just
> > > accepting that the fog color becomes the background color in scenes
> > > with Fog is acceptable as well. This seems currently to be not
> > > inconsistent with spec. as well but it is not how most browsers apply
> > > Fog.
> > >
> > > In any case, a clarifying sentence in the spec. on how Fog should
> > > affect Background seems to be needed:
> > >
> > > Options:
> > >
> > > A) "Fog only affects rendering of Shapes." May boil down "only" in the
> > > appropriate place.
> > > B) "A Background node is considered to be at a distance larger than range."
> > > C) "Fog color replaces any Background for background rendering."
> > > D) "The intensity field can be used to limit the maximum fog
> > > intensity." and updates to the fog equations (replace 1.0 with
> > > intensity).
> > >
> > > Any thoughts or ideas on how to address Fog and Background interaction
> > > very welcome. Since these nodes exist for a very long time, there
> > > probably was an earlier discussion also.
> > >
> > > Thanks, Andreas
> > >
> > > --
> > > 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



More information about the x3d-public mailing list