Is there any open source engine allowing to perform portal culling?

Hi!

I don’t succeed in ending the implementation of the portal culling, especially the computation of new frustums by using the portals. I would like to look at any other open source engine written in Java that already implements this algorithm to understand how it works. JPCT allows portal rendering but it is not open source. EgonOlsen, if you read this, can you at least explain to me the different steps to project the portal onto the near plane? Xith3D does not use portal culling, JME neither (of course, I’m implementing this feature in it), 3DzzD neither :frowning: Is there any open source engine written in Java allowing to perform portal culling?

You could just use JPCT, it now has the option to use your favourite JOGL ::slight_smile:
I know there are a few minor open sourced engines, but not sure if any have what you want… Ill have a basic look around.

Blogger

PM

Ta.

This might have what you want: http://www.espresso3d.com/

Don’t know of an source code, but it should be fairly straight forward. Maybe we can help you threw it. The frustum is a set of planes. The portal is a convex polygon. Then you have to clip the polygon against the planes. Then you have to create a plane for each edge in the clipped polygon. This will be the new frustum that you use in the next room.

Clipping a polygon against the view frustum is a common operation in old software renderers, so there should be able to find information about it. Google for “frustum polygon clipping” or something similar.

Good luck.

edit: how to clip:

No as it is not open source.

It is a good piece of news for the people who push JOGL like me :smiley:

Thank you for your help.

Good idea.

I’m watching it, it use portal culling :smiley: Excellent :smiley:

Thank you very much, it is a precise explanation.

Hi!

I found what was wrong in my code in the way of using the culled test and now I get the expected behavior :smiley: Thank you.

It works almost fine but there is still a problem. I follow these steps:
if a portal is inside or intersects with the currently used frustum
then
look for its leftmost point
look for its rightmost point
look for its topmost point
look for its bottommost point
left <- max( abscissa of the leftmost point , current frustum left )
bottom <- max( ordinate of the bottommost point , current frustum bottom )
right <- min( abscissa of the rightmost point , current frustum right )
top <- min( ordinate of the topmost point , current frustum top )
sub-frustum <- copyOf( current frustum )
sub-frustum.left = left
sub-frustum.right = right
sub-frustum.top = top
sub-frustum.bottom = bottom

As my explanation might be not clear enough, please look at this article, it deals with some algorithms used in Fallout 3:
http://geck.bethsoft.com/index.php/Occlusion_Culling
My sub-frustum seems to be too small whereas I only get normalized device coordinates of the portal and I convert them into frustum coordinates. When I create a sub-frustum from the current frustum, should I change anything else than left, right, top and bottom?

Normalized device coordinates are defined in the explanation below:

[quote]Object Coordinates are transformed by the ModelView matrix to produce Eye Coordinates.

Eye Coordinates are transformed by the Projection matrix to produce Clip Coordinates.

Clip Coordinate X, Y, and Z are divided by Clip Coordinate W to produce Normalized Device Coordinates.

Normalized Device Coordinates are scaled and translated by the viewport parameters to produce Window Coordinates.
[/quote]

I guess you have to multiply x, y, z with w and then multiply that point with the inverse of the projection matrix.

Although I think you are making it difficult for yourself. I think it would be easier to do everything in world space. Also don’t get hung up on “frustum” word in the article. A frustum is just a set of plane. Don’t use frustum culling in your algorithm. Write your own culling that starts off with the frustum planes. Just my opinion.

If I do this, I will get the eye coordinates according to the FAQ of OpenGL, won’t I?

I have to implement the portal culling as smartly as I can by using existing features of JME 2.0 when it is possible. If I write my own culling, I will compute the frustum planes whereas they are already computed in an object of JME 2.0. I have succeeded in using the frustum culling of JME, it is not the problem and the result is already interesting (the blue print is at least between 2 and 4 times faster now) but when I try to create my own frusta, it does not work anymore. I have already spent some months on it, I cannot restart from scratch whereas 95% of the source code is reliable (it does what it is expected to do) :-\

You have just given me an interesting idea… Maybe I should rather use the clip coordinates instead of the normalized device coordinates and then apply some transformations by using the frustum parameters to get the “frustum” coordinates. I will try this when I’m back home.