OpenGL 3d engine doubts

Recommended Posts

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]

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

Share on other sites
Well for starters a scene graph is just a representation of the data in a scene. An octree is a culling method used to simplify the data in a scene graph before working on it.

To start, what are your known variables. Do you know what the scene will look like before you start processing it? For working with that many triangles it might be beneficial to look at some sort of ray-tracing option, since that would scale better with higher triangle counts. But I would only go that route if it makes sense with the data you have.

I'd suggest some more research into real-time rendering algorithms, a great book would be "Real-time Rendering" by Moller.

Share on other sites
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.

Share on other sites
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.

Share on other sites
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 ?

Share on other sites
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!

Share on other sites
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]

Create an account

Register a new account

• Forum Statistics

• Total Topics
627702
• Total Posts
2978712
• Similar Content

• A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

-What I'm using:
C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.
-Questions
Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?

• Both functions are available since 3.0, and I'm currently using glMapBuffer(), which works fine.
But, I was wondering if anyone has experienced advantage in using glMapBufferRange(), which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
• By xhcao
Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness.
• By cebugdev
hi guys,
are there any books, link online or any other resources that discusses on how to build special effects such as magic, lightning, etc. in OpenGL? i mean, yeah most of them are using particles but im looking for resources specifically on how to manipulate the particles to look like an effect that can be use for games,. i did fire particle before, and I want to learn how to do the other 'magic' as well.
Like are there one book or link(cant find in google) that atleast featured how to make different particle effects in OpenGL (or DirectX)? If there is no one stop shop for it, maybe ill just look for some tips on how to make a particle engine that is flexible enough to enable me to design different effects/magic
let me know if you guys have recommendations.
• By dud3
How do we rotate the camera around x axis 360 degrees, without having the strange effect as in my video below?
Mine behaves exactly the same way spherical coordinates would, I'm using euler angles.
Tried googling, but couldn't find a proper answer, guessing I don't know what exactly to google for, googled 'rotate 360 around x axis', got no proper answers.

References:
Code: https://pastebin.com/Hcshj3FQ
The video shows the difference between blender and my rotation:

• 21
• 14
• 12
• 10
• 12