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?

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.

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.

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.

Quote

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.

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.

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.

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?

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...

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org