Track making: Performance optimization

Report issues or bugs in RVGL or ask for help regarding any Re-Volt topic.
User avatar
kiwi
Posts: 557

Track making: Performance optimization

Unread post by kiwi » Mon Jun 18, 2018 12:50 pm

Hello Re-Volt track makers,
Hello technic-interested Re-Volters,

as most of you know, I am doing my first map in Re-Volt (Spa-Volt) at the moment. It is a very ambitious map with a lot of details. At the moment, Spa-Volt has about 30.000 faces in Blender, and with the "normal" RVGL-version (Non-Shader version), I have on my fairly good computer "only" about 150-200 fps.

However, in the Shader version i reach 1000+ fps. But I know, that not everybody can/want to run the Shader version. Also a lot of guys with very low-end hardware are playing Re-Volt.

My goal is, that Spa-Volt runs as smooth as possible also on low-end hardware, with a visual appearance as good as possible.

So I want to know, what I can do to improve the performance. I have no good knowledge in terms of 3d engines/computer graphics, so Sorry for some maybe stupid questions.
  • What is causing the most issues regarding performance?
  • How do I know, how many polygons the track have? I only have the values with amount of vertics/edges/faces inside Blender - but some faces will be splitted into triangles, while exporting?
  • The more polygons visible at one time while racing, the slower?
  • When I have a big open room, it's not possible to use VisiBoxes - what other possibilities do I have to optimize?
  • When will the polygons will be calculated by the GPU? As soon as visible, or also the ones in the background?
  • How much does effects (like steam, waterdrops, waterboxes, rain) affect the performance?
  • Should I avoid to have to many effects at one place? (For example: Place 10 spark generators at one place)
  • Does lights have influence to the performance? Or is lighting only the brightness/darkness of faces?
  • How much does the textures affect the performance? Does it make a big difference, if 256x256 or 512x512 textures have to be loaded?
  • Does it makes a difference, which parts on a texture-file are mapped on which parts on the meshes? Can I optimize something?
  • When will the textures be loaded? At the loading of the track, or as soon a texture is visible?
  • Is it recommended, to use bmq, bmr,... texture files, for mip-mapping?
  • Does the fog-values inside the track.inf influence the performance a lot?
  • I guess mirrored surfaces are also causing performance issues?
  • What else is affecting the performance?
  • Any other suggestions/comments?
And one general question: Why can't the RVGL Shader-version not be set as the standard for everyone? It has really huge performance advantages, it seems.

Ciao, Kiwi
User avatar
VaidX47
Administrator
Posts: 125
From: 333

Re: Track making: Performance optimization

Unread post by VaidX47 » Mon Jun 18, 2018 1:22 pm

Kiwi wrote: Mon Jun 18, 2018 12:50 pmWhy can't the RVGL Shader-version not be set as the standard for everyone?
Shader isn't stable in every aspect, yet. It got better over the last year, but I've heard it still tends to crash in edit mode more often. Also rendering issues in some edit modes. Hence, I personally still can't use as my default.
It will eventually be default, I'm sure. Well, it is on Android port at least.
aka Vaid; >[MediaFire Stuff]<
User avatar
Marv
Developer
Posts: 236
From: Europe 2

Re: Track making: Performance optimization

Unread post by Marv » Mon Jun 18, 2018 9:06 pm

I'll try to go through the list with my semi-knowledge.

What is causing the most issues regarding performance?
Transparent polygons are probably one major concern.
How do I know, how many polygons the track have? I only have the values with amount of vertics/edges/faces inside Blender - but some faces will be splitted into triangles, while exporting?
Open a terminal in 'blender/2.79/scripts/addons/io_revolt' and type `python` (make sure it's installed), then:

Code: Select all

>>> from rvstruct import World
>>> with open("/path/to/world.w", "rb") as f:
...     world = World(f)
... 
>>> sum([m.polygon_count for m in world.meshes])
4121
The more polygons visible at one time while racing, the slower?
Yup, pretty much.
When I have a big open room, it's not possible to use VisiBoxes - what other possibilities do I have to optimize?
Not really. Games use a technique called occlusion culling for this. There's not much you can do but using polygons efficiently. Your mesh looks fine so you shouldn't worry too much.
When will the polygons will be calculated by the GPU? As soon as visible, or also the ones in the background?
As far as I know, the game only renders polygons that are within the viewport.
How much does effects (like steam, waterdrops, waterboxes, rain) affect the performance?
Since these effects are additively rendered polygons for the most part, quite a lot.
Should I avoid to have to many effects at one place? (For example: Place 10 spark generators at one place)
Yes, there is a limit for particles and they're not affected by visiboxes. You should be efficient with them.
Does lights have influence to the performance? Or is lighting only the brightness/darkness of faces?
There shouldn't be a huge impact. Lights render to the vertex color of the world and objects.
Does it makes a difference, which parts on a texture-file are mapped on which parts on the meshes? Can I optimize something?
Not as far as I know.
When will the textures be loaded? At the loading of the track, or as soon a texture is visible?
When the track is loaded
Is it recommended, to use bmq, bmr,... texture files, for mip-mapping?
Yes because mipmaps are not generated by default.
I guess mirrored surfaces are also causing performance issues?
The faces have to be rendered twice. I wouldn't call it an issue.


You shouldn't worry too much about performance since you're aiming quite high with your track. Players can lower the drawing distance if they're having problems.

Huki gave me the tip to use Jigebren's WorldCut with the values 4000, 12000 for optimal performance in the shader version.

You could also use the new texture properties to disable alpha testing: https://yethiel.gitlab.io/RVDocs/#texture-properties
The benefits of this shouldn't be much, if noticeable at all.
User avatar
kiwi
Posts: 557

Re: Track making: Performance optimization

Unread post by kiwi » Mon Jun 25, 2018 7:15 am

Thanks a lot Marv, there are a lot of usefull hints in your answer.

I've found a very usefull documentation from a swedish university, regarding performance optimization in 3d games. It's based on the Unreal engine, but most of the topics are also applicable for other 3d engines:

https://www.diva-portal.org/smash/get/d ... TEXT01.pdf

Regarding Occlusion Culling: Is RVGL able to do this in some way? (When I understand it correctly, I can't get Occlusion Culling by using VisiBoxes).
Post Reply