Methods to boost rendering speed

Luminary
Posts: 5,143
Joined: 2002.04
Post: #16
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?
Quote this message in a reply
Moderator
Posts: 771
Joined: 2003.04
Post: #17
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
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #18
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)
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #19
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.
Quote this message in a reply
Jones
Unregistered
 
Post: #20
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! Rasp ) 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. Rasp

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.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #21
The reason why you didn't see anything is because that's exactly what it's supposed to do. Rasp 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.
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #22
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).
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #23
The Rage 128 doesn't have hardware T&L??? No wonder why it was so crappy...
Quote this message in a reply
Jones
Unregistered
 
Post: #24
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. Rasp

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.
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #25
It may not be broken, but it sure as hell will run dog slow if your entire game is in immediate mode. (including terrain... Cry)
Quote this message in a reply
Luminary
Posts: 5,143
Joined: 2002.04
Post: #26
131072 floats is less than a MB o_O
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #27
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)
Quote this message in a reply
Moderator
Posts: 522
Joined: 2002.04
Post: #28
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?
Quote this message in a reply
Moderator
Posts: 1,140
Joined: 2005.07
Post: #29
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. Rasp
Quote this message in a reply
Jones
Unregistered
 
Post: #30
OneSadCookie Wrote:131072 floats is less than a MB o_O

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

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. Rasp
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  what methods can't be used in display lists? ghettotek 9 4,165 Feb 9, 2003 12:47 PM
Last Post: OneSadCookie