Functional Background Node

Engines, Libraries and Tools Xith3D Forums
#1

Hello,

I am working on fixing the Background Node so that the geometry is actually rendered, and rendered in the background.

Yuri has already implemented the background colour, so I shall endevour to get the Shape3D backgrounds working. Fortunately, a lot of the code is already there (e.g. the render bins are ready to do) so it’s really just a case of fleshing it out.

Currently I have created a partially working BackgroundShader/ShaderPeer combo for Xith3D (jogl impl). The geometry is being drawn in the background (i.e. with the depth buffer disabled) which I am happy about.

I am posting this topic to get a better understanding of how the Background node should work (or how you want it to work).

Is it up to the programmer to keep the geometry alined with the View? For example with a skybox (why I want the background node in the first place), should the developer be able to simply create the skybox geometry as a background node then forget about it - or do they need to update the skybox’s position every time the view position changes?

I am guessing it is the former option (i.e. the scenegraph updates the skybox’s position to be equal to the View). Is there some nice way of doing this in OpenGL so it is drawn relative to the current view? Or should we use the scenegraph and wrap the Shape3D in a transform group and update it that way - or if this is not the task of the renderer then the developer can worry about it.

I look forward to reading your comments.

Will.

#2

Hello Will

Putting a geometry in a background node results in
some positions to a SingularMatrixException.
(I have bypassed this problem by creating a ‘normal’
node).
As far as i can overview, it comes from class ‘View’.
If a geometry was added in a background node, with it’s
method ‘setGeometry’, then automatically during
rendering there was a call to method
‘getBackgroundTransform()’ from class ‘View’,that
sometimes results in a SingularMatrixException.

(I don’t understand, why in this method an inverted
matrix is required.)

Bye Adi

#3

I found problems with the call to getBackgroundTransform() as well. I commented it out and things seemed to work better :).

Anyone have comments regarding the questions I raised?

Will.

#4

Thanks.

I have another question.
I use the classes :
com.xith3d.io.ScribeInputStream
com.xith3d.io.ScribeOutputStream
com.xith3d.io.Scribe
com.xith3d.io.ScribeGeometryArray

Can you free them from ‘Log4j.jar’, so xith3d-user must not send this jar also with his examples?
(It’s only 2 lines per class that have references to class ‘org.apache.log4j.Category’ from Log4j.jar )
Thanks.

Adi

#5

Hi Will,

I think that for correct background geometry rendering we do not need separate Shader/ShaderPeer. There is a separate rendering pass for the background node, but I anyway think it should be reviewed in favor of the following things I am thinking to add to the core:

  1. Viewing Platform. This answers to the

[quote]Is it up to the programmer to keep the geometry alined with the View?
[/quote]
We can go in two directions: implement Background node Java3D-compatible way, as it has been done for Color background and has to be done for background images, and implement alternate background geometry definition using rendering pass separation (current implementation of Xith3D went half way in this direction).

  1. Multipass rendering and Render-To-Texture.

I already tried several API design approaches for this, but they do not look elegant…

Background rendering can become just one of the rendering passes, so, for example, you can attach your skybox below the Viewing Platform and assign it to Background Rendering Pass, so it has proper transform, as well as will be rendered before all the other shapes [ok, this is bad example beause of your camera will not be moving relative to the skybox, but I guess you got the idea].

  1. OpenGL Shading Language support.

OK, this is not directly related to multipass rendering, but has higher priority for me.

Yuri

#6

Yuri,

Thanks for the comments on the Background node. The ViewingPlatform node does solve one question very nicely.

In which function does the background OpenGL code belong?

Essentially the calls consist of:


        gl.glClear(GL.GL_DEPTH_BUFFER_BIT);
        gl.glDisable(GL.GL_DEPTH_TEST);
        gl.glDepthMask(false);

to disable the Z buffer and then


        gl.glEnable(GL.GL_DEPTH_TEST);
        gl.glDepthMask(true);

to enable it again.

Does this even need a separate rendering pass? So long as the background geometry is rendered first with the depth buffer disabled then it should work fine, at least for the use-cases I have though of. I have done some limited testing and I got the desired affect. (edit: maybe this is exactly what you meant, I’m not 100% sure my interpretation of “rendering pass” is correct).

I think a Shader/ShaderPeer combo can solve this - disabling the depth buffer on the “shade” call and enabling it on the “doneShading” call. Is there a better way of doing it? What class files/methods should I be looking at?

At this stage I don’t know if Java3D compatability is really a big issue, it certianly isn’t for me and I would rather see it done whatever way we think is the best.

Thanks again,

Will.

#7

There’s more to background rendering than just disabling the depth buffer. In particular, to get the behaviour that Java3D uses, you need to also play with the transformation stack down to the background object itself.

Basically, what you need to do is undo the transformation heirarchy, but leave in the rotation component of the modelview matrix, then scale the world by the distance to the rear clipping plane. This scale is the critical bit as that is what gives you the “rendered to a unit sphere” effect that J3D talks about.

Here’s the code that we use:


            gl.glClear(GL.GL_DEPTH_BUFFER_BIT);
            gl.glMatrixMode(GL.GL_MODELVIEW);
            gl.glPushMatrix();
            gl.glLoadIdentity();
            gl.glMultMatrixf(backgroundMatrix);

            gl.glScaled(currentFrustum[5],currentFrustum[5],currentFrustum[5]);

            gl.glDepthMask(false);
            gl.glDisable(GL.GL_DEPTH_TEST);

            currentBackground.render(gl, glu);
            currentBackground.postRender(gl, glu);

            gl.glDepthMask(true);
            gl.glEnable(GL.GL_DEPTH_TEST);

            gl.glMatrixMode(GL.GL_MODELVIEW);
            gl.glPopMatrix();
            renderViewpoint(gl, glu);

To set up backgroundMatrix, we do this:


        matrixUtils.inverse(data.viewTransform, cameraMatrix);

        // Setup the matrix for the rendering. Transpose in place.
        viewMatrix[0] = cameraMatrix.m00;
        viewMatrix[1] = cameraMatrix.m10;
        viewMatrix[2] = cameraMatrix.m20;
        viewMatrix[3] = cameraMatrix.m30;
        viewMatrix[4] = cameraMatrix.m01;
        viewMatrix[5] = cameraMatrix.m11;
        viewMatrix[6] = cameraMatrix.m21;
        viewMatrix[7] = cameraMatrix.m31;
        viewMatrix[8] = cameraMatrix.m02;
        viewMatrix[9] = cameraMatrix.m12;
        viewMatrix[10] = cameraMatrix.m22;
        viewMatrix[11] = cameraMatrix.m32;
        viewMatrix[12] = cameraMatrix.m03;
        viewMatrix[13] = cameraMatrix.m13;
        viewMatrix[14] = cameraMatrix.m23;
        viewMatrix[15] = cameraMatrix.m33;

        Matrix4f bg_mat = data.backgroundTransform;

        bg_mat.mul(data.viewTransform);

        backgroundMatrix[0] = bg_mat.m00;
        backgroundMatrix[1] = bg_mat.m01;
        backgroundMatrix[2] = bg_mat.m02;
        backgroundMatrix[3] = 0;
        backgroundMatrix[4] = bg_mat.m10;
        backgroundMatrix[5] = bg_mat.m11;
        backgroundMatrix[6] = bg_mat.m12;
        backgroundMatrix[7] = 0;
        backgroundMatrix[8] = bg_mat.m20;
        backgroundMatrix[9] = bg_mat.m21;
        backgroundMatrix[10] = bg_mat.m22;
        backgroundMatrix[11] = 0;
        backgroundMatrix[12] = bg_mat.m30;
        backgroundMatrix[13] = bg_mat.m31;
        backgroundMatrix[14] = bg_mat.m32;
        backgroundMatrix[15] = bg_mat.m33;

Note how we deliberately zero out the translation components.

Yuri, for render-to-texture and multipass rendering, the way Aviatrix3D does these is through extensions on the Texture and TextureComponent classes. Shaders have a completely separate structure that separates the programs from the arguments and allows mixing both the ASM program and GLSLang programs to run together in the same scene graph. We’ve broken our class structure down a lot more fine-grained than Java3D has though, which allows us to do this. I’ll post a class structure sometime later in the week for you guys to have a look at. I’m about to head off down south on another work trip in 30min so running out of time.

#8

Hi,

[quote]Does this even need a separate rendering pass?
[/quote]
No. For enabling/disabling depth buffer, you even don’t need separate shader - you can call setDepthBufferWriteEnable(false) on RenderingAttributes of the Appearance of your shape, and you will get exactly what you are doing in your code (depth writes will be auto-enabled again when needed under control of state management code).

[quote]I’m not 100% sure my interpretation of “rendering pass” is correct
[/quote]
I name “rendering pass” process of rendering several shapes grouped by some criteria (Background rendering pass, Opaque rendering pass, Transparent rendering pass, Foreground rendering pass, etc.). In some cases the same shape should be rendered on several rendering passes with different appearances to achieve specific effects (OK, this is rare case and is not implemented in Xith3D right now). The best example is if you want to make houses on the street and other cars reflecting on the car’s body: on the 1st pass you render surrounding without a car on the texture, and after on 2nd pass you render surrounding AND car on your scene, with car env. textured with texture generated on pass 1.

[quote]I think a Shader/ShaderPeer combo can solve this - disabling the depth buffer on the “shade” call and enabling it on the “doneShading” call. Is there a better way of doing it?
[/quote]
I think it is better to use RenderingAttributes, because of even for background you MAY need depth buffer writes enabled.

[quote]What class files/methods should I be looking at?
[/quote]
Take a look at display(…) method of CanvasPeerImpl in JOGL renderer. From there you will exactly get the idea of rendering passes and how background is handled now. Note that every call to drawBin(…) is a rendering pass.

Yuri

#9

Hi,

[quote]Yuri, for render-to-texture and multipass rendering, the way Aviatrix3D does these is through extensions on the Texture and TextureComponent classes. Shaders have a completely separate structure that separates the programs from the arguments and allows mixing both the ASM program and GLSLang programs to run together in the same scene graph.
[/quote]
Yes, this is pretty clear. What I want to achieve is a logical and transparent mechanism for associating which shapes should be rendered on which pass, so we can set up a scene and after call only renderOnce() once per frame letting core code update all of the dynamic textures when needed.

Yuri

#10

Yuri,

Thanks for the pointer to the setDepthBufferWriteEnable method. It does make any shader to do the same completally redundant. I had been looking at those display and drawBin methods while looking into the Background node issue. Thanks for defining rendering pass for me (i.e. rendering pass == drawBin) makes perfect sense.

Justin,

Thanks for that code, that is exactly what I was looking for! I wanted a way to do it with raw OpenGL calls to make it faster. Also, we may as well make it Java3D compatable now.

Yuri - If I were to implement this more complex version of the Background Node (i.e. where the geometry transform is kept equal to the view) what would be the correct way to do it (is this where a shader is appropriate)?

Cheers,

Will.

#11

I have fixed the Background geometry support, at least partially.

The code I changed is the getBackgroundTransform method in com.xith3d.scenegraph.View. It appears the existing code was just for testing code or something - basically it was broken so I replaced it with how I think it should work.

The code works as expected - most of the time. In my project, I have a static generated terrain (GeometryArray) and several other objects loaded with the ASE loader. The strangest thing happens sometimes, normally when there are not many objects on the screen - the terrain either jumps ~10m up or falls ~10m down. The moment another object enters the view everything looks good again.

It’s proving a hard bug to find, so I would appreciate your help.

Anyone who has a project with a camera capable of viewing most of the scene (i.e if it’s attached to a unit or whatever), please try adding this extreemly primitive sky box (actually a pyrimid) to your scene. It’s not meant to look pretty and only to test the background node:


            TextureLoader.tf.registerPath("./data");
            BranchGroup m = new BranchGroup();
            
            {
                  Shape3D sh = new Shape3D();
                  
                  Point3f [] pts = new Point3f[5];
                  pts[0] = new Point3f(-10f, -10f, 10f);
                  pts[1] = new Point3f(-10f, -10f, -10f);
                  pts[2] = new Point3f(10f, -10f, -10f);
                  pts[3] = new Point3f(10f, -10f, 10f);
                  pts[4] = new Point3f(0f, 10f, 0f);

                  int [] indicies = {
                        0, 2, 1,
                        0, 3, 2,
                        0, 4, 1,
                        1, 4, 2,
                        2, 4, 3,
                        3, 4, 0
                  };

                  Point3f [] coords = new Point3f[] {
                        pts[0], pts[2], pts[1],
                        pts[0], pts[3], pts[2],
                        pts[0], pts[4], pts[1],
                        pts[1], pts[4], pts[2],
                        pts[2], pts[4], pts[3],
                        pts[3], pts[4], pts[0],
                  };

                  
                  
                  TexCoord2f[] texCoords = new TexCoord2f[] {
                        new TexCoord2f(0f,0f),
                        new TexCoord2f(1f,0f),
                        new TexCoord2f(1f,1f),
                        
                        new TexCoord2f(1f,1f),
                        new TexCoord2f(0f,1f),
                        new TexCoord2f(0f,0f),
                        
                        new TexCoord2f(0f,0f),
                        new TexCoord2f(1f,0f),
                        new TexCoord2f(1f,1f),
                        
                        new TexCoord2f(1f,1f),
                        new TexCoord2f(0f,1f),
                        new TexCoord2f(0f,0f),

                        new TexCoord2f(0f,0f),
                        new TexCoord2f(1f,0f),
                        new TexCoord2f(1f,1f),
                        
                        new TexCoord2f(1f,1f),
                        new TexCoord2f(0f,1f),
                        new TexCoord2f(0f,0f),
                  };                        
                  
                  TriangleArray ta = new TriangleArray(coords.length, GeometryArray.COORDINATES | GeometryArray.NORMALS | GeometryArray.TEXTURE_COORDINATE_2 );
                  
                  ta.setCoordinates(0,coords);
                  ta.setTextureCoordinates(0,0,texCoords);
                  
                  ta.calculateFaceNormals();

                  sh.setGeometry(ta);

                  Texture2D texture = (Texture2D) TextureLoader.tf.getMinMapTexture("rustycan.jpg");

                  Appearance a = new Appearance();
                  a.setRenderingAttributes(new RenderingAttributes());
                  
                  a.getRenderingAttributes().setDepthBufferWriteEnable(false);
                  a.setTexture(texture);
                  sh.setAppearance(a);
                  BranchGroup group = new BranchGroup();
                  group.addChild(sh);
                  Background bg = new Background(group);
                  m.addChild(bg);
            }

Where “rustycan.jpg” is a texture of your choice and there is a BranchGroup named “m” in your method which is added to the scene.

Screen shot of my test environment when working:

Will.

#12

I should add that you will need to do a cvs update first as I just committed the fix then.

Also, I haven’t looked into the scaling idea yet (" scale the world by the distance to the rear clipping plane").

Will.

#13

I found the problem. All that was needed was to reset the current OpenGL matrix when the normal view is reset. I think any geometry which was not a child of a TransformGroup was simply drawn without changing the Matrix (which was done for geometry in TransformGroups hence the strange error).

Don’t bother running my test now.

If you want, you can check out a very basic demo - Xith3DBackgroundGeomTest.

All the tools are there now to create a proper Skybox with the Background node. Enjoy!

Will.

#14

nice work Will and thanks :slight_smile:

#15

Thanks :slight_smile:

Here is a real skybox:

Textures created in Terragen using the method described in this tutorial: http://www.delphigl.de/tutorials/skybox.html

Code coming soon.

Will.

PS.

and look - it doesn’t get fogged (unlike the old xith3d style “big box” ones)

WD.

#16

Cool! Nice to see you got it all working. I was at a bit of a loss to help you debug stuff as I’m not very familiar with the Xith3D internals. I read them every so often to see what you guys are doing for some given task, but the way our internals work are like chalk and cheese. Best I can do is give a rough guide on how we might do something at the low leve GL callsl. So, if you guys need to do something that we’ve already got in AV3D, feel free to drop me a line and ask questions about what we did and what worked/didn’t work.