I have a couple of questions about portal systems for visibility determination that I couldnt find any info on and I hope somebody here could answer.
How do you keep track of which cell the player is currently in? Do you contain each cell in a bounding box? if so, what about cells that aren't box shaped?
Also I have read that a good method is to project the portal into screen space and check which objects in the connecting cell are within the 2d bounds of the portal. Could anybody explain how to do this I dont really understand how to project the portal from world to screen space and test collisions with objects this way.
thanks,
Portal visibility culling
How do you keep track of which cell the player is currently in? Do you contain each cell in a bounding box? if so, what about cells that aren't box shaped?If your cells aren't box shaped, they should probably be convex polytopes., which can be described as an array of planes (if a point is on the 'inside' of every plane in the array, then it's inside the polytope). You can start by checking against each cell's bounding box first (which might give more than 1 result), and then do the more expensive plane test for every cell that passed the first test.
Also I have read that a good method is to project the portal into screen space and check which objects in the connecting cell are within the 2d bounds of the portal. Could anybody explain how to do this I dont really understand how to project the portal from world to screen space and test collisions with objects this way.[/quote]To project a point from world to screen, you multiply it with the view-projection matrix.
Author
Ok, so would you check the players bounds against all of the cell bounding boxes each frame? or would you need to keep track of the players movement through portals to speed this up?
So when you project the corners of the portal into screen space and build a 2D bounding box from them how do you project the objects to screen space and get a 2D box from those? Would you take the corners of the objects bounding box and project them to screen space and then create the smallest 2D box from the 8 corners?
Thanks so much for the tips!
So when you project the corners of the portal into screen space and build a 2D bounding box from them how do you project the objects to screen space and get a 2D box from those? Would you take the corners of the objects bounding box and project them to screen space and then create the smallest 2D box from the 8 corners?
Thanks so much for the tips!
In theory, the latter is optimal. However, it's probably complicated to implement, wheras the former option is simple (if somewhat brute force). I'd probably default to the first option, and only worry with the complexity of actually tracking the player if it turned out to be prohibitively slow.
Ok, so would you check the players bounds against all of the cell bounding boxes each frame? or would you need to keep track of the players movement through portals to speed this up?
So when you project the corners of the portal into screen space and build a 2D bounding box from them how do you project the objects to screen space and get a 2D box from those? Would you take the corners of the objects bounding box and project them to screen space and then create the smallest 2D box from the 8 corners?[/quote]Yes, you could project all 8 points and take the min/max to get their 2D bounds.
Also, I forgot to mention before that projection requires a few more steps than just "multiply with the view-projection matrix". After that multiply, you've got a vec4 result -- to convert that to a 2D position you've then got to perform perspective division, which means divide the result by it's own [font=courier new,courier,monospace]w[/font]/[font=courier new,courier,monospace][3][/font]/[font=courier new,courier,monospace]4th[/font] component. That then gives you a 2D point from (-1,-1)to(1,1), so you've then got to remap it if you want a (0,0)to(1,1) value, e.g. [font=courier new,courier,monospace]final = result * 0.5 + 0.5[/font]
Alternatively, you can turn this around and transform your portal's 2D bound into a 3D frustum. If you take the 4 corners of that bounding rectangle, and unproject them (mul with inverse viewproj matrix) with z=0 and z=1, then you get 8 3D points that are the bounding frustum of the portal. This frustum (bounding volume of the 8 points) is equivalent to 6 planes -- instead of the above 2D test, you could test each object's 3D bounds against this 3D frustum.
Author
One thing, with the last point you made, would that not be a much slower method than just creating a frustum from the 4 corners in the first place?
Also do you have any opinion on whether projecting to screen space vs creating frustums from the portals is faster?
Also do you have any opinion on whether projecting to screen space vs creating frustums from the portals is faster?
Yes the screen space idea is probably simple and fast. I mentioned the 3D case just to get you thinking about other possibilities.
e.g. A more advanced 3D version would take the 2D outline of each portal (could be more than 4 sides -- e.g. an octagonal window portal) and create a plane from the observer's position and each of those lines, so the 3D 'frustum' for testing is an extruded octagon instead of an extruded rectangle.
e.g. A more advanced 3D version would take the 2D outline of each portal (could be more than 4 sides -- e.g. an octagonal window portal) and create a plane from the observer's position and each of those lines, so the 3D 'frustum' for testing is an extruded octagon instead of an extruded rectangle.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
