Portals, somehow

Believe it or not, I managed to develop something portal-like in jME, based (very losely) on the example code I found in the Wild Magic repository. No BSP trees yet, though. I found that they are not really necessary for portals.



I now need someone with more knowledge than I have (so no high demands here :slight_smile: to look into this and tell me, whether this is complete bllsht or at least somehow useful. Looking at my small example programm in wireframe mode, I’d say that at least under the expected circumstances the correct convex regions are no longer painted.



Anyone interested?

I am. What features of portals did you implement?

I implemented 3 classes so far: ConvexRegionManager, ConvexRegion and Portal.



A ConvexRegionManager extends Node. It maintains a spatial representing the “outside” ie. everything outside the portal-controlled regions. Additionally, it maintains an array of ConvexRegions.



A ConvexRegion extends node and maintains it’s representation (a Spatial containing the geometry of the convex region itself) and an array of Portals, which are leading out of the region.



A portal is not a Spatial at all. It maintains a planar convex polygon representing the portal itself and a reference to the adjacent region.





Currently you have to set up all necessary data yourself. The small test app I have written sets up the following situation


+


+
+   1    +
+---+===++
    | 2  |
+---+===++
+    3   +
+
+


That is, three regions 1, 2 and 3, connected to each other via portals (there is a block surrounding everything which represents "outside", too).
Region 1 has 1 portal, region 2 has 2 portals, region 3 has 1 portal again.

If the draw method of the ConvexRegionManager is called, it checks, whether the camera currently is inside any of it's regions (check is currently via bounding box, so it is inaccurate somehow). If the cam is not inside any region, outside is drawn. If it is, the draw method of the region is called.

The draw method of the region calls draw of all its portals, which checks, whether the portal is in the view frustum (via a bounding sphere, again not very accurate). If it is, the adjacent region is drawn. After the portal drawing, the representation of the ConvexRegion is drawn.

That's it, roughly.

My next plan is to write something which understands Q3 BSP files and creates a scenegraph from it. Then I'll take a look at whether I can make any use of the portal hints in the BSP files. Then I'll have a look, whether BSP-based rendering will gain any improvements. Currently, I have no plans to implement the BSP partitioning/creation algorithm. The problem with it is that you need to create the best possible BSP tree, ie. the one which splits the lowest number of polygons. As this is an np-complete problem, it cannot be done realtime - that's the reason for BSP map compilers. So the only advantage I can see is improving the rendering itself, if the BSP information is already there.

One day it would be nice then to think of how this all can be converted into a .jme file. But I would like to make it work in the engine first.

I can post the current source code here, if appreciated.

BTW, cep, you're not using your ICQ account? I tried to contact you several days ago.

Put it in code review form.

"Badmi" wrote:
Put it in code review form.

I will put some improvements into the code and enhance it, maybe tomorrow. Then I will place it here - I currently do not see it as something that is ready to go into jme.

Can you get it so that it autogenerates the portals rather than us having to set the portals by hand?



Im sure there is a method to determine whether a model is open or closed…



DP

"DarkProphet" wrote:
Can you get it so that it autogenerates the portals rather than us having to set the portals by hand?

Im sure there is a method to determine whether a model is open or closed....

DP
Consider the following situation: you have a hollow cube and centered in it is a sphere. With any automatic solution for generating portals that I found you would create zillions of portals and the engine would be dying from the clipping calculations. I doubt that there is an automatic solution for this - generating a bsp tree is an easy task compared to portal finding. Finding the optimal bsp tree is just a matter of time. Finding "optimal" portals without at least a hint seems a hopeless task.

hehe, fair enough. :slight_smile: