Octree + Portal engine question
Author
Hello folks. I could use help with a design issue.
I have my "outdoor" octree rendering working, and my "indoor" portal rendering working but I didnt really consider how I would track the camera from outdoor to indoor and vice versa.
What I did was for my root octree node, i had it implement ISector and thus it could also host portals to the "real" sectors for the indoor parts of the world. But this means that for this special case, I have sectors within a sector (overlapping sectors). This complicates how one determines which sector the camera is currently in each frame.
Now I could solve this by casting a ray from the previous camera location to the current frame's camera location and determining if that ray crossed a portal and if it did, switch the current sector to this new sector (potentially recursing if the ray traversed more than one portal - though this should be an unlikely scenario).
Anyone have any alternative ideas for handling this or is the ray test a reasonable enough approach? How have others combined Octree rendering with portal rendering?
Thanks.
-Hypno
Author
Actually, I guess that pretty much sums it up :)
I'm thinking the ray test is the only solution.
I'm thinking the ray test is the only solution.
Why not simply test if the camera is in the bounding volume of the of the portal sections? Simple point-box test. And if it's not inside then it must be outside.
Also it would be possible to make the outside as a portal section. Kinda a room-in-a-room solution. If the outside-inside separator portal is visible, you do either a frustum-octree (if you are inside) or a frustum-room (if you are inside) visibility test to see what to render.
Also it would be possible to make the outside as a portal section. Kinda a room-in-a-room solution. If the outside-inside separator portal is visible, you do either a frustum-octree (if you are inside) or a frustum-room (if you are inside) visibility test to see what to render.
Author
Well, the room-in-a-room solution is exactly what i'm doing now. But this poses the problem which i've been trying to describe.
A simple point in box test is not necessarily enough to guarantee that you (the player) might not fall through from the octree into a sector unintentionally... So if you're running around the world and there's a "hole" in the octree world geometry such that you fall into the bounds of a sector, or if your collision detection is a bit off somewhere, things start to go wrong.
So it just seemed to me if you enforced the transition through a portal when entering or existing a portal to or from the octree, then you could easily prevent these sorts of problems. So whether your inside or outside, the only way to go from one to the other is by physically passing through a portal.
A simple point in box test is not necessarily enough to guarantee that you (the player) might not fall through from the octree into a sector unintentionally... So if you're running around the world and there's a "hole" in the octree world geometry such that you fall into the bounds of a sector, or if your collision detection is a bit off somewhere, things start to go wrong.
So it just seemed to me if you enforced the transition through a portal when entering or existing a portal to or from the octree, then you could easily prevent these sorts of problems. So whether your inside or outside, the only way to go from one to the other is by physically passing through a portal.
Right. So this problem has nothing to do with visibility but collision detection problem instead?
If you fall into a sector you just switch to rendering that sector. You can determine if you are in a sector or not. It should have a bounding box. You can make special portals between outside and sectors. And if that is not visible, you just skip the one you are not in from the rendering queue.
It should be enough. And if they can walk into sectors thru a wall accidently then it means the collision detection is not good enough. You can use your ray idea but if I get the problem right, that is just covering up the shortcomings of the collision detection system. Hope I got it right...
If you fall into a sector you just switch to rendering that sector. You can determine if you are in a sector or not. It should have a bounding box. You can make special portals between outside and sectors. And if that is not visible, you just skip the one you are not in from the rendering queue.
Quote:A simple point in box test is not necessarily enough to guarantee that you (the player) might not fall through from the octree into a sector unintentionally...
It should be enough. And if they can walk into sectors thru a wall accidently then it means the collision detection is not good enough. You can use your ray idea but if I get the problem right, that is just covering up the shortcomings of the collision detection system. Hope I got it right...
Author
Ok, you have a point there. If the level design and the collision detection are flawless, then there's no problem with just doing a simple point in box test.
Of course, you can use outside-sector portals as a safety check. In that case, you ray solution should work. You would need a quad-ray test for that, to ensure that the camera could have only went thru there and nowhere else.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
