DGL
https://delphigl.com/forum/

Rendering Faces + FPS
https://delphigl.com/forum/viewtopic.php?f=19&t=3268		 Seite 1 von 1
Autor:  Stucuk [ Mo Sep 20, 2004 21:37 ]
Betreff des Beitrags:  Rendering Faces + FPS
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
Autor:  Sascha Willems [ Mo Sep 20, 2004 21:44 ]
Betreff des Beitrags: 
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.
Autor:  Stucuk [ Mo Sep 20, 2004 22:04 ]
Betreff des Beitrags: 
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:
  1. 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.
Autor:  Sascha Willems [ Mo Sep 20, 2004 22:12 ]
Betreff des Beitrags: 
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.
Autor:  Stucuk [ Mo Sep 20, 2004 22:35 ]
Betreff des Beitrags: 
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.
Autor:  Sascha Willems [ Mo Sep 20, 2004 22:38 ]
Betreff des Beitrags: 
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.
Autor:  Stucuk [ Mo Sep 20, 2004 23:15 ]
Betreff des Beitrags: 
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.
Autor:  Stucuk [ Mi Sep 22, 2004 02:21 ]
Betreff des Beitrags: 
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.
Autor:  Sascha Willems [ Mo Sep 27, 2004 20:47 ]
Betreff des Beitrags: 
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.
Autor:  Stucuk [ Di Sep 28, 2004 16:59 ]
Betreff des Beitrags: 
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
Seite 1 von 1 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/