castle-engine / castle-model-viewer

Viewer for many 3D and 2D model formats: glTF, X3D, VRML, Collada, 3DS, MD3, Wavefront OBJ, STL, Spine JSON, sprite sheets in Cocos2D and Starling XML formats
https://castle-engine.io/castle-model-viewer
90 stars 19 forks source link

SpotLight ambientIntensity being applied regionally.(as Intensity.) #15

Closed splace closed 5 years ago

splace commented 5 years ago

bit of rare case, but saw it, so reporting.

example; (with lighting setup to maximise effect.)

light_street_lights_radius_0 (view3dscene 3.18 phong lighting)

#VRML V2.0 utf8

DEF _1 SpotLight {
  intensity 0
  ambientIntensity 1
  location 1.27471 2 1.64777e-08
  direction -7.45057e-09 1.49012e-08 -1
}

Shape {
  appearance Appearance {
    material Material {
      ambientIntensity 1
    }
  }
  geometry Box {
    size 3.09537 3.09537 10.7638
  }
}

NavigationInfo {
  headlight FALSE
}
michaliskambi commented 5 years ago

I think this is correct, reading lighting equations on http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/lighting.html#Lightingmodel .

ambientIntensity is only applied where the spot shines. In case of SpotLight with ambientIntensity=1, it should indeed fill the spot "cone".

In the lighting equations, this is reflected by multiplying spot_i by ambient_i. So when spot_i is 0, the ambient is not applied.

splace commented 5 years ago

really, ambientIntensity is not ambient?

OK, makes not sense to me, but if that's what the equations do.

michaliskambi commented 5 years ago

Well, ambientIntensity is "ambient" in the sense that it doesn't depend on the normal vector or direction to lighting :) That is the main difference between ambient_i and diffuse_i on http://www.web3d.org/documents/specifications/19775-1/V3.2/Part01/components/lighting.html#Lightingmodel .

But ambientIntensity is limited by SpotLight cone, just like regular intensity.

splace commented 5 years ago

Well, ambientIntensity is "ambient" in the sense that it doesn't depend on the normal vector or direction to lighting :) That is the main difference between ambient_i and diffuse_i

thanks, i have been looking at equations...

trying to get a 'sense' of this; something that was bothering me was what looked like the duplication with diffuseColor, but i think i see that that blends with the light colour but ambient is just the lights colour. all i have to do now is find a 'real' situation that this mimics.

i guess ambient is just the word chosen to approximate the spec. definition, (and something had to be) still for me ambient light is that which is considered to have bounced around so much you can assume it comes in uniformly from all directions, so as a 'concept' it couldn't be restricted to a zone, of course the spec. can do anything and the english word used as the parameter name is only the most basic 'documentation'.

splace commented 5 years ago

the drop-off between beamwidth and cutoffangle is not supported/working?

michaliskambi commented 5 years ago

the drop-off between beamwidth and cutoffangle is not supported/working?

It is supported and working in my tests.

Note that by default, beamWidth is > cutOffAngle (according to X3D spec), so there is no smooth drop-off. If you modify your example SpotLight to have beamWidth < cutOffAngle, you will notice a smooth drop-off.

DEF _1 SpotLight {
  intensity 0
  ambientIntensity 1
  cutOffAngle 0.9
  beamWidth 0.7
  location 1.27471 2 1.64777e-08
  direction -7.45057e-09 1.49012e-08 -1
}

s_0

splace commented 5 years ago

yes, sorry i was reading the default values is resulting in a roll-off, that was cutoffangle > beamwidth.