PowerMacX Wrote:Frustrum culling is handled automatically (if roughly) by the graphic card (if no part of a patch lies inside the frustrum, it doesn't try to render the list at all).

That seems highly unlikely. Do you have any proof?

OneSadCookie Wrote:That seems highly unlikely. Do you have any proof?

This are the results on my MacBook:

Terrain rendering:
- Centered on the screen: 351 fps
- Completely outside the viewing frustum: 373 fps
-> Speed-up: 6.27%

- Centered on the screen using a display list: 448 fps
- Completely outside the viewing frustum using a display list: 630 fps
-> Speed-up: 40.6%

- Drawing disabled, just swapping buffers: 630 fps

Ugly (but short) test I made with code borrowed from NeHe for the terrain:
http://rapidshare.de/files/34707374/Test...t.zip.html

How to test:
1. Move the mouse as close as possible to the middle of the window, see the fps in the title.
2. Move the mouse away until the terrain is completely out of view, check the fps again
3. Click once to switch to Display List mode (the title will read "123 DL")
4. Repeat 1 & 2
5. Press the space to disable the terrain rendering altogether, check the fps again

For my PowerMac with an X800:
≈1760 fps with the display list on and off the screen
≈2260 fps with nothing being drawn

Conclusion: It's going so fast, it may just be the overhead of calling the GL functions that's causing the discrepancy, especially since no matter whether a vertex is on screen or not the framerate doesn't seem to change. (even in immediate mode, which goes at like 440 fps)

Intel Core Duo iMac @ 1.83GHz, Radeon X1600:

483, on- or off-screen with the normal
943 on-screen with the display list
1103 off-screen with the display list
1298 without rendering

There's definitely an inexplicable advantage to having the display list when it comes to off-screen rendering.

I wonder whether enabling a vertex shader removes that advantage.

Wow this thread has been busy since I've been at band camp. But I'm back now.

I've been messing around with vertex arrays and VOB's. This is not something I've ever done before. (Yeah, I wrap my drawing code in glBegin/glEnd.)

It's a bit difficult on the VOB side of things because my copy of the red book is for OpenGL 1.4, at that point there was no such thing in the OpenGL core. But using a copy of "OpenGL Distilled" from the library I was able to learn about VOB support added in 1.5.

I'm writing a new class just for VOB's and Vertex Arrays. (I know, I'm going OOP crazy! ) And I was wondering.

How soon do most systems receive updates to OpenGL when they become available? How likely is it that most people with PC's at home (including windows boxes) have OpenGL 1.5? I ask because I'm wondering if it's worth it to deal with some more complex memory handling that arises using vertex arrays without vertex objects.

Thanks!

EDIT: PowerMacX, when I run your app and hit space-bar to start the display list I don't see anything. I do get like 400Fps though.

EDIT 2: You guys have crazy video cards. I get 50fps with normal rendering on my Radeon 9550. I'm too lazy to recompile it just so I can boast about framerates on my GeForce 6800 GS in my PC.

The reason why you didn't see anything is because that's exactly what it's supposed to do. Clicking switches between immediate mode and display list.

With vertex arrays, when you change the data there's no need to do anything else: the data is stored in main memory, which means it's sent over each time. With VBOs, however, you will need to replace the changed data in the buffer stored by OpenGL. (which may be in main memory or on the video card, depending on the implementation and how often you say the data is to be changed) To see if VBOs are supported, you can check for ARB_vertex_buffer_object. (or also check for the version of OpenGL) However, it's best to use the extension version for the video cards that only support lower versions of OpenGL, but do still support VBOs.

As akb825 says, and I'm sure I've told you before, ignore the version of OpenGL.

Check for the extension support instead. In this case, ARB_vertex_buffer_object.

Mac OS X 10.4.3 and later support ARB_vertex_buffer_object on all hardware. Mac OS X 10.3.4 (?) and later support it on all hardware with hardware T&L capabilities (only excludes the Rage 128, essentially).

The Rage 128 doesn't have hardware T&L??? No wonder why it was so crappy...

Ok, ignore version but check extensions and use extension even if core does not support it due to old-version stuff.

What I meant when I talked about the memory complications was that I didn't want to re-write the system I had now, despite the fact that I could get faster rendering even without using vertex arrays, display lists or VOBs. It's just a task of pre-calcing more stuff. If it ain't broke don't fix it.

I suppose sacrificing 131 072 floats worth of memory here and there wouldn't hurt *too* much. It's only likely there will be one terrain per-level/scene/whatever.

It may not be broken, but it sure as hell will run dog slow if your entire game is in immediate mode. (including terrain... )

131072 floats is less than a MB o_O

OneSadCookie Wrote:hardware T&L capabilities (only excludes the Rage 128, essentially).

Intel GMA 950... (but it does have ARB_vertex_buffer_object I thinky)

OneSadCookie Wrote:Mac OS X 10.3.4 (?) and later support it on all hardware with hardware T&L capabilities (only excludes the Rage 128, essentially).

Did you mean earlier?

He meant later, as in 10.3.4 - 10.4.3. As for the GMA 9050, since no computer with ti can run earlier than 10.4.3, how any versions beforehand would react isn't really an issue.

OneSadCookie Wrote:131072 floats is less than a MB o_O

But it *sounds* like a lot. It's actually just about 0.5mb.

First thing I'm gonna do is speed up normal immediate rendering. Then add display list capability, then finally I'll add VOB stuff, probably in that order.

EDIT: I changed my system to use less CPU and more memory. Sure enough, it broke.