DGL • Thema anzeigen - Rendering Faces + FPS

Rendering Faces + FPS

Moderator: DGL-Team

Seite 1 von 1

[ 10 Beiträge ]

Druckansicht

Vorheriges Thema | Nächstes Thema

Autor

Nachricht

Stucuk

Betreff des Beitrags: Rendering Faces + FPS

Verfasst: Mo Sep 20, 2004 21:37

DGL Member

Registriert: Mi Jul 21, 2004 22:39
Beiträge: 360
Wohnort: UK, Scotland

Im wondering if when rendering 1074 tryangles the fps should be at a decent ammount. I wonder because RTCW renders a scene with about 88 FPS, helios renders the exact same scene with a FPS of 12........ Even when there is only 64 tryangles it only gets 40 FPS.

Note: RTCW has a FOV of 90, Helios has a FOV of 45, thus the RTCW image's corridor looks longer

Dateianhänge:

Dateikommentar: Escape1.bsp - Helios - Wireframe

ESCAPE1_0018.jpg [241.98 KiB]
109-mal heruntergeladen

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Zuletzt geändert von Stucuk am Mo Sep 20, 2004 21:47, insgesamt 1-mal geändert.

Nach oben

Sascha Willems

Betreff des Beitrags:

Verfasst: Mo Sep 20, 2004 21:44

DGL Member

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++

I guess the Q3-Engine uses plenty of optimizations for rendering (as for example PVS, (C)VAs and so on), so this may be the cause of your lower FPS.

P.S. : Plz don't post screenshots with swastikas/hooked crosses in here, cause those symbols are forbidden (and will give trouble) here in germany, as is RTCW (there is a special localized version of RTCW made for germany, without any third reich references). So please pay attention to this when posting new screenshots.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nach oben

Stucuk

Betreff des Beitrags:

Verfasst: Mo Sep 20, 2004 22:04

DGL Member

Registriert: Mi Jul 21, 2004 22:39
Beiträge: 360
Wohnort: UK, Scotland

Removed Both screenshots with the flag. Was wondering why the RTCW site said it may b against the law to view it....... personaly i think the flag looks cool.

Helios has PVS and Frustrum culling.

Zitat:

Compiled Vertex Arrays
The EXT_compiled_vertex_arrays extension adds two functions which allow you to lock and unlock your vertex arrays. When the vertex arrays are locked, OpenGL assumes that their contents will not be changed. This allows OpenGL to make certain optimizations, such as caching the results of vertex transformation. This is especially useful if your data contains large numbers of shared vertices, or if you are using multipass rendering. When a vertex needs to be transformed, the cache is checked to see if the results of the transformation are already available. If they are, the cached results are used instead of recalculating the transformation.

The benefits gained by using CVAs depend on the data set, the video card, and the drivers. Although you generally won't see a decrease in performance when using CVAs, it's quite possible that you won't see much of an increase either. In any case, the fact that they are fairly widely supported makes them worth looking into.

Going by the lock references im guessing they mean something like

Code:

if LockArrays then glLockArraysEXT(0, numOfVerts);

which is in the code. Its disabled in the code(LockArrays = false), but when enabled there is no gain or loss.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Nach oben

Sascha Willems

Betreff des Beitrags:

Verfasst: Mo Sep 20, 2004 22:12

DGL Member

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++

Hm, if you use the (almost) same rendering code (I guess Q3-View is much like the Q3-Engine itself, concering rendering) as the Q3-Engine, then you maybe doing too much things on your CPU, so you're CPU-Bound. You posted some sources here recently about the shaders, where you do many things on the CPU (like if-statements and so on), which could be a (but not THE) cause of your lower performance.
But nonetheless, I suggest you to put your geometry in VRAM using VBOs or Displaylists, but that may only help if you're bound by vertexthroughput (which much likely isn't the case on modern GPUs). You should also try to eliminate as many statechanges as you can. Especially texture changes are very (the most expensive ) expensive, so try to sort your scene by textures.

P.S. : CVAs are deprecated. They we're state-of-the-art back in Q3-days, but should always be replaced by VBOs.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nach oben

Stucuk

Betreff des Beitrags:

Verfasst: Mo Sep 20, 2004 22:35

DGL Member

Registriert: Mi Jul 21, 2004 22:39
Beiträge: 360
Wohnort: UK, Scotland

When shaders are off there isn't much gain(it jumps from 11 to about 17) so the shaders can't be causing much(well 17 is still along way from 60, which is the cap point) fps loss. Currently each face's texture is applyed even if the same texture is used multipul times, it shouldn't be hard to arange the faces by order of texture, then only call the bind once per texture.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Nach oben

Sascha Willems

Betreff des Beitrags:

Verfasst: Mo Sep 20, 2004 22:38

DGL Member

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++

That should be your problem then. I had the same thing some days ago, where I (lazy as I was) rendered a huge level with an octree and just assigned the texture before rendering a face. After sorting the faces by texture, I gained much performance. And as texture changes are really expensive, your performance should go up by some hundred percent.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nach oben

Stucuk

Betreff des Beitrags:

Verfasst: Mo Sep 20, 2004 23:15

DGL Member

Registriert: Mi Jul 21, 2004 22:39
Beiträge: 360
Wohnort: UK, Scotland

Well, made it so it sorted the faces by texture id after being sorted by depth. Even when i made the shades only have one layer(multipul layers means shaders with multipul layers have to call bind) the increase in fps was about 2-3 FPS, with 200 odd binds being saved. With multipul layers no increase in FPS and only 49 binds saved.

The guy that made q3mapviewer has made alot of state changes..... glEnableClientState, glDisableClientState

EDIT: after more tinkering the binds saved is 786, some setdefult's were removed too(it set states to the defult settings). The fps is now about 16fps. FPS over the whole map has improved, max fps is now 50 insted of about 40, lowest the fps goes is about 10fps insted of 4fps. But its still low.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Nach oben

Stucuk

Betreff des Beitrags:

Verfasst: Mi Sep 22, 2004 02:21

DGL Member

Registriert: Mi Jul 21, 2004 22:39
Beiträge: 360
Wohnort: UK, Scotland

with further thinkering 17-18 fps.

Anyway would changing it from being TForm.Idle() activated to a timer make it faster or slower? Iv taken out about as much code as i can without the program having bugs.

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Nach oben

Sascha Willems

Betreff des Beitrags:

Verfasst: Mo Sep 27, 2004 20:47

DGL Member

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++

Stucuk hat geschrieben:

Anyway would changing it from being TForm.Idle() activated to a timer make it faster or slower? Iv taken out about as much code as i can without the program having bugs.

Gah, I knew I wanted to answer here, but I had to leave my PC, so I just forgot writing my anwser :
If you do a Done := False; at the end of your TForm.Idle, then it's the same as if you would do a mainloop by yourself. And a timer would be the worst solution, cause (depending on windowsversion) the resolution of a timer is too low (under Win98 it was 55ms, even if you set it to something lower), so that using a timer would slow your app down by a very big margin.

P.S. : Does your engine also work with maps from Wolfenstein : Enemy Territory? If yes, you could send it to me (compiled) and I could see if it's also so slow on my Radeon.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Nach oben

Stucuk

Betreff des Beitrags:

Verfasst: Di Sep 28, 2004 16:59

DGL Member

Registriert: Mi Jul 21, 2004 22:39
Beiträge: 360
Wohnort: UK, Scotland

It should work with Et maps, ill install ET and test. Will post a download after iv tested it (i don't know how portable it is.... Only been tested here and on a friends ATI where it crashed when loading a map......)

Helios can read:

IBSP maps version 46(Quake) and 47(RTCW.... which to my knowlage has no differences than 46...)
RBSP maps version 1(JKA, never tryed SOF2), since i could only find one site on RBSP the lightmaps are screwed(RBSP adds more fields to the file which are ignored)

RBSP = Raven's BSP, IBSP = ID's BSP

_________________
Free Map Editor - Game Requirements - Stucuk.Net
-Stu

Nach oben

Seite 1 von 1

[ 10 Beiträge ]

Foren-Übersicht » English » English Programming Forum

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 2 Gäste

Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.