MultiPass & Rendering Order

[bohdan]

Hi!

I have tried to use multipass rendering to render two BranchGroups: A & B, so that group B is rendered on top of A, but with no luck... 
Is it possible to achieve? Should I know something specific about usage of MultiPassView etc..?

My problem is that I actually can achive the order but strangly only when I set to render B in PARALLEL_PROJECTION.
If I set A to render in parallel - then A would be rendered on top..

And finaly, when I set both to perspective - they are rendered just as there are no multipass (or probably I'm putting different meaning to multipass ). For example if I have cube and sphere in the same location - I can see how they overlap as in normal rendering... (See the picture), though they are in different rendering passes. Is it correct behaviour?

Bohdan.

[Marvin Fröhlich]

Please post your code, so that we can track the problem. It seems that you have done everything correctly.

[Amos Wenger]

Hey I had this "problem" but you know it's not a bug, it's features ^^

Actually I think it's because of the Z-Buffer which isn't cleared between different passes but.. I may be wrong.

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

Now I also seem to have a strange problem with the MultiPassView. It seems to ignore the rendering order, which I simply can't understand, since the passes are rendered step by step.

Please have a look at the (redesigned) HUD3DTest and you'll see the problem.

Does anyone have a clue?

Marvin

[Amos Wenger]

Now I also seem to have a strange problem with the MultiPassView. It seems to ignore the rendering order, which I simply can't understand, since the passes are rendered step by step.

Please have a look at the (redesigned) HUD3DTest and you'll see the problem.

Does anyone have a clue?

Marvin

Did you look at the rendering code yet ?

[cylab]

Now I also seem to have a strange problem with the MultiPassView. It seems to ignore the rendering order, which I simply can't understand, since the passes are rendered step by step.

Have you checked the Z-buffer thingy? I suspect the multi pass rendering is correct. Is there possibly a flag to clear the depth-buffer after finishing a pass (or before starting the next)?

[Marvin Fröhlich]

Did you look at the rendering code yet ?

Not yet. I was really tired yesterday evening. I'll hopefully do it the next hours.

Have you checked the Z-buffer thingy? I suspect the multi pass rendering is correct. Is there possibly a flag to clear the depth-buffer after finishing a pass (or before starting the next)?

Unfortunately I haven't used the z-buffer things before. I'll have to search through the code and collect information on it. Any hints?

[Amos Wenger]

Have you checked the Z-buffer thingy? I suspect the multi pass rendering is correct. Is there possibly a flag to clear the depth-buffer after finishing a pass (or before starting the next)?

Unfortunately I haven't used the z-buffer things before. I'll have to search through the code and collect information on it. Any hints?

Well Z-buffer is easy : it's used to check that polygons are rendered in the correct (perspective order). It must be cleared (or ignored) if you want to render object each on top on each other by rendering order, not Z order.

[Marvin Fröhlich]

Well Z-buffer is easy : it's used to check that polygons are rendered in the correct (perspective order). It must be cleared (or ignored) if you want to render object each on top on each other by rendering order, not Z order.

Yes, thnks, I do know the principle of z-buffering . The thing is that I don't know how ot is implemented in Xith.

[cylab]

Unfortunately I haven't used the z-buffer things before. I'll have to search through the code and collect information on it. Any hints?

search for glEnable([GL.]GL_DEPTH_TEST) and glClear([GL.]GL_DEPTH_BUFFER_BIT)

Games published by our own members! Check 'em out!

[Marvin Fröhlich]

Unfortunately I haven't used the z-buffer things before. I'll have to search through the code and collect information on it. Any hints?

search for glEnable([GL.]GL_DEPTH_TEST) and glClear([GL.]GL_DEPTH_BUFFER_BIT)

Thanks.

[Amos Wenger]

1   2   3   4   5   6   7   8   9

public void renderOnce()     {         int i = 0;         for (RenderPass pass: listRenderPasses)         {             renderOnce(pass, (i == 0), (i == listRenderPasses.size() - 1));             i++;         }     }

1   2   3   4   5   6   7   8   9

/**      * This renders just the given pass, overriding the clearBuffer and      * swapBuffer states.      *      * @param pass the pass to render      * @param forceClearBuffer      * @param forceSwapBuffers      */     protected void renderOnce(RenderPass pass, boolean forceClearBuffer, boolean forceSwapBuffers)

should it be

1	renderOnce(pass, true, (i == listRenderPasses.size() - 1));

?

[Marvin Fröhlich]

should it be

1	renderOnce(pass, true, (i == listRenderPasses.size() - 1));

?

Hmm... no. With these values the HUD3DTest end in an unrendered main scene. But thank you very much for helping me to find the clue. Please keep on searching .

[cylab]

No, I don't think so. It might be a desired behaviour to have correct z-buffering drawing while multi pass rendering. There should be a flag to control this behaviour.

On a sidenote, it should be possible to specify a texture as target of the rendering (using FBOs) except for the last pass, so you could refer to the pixels of a preceding render pass.

[Marvin Fröhlich]

No, I don't think so. It might be a desired behaviour to have correct z-buffering drawing while multi pass rendering. There should be a flag to control this behaviour.

On a sidenote, it should be possible to specify a texture as target of the rendering (using FBOs) except for the last pass, so you could refer to the pixels of a preceding render pass.

hmm... if that didn't hit the performance. I guess one shouldn't be able to grab directly into the frame buffer (too fragile).

[cylab]

hmm... if that didn't hit the performance. I guess one shouldn't be able to grab directly into the frame buffer (too fragile).

That's what FBOs are for. It's a nice thing and not too difficult to implement (if it is supported by the driver). Maybe I'll find the time and prototype this.

But thank you very much for helping me to find the clue. Please keep on searching

I think the place is right. The problem is, that the forceClearBuffer flag clears the color buffer, too. I think the implementation of renderOnce has to be extended to allow for depth buffer clearing only.

[Marvin Fröhlich]

hmm... if that didn't hit the performance. I guess one shouldn't be able to grab directly into the frame buffer (too fragile).

That's what FBOs are for. It's a nice thing and not too difficult to implement (if it is supported by the driver). Maybe I'll find the time and prototype this.

OK. Than it's good .

But thank you very much for helping me to find the clue. Please keep on searching

I think the place is right. The problem is, that the forceClearBuffer flag clears the color buffer, too. I think the implementation of renderOnce has to be extended to allow for depth buffer clearing only.

I'll check that.

[cylab]

Where do you guys put the tests and demos? The cvs repository did not contain anything like that. All demos seem to be deleted some months ago. 

[Marvin Fröhlich]

Where do you guys put the tests and demos? The cvs repository did not contain anything like that. All demos seem to be deleted some months ago. 

You probably checked out xith3d CVS. All tests and demos now resist in xith-tk.

Marvin

[cylab]

Ah, thanks

[cylab]

I took a quick look in the source. To configure the CanvasPeer to draw the render passes on top of each other, you have to call

1   2   3   4

// clear the buffer... canvasPeer.setDisableClearBuffer(false); // ...but specify, that depth-buffer clearing is not necessary canvasPeer.setFullOverpaint(true);

The MultiPassView however only calls the first in it's prepareRenderOnce() method:

1   2   3   4   5   6   7   8   9   10   11   12   13   14   15   16   17   18   19   20   21

// MultiPassView:195 ... prepareRenderOnce(RenderPass pass, boolean forceClearBuffer, boolean forceSwapBuffers, Canvas3D canvas3D) {         // (...)        if (canvas3D.get3DPeer() instanceof com.xith3d.render.jsr231.CanvasPeerImpl)         {             com.xith3d.render.jsr231.CanvasPeerImpl canvasPeerImpl = (com.xith3d.render.jsr231.CanvasPeerImpl)(canvas3D.get3DPeer());             // set clear buffer state            canvasPeerImpl.setDisableClearBuffer(!forceClearBuffer);             // set force swap state            canvasPeerImpl.setForceNoSwap(!forceSwapBuffers);         }         else if (canvas3D.get3DPeer() instanceof com.xith3d.render.lwjgl.CanvasPeerImpl)         {             com.xith3d.render.lwjgl.CanvasPeerImpl canvasPeerImpl = (com.xith3d.render.lwjgl.CanvasPeerImpl)(canvas3D.get3DPeer());             // set clear buffer state            canvasPeerImpl.setDisableClearBuffer(forceClearBuffer);             // set force swap state            //canvasPeerImpl.setForceNoSwap(!forceSwapBuffers);        } }

which results in either no clearing at all or full clearing including the color buffer.

So to solve this, a new property - named "layered" for example - should be added to MultiPassView. If this is set to true, the two canvasPeer-properties should be set like the code at the top of this post for all render passes but the first one.

I'll try this tomorrow, maybe

[cylab]

Ha!... just tested it and it seems to work. The only drawback is, that you also loose the stencil buffer in "layered-mode", but I don't know, if someone might miss it in this context...

[Marvin Fröhlich]

I took a quick look in the source. To configure ...

Great! Great!  Thank you very much.

So to solve this, a new property - named "layered" for example - should be added to MultiPassView. If this is set to true, the two canvasPeer-properties should be set like the code at the top of this post for all render passes but the first one.

Isn't multipass rendering always layered? At least it should be the default. What is the effort of multipass rendering when it's not layered?

Marvin

[cylab]

Isn't multipass rendering always layered? At least it should be the default. What is the effort of multipass rendering when it's not layered?

Dunno... maybe to better organize your scene by using multiple independent scene graphs!? Anyway, making the layered variant the default is a good idea as long as there are no compatibility concerns to change the default behaviour of the MultiPassView...

[Amos Wenger]

cylab, great to see you contribute !

When I saw "clearBuffers" I also had suspicion that it may be not only the depth buffer.

[cylab]

cylab, great to see you contribute !

How to proceed? Should I send a patch or can I have write access to the cvs rep?

I might contibute a little (render-to-texture in MultiPassView and terrain maybe), but I have little time due to work and am not always very motivated to code after a 10hour day with J2EE

[Amos Wenger]

cylab, great to see you contribute !

How to proceed? Should I send a patch or can I have write access to the cvs rep?

I might contibute a little (render-to-texture in MultiPassView and terrain maybe), but I have little time due to work and am not always very motivated to code after a 10hour day with J2EE

Please register at xith-tk and I'll give you Developer access as soon as possible.

[bohdan]

Great work cylab, I was waiting for multy-pass to really start working  So looking forward to try it out when fix is comitted.
Thanks!

[Marvin Fröhlich]

I might contibute a little (render-to-texture in MultiPassView and terrain maybe), but I have little time due to work and am not always very motivated to code after a 10hour day with J2EE

The I'd suggest you to further concentrate on terrain. It is a frequently requested feature.

[cylab]

I thought about porting this, but haven't analysed it's source yet.