Jump to content
The Dark Mod Forums

Optimizing maps / optimizing techniques (brushwork) questions


Recommended Posts

Hello everyone,

a few weeks ago I stumbled upon the dark mod by sheer accident and I'm so glad I did. Then realizing that there is an easy way to create your own maps was what really got me hooked since I have some experience with sourcegold and worldcraft / hammer for which I build a lot of maps back then, nothing published though. Just for me, putting my creativity somewhere.
And since sourcegold and idtech are relatives I figured that they maybe share some of the same techniques to optimize your maps.


I watched a youtube introduction / tutorial series from Nico Autia and realised that he was doing some stuff that i did way back then when I first started designing levels for half-life but relatively quickly got rid of, since this was scoffed at by the HL mapping community, due to having a huge impact on performance, especially on bigger maps. Like using carve out / hollow tools, the best way to connect 2 walls in a corridor for example having a 90° corner was not to give them flat contact but rather move the inner vertexes so they have a 45° angle of contact, like most wodden window picture frames do, or for example dont use carve out to make a cylindrical hole / tunnel and rather use the vertexes of a prefab cylinder to manually manipulate the vertexes of the "tunnel"brushes while minimizing the amount of them (triangle brushes gave best performance in sourcegold.

Also, I switched rather quick to do all the brushwork with trigger/invis textures that weren't rendered and only texture paint the surfaces you could actually see, is this important here?

So the big question since I haven't started working with dark radiant is, are those techniques still a thing? Is it even comparable to sourcegold?
Is there a comprehensive best practice list on how to do actual brush work for maximum performance?
Sorry If I have trouble in making clear what I want to say, english is not my native language. Feel free to ask right away if my questions aren't as clear as I hope them to be / understandable.

Thanks in advance :)

Edited by itsShas
  • Like 1
Link to post
Share on other sites

Hi there! This is the main wiki entry about performance and I see it's pretty up to date: https://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows

This engine is slightly different from CSG engines of that era, you don't carve out spaces from solid void, but you do seal off rooms from it. You still use portals and such for optimization, but you don't have to hide (caulk) backfaces.

  • Thanks 1
Link to post
Share on other sites
1 hour ago, itsShas said:

Hello everyone,

a few weeks ago I stumbled upon the dark mod by sheer accident and I'm so glad I did. Then realizing that there is an easy way to create your own maps was what really got me hooked since I have some experience with sourcegold and worldcraft / hammer for which I build a lot of maps back then, nothing published though. Just for me, putting my creativity somewhere.
And since sourcegold and idtech are relatives I figured that they maybe share some of the same techniques to optimize your maps.


I watched a youtube introduction / tutorial series from Nico Autia and realised that he was doing some stuff that i did way back then when I first started designing levels for half-life but relatively quickly got rid of, since this was scoffed at by the HL mapping community, due to having a huge impact on performance, especially on bigger maps. Like using carve out / hollow tools, the best way to connect 2 walls in a corridor for example having a 90° corner was not to give them flat contact but rather move the inner vertexes so they have a 45° angle of contact, like most wodden window picture frames do, or for example dont use carve out to make a cylindrical hole / tunnel and rather use the vertexes of a prefab cylinder to manually manipulate the vertexes of the "tunnel"brushes while minimizing the amount of them (triangle brushes gave best performance in sourcegold.

Also, I switched rather quick to do all the brushwork with trigger/invis textures that weren't rendered and only texture paint the surfaces you could actually see, is this important here?

So the big question since I haven't started working with dark radiant is, are those techniques still a thing? Is it even comparable to sourcegold?
Is there a comprehensive best practice list on how to do actual brush work for maximum performance?
Sorry If I have trouble in making clear what I want to say, english is not my native language. Feel free to ask right away if my questions aren't as clear as I hope them to be / understandable.

Thanks in advance :)

If you worked with HL1 hammer imo you will feal almost in home, afaik DR follows the exact same conventions than HL 1 hammer, as the later is based on quake Radiant as well.  So some techniques for optimizing brushes should still be valid, but there's no need for some things that you add to do, on Quake3 engine days for example, like peter_spy said, no need to caulk backfaces, because idtech 4 engine removes those automatically at dmap time, BUT imo there's a huge advantage to use caulk texture in backfaces, when working on DR itself, with that you can hide those faces very easily, using the filters options or turning on the light render view and see a preview of what the final geometry may look like, if you care abou that. (btw DR render view, is not a 1 to 1 to the main engine render, so don't lean on it to "preview" the final lighting).

About the 45º rule for corners of brush walls, imo there's no need for that, at lest for "outside" walls, those looking into the void, like I said the back faces will get removed, so in the end you only get the visible face, looking in, is just a flat plane, so imo is wasted time, just use the make room tool in DR tool bar, that produces good enough walls, please do not use the make hollow option that is poison, it makes overlapping brushes and that causes z-fighting and problems with texture alignment. 

some good rules:

Don't make too thin walls that causes light leaking and potencial leaks into the void, walls should be made in grid 8 or above.

Make sure the origin of models is within a room, if it is on the void it will cause a hard to find leak. 

The rest is just a matter of making rooms that you can perfectly close from each other using portals, and that many portals don't look into each other. 

Edited by HMart
  • Like 1
Link to post
Share on other sites

With minor exceptions like water volumes, brushes don't exist when you play the game. The dmap compiler uses them to determine visleafs/portals structure, and to produce triangular "surfaces" which are actually rendered in-game.

If you have too many brushes, then you will mainly experience slow dmap compilation and perhaps occasional buggy output (e.g. missing triangles in a wall) or dmap crashes. Serious issues are rare as long as you use axis-aligned brushes. But if you decide to e.g. make nice-looking trees out of brushes, I'd say you are risking 😲. Even spiral stairs sometimes cause problems.

56 minutes ago, itsShas said:

Also, I switched rather quick to do all the brushwork with trigger/invis textures that weren't rendered and only texture paint the surfaces you could actually see, is this important here?

I think it is useless. If you have a room which is a visleaf area, then the inner wall faces (visible from inside the room) will be put into a mesh surface assigned to the room visleaf, the internal/side faces will be removed since they don't separate opaque from non-opaque, and the outer wall faces will be put into surfaces assigned to whatever visleafs present outside (if there are any). When the player is inside the room, he will most likely not see the outside visleafs through the portals, so the outer faces won't be rendered.

P.S. Note that I'm a programmer and not a mapper. What I say comes from "theory", not practice 😉

  • Like 1
Link to post
Share on other sites
8 minutes ago, HMart said:

Don't make too thin walls that causes light leaking and potencial leaks into the void, walls should be made in grid 8 or above.

Make sure the origin of models is within a room, if it is on the void it will cause a hard to find leak. 

Yeah, thick walls are also important from the sound perspective, they block it better. Brushes and portals are needed to propagate the sound correctly, otherwise it travels though walls.

Also, leaving any entity outside sealed rooms will result in a leak, unfortunately. In other engines I could keep models, lights and such in the void, nearby my map bounds, so I would clone and use them later. Here I need to have a dedicated room for this.

  • Like 1
Link to post
Share on other sites

A dedicated room for most used models, is a nice idea, imo because you can easily select them all and copy paste into a new map, or make it into a prefab, if you could put models anywhere in the void, I'm sure some people (like me) would put them all over the place and make a mess. :)

  • Like 1
Link to post
Share on other sites
  • 3 weeks later...

As our other mappers have stated, optimising brushwork is nowhere near as important in this engine as it was in previous ID games, however optimising lights (especially those that cast shadows) has become a lot more important since lights are rendered at runtime rather than precalculated and baked into the map. Having 100 overlapping shadow-casting lights illuminating a simple brush is going to have a much greater impact on performance than a complex brush illuminated by a single light.

Link to post
Share on other sites

Other than light counts, please become very aware of the concept of "visportals".

 

Visportals not only help the renderer decide when an area can be split and culled but also act as a shortcut

to prevent the engine from performing needless work identifying whether geometry past the next portal needs to

be evaluated. The engine will only consider an area closed to a portal if it is two closed portals beyond the player.

 

The current suggestion is to place a visportal halfway through each room so that geometry past the closed door

is not evaluated in the portal bounds calculation.

  • Like 1

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 post
Share on other sites

Somewhere there's a good tutorial on visportal placement, which had top-down drawings of examples.

You don't want long lines of sight where where you can ever look through three visportals in a row, or at least not until you right next to the first, and at least when we're talking about open outside areas with lots of triangles.

One way to do that is make hubs where the streets/hallways go off in T-like or Y-like intersections, where each opening is about 60 degrees offset. And then you can make the entrances have a quick horizontal displacement like a Z-shape, and you can put a second visportal at the other side of that, so it's unlikely the two ends will be in a line of sight, but definitely not from looking through a third visportal.

Tricks like that. I've been looking into doing that for forest like areas, which I think we have some good FM examples of. I think once you get an idea of the basic principle, don't allow lines of sight through more than 2 visportals, you can naturally start to plan areas around the idea.

  • Like 1

What do you see when you turn out the light? I can't tell you but I know that it's mine.

Link to post
Share on other sites
11 hours ago, demagogue said:

Somewhere there's a good tutorial on visportal placement, which had top-down drawings of examples.

 

 

  • Like 3
Link to post
Share on other sites

Talking about visportals, Is it really required to make visportals, if you don't need the player to look or normally travel into another room? I ask because, just for kicks, I coded a resident evil/skyrim, etc kind of door system, one that you click and get transported to another room, instead of opening a door like on TDM, this made me able to make separate/unconnected rooms and just teletransport the player between them, I made it very seamless and imo is very cool (with some nice possibilities, no need to animate or rotate doors, no need to make the rooms next to each other or follow a real layout). But I don't know if the engine can optimize visibility this way. I know that some effects like the skyportal system uses unconnected rooms but I don't know if you can make a entire level, where every division/room is a real separate unit, with no visportal between them.

 

Link to post
Share on other sites
  • 2 weeks later...
On 12/4/2020 at 9:55 PM, HMart said:

Talking about visportals, Is it really required to make visportals, if you don't need the player to look or normally travel into another room?

Technically it's never required to make visportals, but if you don't, everything in front of the camera will be rendered regardless of whether it is in the same "room" or hidden behind other objects. There is no automatic culling of geometry based on "connectedness", or anything other than the manual dividing up of map geometry by placing visportals.

If you want to see what is happening at the render level you can use the r_showTris cvar to enable drawing of triangle outlines.

Link to post
Share on other sites

That cvar is what I've used to test this but I was not sure, if it was showing if the geometry was really being culled or not.

I could be mistaken but it seems the engine does care, if you are inside a closed "room" or not, why? Because if you noclip and position your self next to a wall, in a way that the camera is clipping the wall and showing the other room somewhere in the void, if you move a little into the room, but still able to keep seeing the other room, there will be a point, where it will vanish, even if the camera is still clipping the wall and should be seeing it, to me seems it happens when the player origin falls entirely inside the room.

Link to post
Share on other sites

Is that without no visportals in the level? If so that tells me that the engine, default is to automatically cull everything outside the current "room" or visleaf? the player origin is in and needs visportals, so the player can see into other rooms but if you have no visportals and the rooms are not connected then it doesn't care to show the other geometry, unless the player origin is in the void, then it renders everything. If this is true then the engine can indeed support the kind of unconnected rooms i'm thinking about. :)

I will do a video showing what I'm saying but don't expect something pretty, far from it, is all programmer art the "level design", texturing, lighting, etc, for now is very very basic, just test rooms to test my c++ coding. :P And you peter_spy will recognize the door models no doubt, btw none of the models in the video are to be released for the public and are just place holders.

Also sorry for the very dark look at the end, is a huge testing "room" just with a ambient light, on my monitor, ingame it looks reasonable but on the video looks very dark and I didn't care to edit the video. what I want to show imo is very apparent.

https://drive.google.com/file/d/1KIgExPcmeVg14nGFnwa-YDwaO_8ZCPHu/view?usp=sharing

  • Like 1
Link to post
Share on other sites
35 minutes ago, HMart said:

Is that without no visportals in the level?

No, the visportals are there, as I said, brushes+portals.

But, portals don't need to be closed for the geometry to be culled, look:

Clipboard01.jpg.b6a5e9b5b7ed6f872d5dd9a7c9870c1f.jpg

 

  

35 minutes ago, HMart said:


Ah, this is old Resident Evil / The Elder Scrolls kind of solution, minus loading of course :). I've seen the same thing used in a quite broken stealth game called Velvet Assassin (it grew on me though). They used it just like in the video, perhaps to space out the AI and avoid pathfinding problems in larger interconnected areas. It can be a useful trick.

But yeah, if you have sealed rooms separated by the void, and the player is inside one of these, only what's in camera frustum is rendered.

Edited by peter_spy
  • Like 1
Link to post
Share on other sites

Yes, is indeed inspired by Resident Evil, so much so that I called this door entities idREdoors :D  

I have Velvet Assassin, bought it on a sale ages ago and even thou like you said, is broken in some things and is clearly a small indie game, it also grew on me. Petty the developers add to close shop they add potencial.  

Link to post
Share on other sites
1 hour ago, HMart said:

If so that tells me that the engine, default is to automatically cull everything outside the current "room" or visleaf?

No. If there are no visportals, there are no visleafs. The whole map is a single visleaf, and the whole thing will be rendered as long as it is in front of the camera (I assume the engines culls everything behind the camera or out of view, regardless of visportals).

I think you're getting confused by the name "visportal", since the "portal" part suggests it's just a gateway between two things. From this it might follow that a map full of completely unconnected rooms wouldn't need any portals (because there are no doors or gateways between them). But the engine does not work this way. Visportals are more like "vis leaf separators", and without them the whole world is just one big model.

I don't know how your map of completely unconnected rooms will interact with the flood fill system, though. For example, it's possible that the engine will see some of those rooms as "outside of the map" and remove them just like it does with textures on the outside of your wall brushes. Perhaps the map compiler will pick one room as the "inside" and then complain that entities in other rooms are "outside" and therefore a leak. Not something I've ever tested.

Link to post
Share on other sites

I think that unconnected rooms will become distinct visleafs? The search algorithm uses both portals and "opaque nodes":

https://fabiensanglard.net/doom3/dmap.php

 

Back in the Doom3world days, someone created a "Prey style portals" mod that had unconnected rooms with camera views projected

onto a videomap where the door was supposed to be. Since you have to render the same geometry to see out real door vs see what the remote

camera sees one would think that performance would be equivalent or worse in the Prey setup but instead it was better.

 

I suspect that long views impact the performance of the "search" algorithm regardless of geometric complexity.

Thus we have TDM missions with oodles of geometry in short views that run very well but other TDM missions with long views largely devoid

of complex objects that are pretty poor performance-wise.

 

Portals break up the recursion pattern in a similar way but only if they close...

  • Like 1

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 post
Share on other sites

I'm certainly not a expert in idtech4 rendering engine, so you may be right, perhaps my misconception came from my past work with the C4 engine, in that engine, portals were gateways into other areas, so much so that, contrary to idtech4, in C4 you add to make two portals to connect visually two areas, I think HPL engine does the same.

Quote

(I assume the engines culls everything behind the camera or out of view, regardless of visportals).

This part at lest seem to be true, like you see on the video at the end. So even if all unconnected rooms are a single model the engine somehow knows to only hide the parts of the model outside the view, that seems to be a perfect behavior for my idea but like you implied, I don't know how this affects, the AI, AAS or sound flooding, perhaps if I make the rooms to near each other sounds could leak into the visible part, need to test this. But all of this is just a curiosity, I don't know if I will use this door system.   

 

I read this on the link nbohr1more posted 

Quote

Now dmap group leafs together with area IDs: For each leaf a floodfilling algorithm is triggered. It tries to flow everywhere using portals associated to the leaf.

This is where the designer work is tremendously important: Areas can be identified only if visportals (the portal brushes mentioned in Step 1) were manually placed on the map. Without them dmap will identify only one area and the entire map will be sent to the GPU each frame.

The Floodfilling recursive algorithm is stopped only by areaportals and opaque nodes.

Seems to say exactly what OrbWeaver said but at the end, it talks about the opaque nodes. And if the entire map is send to the GPU to render, then why Is the other parts of it not rendered when not in view? Imo seems to be a contradiction. 

Edited by HMart
Link to post
Share on other sites
12 hours ago, nbohr1more said:

I think that unconnected rooms will become distinct visleafs?

I'm 99% sure that they won't, and that the "opaque nodes" reference only refers to the flood-filling algorithm, not the division of the map into visleafs. What it means is that the inside of a sealed box will be completely optimised away by the flood-filling algorithm, because the walls are opaque and they stop the flood-filling (which only covers parts of the map reachable from the player start). This also suggests that with HMart's unconnected rooms idea, the problem will be that most of the rooms will be considered unreachable (opaque) and optimised out by the dmap compiler.

Nothing in that article indicates that there is any kind of automatic visleaf creation; indeed the article explicitly states that without visportals the entire map will be sent to the GPU as a single unit.

12 hours ago, HMart said:

So even if all unconnected rooms are a single model the engine somehow knows to only hide the parts of the model outside the view,

12 hours ago, HMart said:

And if the entire map is send to the GPU to render, then why Is the other parts of it not rendered when not in view? Imo seems to be a contradiction. 

By "outside the view" I mean outside the field of view of the camera (i.e. to the left or right, or above or below the view frustum). GPUs are smart enough not to render pixels for objects that are not within the boundaries of the view frustum, but the geometry will still be sent to the graphics card for rendering because the visleaf is a single model (essentially like a big static mesh). So you get some optimisation based on the camera view, but nowhere near as much as if you set up visleafs and avoid sending sections of the map to the GPU altogether.

 

Link to post
Share on other sites
3 hours ago, OrbWeaver said:

What it means is that the inside of a sealed box will be completely optimised away by the flood-filling algorithm, because the walls are opaque and they stop the flood-filling (which only covers parts of the map reachable from the player start).

As far as I remember, any entity is enough to make sealed area pass through compiler, not only player-start. So if you put at least one entity per room, it is quite expected that you will get many visleafs without visportals 😃

  • Like 1
Link to post
Share on other sites
3 hours ago, OrbWeaver said:

...

By "outside the view" I mean outside the field of view of the camera (i.e. to the left or right, or above or below the view frustum). GPUs are smart enough not to render pixels for objects that are not within the boundaries of the view frustum, 

 

Sorry if I'm being stubborn but have you seen my video and what I show at the end? I ask because to me that is not what's happening, by "view frustum" i assume you mean the camera view, the rectangle that make up the game window, so based on that article, you should be entirely right no doubt and while those parts are in view, they should render, even if behind a "wall" but that is not what I see and I hope you guys too :D the other parts of the single model/visleaf, are still obviously inside the view of the camera, but get hidden/stop rendering when I move, again I assume, the player origin from the void into the closed room. 

Also I don't know if this matters to the discussion but I have no problem transporting the player between the different "rooms", physics, lighting and sound, seems to work correctly, have not tested AI because right now, I don't have a working AI model, so perhaps the thing that fails is AAS.

Btw in Doom 3 when the player first gets transported from Mars to hell, using the transporter, is that really loading a different level? I remember that organic tunnel effect during the transport but I don't remember the game going into a loading screen that it normally does, when changing levels, but truth be told I don't play Doom 3 for ages.  

Link to post
Share on other sites
1 hour ago, HMart said:

Sorry if I'm being stubborn but have you seen my video and what I show at the end?

Sorry, I can't see what's happening from that video. All I see is a distant room flickering on a completely black background; I can't see what is being rendered or sent to the GPU (since r_showTris is turned off, noclip doesn't provide any information about render culling, and I can't even see if you are behind or in front of another wall since everything else is completely dark).

If you want to definitively see what geometry is being sent to the GPU, you need to use r_showTris 2. Without this option, there is no way to tell the difference between something not being rendered at all, and something being rendered but hidden behind another object.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...