Hi all I am designing a rendering engine for a 3d visualization application , typically supporting arcball rotation , zoom and panning operations. My problem is as follows : I will be required to render scenes where number of polygons is in the order of 100M. Thus i have to use some culling method before I actually send data to OpenGL for rendering. What is the best method i could use for this purpose ? I have looked into Scene graphs and octrees. And am not able to decide which is the better one. What are the other methods that are typically used for applications such as this ? I will explain my problem in more detail : 1. I am working on visualizing large 3d-datasets. 2. The visualization algorithms generate large polygonal data that needs to be rendered. A typical algorithm would be an algorithm for isosurface extraction. It generates a lot of triangles making up the surface. 3. So there will be no polygons that can be calculated in advance. Everything happens as the users requests for something. 4. Another algorithm requeires me to render ellipsoids at each point , on the 3d datasets , hence leading to as many ellipsoids as the number of data points. 5. Rendering all this without any culling is going to be too costly , thats why i am looking at some culling algorithm to filter out data that will not be visible from a particular viewpoint / orientation. thanks in advance [Edited by - _gl_coder_one_ on September 28, 2006 8:48:49 PM]

The best method is the one that most closely matches your data. How is it organised?

I will explain my problem in more detail :

1. I am working on visualizing large 3d-datasets.

2. The visualization algorithms generate large polygonal data that needs to be rendered. A typical algorithm would be an algorithm for isosurface extraction. It generates a lot of triangles making up the surface.

3. So there will be no polygons that can be calculated in advance. Everything happens as the users requests for something.

4. Another algorithm requeires me to render ellipsoids at each point , on the 3d datasets , hence leading to as many ellipsoids as the number of data points.

5. Rendering all this without any culling is going to be too costly , thats why i am looking at some culling algorithm to filter out data that will not be visible from a particular viewpoint / orientation.

Quote:Original post by _gl_coder_one_
I will explain my problem in more detail :

1. I am working on visualizing large 3d-datasets.

2. The visualization algorithms generate large polygonal data that needs to be rendered. A typical algorithm would be an algorithm for isosurface extraction. It generates a lot of triangles making up the surface.

3. So there will be no polygons that can be calculated in advance. Everything happens as the users requests for something.

4. Another algorithm requeires me to render ellipsoids at each point , on the 3d datasets , hence leading to as many ellipsoids as the number of data points.

5. Rendering all this without any culling is going to be too costly , thats why i am looking at some culling algorithm to filter out data that will not be visible from a particular viewpoint / orientation.

Sounds like data handling and display optimization is needed early on in early graphics design of this particular project.

1. Prepare for optimum storage and read/write access minimizing your data processing tasks as much as possible to speed things up.

2. Sounds like you're going for a high level of detail, so researching realtime rendering algorythm's might help, but I'd start with any special hardware based functionality to speed up the process first, such as optimal usage or your near and far clipping planes.

3. Not sure totally what you mean here unless you're talking about using dynamic data calculations in realtime via realtime processing, like a simulation of a tornado, sky, or water, but even those things use pre-determined math methods as things are known ahead of time about what causes things to interact such as particles, even when randomly generated when we as programmers program something even if it's to have a variable result we're still programming our computer's hardware on how to react and see things logically. Much like robotics, speech recognition, and other interactive design via programmed logic.

4. You'll have to work with the algorythm to accomplish this, the information is out there but it sounds like you've already got this one figured out.

5. Yeah, near far clipping planes etc, there's no need to render or display anything that is beyond your viewing frustum, such as the near/far left, right, and behind you. Just imagine your eyes, if you're looking forward at something unless you've got eyes in the back of your head you're not gonna see what's directly behind you, so if you're moving around in a 3D environment and you've got a chair object that's behind you and has a Z value of -1 and you're facing Z+ and at Z = 1 then there's no need to render the object behind you as you cannot see it unless you turn to your side to where you can see the object. This is just an example. But what I'm saying is if it's not meant to be visible anyways don't handle it.

Keep it as straight forward and simple as possible, it'll save you headaches later.

Knight Chat X said

Quote:
5. Yeah, near far clipping planes etc, there's no need to render or display anything that is beyond your viewing frustum, such as the near/far left, right, and behind you. Just imagine your eyes, if you're looking forward at something unless you've got eyes in the back of your head you're not gonna see what's directly behind you, so if you're moving around in a 3D environment and you've got a chair object that's behind you and has a Z value of -1 and you're facing Z+ and at Z = 1 then there's no need to render the object behind you as you cannot see it unless you turn to your side to where you can see the object. This is just an example. But what I'm saying is if it's not meant to be visible anyways don't handle it.

The z-buffer algorithms happens in hardware , which is pretty much the end of the pipeline . My problem is to find the best way to cull unwanted objects / polygons much earlier , even before a GL call for them is given.
Will octree provide me with a good method for the same ?

Coming to octrees , should i construct an octree of OBJECTS , or an octree of POLYGONS ?

Quote:Original post by _gl_coder_one_
Knight Chat X said

Quote:
5. Yeah, near far clipping planes etc, there's no need to render or display anything that is beyond your viewing frustum, such as the near/far left, right, and behind you. Just imagine your eyes, if you're looking forward at something unless you've got eyes in the back of your head you're not gonna see what's directly behind you, so if you're moving around in a 3D environment and you've got a chair object that's behind you and has a Z value of -1 and you're facing Z+ and at Z = 1 then there's no need to render the object behind you as you cannot see it unless you turn to your side to where you can see the object. This is just an example. But what I'm saying is if it's not meant to be visible anyways don't handle it.

The z-buffer algorithms happens in hardware , which is pretty much the end of the pipeline . My problem is to find the best way to cull unwanted objects / polygons much earlier , even before a GL call for them is given.
Will octree provide me with a good method for the same ?

Coming to octrees , should i construct an octree of OBJECTS , or an octree of POLYGONS ?

Ok, before the stuff is processed, got it, well, that would be by choice of design and usage, but I'd tend to believe working with objects themselves would be much less complicated than dealing with the individual polygons themselves unless it was something such as part of a floor and you wanted to subdivide it and not display the quads behind you and not within the camera's view, I hope that makes sense.

Hope you're able to come to a simple and straight forward solution you need that works the way you want it too, goodluck!

Quote:Original post by _gl_coder_one_
Knight Chat X said

Quote:
5. Yeah, near far clipping planes etc, there's no need to render or display anything that is beyond your viewing frustum, such as the near/far left, right, and behind you. Just imagine your eyes, if you're looking forward at something unless you've got eyes in the back of your head you're not gonna see what's directly behind you, so if you're moving around in a 3D environment and you've got a chair object that's behind you and has a Z value of -1 and you're facing Z+ and at Z = 1 then there's no need to render the object behind you as you cannot see it unless you turn to your side to where you can see the object. This is just an example. But what I'm saying is if it's not meant to be visible anyways don't handle it.

The z-buffer algorithms happens in hardware , which is pretty much the end of the pipeline . My problem is to find the best way to cull unwanted objects / polygons much earlier , even before a GL call for them is given.
Will octree provide me with a good method for the same ?

Coming to octrees , should i construct an octree of OBJECTS , or an octree of POLYGONS ?

Ok, before the stuff is processed, got it, well, that would be by choice of design and usage, but I'd tend to believe working with objects themselves would be much less complicated than dealing with the individual polygons themselves unless it was something such as part of a floor and you wanted to subdivide it and not display the quads behind you and not within the camera's view, it depends on your view, I hope that makes sense.

If not just think of it like you have a complete mesh object, and you can only see part of it, the rest of the polygons which are beyond the view of your camera don't need to be rendered, so whatever culling algorythm you use or make yourself could ignore the polygons which are beyond the camera's view so they aren't processed at all.

If you were choosing to go by polygon only and an object made up of many polygons had different sized polygons and culling omitted polygons of the object and left empty spaces the mesh would look messy when displayed if it wasn't done right as anything that would still be displayed within the camera's view could show area's where those polygons are missing.

Hope you're able to come to a simple and straight forward solution you need that works the way you want it too, goodluck!

[Edited by - Knight Chat X on September 29, 2006 2:12:38 AM]