kingsal Posted August 25, 2016 Report Share Posted August 25, 2016 Hey All, I wanted to get some people's thoughts on the pros and cons of converting a bunch of DR func_statics to mesh objects. The obviously benefit of mesh objects is that you can easily change/ place them without dmaping. The downside is.. well its a lot of work build them (especially in the case of architecture where their best made to be modular) . Meshes:What is the performance impact of creating custom mesh objects vs func_statics in DR.My assumption is that func_statics impact your dmap times whereas custom meshes impact your loading times? Does the engine treat a mesh object and a func_static any differently? Textures:Is the engine faster at loading lots of small textures or a few large ones (assuming both are used on multiple meshes)? Thanks in advance 1 Quote Volta Missions: Volta and the Stone, Volta II: Cauldron of the Gods Standalones: Snowed Inn, Hazard Pay Moongate Ruckus Link to comment Share on other sites More sharing options...
nbohr1more Posted August 25, 2016 Report Share Posted August 25, 2016 Func_statics get turned into meshes on map load so they are largely equivalent in the engine. That said, if you re-use meshes the engine only loads the original and uses a pointer to keep track of the others (saves on RAM and processing). For both func_static and meshes, these do not split at portals or split geometry at the light boundaries so watch out for light counts and just knowthat if a light radius poly touches a single mesh poly, the whole mesh is evaluated for that light. Fewer large textures or "texture atlas" is more optimal but the image_downsize configurations for lowend players will murder image quality if you do it that way.So it might be best to use a hybrid strategy. Detailed textures being tiny and individual, whereas large low frequency textures all atlas-ed together. Oh, the biggest problem are shadow tris, so the downside of light counts can be offset a great deal with the use of low-poly shadow meshes.They will still have the same problem of not splitting but the lower poly counts will mean that the CPU effort will be greatly reduced. 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to comment Share on other sites More sharing options...
nbohr1more Posted August 25, 2016 Report Share Posted August 25, 2016 Hmm. I guess if you made an optimal texture atlas that wouldn't kill the video ram of lowend players you could add the nopicmip stage keywordto the stages to prevent downsizing. You'd want to test that with a bunch of lowend users first to prevent a bunch of malloc error reports. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to comment Share on other sites More sharing options...
kingsal Posted August 26, 2016 Author Report Share Posted August 26, 2016 This is all great info nobohr1. I might post more questions here as they come up. Thanks so much! Quote Volta Missions: Volta and the Stone, Volta II: Cauldron of the Gods Standalones: Snowed Inn, Hazard Pay Moongate Ruckus Link to comment Share on other sites More sharing options...
Obsttorte Posted August 29, 2016 Report Share Posted August 29, 2016 Func_statics get split up the same way worldspawn does in regardence to how the tris are generated from the single planes. Hence they tend to have more tris in comparision to the same model exported as mesh. Additionaly, if you create a func_static and copy it, it will use it's own model, whereas using meshes means that all objects are referring to the same model. This doesn not only reduce loading times and performance impacts, but also the size of the cm file. There is actually no advantage of using a func_static over a mesh. The latter is always better. At least I do not know of any advantage a fs might have. Quote FM's: Builder Roads, Old Habits, Old Habits Rebuild Mapping and Scripting: Apples and Peaches Sculptris Models and Tutorials: Obsttortes Models My wiki articles: Obstipedia Texture Blending in DR: DR ASE Blend Exporter Link to comment Share on other sites More sharing options...
NeonsStyle Posted August 31, 2016 Report Share Posted August 31, 2016 What about brushwork? If you increase the brush detail of a room significantly than normal how much would that impact performance? Is it linear? I have something in mind thatwould be a large increase in brushes in a room, but I'm concerned on performance for it too. Better to know these things before starting. Quote I have an eclectic YouTube channel making videos on a variety of games. Come and have look here:https://www.youtube.com/c/NeonsStyleHD Dark Mod Missions: Briarwood Manor - available here or in gamehttp://forums.thedarkmod.com/topic/18980-fan-mission-briarwood-manor-by-neonsstyle-first-mission-6082017-update-16/ Link to comment Share on other sites More sharing options...
nbohr1more Posted August 31, 2016 Report Share Posted August 31, 2016 Brushes are more expensive that func_static or models in many cases. They always generate collision unless you use custom materials with the "nonsolid" keywordand they are heuristically split into more triangles to attempt to keep light counts low and ensure that they obey BSP visibility branching. Brushes do sometimes win in scenarios where larger light counts are involved because models and FS will render the whole thing for each light that hits thembut in most cases models and FS have better performance attributes. Brushes are mostly intended for prototyping, simple walls, and collision\pathing design as I can tell. Most of the level detail in Doom 3 was models with minimal brushwork. We've recently been evangelizing a modular workflow which involves re-using generic room model orbuilding model components to build out levels Lego-style then add detail patches and caulk with brushes.Of course that requires building a model (module) library which is currently WIP but Sotha has already shown the benefits of the technique in his recent missions. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to comment Share on other sites More sharing options...
Moonbo Posted August 31, 2016 Report Share Posted August 31, 2016 Much more important than the number of brushes or models in a scene is the number of lights and if they are shadow casting or overlapping. I had instances where, based on the lighting layout, brushwork was actually cheaper than func statics because I could carve up the brushes so that multiple lights didn't hit them vs. if they had been a single FS. 1 Quote But you should walk having internal dignity. Be a wonderful person who can dance pleasantly to the rhythm of the universe.-Sun Myung Moon My work blog: gfleisher.blogspot.com Link to comment Share on other sites More sharing options...
kingsal Posted August 31, 2016 Author Report Share Posted August 31, 2016 I poked around the Doom 3 maps a bit they're incredibly well done and I would encourage everyone to do it. As nbohr mentioned, the brush work is simply used for laying out the design and guts of the level. Most of the visual fidelity comes from modular static meshes and smartly placed lighting. This is definitely challenging in a handcrafted medieval setting. Another performance note:This feels like a huge oversight on my part. I recently realized that shadow casting light volumes will overdraw past world brushes (even when separated by portals). This is a huge killer on performance. So for instance, if your light volumes on the first floor collide with objects on the second floor. It will still calculate the shadows of anything the light touches, even though they are not visually rendered. I think the general principle is to keep your shadow casting lights small and use ambient lights to "fill" the room. This of course, will be tough if you have lots of strangely shaped medieval rooms which doom does not . I can't be certain, but are the long load times for FMs in part due to the use of func_statics over meshes? It could also be the texture count. 1 Quote Volta Missions: Volta and the Stone, Volta II: Cauldron of the Gods Standalones: Snowed Inn, Hazard Pay Moongate Ruckus Link to comment Share on other sites More sharing options...
nbohr1more Posted August 31, 2016 Report Share Posted August 31, 2016 Mipmap generation for normal maps is the biggest culprit there.If haven't already done so, set the normal map compression cvar to 0. Leaving it at 2 does nothing since none of our normal textures are compressed and the decode logic for compressed normals is already disable in anticipation for a better option. Users are wasting time waiting while the engine encodes textures in RAM that it never uses.Reused meshes will help loading time though. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to comment Share on other sites More sharing options...
kingsal Posted August 31, 2016 Author Report Share Posted August 31, 2016 Here is an example:Unless I am totally wrong about this, I believe the torch light's volume is still generating the shadows of the barrels in the room next door even though they are separated by a wall. Am I understanding this correctly? 2 Quote Volta Missions: Volta and the Stone, Volta II: Cauldron of the Gods Standalones: Snowed Inn, Hazard Pay Moongate Ruckus Link to comment Share on other sites More sharing options...
nbohr1more Posted August 31, 2016 Report Share Posted August 31, 2016 I believe you are correct. Use r_showShadows in the console to see what is being generated where. Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to comment Share on other sites More sharing options...
Bikerdude Posted August 31, 2016 Report Share Posted August 31, 2016 This feels like a huge oversight on my part. I recently realized that shadow casting light volumes will overdraw past world brushes (even when separated by portals). This is a huge killer on performance. So for instance, if your light volumes on the first floor collide with objects on the second floor. It will still calculate the shadows of anything the light touches, even though they are not visually rendered. I think the general principle is to keep your shadow casting lights small and use ambient lights to "fill" the room.Thats interesting to know. When I have worked on my own maps, or when asked to do a perfing run on other peoples maps I have always had to reduce thier light volumes which were just big. This was mostly due to wanting to prevent over lapping light volumes, but now I see that I have inadvertently been reducing the issue you spoke about also. I also think I was the first person (some one will correct me if I am wrong) that used bounce lights to fill a room or a section of a room. Quote Link to comment Share on other sites More sharing options...
Destined Posted September 1, 2016 Report Share Posted September 1, 2016 This feels like a huge oversight on my part. I recently realized that shadow casting light volumes will overdraw past world brushes (even when separated by portals). This is a huge killer on performance. So for instance, if your light volumes on the first floor collide with objects on the second floor. It will still calculate the shadows of anything the light touches, even though they are not visually rendered. I think the general principle is to keep your shadow casting lights small and use ambient lights to "fill" the room. This is really good to know. Maybe it should be mentioned in the tutorial in the Wiki, so new mappers will know of this issue as soon as they start mapping. Quote Link to comment Share on other sites More sharing options...
Obsttorte Posted September 1, 2016 Report Share Posted September 1, 2016 Here is an example:Unless I am totally wrong about this, I believe the torch light's volume is still generating the shadows of the barrels in the room next door even though they are separated by a wall. Am I understanding this correctly? volta_v2_0_2016-08-31_11.34.40.jpg That's true. It can happen that a light causes an object to draw a shadow into the visible are, even though the model and/or the light is not rendered. However, the shadow has to be visible so there is a need for the shadow generation. Otherwise the engine can't decide whether a shadow has to be rendered or not. Quote FM's: Builder Roads, Old Habits, Old Habits Rebuild Mapping and Scripting: Apples and Peaches Sculptris Models and Tutorials: Obsttortes Models My wiki articles: Obstipedia Texture Blending in DR: DR ASE Blend Exporter Link to comment Share on other sites More sharing options...
kingsal Posted September 1, 2016 Author Report Share Posted September 1, 2016 (edited) I would definitely suggest people at least be aware of it. The shadow over-draw was adding 300-400 drawcalls to my current level until I finally figured out what was happening. As biker mentioned, reducing light volumes solves many of these nasty issues. However, a lot of the default tdm lights such as torches spawn lights with fairly large volumes. So that's something to be careful of. Another consideration would be to design levels with this problem in mind, lots of open space between rooms to avoid light overlap. I keep getting myself into this rabbit hole.. lots of tightly packed rooms with shared walls.. ugh. Its a nightmare to light. Biker- I do remember you using bounced lighting in your maps. Its such a nice effect... Edited September 1, 2016 by kingsal 2 Quote Volta Missions: Volta and the Stone, Volta II: Cauldron of the Gods Standalones: Snowed Inn, Hazard Pay Moongate Ruckus Link to comment Share on other sites More sharing options...
Obsttorte Posted September 1, 2016 Report Share Posted September 1, 2016 However, a lot of the default tdm lights such as torches spawn lights with fairly large volumes. So that's something to be careful of.Yeah, back in the day I always reduced them from 320^3 down to 192^3. You can use the set <spawnarg> on <attachmentName> spawnarg to alter spawnargs on attached entities. Quote FM's: Builder Roads, Old Habits, Old Habits Rebuild Mapping and Scripting: Apples and Peaches Sculptris Models and Tutorials: Obsttortes Models My wiki articles: Obstipedia Texture Blending in DR: DR ASE Blend Exporter Link to comment Share on other sites More sharing options...
NeonsStyle Posted September 2, 2016 Report Share Posted September 2, 2016 Fascinating. So much to learn here. I had no idea about D3 map setup. I've looked at them in an editor, but never from a performance point of view. Given this issue with lights impacting adjacent rooms. Currently, if you adjust the size of a light, it adjusts all sides, would it be possible to make it soyou could set the size of each side uniquely? Quote I have an eclectic YouTube channel making videos on a variety of games. Come and have look here:https://www.youtube.com/c/NeonsStyleHD Dark Mod Missions: Briarwood Manor - available here or in gamehttp://forums.thedarkmod.com/topic/18980-fan-mission-briarwood-manor-by-neonsstyle-first-mission-6082017-update-16/ Link to comment Share on other sites More sharing options...
Destined Posted September 2, 2016 Report Share Posted September 2, 2016 Currently, if you adjust the size of a light, it adjusts all sides, would it be possible to make it soyou could set the size of each side uniquely? That is a very good point. This would make things much easier (regarding performance). However, I could imagine, that the light might not look realistic anymore. Quote Link to comment Share on other sites More sharing options...
Obsttorte Posted September 2, 2016 Report Share Posted September 2, 2016 You can offset the light origin to achieve this. I think the spawnarg is light_origin, which takes the light position relative to the light entities origin. However, it may not look good due to the light texture used (so you would have to adjust this, too, to get the best results). The easiest ways to avoid too high performance impact of lights are toavoid overlapping lightsavoid several lights hitting the same tris (r_showTris will show you the tris), split surfaces up where neccessaryavoid too much shadow casting entities within light boundsonly use shadowcasting lights where really neccessary, ambient lights are your friends avoid entites casting shadows into adjacenting rooms if possibleThere are a few more things which can help with performance, thoughsplit up your level geometry in a way so that visportals can do their job properly, this means that you should avoid that the player can see into zones of which he can only see a tiny bittake the vertical aspect into account when creating outdoor areas (many mappers oversee this, as we tend to think two dimensional)plan visportal placement in probably performance houngry areas before you build the area, placing vp's afterwards will not always be of much helpmake use of the lod systemif you use a func_static very often (for example a custom decoration, window frame or whatever), export it as a model and use this insteadturn all decorative elements into func_statics, if they are rather small, make them non-solid and non-shadow castinggenerally models have less tris then func_statics, so if you have performance drops in areas with fs check the tris (r_showTris) and export them as model if the tris count is highonly put details in areas where the player can see it, in dark spots for example the player might not notice the difference if details are lackingavoid the use of too much texturesThese are a few things to consider, but I guess there are more ways to improve performance. Note that if you are going to do an performance houngry mission, like something that plays outdoors, you have to make performance considerations before you start building the level. This makes things much easier for you and everyone else as if you have to fix the performance afterwards. 1 Quote FM's: Builder Roads, Old Habits, Old Habits Rebuild Mapping and Scripting: Apples and Peaches Sculptris Models and Tutorials: Obsttortes Models My wiki articles: Obstipedia Texture Blending in DR: DR ASE Blend Exporter Link to comment Share on other sites More sharing options...
nbohr1more Posted September 2, 2016 Report Share Posted September 2, 2016 Yes, it's called light_center. The only problem being that the particle flames are attached to the origin rather than the light center. You can use an offset arg to adjust that though or make a custom light def where the attach point is the light_center as I recall. 1 Quote Please visit TDM's IndieDB site and help promote the mod: http://www.indiedb.com/mods/the-dark-mod (Yeah, shameless promotion... but traffic is traffic folks...) Link to comment Share on other sites More sharing options...
Spooks Posted September 9, 2016 Report Share Posted September 9, 2016 You can offset the light origin to achieve this. I think the spawnarg is light_origin, which takes the light position relative to the light entities origin. However, it may not look good due to the light texture used (so you would have to adjust this, too, to get the best results). This is an important thing to remember. All lights are basically static textures and changing the light center of a big_round light for example will not change how the light looks - just where the bumpmapping, shadows and fresnel highlight are coming from. If you want a light to be snug against a corner and taper off into the center of a room you would need to create a custom texture for it. 1 Quote My FMs: The King of Diamonds (2016) | Visit my Mapbook thread sometimes! | Read my tutorial on Image-Based Lighting Workflows for TDM! Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.