Optimising Maps

[nbohr1more]

You ask but then didn't actually put any example baseline numbers for a sense of scale.

 

What kind of improvement in FPS can lightCarve do for a familiar FM scene, and how much bigger does it make the map? Are we talking like roughly +10 FPS for +30MB or what...

 

The last thing I read over at D3W the Light Carve reports were like:

 

Up to 3X the number of polyons (thus map size in MB) for 10 to 50% boost in FPS.

 

Contrary to Orbweaver's statement, the other mappers (at the time) were all advising manual splits as apposed to lightCarve but Modwiki's current word on the subject is that light counts don't matter much anymore (waste of time... just as Orbweaver stated) so just focus on shadow casting. Quake3world seems to be of the opinion that noshadows light overlaps are less important than texture batching.

 

Still... GPU resources aren't unlimited and optimizing light counts is still an option to squeeze more prettiness for less impact.

 

I am just curious how well some of the mappers fare against lightCarve and whether even HUGE maps still perform better if it is used. I'm pretty sure that since Baddcog has already extolled the virtues of manually splitting lights that his maps or ones that he's helped with probably wouldn't see any boosts.

 

I would also be tickled to see some super-duper hardcore "Brush Carve" mapper that uses ALL of the techniques including "noFragment" and "discrete" materials to bend the map compiler to his\her will.

 

Just out of curiosity:

 

If you make brushwork Func_Static the map compiler will NEVER cut it, correct?

 

If so, then if you carefully arrange Brushwork seams between Func_Static's you could let LightCarve cut them up without worrying about too many polygons being generated?

 

Best of both worlds?

[Melan]

Contrary to Orbweaver's statement, the other mappers (at the time) were all advising manual splits as apposed to lightCarve but Modwiki's current word on the subject is that light counts don't matter much anymore (waste of time... just as Orbweaver stated) so just focus on shadow casting. Quake3world seems to be of the opinion that noshadows light overlaps are less important than texture batching.

So, if I understand correctly, having a lot of lights in a rendered area, even with overlaps, is not as much of a performance hit as having them all be shadow-casting. But texture batching - meaning use less textures per rendered area? How much is "less"? Is it "don't go overboard" less or is there an idea about how much there could/should be?

Edited April 26, 2011 by Melan

[Briareos H]

Just an off remark and not meant to be taken as a criticism on what has been done, but it's a real shame that UDK came out after the inception of TDM...

[OrbWeaver]

Contrary to Orbweaver's statement, the other mappers (at the time) were all advising manual splits as apposed to lightCarve

 

Yes, there was at one point a lot of belief in the burning need for manual light carving, all based (as far as I could tell) on a single post by a mapper who discovered the use of r_showLightCount, and arbitrarily assigned particular subjective terms to count values: 1=good, 2=ok, 3=bad etc. From then on, the "NEVER HAVE MORE THAN 3 LIGHTS HITTING A SURFACE!!!!" myth seemed to take on a life of its own, with newbie mappers convinced that there would be some sudden catastrophic performance drop if a surface ever had a light count of 4.

 

but Modwiki's current word on the subject is that light counts don't matter much anymore (waste of time... just as Orbweaver stated)

 

To be fair though, I probably added that part to the ModWiki article myself in an attempt to reduce the confusion for new mappers. Even Brian Harris at id Software confirmed that they didn't bother with light carving when making Doom 3 because it wasn't a good use of time, just like in my own tests when it never made any significant difference to frame rate.

[rich_is_bored]

The engine is highly scalable so performance is a moving target. It's hard to say how much is too much other than you'll know when you've reached it.

[DeTeEff]

Exactly which spawnargs on the AI changes their thinking range and thinking interval?

 

If I understand correctly the first is the radius which the player needs to be inside to make the AI think (check if he/she sees/hears anything.

 

And the second is how often he/she does these checks.

 

I believe it is

 

min_interleave_think_dist

and

max_interleave_think_dist

and

max_interleave_think_frames

 

How will the AI behave if these are set at an extreme lo-thinking level?

Edited April 26, 2011 by Fieldmedic

[Sotha]

http://wiki.thedarkmod.com/index.php?title=Interleaved_Thinking_optimization

 

I'm not sure what happens. Incorrect values might result in AI dying without any reason. Or they cycle back and forth a waypoint, never hitting it.

[New Horizon]

Just an off remark and not meant to be taken as a criticism on what has been done, but it's a real shame that UDK came out after the inception of TDM...

 

From my understanding, UDK does not yet support linux or mac. It might have some more bells and whistles, but once the D3 source is released...TDM will be free to optimize and enhance different areas of the engine. I think there are still some parts of UDK that are closed...so it wouldn't have been that much better of an option.

[Baddcog]

 

 

 

 

To be fair though, I probably added that part to the ModWiki article myself in an attempt to reduce the confusion for new mappers. Even Brian Harris at id Software confirmed that they didn't bother with light carving when making Doom 3 because it wasn't a good use of time, just like in my own tests when it never made any significant difference to frame rate.

 

Honestly I don't think it's a great idea to put out there that it doesn't matter. Light count DOES matter and it will have a serious impact on performance.

 

Of course that comes with certain properties like shadow casting. It's the casting of dynamic shadow tris onto other tris that kills fps. So if you have 6 lights casting shadows from 100 tris, that's 600 shadow tris being cast.

 

You can easily see the performance impact in game.

 

So the Wiki should be clear about this.

 

Of course if there are 6 non-shadow lights there won't be an impact.

 

But this is TDM, thief, it is based on light AND shadows. No shadows work fine in some areas here and there, but for the most part most lights in most maps WILL be casting shadows. Thus the need to watch light count.

 

The quote about Doom3 team not worring about them isn't all that fitting imo. It was Doom3, lots of areas with no lights. If they saw performance hits they could make some lights no shadow and see no gameplay impact.

They also seems to use a lot of 'one light per area' set ups. One room would have one electric light and the square bounds of the light filled the room.

We're using round light shaders, so to fill a room with light requires more overlapping lights, etc.. We have more high poly enemies on screen at once than Doom...

[OrbWeaver]

Honestly I don't think it's a great idea to put out there that it doesn't matter. Light count DOES matter and it will have a serious impact on performance.

 

I never said that light count didn't matter, I was referring specifically to the manual carving of brushes, especially when it is done unconditionally under the false belief that there is some "3 light performance limit", which used to be common amongst starting mappers (myself included).

 

Of course reducing the number of shadow-casting lights is an important optimisation (along with the complexity of shadow-casting geometry), and to a lesser extent non-shadow-casting lights in particular degenerate cases where a very large surface might have an excessively high light count. But like all performance optimisations, they should be done with reference to the actual FPS changes and the statistics available through cvars, rather than blanket rules like "The number of X should never be more than Y" which don't take into account the particular rendering situation.

[nbohr1more]

@Melan:

 

It doesn't sit well with human understanding but the general figure is to group 500 to 1000 triangles to a texture. So that OpenGL state changes don't happen every few triangles. Again, if you want more texture variety in a scene you can fool Doom 3 by creating a texture sheet that includes all the textures in a scene. This is all to help CPU performance.

 

The other thorny issue is that if you batch too many triangles to a texture that can hit GPU too heavily.

 

So you have to try to reach a happy medium

 

~~~

 

After again re-reading Lunaran's "Strombine" article, I have hit another clue:

 

I came to the realization that it is to your artistic advantage to paint a unique image for every light source, because you get almost no performance savings by reusing the same lights.

 

What I think Lunaran is saying is that EVERY light invokes a unique GL state change. The light projection textures don't batch together...?

 

I wonder if that is the case?

 

Does that apply to BlendLights as well?

 

Since Sikkpin was able to make the interaction shader accept a Cubemap could you also alter it to accept multiple translated textures and thus improve batching?

 

Hey, can lights have multiple projection images applied to them via material stages...? If so, rather than build paint a complex texture like Lunaran you could composite via stages that use the same texture... Maybe that would batch better as well?

Edited April 26, 2011 by nbohr1more

[OrbWeaver]

What I think Lunaran is saying is that EVERY light invokes a unique GL state change. The light projection textures don't batch together...?

 

Lights require a hell of a lot more than just a GL status change: the rendering algorithm processes lights one by one, and accumulates the result. Therefore there is no performance advantage to using the same texture on lots of lights, because each light (and its contained geometry) is still going to be processed in its own individual pass.

 

Does that apply to BlendLights as well?

 

My guess would be yes, but you'd have to look at the source to be sure. The high performance of blend lights comes from the fact that they don't need to use the full interaction shader with bump-mapping etc, but simply fill the volume with the light texture and blend it into the image using the specified blend mode.

[nbohr1more]

Lights require a hell of a lot more than just a GL status change: the rendering algorithm processes lights one by one, and accumulates the result. Therefore there is no performance advantage to using the same texture on lots of lights, because each light (and its contained geometry) is still going to be processed in its own individual pass.

 

So maybe it wouldn't be so crazy to consider adding a Cubemap Light interaction shader as a special option for new missions made past yada yada version 1.0x (etc). The improved appearance and practical performance benefits of reducing light counts would be available in the interim while we wait for Doom 3 GPL and you could build-up a library of cubemaps and light shaders for the future when this is considered a ubiquitous method.