Mixing parallel and perspective projection in the same frame

[endolf]

Hi

is it possible to render a scene using perspective projection, then switch to parallel and render a few more things over the top each frame?

Endolf

[Spasi]

Yes, of course.

[arne]

This is possible? How? I think you have to set parallel and perspective mode in View - and you can't change it during rendering, because that's jogl/lwjgl doing and only one call in Xith3d.

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

[endolf]

Any hints as to how?

I mean, I can figure out that I do something like

1   2   3   4

view.setProjectionPolicy(View.PERSPECTIVE_PROJECTION); view.renderOnce(); view.setProjectionPolicy(View.PARALLEL_PROJECTION);

but at that point, if I call view.renderOnce() again, the scene has the 3d parts in it, and not the 2d parts. I don't want to have to start removing objects from the scene tree and placing other ones in it, twice a frame, every frame. Also, I have a background, and if I renderOnce again I'll lose what I rendered the first time won't i?

Endolf

[Riven]

I've never worked with Java3D or Xith3D but...

Can't you use the SwitchNode to switch between the 2D/3D branches then?

If this sounds like I completely missed the point, I probably did

[endolf]

I could yes, I just want to make sure that when I draw the second part of the frame, that I don't end up clearing the buffer at the same time, ie, I still need what I last rendered. I *think* xith does an equivelant of a glClear

Endolf

[Spasi]

Whoops, sorry, I just noticed this is the Xith3D forums.

[endolf]

So does anyone know how to tell xith to 'draw this frame over the top of the prvious one, allowing any transparent objects to show what was drawn the frame before'?

Endolf

[Amos Wenger]

So does anyone know how to tell xith to 'draw this frame over the top of the prvious one, allowing any transparent objects to show what was drawn the frame before'?

Endolf

I think this would require a modification in the Xith code, because the screen shouldn't be filled with the background color between the 2 renders.

[William Denniss]

This sounds like an issue relating to multi-pass.  Unfortuantely Xith3D has never really implemented this feature -- there are other nice things like render to texture that fall in the same bucket (I think).  Yuri has raised this topic previously on a few occasions.

If you have an idea on how best to implement this, please start a dialog on the topic

Will.

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

[arne]

I looked at the CanvasPeerImpl code for jogl. There is a function called setDisableClearBuffer(boolean disable), which turns the glClear off.
So you can mix parallel and perspective, you'll only have to remember your CanvasPeerImpl and switch setDisableClearBuffer on and off.

Arne

[William Denniss]

endolf have you tried this?

Perhaps we should make it an abstract RenderOption so LWJGL can implement it too.  Potentially you could simply have two RenderOptions objects lying around and just swich them in and out each frame.

Will.

[jaakko777]

Ok so i got this kind of rendering loop. It's working very nicely exept for one small but annoying thing (which is obious) - the hud flickers a bit.

1   2   3   4   5   6   7   8   9   10   11   12

// run the rendering loops         mySceneGraph.setRenderable(true);          myHud.setRenderable(false);          view.setProjectionPolicy(View.PERSPECTIVE_PROJECTION);          canvasPeer.setDisableClearBuffer(false);          view.renderOnce();                    mySceneGraph.setRenderable(false);          myHud.setRenderable(true);          view.setProjectionPolicy(View.PARALLEL_PROJECTION);          canvasPeer.setDisableClearBuffer(true);          view.renderOnce();

How can i do in xith so that the buffers dont get swapped automatically, intsead i would swap it after im done rendering the hud.
Can this be done? Yes. 
How?

---
Edit:

Ok I found out how to disable the automatic swapping.

1	canvasPeer.setForceNoSwap(true);

But now i dont know how to swap it manually.. 

[c_lilian]

may be exposing the glFlush() instruction ?

(search for renderDone() in canvas peer impl)

Lilian

[jaakko777]

I have tried this:

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

canvasPeer.setForceNoSwap(true); while(true) {     // run the rendering loops    mySceneGraph.setRenderable(true);     myHud.setRenderable(false);     view.setProjectionPolicy(View.PERSPECTIVE_PROJECTION);     canvasPeer.setDisableClearBuffer(false);     view.renderOnce();     mySceneGraph.setRenderable(false);     myHud.setRenderable(true);     view.setProjectionPolicy(View.PARALLEL_PROJECTION);     canvasPeer.setDisableClearBuffer(true);     view.renderOnce();     canvasPeer.getGl().glFlush();

... but it didnt work.

[jaakko777]

Ok, i figured out a way to do it
Thanks to all that helped!!

Here is what i did in case someone finds this useful:

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

// render loop while(true) {     // render the scene, clearing the buffer before doing it    mySceneGraph.setRenderable(true);     myHud.setRenderable(false);     canvasPeer.setDisableClearBuffer(false);     canvasPeer.setForceNoSwap(true);     view.renderOnce();     view.setProjectionPolicy(View.PARALLEL_PROJECTION);     // render the hud, not clearing the buffer before    mySceneGraph.setRenderable(false);     myHud.setRenderable(true);     canvasPeer.setDisableClearBuffer(true);     canvasPeer.setForceNoSwap(false);     view.renderOnce();     view.setProjectionPolicy(View.PERSPECTIVE_PROJECTION); }

So sum it up i keep the setForceNoSwap as true as long as i still want ro render more frames and finally set it to false before the final frame rendering.

[Amos Wenger]

Great ! and does it work really well ?
Your GUI is made of textured quads, aren't there ? But are they simply foreground nodes ?

[c_lilian]

Now we should try and encapsulate it ...

may be with a Switch node and a MultiPassView(View) (each switch beeing a pass) ?

Lilian

[arne]

nice ... very nice

MultiPassView sounds nice...
maybe we could do it like this?:

1   2   3   4   5   6   7   8   9   10   11

class MultiPassView extends View {   ArrayList<Switch> renderpasses;   public void addRenderPass(Switch s) { renderpasses.add(s); }   public void removeRenderPass(Switch s) ..   public void render() {     for(Switch s : renderpasses) {       // set settings, activate switch and render     // deactivate switch    }   } }

or we could also add a class RenderPass, where we can set the combination of switches, that should be set during that render pass.

Anybody even better ideas?

Arne

[jaakko777]

Thanks.

Great ! and does it work really well ?
Your GUI is made of textured quads, aren't there ? But are they simply foreground nodes ?

Yes it works quite well indeed with no performance loss.
Or, hmm.. I havent faced any problems yet but also havent had the time to test it extensively.

I havent really built up the gui yet (just two foreground node shapes so i can see that it renders).
Infact i still havent really decided how ill implement the gui.. 
Textured quads sounds like a good idea for a traditional gui.
Though, I cant get over the idea to make a really 3D ui with interactive components...  Something like switches and such things. It would be cool but lets see, maybe ill end up with a "simple 2D" gui.

nice ... very nice

MultiPassView sounds nice...
maybe we could do it like this?:

1   2   3   4   5   6   7   8   9   10   11

class MultiPassView extends View {  ArrayList<Switch> renderpasses;  public void addRenderPass(Switch s) { renderpasses.add(s); }  public void removeRenderPass(Switch s) ..  public void render() {  for(Switch s : renderpasses) {  // set settings, activate switch and render // deactivate switch }  } }

or we could also add a class RenderPass, where we can set the combination of switches, that should be set during that render pass.

Anybody even better ideas?

Arne

Sounds great!
But let me ask (maybe) a stupid question:
Why need multiple Switches? Wouldnt just one do if it contains for example BranchGroups that represent the different passes?
Please correct me if i missed something.. 

[Amos Wenger]

Probably switches are faster than de/reactivating BranchGroups.
jaakko777, I soon will arrive in the GUI implementation phase in my game. I would be pleased if we could, with the others Java Games gurus, think about that, and why not make a "reutilisable" system for Xith. (I had this project some weeks ago, but I didn't concretized it)
So, 2D (textured quads) or 3D ? Or maybe both ? Can we mix them ?

[arne]

So, 2D (textured quads) or 3D ? Or maybe both ? Can we mix them ?

It's only parallel perspective, so you should be able to mix it.

Parallel perspective has the advantage, that you don't have to use picks to determine, where you've clicked on the gui.

[jaakko777]

Probably switches are faster than de/reactivating BranchGroups.

Ok but wouldnt this be exactly using the speed of a swich?

1   2   3   4   5   6   7   8   9   10   11   12   13

class MultiPassView extends View {    Switch renderpasses;    public void addRenderPass(Node n) { renderpasses.addChild(n); }    public void removeRenderPass(Node n) ..    public void render() {       for(int i = 0; i < renderpasses.numChildren(); i++) {          // set correct node         renderpasses.setWhichChild(i);          // set other settings and render         ...       }    } }

If multiple switches are faster, could someone explain to me why.. 

jaakko777, I soon will arrive in the GUI implementation phase in my game. I would be pleased if we could, with the others Java Games gurus, think about that, and why not make a "reutilisable" system for Xith. (I had this project some weeks ago, but I didn't concretized it)
So, 2D (textured quads) or 3D ? Or maybe both ? Can we mix them ?

If you suggest some sort of joint effort you can count me in if we can pull it off relatively quickly, meaning that i dont want to get stuck in long debates (referring to the existing threads about GUI implementation*)  since im working on a game project and there are other's that are going to need some sort of gui soon.  Apart from that i would really much like to contribute to this great API!

*) Not that i wouldnt hold them in value, on the contrary thanks to those threads i got started on the right track in the firts place   

[Amos Wenger]

If multiple switches are faster, could someone explain to me why.. 

Oh excuse me I didn't understood really what you were talking about. Multiple switches aren't necessary

If you suggest some sort of joint effort...

Yes indeed.

you can count me in if we can pull it off relatively quickly, meaning that i dont want to get stuck in long debates (referring to the existing threads about GUI implementation*)  since im working on a game project and there are other's that are going to need some sort of gui soon.  Apart from that i would really much like to contribute to this great API!

Yes me too. Okay, so I propose to start another subject talking about that.

[jaakko777]

Looking into the source of View.renderNode() it actually seems to return faster from there if a Node is set as not renderable than it returns if its a Switch.

Could someone familiar with the rendering engine confirm this? Especially regarding the case we are dealing with in this thread.

[jaakko777]

It seems that by default in PARALLEL_PROJECTION the coordinate system is such that the edges of the screen on the x-axis are allways 1.0f and -1.0f.
It's quite practical from one point of view but what if i want to draw something on the screen that does not get resized if the screen is resized. Can the coordinate system be somehow made "ignorant" of the screen size?