From Hammer to DarkRadiant, some questions

[Skaruts]

I made maps for the source engine for a few years (specifically for HL2dm), so I have a fairly good understanding of how BSP geometry works and most of its intricacies, but there are a number of differences from half-life to quake (EDIT: I meant Doom :S But I guess it doesn't matter much, they're all very similar). I don't think that's a problem, though, I think I just need to adapt. But I'm looking to understand the differences.

 

I started playing around with Dark Radiant, and a few things came to my mind so far.

 

To put it all in context, in Source there were Hints and Area Portals, and they had different uses. Hint brushes were used for manual control over visleafs, which suficed to get the engine to automatically determine what geometry to render and what not to (used in corridors, and doorless doorways, for example, like visportals are, except that they didn't turn on or off, they just manually controlled where visleafs started and ended), while Area portals were used to turn rendering of separate sections of the map on and off (mostly used in doors and windows, and the like, and they did turn on and off like visportals do). They were also recommended to be used sparingly (the APs, not the Hints), for performance reasons (although, I always wondered if that was a myth, to a certain extent).

 

There were also Occluders, that were used to prevent rendering entities that might be hiden behind some geometry where hints and area portals might not work (for example, crates or NPCs behind a shattered wall from say, a ruin, which the player wouldn't see until he went around the wall and thus shouldn't be rendered until then - or stuff behind a hill, on top of a catwalk, etc)

 

https://developer.va...ty_optimization

 

So, I'd like to ask a few questions:

 

1- Are Visportals the only thing used to control visleafs and overal visibility in DR, and used for both purposes? Or did I overlook something?

And is there such a thing as too many visportals and any related performance issues?

 

2- Is there an equivallent to occluders? (this isn't very important, just out of curiosity. I don't think I ever even used them)

 

3- Are there cvars to show visleafs ingame and for ingame fullbright? (I couldn't find any of them in the wiki)

 

4- Is there anyone here with experience in Source SDK that might point out other stuff I should be aware of?

 

 

This is all I have for now. Any feedback would be greatly appreciated.

Thanks in advance.

Edited February 2, 2014 by Skaruts

[Xarg]

By no means an expert, but my take on your questions

 

1b- I've read there is a performance hit for visportals, though I've never really noticed any.. what I have noticed, is performance hits when you don't use them, the longer you go on creating the things the worse the performance will get, and it will not stop getting worse until you put in some portals to remove some of the out of sight stuff from rendering.

 

3- If I understand what you're asking (and have the correct binding set in my .cfg), try r_showTris 0/1/2/3, that should show what's being rendered and how complex it is (what would be inside what I understand a "visleaf" to be)(if you actually want to just see if a portal is working properly and whether or not it is open, r_showPortals 0/1), I don't think I understand what you mean by "ingame fullbright" though.

[RJFerret]

Others will please correct/enlighten me where I'm wrong.

 

1a. Yes, visportals are the sole method to seal visleafs and allow a connection between them. They do have a subset (via spawnarg) function of allowing openings that control sound propagation or manually being controlled.

 

1b. I've not heard/come across anything suggesting minimizing visportals for performance. However, the nature of geometry obviously limits the quantity. There's just so many areas you can reasonably separate intersections. Obviously line of sight affects things too, there's no point putting portals where they'd always be open and you spend lots of mapping effort creating sealed areas for them.

 

2. The equivalent to occluders that comes to my mind would be the hide spawnarg based upon distance rather than occlusion--which is designed more as a coarse LOD feature for when you don't have LOD models/functionality. That being said, there is a technique with a visportal to show a 2D representation of what would be behind with it manually closed (which would show black or sky natively). However this is rarely used.

 

3. I don't know of anything that shows leafs or fullbright specifically. r_showportals 1 will show rendered visportals (green if open, red if closed) which are obviously dividing your leafs, and r_showtris 2 will show geometry that is being rendered even if occluded if an adjoining visportal is open (green) such that the adjoining leaf is being rendered.

[Bikerdude]

1. Yes, visportals are the sole method to seal visleafs and allow a connection between them. They do have a subset (via spawnarg) function of allowing openings that control sound propagation or manually being controlled.
   
2. I've not heard/come across anything suggesting minimizing visportals for performance. However, the nature of geometry obviously limits the quantity. There's just so many areas you can reasonably separate intersections. Obviously line of sight affects things too, there's no point putting portals where they'd always be open and you spend lots of mapping effort creating sealed areas for them.
   

1. And just to add, you apply said spwn_args to a "func_portal" entit that you place into the Vizportal.
   
2. the smaller a VP, (just like in real life with a hole) the less the viewer can see through it.
   

[Springheel]

Obviously line of sight affects things too, there's no point putting portals where they'd always be open and you spend lots of mapping effort creating sealed areas for them.

 

The exception would be for proper sound propogation; sound goes straight through brushes inside a single visleaf, so you may want to use portals to guide it properly.

[Skaruts]

Thanks for the feedback.

 

I just made a quick test and noticed the engine doesn't hide any geometry at all by itself, so it isn't taking visleafs in consideration without visportals. Visportals it is, then.

 

I still would love to know how the engine handles visleafs, so that I could test how exactly to place the portals in certain situations, to not end up creating unnecessary leafs, but... I guess I'll have to rely on that not being a performance killer if the rest of the map is well organized.

 

 

By the way, I don't suppose there is any way to make the "tool shaders" (such as nodraw, visportals, caulk, etc) transparent. Or is there a way? Stuff gets really confusing with this... (I know I can filter them, but I can't filter them while I'm working on them - and I'm very used to be working like this)

Edited January 31, 2014 by Skaruts

[RJFerret]

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

 

There are three articles in there that'll give you the insights you desire.

 

Leafs are entirely reliant/triggered by visportals. Visportals are based on line of sight. As such, if you put two visportals in a row, when they overlap, both will be open, all three regions will be rendered (current, beyond visportal, and beyond the one aligned). That's not great.

 

Better would be if the further area is around a corner and the visportal to it is not parallel to the first. Now when the player looks down that way, the first will be open, so two areas are rendered, but the one around the bend will be closed. Yay!

 

I wouldn't worry at all here about creating "unnecessary" leafs. Consider it based upon what the player will have in view. You would not visportal every cavity made by every shelf in a closet. They'd all be open/rendered when in view, so no gain. However a visportal on the door of the closet is important, so when the player jostles items within, the sound comes out the proper opening and goes around down the hall to AI.

 

Go ahead and try placing too many portals, you aren't going to try dividing every room into multiple leafs after all! But each room wants to be it's own. Each hall it's own. Each courtyard it's own. Each whatever, it's own.

 

When it gets difficult/challenging is outside, doing a city street. There you intentionally want to design to create as many as you can, or performance will decline horribly. To achieve this, you want lots of corners instead of long straightaways. It can also be tricky to deal with roofs, especially if you want the players to be able to get up there.

 

I believe you'll really need to get out of this mindset of not creating too many leafs, and instead try to create as many as you can.

Like I said before, creating the sealing geometry and designing for portals takes effort that draws you away from other creation, so you won't overdo it.

[Skaruts]

Nah, I don't really have that mindset. Controlling visleafs was relevant in Source, since the engine calculates visibility automatically, but not always the right way. If the leaves are all manually created that's not relevant anymore. I still like to know the details, so that I have a good idea of what's happening behind my work.

 

Thanks for the links.

[Springheel]

This starts off basic but has some good advice after the 7:40 mark.

 

[Skaruts]

Thanks Springheel. I already have a fairly good understanding of how to use them (not wanting to sound like an expert, which I'm definitely not), I just needed to know if there was anything else besides visportals in this engine. I had already watched that video too. But thanks anyway.

[Mortem Desino]

Hey, another chum that migrated from Hammer! Welcome!

 

If you've got a good handle on how to use hint/skip, then you're already prepared for visportals. The Hammer map compiler was pretty smart at figuring out good visleaf separation (assisted by the mapper's hint/skip). In idTech4, you have to think through visleafs yourself.

Otherwise, visportal rules are very much like areaportal rules. You can put several visportals side-by-side if the hole it covers is irregularly shaped. Visportals with more than 4 sides (e.g. an octagon-shaped hole) can work, but are generally advised against.

 

In idTech4, a visportal touching a door, or a visportal with a func_portal point entity touching it, are very much like a HL2 Areaportal. The first opens on activation (no linking required), and the second opens at a specified distance). I wish we had something like a func_areaportalwindow, coz all visportals "pop".

 

The larger areaportals in HL2 that you would close with trigger brushes are largely automated in idTech 4 (i.e. they're turned on/off well enough just depending on their visiblity)

 

idTech4 has no equivalent to an Occluder, unfortunately. Even though they were a CPU hog, they could help a lot with large outdoor areas.

[Skaruts]

Thanks Desino. I've been doing some testing here and there to see how they work as situations come along. So far so good. Trying to make a large city with rooftops access is a tricky puzzle though.

Edited February 4, 2014 by Skaruts

[RJFerret]

Trying to make a large city with rooftops access is a tricky puzzle though.

 

Hear, hear. I wish I knew a way to pull that off. The nature of the beast precludes seeing over a roofline, nevermind going over it.

[Skaruts]

Hear, hear. I wish I knew a way to pull that off. The nature of the beast precludes seeing over a roofline, nevermind going over it.

I have a few ideas I'm testing. On both I'm "encapsulating" the city in sections, and one of my goals is that on the roofs you'll have "rooftop-roads" which work much like any other corridor, but between roofs and higher buildings.

 

On one I'm trying to leave it open wide but with city walls separating the sections, so that on a worse case you never have more than that section rendered when on the roofs, on the other I'm still trying to do the same but with higher buildings instead of walls. I'm thinking a mix of both might be a pleasant sight, though. If that fails, I'll go with the roof-roads concept.

 

The streets and the wide areas are the tricky part. Ideally I'd want to leave them open, but I'm not sure if that's a good idea. Currently I'm leaving the large road that traverses the city open to the sky, and the alleys covered by the top floors that bridge across. So basically the alleys are tunnels (and I'm leaving enough height to make several rafter-paths in the alleys) .

 

Now... If any of this will work, I have no idea. But sounds feasible to me.

Edited February 4, 2014 by Skaruts

[RJFerret]

It will be feasible if the main road that traverses zig-zags, so there are corners interrupting line of sight for visportals. (You can also use them horizontally, which might help if the accessible roof height is high enough.)

[Skaruts]

Yea, all the roads and alleys do zigzag (originally the alleys were intended to create L shaped entrances to some houses).

 

But the problem with visportals on open roads is that they don't get enclosed by anything on top, so they'll all be open when you're on the roof looking at the road (regardless of zigzags and horizontal visportals (which will also be always open when viewed from the roofs) - unless perhaps if I make double visportals horizontally.. hmm, gotta try that). I was thinking I may have to surround the road with higher floors and extend the visportals up to the sky brush. This would probably work, but it would also take away the chances of looking down the street from the roof. Unless I can manage to create openings for the player to get in there at certain places.

 

Perhaps I should make a thread about this. Maybe someone else has found useful tricks that remain unshared.

Edited February 4, 2014 by Skaruts

[RJFerret]

*nods, yeah, you're ahead of me. ;-) That was why I was saying high enough so a horizontal visportal might close. Doubling them might be good, I was envisioning a set surrounding the roof/road vertically up to sky which would be perpendicular and negate the need to double. That way when the horizontal wasn't in line with the bottom edge/roof edge, it would close. It's only if the player goes to that edge to look down, which is when you'd want it open anyway. At least the other three sides of the building would be closed then.

 

Corners would be the worst spots, since every roof leaf in sight as well as more than two on the road.

 

Although they can be touchy, it technically is possible to put them at angles too, such that you can keep them out of line of sight for longer, if that makes any sense.

[Skaruts]

Indeed, that's one of the options I was thinking of.

 

Although they can be touchy, it technically is possible to put them at angles too, such that you can keep them out of line of sight for longer, if that makes any sense.

That's also not a bad idea at all. I've been placing them 32-64 units in and away from the corner edges, so that you have to come closer to the corner to open them. But now that I think about it... diagonally might be a bit better. I think I can control the angles better that way.

Edited February 4, 2014 by Skaruts

[Skaruts]

Doubled portals alone seems to work reasonably well. I guess I can mix it with walls of buildings like you mentioned, depending on the situation and the performance demands.

http://www.mediafire...27q6z/test3.map

 

Diagonal portals in this case didn't work. They only gave me glitches.

Edited February 4, 2014 by Skaruts