Quickest way to calculate what to draw (jogl)

[Mickelukas]

Hi all,

I posted a thread yesterday regarding VBO/Displaylist for speed but during writing it I realized that the problem wasn't the VBO's but the calculations around them.

I am currently doing as follows:
Fill 160 VBO's with 1024 triangles each (3072 vertices). After that I store the buffer ids into a hashmap that looks something like this:
Hashmap<Position, Buffer>.

When my view has changed I do an unproject on each corner of my application against z=0 to get a rectangle (getRedrawViewport) containing what coordinates I can see. I don't think that the unproject is a problem because I get the same fps when I move my camera and when I don't.

My loop in the display function to pick up the correct hashmaps looks like this:

(Containers.getContainersize() is the size of the VBOs, they are all of the same size)

for (int i=(int) Math.floor(getRedrawViewport().getX()/Containers.getContainersize());i<Math.ceil(getRedrawViewport().getMaxX()/Containers.getContainersize());i++){
   for (int j=(int) Math.floor(getRedrawViewport().getY()/Containers.getContainersize());j<Math.ceil(getRedrawViewport().getMaxY()/Containers.getContainersize());j++){
      CurrentPos=new Point2D.Double(i,j);
      int[] ids = Containers.GetBufferIds(CurrentPos);
      //Draw the buffers
   }
}

What is the quickest way to do this because I don't think I'm doing it right.

If you want more info just give a shout.

Thanks in advance.

[gouessej]

What about using some space partitioning method(s)? BSP trees? Octrees? Cells and portals?

[cylab]

I don't get this loop (maybe you can eloborate), but this way you would have a lot of checks especially with bigger redraw viewports. Another problem might be, that you don't take the zaxis and perspective projection into account.

I think what you are after is view frustum culling: http://www.lighthouse3d.com/opengl/viewfrustum/

Edit: Later you can look into space partinioning, but with 160 objects you probably can check each every frame.

Games published by our own members! Check 'em out!

[Mickelukas]

What about using some space partitioning method(s)? BSP trees? Octrees? Cells and portals?

Those words meant nothing to me but I'll google them

[Mickelukas]

I don't get this loop (maybe you can eloborate), but this way you would have a lot of checks especially with bigger redraw viewports. Another problem might be, that you don't take the zaxis and perspective projection into account.

Sure, the loop goes as following:
Each container has an incrementing x and y value (so 0,0;0,1;1,0;1,1 and 156 more). I have created a rectangle of which of these are currently visible (so if the rectangle is (7,7,2,2) I loop through the x values 7, 8 and 9 and the y values 7, 8 and 9 and for each combination I do a get on my hashmap to get the FBO buffers I should draw.

The z values and perspective projection are taken into account when I generate the rectangle of what I can see, I have a fixed range for z.

I think what you are after is view frustum culling: http://www.lighthouse3d.com/opengl/viewfrustum/

Edit: Later you can look into space partinioning, but with 160 objects you probably can check each every frame.

They do it the other way around. Instead of saying "This is what you see, get all the objects inside it" they loop through all objects and ask "do I see this object?" Is that preffered when it comes to performance?

[cylab]

They do it the other way around. Instead of saying "This is what you see, get all the objects inside it" they loop through all objects and ask "do I see this object?" Is that preffered when it comes to performance?

Yep. It's the standard way of doing it and combined with spatial partitioning and hierarchical bounds very fast even with a lot of objects.

The z values and perspective projection are taken into account when I generate the rectangle of what I can see, I have a fixed range for z.

So all of your objects are coplanar at a fixed z-value?

Those words meant nothing to me but I'll google them

Actually your approach seems to be some kind of space partitioning, but flat and not hierarchical, which would make out the benefit of space partitioning. The theory is that you can rule out groups of partitions because the test criterion for the parent partition already discards the spatial area in the check.

[Mickelukas]

Yep. It's the standard way of doing it and combined with spatial partitioning and hierarchical bounds very fast even with a lot of objects.

I'll change it around and see what happens, also, it is fine for performance to have the combination position and buffers in a hashmap or should I do it in another way?

So all of your objects are coplanar at a fixed z-value?

Nope, but they do have a max and a min so when I generate the rectangle of what is visible I do the calculation 8 times and take the points furthest away (once per corner per absolute z value).

Actually your approach seems to be some kind of space partitioning, but flat and not hierarchical, which would make out the benefit of space partitioning. The theory is that you can rule out groups of partitions because the test criterion for the parent partition already discards the spatial area in the check.

Sounds reasonable, I'll look into partitioning and the buzz words in the previous post.

Thanks alot everyone

[cylab]

I'll change it around and see what happens, also, it is fine for performance to have the combination position and buffers in a hashmap or should I do it in another way?

Leave alone the hashmap, they will likely be slower than flat lists for only 160 objects and the sole position is unsufficient for fustum culling anyway. Store the 160 VBOs along with their position and bounds (spherical for starters, since sphere<->plane intersections are are fast and easy to compute) in a simple list/array/whatever and iterate over them every frame. Once you grasped spatial partitioning trees you can make your own container hierarchy.

[Mickelukas]

After messing with performance during the whole day I have some other tips as well:

Only call gl.glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT); when you really, really need to, it takes alot of time (relatively) to clear.

Avoid both new as well as hashmaps in your display loop.

If using overlay only draw what really needs to be drawn.

Thanks alot guys.