Hi all,
is there some scenegraph support for portals and bsp’s? For instance something similar to the PortalNode in the WildMagic3 graphics engine?
It’s not yet there, but on the list for 0.10.
Cep has already implemented BSP tree code, I did the same for portals. What’s missing yet is the big picture. I hope that once 0.9 is out and alive, a bunch of guys starts discussing about this type of stuff.
You can find my latest stuff here: http://jmonkeyengine.com/jmeforum/viewtopic.php?t=1168. It’s merely to show that it can be done with the engine rather than being usable off the shelf.
I think David Eberly gives a picture how to include BSP’s and Portals together into a game engine. He does it by adding a new type of node to the scene graph. This node culls all unvisible objects away. The source code of his engine can be downloaded from:
http://www.wild-magic.com/Web/Source.html
The BSP-Portal-System is in the ‘sorting’-package of his engine. There
is also a small demo-level named ‘Castle’ showing the indoor/outdoor rendering skills of the engine like it could be used in a game. It would be nice to see some similar demo for jME.
Actually, what I did is a port of major parts of this exact code you’ve given 
Ahhh, i see . . . :// Is it possible to get the code without copying and pasting it. Also the code for AbstractCamera.java would be nice since the output of ‘diff’ looks somewhat strange. I would prefer a complete code listing. 
What is with the BSP support? I thought in WildMagic3 it is integrated with the concept of portals. :?
BSP normally would be used to quickly find out, where you are inside your scenegraph. This can be used to find the complex region you’re in and it can be used for collision detection.
I found though that portals break some scenegraph tree rules (and they do so in the wild magic code, too), since they alter the rendering order (room 2 may be visible from room 1, but once you render room 2, you must be careful not to render room 1 again eg.). Additionally, I did not have any BSP input. If you look at the Eberly code, they do not provide something which generates BSP’s, they have a hardcoded BSP for their single example. And providing BSP input other than borrowing it from eg. a Q3 bspc would be a very complex thing for a simple tech demo. Therefore I completely left out the BSP stuff - portals can work without BSP’s.
That’s the reason why I said it is not yet in: A decision must be made:
a) if the jME scene graph code will really support BSP’s, Portals, PVS;
b) if so, which way it does this;
c) in which way the input data for these is provided.
The reason why the AbstractCamera diff is complex is that the jME original does not contain the code for the additional checkplane stack pushing and popping. I then had to extend all the BoundingVolume classes, too, in order to not break their contracts.
Meanwhile I think, that additional check planes were a nice thing 10 years back, but in these days the rendering in the graphics board is so fast, that the additional plane checks will rather degenerate the performance than increase them. We’ll see.
If you still want, I could send you my code via mail.
That would be great, so i could see it in action 
My e-mail is
gruenewa@informatik.hu-berlin.de. Thanks (!)
Expect it someday over the weekend, there is carnival going on here in the Rhineland