openGL questions before starting 3d engine code

chopplebrains
Unregistered
 
Post: #1
A friend and I are going to be developing a realtime 3d engine soon. Right now we are doing research before design and implementation. We have approximately 25 weeks to get a basic engine implemented, and we have to have some meaningful features up and running in 10weeks. :um: I have found that there is a lot of conflicting information out there, so I thought it might be a good idea to post some direct questions.

A little about our problem: We have been tasked to write an engine that will run on windows, linux, and mac. To begin with we are going to use openGL, and later add direct 3d support for the win platform. The engine will be used to display real scientific data for our local university, and it is going to be used to bring a game feel to applications meant to teach childern about science, oceanogrophy, environment, etc. So basically, the purpose is two fold: enable realtime networked discussion of data sets, and be able to be used to play 3d games for learning purposes.

Thanks in advance for the help.

opengl questions:

1: Does opengl do clipping automatically? I dont believe it does occlusion culling, so if we implement an algorthim to stop wasting cycles on 3d objects not in the frustrum, will open gl correclty clip the geometry that is partially contained in the view frustrum? Even if it does, how fast is it? Would it be faster (although more work intensive for us) to write our own clipper?

2: Concerning transformations... Is it faster to do our own vector/matrix math and then pass the completed matrix to opengl, or is it faster to make calls to glRotate, glTranslate, etc. I have heard there is a speed up by doing the math yourself, and then loading the matrix through glMultMatrix. Is this true?

3: What is a good model format to use with opengl? The md2 seems to have a lot of documentation, and it seems fairly straight forward to implement. However, the pieces of the model dont seem to fit individually into a scene graph structure. Rather, the model would itself be one node in a graph, instead of having arms, legs, head, being children of a torso node. Is my assumption correct? Is there a better format that is easy to implement, looks good, and is versitile? (We will be useing key frame animation since a lot of modeling packages that will use our software have support, and this type of animation seems to be simplest to implement)

4: Does opengl always use hardware support for its operations (as long as the hardware is there)? We are gauraunteed that any machine (at least the ones we care about) have at least a geforce 2, but most will have a geforce 3. If opengl doesnt automatically use hardware, how do i tell it to do so?

//----mac specific-----//

5: We will be using carbon on osx. Should we use the apple event handling methods, or the newer carbon methods for events? What is an efficent (in terms of our process--we dont care about other things running on the cpu while our engine is the active app) message/event loop? The RunApplicationEventLoop() in carbon seems to steal control. Is there such a thing as a NULL message? So, we can tell the loop to do some processing or do some rendering even though we are not recieving mouse/keyboard/etc. events? The only way i have seen to do this is through the apple event methods. Sorry if my mac lingo isnt correct, i have only been mac programming for a day, but i am pretty impressed with the mac communnity and dev tools for the os.


Thanks for the help and for tollerating such a lengthy post. Any advice is appreciated. I just havent yet had time to go thorugh all the web documentation (and i do have a huge list of sites).
My partner and I (yes there is only 2 of us, we do have an advisor, but he knows nothing of the mac) are looking to use some message boards to get some direct answers to jump start our project.
We are really feeling the crunch of time. Blink If you are interested in helping through some advice, especially if you are an expierenced mac/opengl/3d engine programmer, please email me. chopplebrains@yahoo.com


Thanks again.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #2
Re: 1 -- OpenGL does clipping automatically. It will always be faster to use its support Smile

Re: 2 -- That entirely depends on how you're using the commands. Do whatever's easiest, benchmark/profile to find out if it's too slow.

Re: 3 -- Whatever you choose to use, you'll either be writing or stealing the model-loading code. MD2 is indeed very easy to load, but it doesn't have a lot of features you might want.

Re: 4 -- OpenGL will automatically use whatever hardware support is available.

Re: 5 -- RAEL and the new Carbon Event model are good. The general approach is to set up a timer to call you back every millisecond (in other words as fast as possible), and draw your frame from within the timer callback. This gives very good performance.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
1. yes, opengl does clipping automatically, and its faster than what you could do, and probably more reliable.

2. Using the opengl matrix stack is unlikely to become your bottleneck.

4. You can specify that you want hardware acceleration when setting up opengl, and you then get the accelerated video.

5. If you are not using classic MacOS, I suggest you do your user interface in Cocoa, as it is much easier once you have a basic setup. As far as getting cpu time, you can install timers which call your app (for examle your drawing routine) at certain intervals, whether there are events or not. If you decide to stick with carbon, certainly use the native event handling mechanism.

If you really want help, you can email me, and look at the project im my signature, the code there might be useful to you.

- D.G
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #4
I guess osc is just always faster Grin
Quote this message in a reply
henryj
Unregistered
 
Post: #5
What the other guys said plus...

2. Using glMultMatrix is usually slower but in some cases you have no choice. But 'this "unlikely to become your bottleneck"

If you are pushed for time why not use someone elses engine. There are a million of them. Especially if it has to be cross platform.

It sounds like http://www.openscenegraph.org would meet your needs nicely.
Quote this message in a reply
chopplebrains
Unregistered
 
Post: #6
Thanks very much for all of the useful, prompt replies. Unfortunately, it is not an option to use someone elses engine as was suggested--we are getting some amount of research credit at a university for this, so we need to implement the engine ourselves. We are also going to leave plugins so we can later plug in new algorithims for different aspects of the engine (a lot of graphics research going on in the computer scinece department.)

My only 2 remaining questions are a clarification on the Carbon event handling model and an input question...

Carbon Model:: In the Carbon book which i bought, it doesnt really explain using a timer mechanism to allow my app to do some processing even when the OS isnt sending an event. RunApplicationEventLoop seems like it just runs on its own until there is a message for my program. I would like to use the newest carbon model, rather than the older apple event handler model. Can someone point me to some code that addresses this problem specifically? I have spent some time digging, and downloading code from the apple site, but so far i havent seen any code that addresses this specific issue using the carbon model.

Input:: What is a good, fast way for games, to get input on OSX. It seems that input sprocket is not supported on OSX (although this seems to be the best solution for os8 and 9). I heard that the input sprocket functionality is wrapped up in OSX anyway though. What libraries, APIs or functions do i need to look at to get the fastes, most robust input for a 3d game on OSX?


Cocoa didnt seem like a good choice for us, since we will be insuring backwards compatability with os 8 and 9 later (for right now we only care about osx though).

Thanks again
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #7
I don't know if there's any sample code anywhere which does what I suggested WRT the timer, but that's literally all you have to do to get called back regularly. I've used it before, and it works well. I may have some code somewhere on my HD I can dig out.

For input, just use Carbon Events for the keyboard and the mouse. If you want joystick/gamepad support, you'll have to write two code paths, one using the HID manager for Mac OS X, and one using InputSprocket for 8.6-9.x. It's probably more work than it's worth.
Quote this message in a reply
w_reade
Unregistered
 
Post: #8
Code:
pascal void DoFrame(EventLoopTimerRef theTimer,
                    void *userData)
{
    static EventTime lastTime, thisTime;
    
    lastTime = thisTime;
    thisTime = GetCurrentEventTime();

    //...
}

//...

void StartTimer(void)
{
    EventLoopRef    mainLoop = GetMainEventLoop();
    EventLoopTimerUPP    timerUPP = NewEventLoopTimerUPP(DoFrame);
    double        frameTime = 0.001 * kEventDurationSecond;
    
    InstallEventLoopTimer(mainLoop,
                        0,
                        frameTime,
                        timerUPP,
                        NULL,
                        &g->theTimer);
}

...should work for you if you've g->theTimer is an EventLoopTimerRef - substitute your own. You'll want to keep track of it and...

Code:
RemoveEventLoopTimer(g->theTimer);

...when you've finished with it.

[edit - width, and [alt-semicolon] seems to come out as ? for some reason]
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #9
About question 1: Everyone is correct that GL does its own view frustum clipping, but that does *not* mean it's OK to just throw the whole dataset at GL each frame and let the graphics card sort it out. Doing your own visible-set determination should give you much better performance and scalability. The fact that GL does automatic clipping means that your algorithm doesn't need to be pixel-exact and doesn't need to do (more) low-level geometry processing, but it's no substitute for an efficient scene graph architecture.
Quote this message in a reply
tod_baudais
Unregistered
 
Post: #10
Since you guys are talking about Carbon Events, a few days ago I put some minimal sample code up on my site illustrating timers, mouse (position and deltas), and keyboard input. It should be a good start for any project even though some event types are missing.

Tod.
Quote this message in a reply
BobbyWatson
Unregistered
 
Post: #11
Since your app will have to run on Windows, Linux and Mac OS, why not use SDL for event managing? The same code can be used on those three platforms. SDL is available on Mac OS X (though I think the latest version can't use fullscreen OpenGL on OS X, but I'm not certain).
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #12
There is a bug with mouse deltas in full-screen mode on X in SDL 1.2.5, but everything else seems to work fine.

I too would recommend that for portability.
Quote this message in a reply
henryj
Unregistered
 
Post: #13
That's an excellent point. SDL is very good and will save you a LOT of aggravation. Use it for setting up your window, image handling and events. Plus there are a couple of gui libs that use it but from memory they suck.
Quote this message in a reply
chopplebrains
Unregistered
 
Post: #14
Thanks for all the input. SDL sounds like it is definately worth checking out. I will need somethign that can go fullscreen though. Unfortunately for me, the windows code is already done, and the mac code is getting there fast, so at this point im not sure if SDL is worth it. I will definately check it out though.

Thanks for all the code samples, they are helping--i still feel a little lost when it comes to talking to the mac os.

Above, it is mentioned that OpenGL does clipping, but to do your own preprocessing. Let me pose this question:

We are planning to have some algorithms that will do culling, so we wont waste cycles on things that are visible in the scene at all. After that we were planning on using a bsp tree (or maybe a quad tree, still weighing the pros and cons there) to see if there is anything in the frustrum that is completely hidden. AFter we determine that, we were going to let the OpenGL clipper handle the rest. Are you saying that we should have another level that we perform, like a 'rough' clipper--maybe a clipper that is very fast, but not very precise? Would that actually speed things up, or rather, would it slow down performance overall since we are now using more processing time to do something that opengl would do anyway? So, really what i am asking is if we do some rudementary clipping, will that help make opengl's clipper faster, or will the time it takes to do our own clipping offset the speed gains given to the opengl clipper?

Thanks again
Quote this message in a reply
Member
Posts: 177
Joined: 2002.08
Post: #15
Quote:Originally posted by chopplebrains

We are planning to have some algorithms that will do culling, so we wont waste cycles on things that are visible in the scene at all. After that we were planning on using a bsp tree (or maybe a quad tree, still weighing the pros and cons there) to see if there is anything in the frustrum that is completely hidden. AFter we determine that, we were going to let the OpenGL clipper handle the rest.


That's essentially what I meant, yes. OpenGL clips each polygon, but you should do visibility at the "object" level yourself, which you are Smile
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  OpenGL ES2... many questions vunterslaush 39 25,173 Sep 5, 2011 09:21 AM
Last Post: ipeku
  Starting with OpenGL, need some help wsc981 5 5,516 Jul 17, 2010 06:28 AM
Last Post: wsc981
  Starting with OpenGL ES techy 2 2,805 Dec 21, 2009 12:10 PM
Last Post: techy
  OpenGL ES questions regarding 2D mixed with 3D jeonghyunhan 5 6,227 Jun 20, 2009 03:54 PM
Last Post: jeonghyunhan
  OpenGL: glRotate and some 3D questions. mikey 1 3,791 May 19, 2009 05:11 PM
Last Post: ThemsAllTook