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 ?
[quote]So, 2D (textured quads) or 3D ? Or maybe both ? Can we mix them ?
[/quote]
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.
[quote="<MagicSpark.org [ BlueSky ]>,post:21,topic:24436"]
Probably switches are faster than de/reactivating BranchGroups.
[/quote]
Ok but wouldnt this be exactly using the speed of a swich?
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…
[quote="<MagicSpark.org [ BlueSky ]>,post:21,topic:24436"]
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 ?
[/quote]
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 
Oh excuse me I didn’t understood really what you were talking about. Multiple switches aren’t necessary
Yes indeed.
[quote=“jaakko777,post:23,topic:24436”]
Yes me too. Okay, so I propose to start another subject talking about that.
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.
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?