Directional light question with new Xith

Please have a look at this small Webstart Jar. (In case my freespace host messes up the Jnlp’s MIME type, please use the the zipped .jnlp version instead.)

There’s a plate which spans the x-z axis (ie it lays on the “floor”). Plus a small model loaded with Kev’s 3ds loader. Directional light comes from the front, ie its vector is (0, 0, -1).
The camera ist at eye-coordinate (0, 0, 20), aiming at (0, 0, 0). It then moves slowly in an arc to (0, 20, 0), always aiming at (0, 0, 0).
The color of the plate (and the model) shouldn’t change, because the Nodes don’t move, just the camera. However they go light red. With the Xith version some days ago the colour didn’t change.

Do I get it wrong, or is there anything unusual with the current Xith3d version?
Many thanks.

PS: Basically the code looks like this:

class Theview 
{
  private Theview mTheview  = new Theview();
  
 
  public static void main() throws Exception
  {
    Point3f eye = new Point3f(0, 0, 0);
    Point3f aim = new Point3f(0, 0.1f, 0);
    for (int i = 0; i < 90; i++) {
      eye.z = (float) (20 * Math.cos(Math.toRadians(i)));
      eye.y = (float) (20 * Math.sin(Math.toRadians(i)));
    mTheview.getTransform().lookAt(eye, aim, new Vector3f(0, 1, 0));
  }

  
  public Theview() throws Exception
  {
    BranchGroup     sceneBg   = new BranchGroup();
    VirtualUniverse universum = new VirtualUniverse();
    Locale lokal = new Locale(); 
    lokal.addBranchGraph(sceneBg);
    universum.addLocale(lokal);
    universum.addView(mTheview);

    sceneBg.addChild(getTestplatte());
    sceneBg.addChild(new TDSLoader().load("Tube.3ds"));

    RenderPeer renderpeer = new RenderPeerImpl();
    CanvasPeer canvaspeer = renderpeer.makeCanvas(null, 640, 480, 32, false);
    Canvas3D   kanvas3d   = new Canvas3D();
    kanvas3d.set3DPeer(canvaspeer);
    mTheview.addCanvas3D(kanvas3d);

    DirectionalLight dirLicht = new DirectionalLight(new Color3f(0.8f, 0.8f, 0.8f), new Vector3f(0, 0, -1));
    sceneBg.addChild(dirLicht);
    AmbientLight ambLicht = new AmbientLight(true, new Color3f(0.6f, 0.6f, 0.6f));
    sceneBg.addChild(ambLicht);

    mTheview.startView();
  }


  /**
   * @return Shape3D
   */
  public static Shape3D getTestplatte()
  {
    final Point3f[] punktefeld = new Point3f[] {
      new Point3f( 0, 0,   0),
      new Point3f(15, 0,   0),
      new Point3f(15, 0, -10),
      new Point3f( 0, 0, -10)
    };

    final int[] polyverbinder = new int[] {
      0, 1, 2,
      2, 3, 0
    };

    final Vector3f[] normalenfeld = new Vector3f[] {
      new Vector3f(0, 1, 0),
      new Vector3f(0, 1, 0),
      new Vector3f(0, 1, 0),
      new Vector3f(0, 1, 0)
    };

    IndexedTriangleArray geo = new IndexedTriangleArray(punktefeld.length, GeometryArray.COORDINATES | GeometryArray.NORMALS, polyverbinder.length);
    geo.setCoordinates(0, punktefeld);
    geo.setIndex(polyverbinder);
    geo.setValidIndexCount(polyverbinder.length);
    geo.setNormals(0, normalenfeld);

    Appearance ape = new Appearance();
    Material material = new Material();
    material.setColorTarget(Material.AMBIENT_AND_DIFFUSE);
    ape.setMaterial(material);
    ape.setPolygonAttributes(new PolygonAttributes(PolygonAttributes.POLYGON_FILL, PolygonAttributes.CULL_BACK, 0));
    ape.setColoringAttributes(new ColoringAttributes(new Color3f(1, 0, 0), ColoringAttributes.NICEST));

    return new Shape3D(geo, ape);
  }
}

It’s easy to use my Testle.jar and run it with an older (1 week?) xith.jar version: just put that older xith.jar next to the Testle.jar and double click the Testle.jar
Then we see: nothing :slight_smile: I mean: all the surfaces don’t change in colour, because they’re lit with just a directional light, and like the models, the light source doesn’t change its position when the app runs. Just the camera moves.

So: which one is the correct effect? The one we get with the older xith.jar or the one we get with the current xith.jar (which I bundled in the Testle.jnlp, mentioned in my 1st posting) ?
Personally I think the effect with the old xith.jar is correct, but I could be wrong, or my code could doing something wrong. So I’d like to ask you other xith users and experts out there…

the problem may come from the new tranfrom process in
xith3d / src / com / xith3d / render / jogl / TransformShaderPeer.java
the function [setTransform] in cvs 2004-01-20 is


    public static void setTransform( GL gl, Matrix4f mat) {
      ...
        gl.glLoadMatrixf(trans);

    }


and the new one in cvs 2004-02-29


    public static void setTransform( GL gl, Matrix4f mat, CanvasPeer canvas) {
...
        // Combine LocalToVWorld and View (camera) transforms
        gl.glLoadMatrixf(((CanvasPeerImpl)canvas).viewTrans);
        gl.glMultMatrixf(trans);

    }


It seems to be incompatible with old lookAt , as call the lookAt from view, the camera, or just the sence objects, rotate to a different location.
Quik fix is changing those two lines back to older version, then wait for the developers to update them so can compatible with lookAt call in view.

;D
so the developers fixed up
update the
CanvasPeerImpl.java
OpenGlExtensions.java
in
xith3d / src / com / xith3d / render / jogl /
it was updated yesterday
it will work fine

[quote]so the developers fixed up
[/quote]
I think not really.

I just reviewed the LightingShaderPeer.java code.

This is true that few versions ago I changed transform management code - there is an explanation in CanvasPeerImpl as well as CVS commit message.

[quote]It seems to be incompatible with old lookAt , as call the lookAt from view, the camera, or just the sence objects, rotate to a different location.
[/quote]
Rendering of objects should work EXACTLy as it worked before. The only question is with light positions and vectors.

[quote]Quik fix is changing those two lines back to older version, then wait for the developers to update them so can compatible with lookAt call in view.
[/quote]
…and this will break the rendering process, because of in previous versions of Xith3D lookAt(…) transforms were combined with Projection matrix, and now they moved to Modelview matrix to make Texture Cube Mapping work.

What we have to do is to add correct transformations for Light Vectors and Positions.

Yuri

Now I understand why my phong lighting demo crapped out with the new Xith build; it relies on the internal GL location of lights, state.light[n].position, to perform the correct phong illumination ::slight_smile:

So… is there a (small) problem with the current Xith version (CVS) when it comes to my described (directional) light source?

Btw. in several places in another project I use the setTranslation and setRotation for the view’s Transform3D object instead of lookAt. Of course, in the end, it should result in the same, so both ways show the light source problem.

[quote]Now I understand why my phong lighting demo crapped out with the new Xith build; it relies on the internal GL location of lights, state.light[n].position, to perform the correct phong illumination
[/quote]
Could be could be…

[quote]So… is there a (small) problem with the current Xith version (CVS) when it comes to my described (directional) light source?
[/quote]
I have to have a deeper look at this, but looks like I missed to adjust light transforms properly. What I should do is to check at which stages OpenGL calculates lighting and which transforms are used before using vectors and points in lighting equations.

[quote]in several places in another project I use the setTranslation and setRotation for the view’s Transform3D object instead of lookAt.
[/quote]
lookAt(…) is just a shortcut for direct modification of View transforms, so there is no difference.

Yuri

[quote]I have to have a deeper look at this, but looks like I missed to adjust light transforms properly. What I should do is to check at which stages OpenGL calculates lighting and which transforms are used before using vectors and points in lighting equations.
[/quote]
OK. Which version of the Xith src tree in CVS should I use so that lights are as they’ve been? :slight_smile:

[quote]lookAt(…) is just a shortcut for direct modification of View transforms, so there is no difference.
[/quote]
Thanks for the clarification.

I just committed an update to Xith3D that should fix this problem. Please check if it works as expected.

@JCD: your code should take into account View transfor now (if it is relevant).

Yuri

Doh I knew something was up with the view transform since with the latest releases, when I moved the mouse around the scene the light relfection would move accordingly whereas it shouldn’t.
Let me see if I can work it out with the cvs built you commited.

PS: You always forget this part


            case Texture.CLAMP_TO_EDGE:
                filter = GL.GL_CLAMP_TO_EDGE;
                break;

;D

[quote]PS: You always forget this part
[/quote]
Added.

In fact, I thought to add also support for texture mirrored repeat, as well as other texture clamping/repeating extensions:

GL_EXT_texture_mirror_clamp (important)
GL_ARB_texture_mirrored_repeat (important)
GL_ARB_texture_border_clamp (important)
GL_IBM_texture_mirrored_repeat
GL_IBM_texture_edge_clamp
GL_ATI_texture_mirror_once
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_border_clamp

but I found a kind of mess with enumerants, so it requires careful check and looking for cards that support specific set of extensions, so Xith3D will choose the correct enumerant values.

Yuri

[quote]I just committed an update to Xith3D that should fix this problem. Please check if it works as expected.
[/quote]
My Testle seems to work now, but on another application I use (with 2 directional light sources) the textured surfaces are being lit differently when I move the camera. So it looks like the “old” issue, which I don’t think is correct. Hopefully I’m going to bundle a small test case tomorrow…

If new behavior different from the old one, we should check which one is correct.

A time ago the goal was to match lighting schema with one used by Java3D and achieve compatibility, so it is even possible that new implementation better match original (Java3D) than the old one.

We should check anyway, but all my applications, as well as Xith3D tests that use lighting, seem to work correct [if not please complain].

Yuri

[quote]If new behavior different from the old one, we should check which one is correct.

A time ago the goal was to match lighting schema with one used by Java3D and achieve compatibility, so it is even possible that new implementation better match original (Java3D) than the old one.
[/quote]
Unfortunately I don’t know Java3D from experience, just from reading the Javadoc and tutorials…

Just a simple question. When there’s just two directional light sources in a scene (ie no spot lights or such) and you move the camera: is it that the lit colour of the model’s surfaces mustn’t change? As far as I understand it: the model’s colour should only change when the model’s are being rotated, but not when the camera is being moved…

Or am I wrong with this assumption?

In case my assumption is correct there’s likely still a problem with the new light source thing in Xith3d.

PS: One last question: do I have to create a influence bounds object and attach it to my (directional) light source, or is it OK to just add this to the root scenegraph (like I did in the previously posted code) ?

Hi,

[quote]When there’s just two directional light sources in a scene (ie no spot lights or such) and you move the camera: is it that the lit colour of the model’s surfaces mustn’t change? As far as I understand it: the model’s colour should only change when the model’s are being rotated, but not when the camera is being moved…
[/quote]
Not really…

Here is a description of OpenGL lighting equation taken from OpenGL docs:

[quote]In RGBA mode, the lighted color of a vertex is the sum of the material emission intensity, the product of the material ambient reflectance and the lighting model full-scene ambient intensity, and the contribution of each enabled light source. Each light source contributes the sum of three terms: ambient, diffuse, and specular. The ambient light source contribution is the product of the material ambient reflectance and the light’s ambient intensity. The diffuse light source contribution is the product of the material diffuse reflectance, the light’s diffuse intensity, and the dot product of the vertex’s normal with the normalized vector from the vertex to the light source. The specular light source contribution is the product of the material specular reflectance, the light’s specular intensity, and the dot product of the normalized vertex-to-eye and vertex-to-light vectors, raised to the power of the shininess of the material. All three light source contributions are attenuated equally based on the distance from the vertex to the light source and on light source direction, spread exponent, and spread cutoff angle. All dot products are replaced with zero if they evaluate to a negative value.

The alpha component of the resulting lighted color is set to the alpha value of the material diffuse reflectance.
[/quote]
Note the presence of dot product of the normalized vertex-to-eye and vertex-to-light vectors. Note that if you move the camera, you change [OK, in majority of cases] the vertex-to-eye vector, so change the contribution of the specular component to the final color of vertex.

[quote]do I have to create a influence bounds object and attach it to my (directional) light source, or is it OK to just add this to the root scenegraph (like I did in the previously posted code) ?
[/quote]
Currently, you do not have to create influence bounds. The light scoping in Xith3D works differently from light scopint in Java3D. In Xith3D, lights are affecting the nodes located under the same group where light is located, including the subgroups. So this is enough if you add your lights to the root scenegraph.

Yuri

OK, thanks for that explanation (once more :slight_smile: . Reads well and sounds logical.
I’ve been confused because the new Xith light source system works different to the old one and we got an light error some days ago (which has been fixed by you, there’s been the xith3d cvs anouncement).
Now we’re closer to Java3d (as you said - or did I get it wrong?), so this is good.

PS: Any chance to see your internal Maya to Xith loader as a pre-pre-alpha-prototype-release or such in the near future? :slight_smile:

Hi,

[quote]Any chance to see your internal Maya to Xith loader as a pre-pre-alpha-prototype-release or such in the near future? :slight_smile:
[/quote]
Currently I have no plan to make fully supported loader for Maya - you already see how much efforts Kev places to his 3ds loader. For me Maya .ma loader is just a path to transport models to our internal format that we use in production.

From the other side, .ma files are just programs on Maya’s script language, so to make perfectly correct importer we will have to reproduce a Maya-compatible set of nodes and write an interpreter for .ma files.

What I have 100% done is JavaCC (JavaCompilerCompiler) parser for .ma files and processing for basic geometry.

I will think about placing it to xith-tk project, but I think it will cause more questions than answers and may lead a lot of people to make a wrong choice and rely on part of code that I don’t plan to maintain in full scale.

Additionally, there is a very long to-do list for Xith3D core, which currently has much higher priority than Maya loader.

Yuri