> Are you using a non-uniform scale factor to increase the elevation?
Yes I do
>
> Possible workarounds:
>
> Scaling the geometry data explicitly and recomputing the normals without
> using a non-uniform Transform3D will always work, but is expensive.
> It's not sufficient to use a non-uniform Transform3D and just rescale
> the normals explicitly, since GL_RESCALE_NORMAL can't be turned off.
>
> On Solaris, the environment variable J3D_FORCE_NORMALIZE can be set in
> the environment to force the use of GL_NORMALIZE initially. This is
> only done the first time when the context is created however, so if
> GL_NORMALIZE is ever disabled it won't be possible to enable it again.
>
> The bug only presents itself when the scale is changed dynamically. If
> the Transform3D is initially created with a non-uniform scale, then the
> lighting is correct until Java 3D notices that the scale has become
> uniform again. In the test application this won't happen unless the Z
> scale is set to 1.0 in the slider and the "BR" button is clicked.
Does that mean, that when I never have a uniform scale the lighting will
be okay? I tried to just start with
scale = new Transform3D();
scale.setScale(new Vector3d(1,1.01,1));
scaleTG.setTransform(scale);
and handle the superelevation like:
scale.setScale(new Vector3d(1,scaleFactor+0.01,1));
scaleTG.setTransform(scale);
It looks more normal now.
Thanks Desiree
>
> -- Mark Hood
>
> ===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> of the message "signoff JAVA3D-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
