Mia Max, on 26 January 2012 - 04:30 AM, said:
Is there an extra thread that explains more about polymer?
I guess many questeions have alraedy been asked about it in this thread, but there are too many posts in here to find answers without searching an awful long time, taking even more time when you don't understand english very well like me.
For example, what does limitate the fps?
I just looked on GPU and CPU-usage during playing and realized that GPU-usage is at 20% and CPU-usage at 50%, but in some scenes I got under 30 fps.
It would be much easier to bulid maps if I knew more about it to avoid low framerates.
For now, the only way you can avoid low fps is by keeping your map fairly simple in construction, and also making sure that there are only a few lights (especially spotlights) which are shining on rendered surfaces at any given point in the map. It's fine to use detailed textured and models, though. I asked about Polymer optimizations a while ago in a different thread, and here is how Plagman replied. It's the most detailed information that we have about it to date, and I believe it all still applies. I underlined the part which seems most relevant to explaining the low fps.
http://forums.duke4....dpost__p__88492
Plagman, on 31 May 2011 - 09:39 PM, said:
The problem isn't that we need to brainstorm for optimization ideas, it's that I have to break everything and put it together in a different fashion. It's been known from the start; I've done it like that at first because it's always easier to get something that works right than something that works right and well. Too bad that only applies to the short term.
There are several different problems; one aspect a map is made of a lot of planes that are all drawn separately from front to back; materials are switched between each plane, and each time a red wall is crossed a "portal" is drawn to determine if the sector that follows needs to be queued for rendering or not. This constant material switching and drawing only one plane at a time isn't really efficient. The former causes a lot of state validation and thrashing, while the latter doesn't utilize the GPU in an efficient fashion. It's constantly submitting tiny pieces of work and reaping it, causing a lot of idle time waiting for the results. This also causes big maps with lots of red walls to be insanely complex to draw.
Another problem is that the multi-pass drawing approach uses a lot of fillrate as soon as a fairly big plane gets a few too many lights on it.
Things that needs to be done:
- Move the diffuse modulation from the material to the vertex attribute. That would cause the amount of different materials in a map to be all the different tiles used, instead of the more complex tile X shade.
- Move plane vertex attributes from several unique vertex buffers to a single storage or several depending on the staticness of the data.
- With a more reasonable material count and stuff sharing buffers, we can start batching planes together. To leverage that, throw planes into material buckets instead of rendering them right away. When we're done building index buffers for the buckets, submit them in one big go (one per material).
- Change the HSR walking to do a first pass before doing the actual shaded drawing. This means that in the event that occlusion queries have to be reaped, we can get the result a lot faster since we're pushing a lot less pixels using a passthrough fragment program.
- For rendering the shadow maps, we only need materials for sprite silhouettes. The rest can be batched in a single draw call after building the right index buffer, same as above. This will be a lot faster.
(Even) bigger projects:
- Defer the lighting model to shade from a fat buffer instead of inline. This eliminates two very expensive steps, light culling and multi-pass drawing.
- Instance models together.