Newbie DarkRadiant Questions

[MirceaKitsune]

Honestly, I still don't understand caulk. If you build a caulk wall through a room or a street, the two sides are sealed off from each other, but you can look right through the caulk and see the other side, because it gets rendered, but apparently with better performance than sealing the same gap with a visportal?

 

That's a bit too heavy for me.

 

Caulk is used to texture surfaces which you are certain will be invisible, but which you also want to act as a full solid (unlike Nodraw). This can be a face on a brush which is fully covered by another face, or the backside of a wall if it's an area the player can never walk to. I think it's a good idea personally... helps keep things better organized at least.

[stumpy]

dmap treats caulk as a solid but doesn't create a texture for it, so that when you goto beta test something with map you can see where you've forgotten to put a texture.

 

the <yourmapname>.lin file when loaded into darkradiant via the pointfile option in file, will show the path to the leak as long as you have a info_playerStart entity in you map.

 

leaks will be either an entities origin in the void or a hole in the map that goes to the void, or a brush with a window texture on all of its sides that has a side that sits in the void.

[Bienie]

dmap treats caulk as a solid but doesn't create a texture for it, so that when you goto beta test something with map you can see where you've forgotten to put a texture.

 

the <yourmapname>.lin file when loaded into darkradiant via the pointfile option in file, will show the path to the leak as long as you have a info_playerStart entity in you map.

 

leaks will be either an entities origin in the void or a hole in the map that goes to the void, or a brush with a window texture on all of its sides that has a side that sits in the void.

 

I understand the causes behind the leaks (aside from the origin thing, that never occurred to me!), it's just that when you do pointfile in DR usually you get a long squiggly line that is more than unhelpful. I've gathered you can look in the log in TDM console while dmaping to see some more detailed information that has helped me a few times. I think the message I have to take home though is to build from scratch in grid 8 to avoid 1000 leaks to fix further down the road.

 

Honestly, I still don't understand caulk. If you build a caulk wall through a room or a street, the two sides are sealed off from each other, but you can look right through the caulk and see the other side, because it gets rendered, but apparently with better performance than sealing the same gap with a visportal?

 

That's a bit too heavy for me.

 

Haha, I'm glad I'm not the only one confused by caulk. So far I only use it for coating surfaces that will be unseen. Read different ideas on whether it improves performance or not, but either way it seems like sound practice. I feel it also helps to make maps look more organized in DR as MirceaKitsune mentioned.

 

Anyway I will continue working with this new information in mind. If nothing else I hope I can make some cool prefab houses for people to use in their missions. But I'm really hoping to release one of my own as well

 

edit: Oh, while on the topic of sealing the void, how do patches work in this regard? One sided patches wouldn't seal I guess, but how about if you thicken it so there are no openings to it? Thinking mostly of rounded roofs on buildings and that sort of thing?

Edited November 5, 2015 by Bienie

[Dragofer]

Haha, I'm glad I'm not the only one confused by caulk. So far I only use it for coating surfaces that will be unseen. Read different ideas on whether it improves performance or not, but either way it seems like sound practice. I feel it also helps to make maps look more organized in DR as MirceaKitsune mentioned.

 

Anyway I will continue working with this new information in mind. If nothing else I hope I can make some cool prefab houses for people to use in their missions. But I'm really hoping to release one of my own as well

 

edit: Oh, while on the topic of sealing the void, how do patches work in this regard? One sided patches wouldn't seal I guess, but how about if you thicken it so there are no openings to it? Thinking mostly of rounded roofs on buildings and that sort of thing?

 

The only things I really use caulk for are:

- the outermost surfaces of the map, so i can enable the caulk filter and look into my map from anywhere without any sealing brushes in the way

- if there'll be func_static walls or patches in front. That avoids running lighting calculations on a 2nd large surface that will never be seen. (It's a quirk of the engine that large single-piece walls cause a slowdown when multiple lights shine on them. One optimisation method for when a mission is almost completed, brush carving, is to clipper walls into smaller pieces so that fewer lights hit each piece.)

 

Otherwise I wouldn't worry about 'caulking' anything. Tests showed that even caulking tens of thousands of smaller surfaces is still a minimal fps increase. And the engine automatically caulks unseen surfaces on worldspawn brushes anyway.

 

 

 

And, patches don't seal at all. For rounded tower roofs that should have accessible rooms inside you'd need to make an outside and interior layer of func_static patches, and inbetween those you'd need simple worldspawn brushes for sealing - best use caulk for those brushes. It's very fiddly and loses a lot of interior space because of the brushes, so I'd suggest going for an angular roof if you want people to go inside.

[rich_is_bored]

It's my understanding that caulk doesn't block visibility. I'm not even sure it survives the compilation process.

 

A map file is simply a collection of entities, brushes, and patches. The interior volume of the level is not explicitly defined but inferred from entity placement during compilation.

 

Imagine every entity is replaced with a water spout and the level is being flood filled. This is where caulk is useful. You fill the gaps created by non-sealing textures and geometry with caulk to assist the compiler. As far as I know, caulk serves no other purpose.

 

If there is a test case where using caulk in an unconventional way improved performance I'd like to see it.

[HMart]

I don't know if this was asked before but how do you guys solve light leaking through walls? In my map i'm seeing many places where light just shines into the next room, as if the brushes have gaps on them, but there's no leak detected.

[demagogue]

Make sure first that shadows are turned on in the properties for the lights (i.e., you want "noshadows 0"). If they're turned off, the leak is just the lights not casting shadows from the walls.

[Melan]

@Hmart: Also check if you haven't accidentally applied noshadows 1 to your worldspawn (which means all your terrain).

[HMart]

Ok guys thanks for the help, i decided to remake all the walls on my level (using modular design) and solved light leaking, still don't know why it was leaking, perhaps some bad geometry, or some problem with portals, i didn't applied noshadows to any brush, but now is solved.

 

I'm having another problem tho, i'm trying to make a new particle but the particle editor is not saving it, i'm not seeing my .prt in the particles folder.

[Spooks]

On the subject of lights, is there a spawnarg or something to make a light seem to move about? I don't mean flicker. In atdm:fireplace_brick, for example, stand near the flame with player shadow enabled and you can clearly see the effect of the shadows moving. I can't seem to find a way to replicate the effect.

edit: Heyy, it's the light_moving entity. I ended up manually having to copy a bunch of inherited properties and then I found I could just use it instead. Oh well, you could say that posting the question made me look extra hard so the forums did help.

Edited November 7, 2015 by Spooks

[HMart]

You could just bind the light to a func_bobing, func_pedolum or func_rotator with very low speeds.

[Spooks]

Thanks for the suggestions! I've been messing with particles tonight and I've some pointers on your particle question.

From my experience DarkRadiant always saves the particles made in the particle editor in DarkRadiant/particles, even if you specify a different folder. So if you have your DarkRadiant not installed in the same directory as TDM (as is my case), that might be your problem. The particles are supposed to go in /particles, which should be in the same folder that also contains your /maps folder.

 

BTW, I'm experiencing weird behaviour with the tdm_lamphaze_wide particle and its variations. The _color spawnarg works without "Use Entity Colour" being enabled, but only when r_usesoftparticles is set to 0. Other particles are fine, it's probably just the texture used in those ones that's somehow doing it. Don't know if it's that much of an issue being that most people won't have soft particles disabled but I don't know why it's the way it is and it's ticking me off.

[Dragofer]

Does someone know a way to instantly stop a patrolling AI, then make him forget where he was going so he can be redirected to a new path? I'm very much after this for a custom AI in Down by the Riverside.

 

These are things I've tested so far:

- script: $ai.stopMove(); only makes the AI twitch

- script: $ai.wander(); as soon as he stops wandering he goes back to finish off his old path

- script: float movestatus(); I haven't found out what needs to go into this script command

- stim/response: clear all targets didn't have any effect. I've used it on the AI or his current path entity, and on its own or combined before or after those script commands

[Bikerdude]

you could use a trigger to remove a path node I guess...

[demagogue]

I wonder what happens if you change the targets of the path nodes by script, if that gets them on a new path.

[Springheel]

If you teleport his current pathnode somewhere that he can't get to, that might stop him. Then use a changetarget entity to give him a new destination.

 

A hackier solution would be a sound that only AI can hear, that triggers him to alert level 2. That would cause him to stop for a few moments.

[Obsttorte]

Does someone know a way to instantly stop a patrolling AI, then make him forget where he was going so he can be redirected to a new path? I'm very much after this for a custom AI in Down by the Riverside.

 

These are things I've tested so far:

- script: $ai.stopMove(); only makes the AI twitch

- script: $ai.wander(); as soon as he stops wandering he goes back to finish off his old path

- script: float movestatus(); I haven't found out what needs to go into this script command

- stim/response: clear all targets didn't have any effect. I've used it on the AI or his current path entity, and on its own or combined before or after those script commands

I've done such thing a while ago (where a while means more then a year) and can only tell you it is possible, but hacky. Maybe I'll stumble over the files.

[Spooks]

I've been wondering if I should put pairs of visportals on some of my windowpanes in my map, like in Komag's tutorial video, but just about the only thing about visportals I don't get is what's the actual difference, performance-wise, between a closed and an open visportal in a situation where there's next to nothing being rendered in the open visleaf anyway, like in the picture. Or is it that the entire visleaf is rendered anyway but r_showtris will only show tris that the player can "see" in there through that visportal, hence the need for pairs of them in certain situations?

 

 

 

And another thing I've been meaning to ask, I've thought of using a number of small ambient lights to simulate radiosity/light bounce paired with a principal, shadowcasting pointlight in order to avoid the light bleed of one big ambient light while still being able to change the ambients' color independent of the pointlight.

 

You can see how it's set up, 3rd light from left to right is the principal one, and the other three are biground ambient lights that overlap for better color blending.

 

Now the thing is, I know lightpasses on surfaces are the engine's biggest FPS eater. But is it so bad if it's just small ambients rather than shadowcasting pointlights? I know, I know, this is an extremely lazy method to do this sorta thing and I would be much better off creating a custom light falloff texture (and I probably will later), but I'm wondering for the sake of science.

Edited November 16, 2015 by Spooks

[Obsttorte]

The visleafs are neccessary for the engine to decide, which tris can be seen theoretically. Which ones are drawn is decided via the depth-map, so tris that can't be seen don't get rendered, but they have to be taken into account to create the depth-map. So even if they are not visibhle, the engine has to go through all of them to find out which can be seen and which not. If a visleaf is discarded from the beginning on because the visportals leading to that are closed, this will save a lot of calculations to be done.

 

In the case of a window, it can help to have two visportals. But as they will be pretty close together like in your case, the usage will be not as high as you may expect.

 

A little hint. Use r_showtris 3, this will show you the discarded tris, too.

 

Regarding the ambient light: It really depends on the situation. Obviously there are better ways to achieve your desired effect, like a cubemap light , but setting them up is normally more time-intensive than your approach, so what you've done isn't neccessarely bad. It really depends on your situation. You have to see how the setup you've choosen will affect performance in the end. If it is fine, than there is no need to use a more complicated approach just because it is "better". If it works, it works.

[Spooks]

Ooh, the visleaf information is very informative and I haven't seen it around so it's great to have it explained, thanks.

 

To be fair, I've only skimmed the Light Textures and Falloff Images wiki page as I'm still busy hammering out geometry in my map, but it's nice to know ahead. I've not seen any cubemap lights in TDM, but I do see them mentioned at the end of that wiki page, are those what you mean or something like using 'envshot' images for light textures?

Edited November 16, 2015 by Spooks

[Obsttorte]

1. Ooh, the visleaf information is very informative and I haven't seen it around so it's great to have it explained, thanks.

I've not seen any cubemap lights in TDM, but I do see them mentioned at the end of that wiki page, are those what you mean or something like using 'envshot' images for light textures?

1. I've read this up on an article written by someone who has worked on the engine iirc. I think nbohr1more once posted the link in the forum. An interesting read.

The latter. You can use envshot to create cubemaps. As those are simple images you can improve them by using an image manipulation program like gimp or photoshop to get a soft shadow like effect. I've never tried this technique myself, but I guess it is pretty powerful if used correctly. But it also means some time effort. I guess the best use it would gain by using it on outdoor scenes to simulate proper moonlightning, as it could bypass the heavy performance impact a large shadowcasting light would have. (When creating the envshot performance plays no role. The game can run at 1fps, you only need a shot of one frame anyway).

[nbohr1more]

Currently, lights can only be 1D+2D projections. You can use the classic Strombine technique for that.

 

Cubemap lighting is possible but we would need to incorporate code support.

 

I've been the biggest proponent of it and I think I know a kludged way to do it but I would prefer that a more

elegant solution be incorporated (define custom light interaction programs in the material shader).

 

I suppose you could include a custom override glprogs in your mission pk4 if you wanted the effect

before whenever it gets added to the mod. It would make all lights into cubemap lights and you would

need the accompanying cubemap assets and material defs to use them but it should work.

 

Code support would negate the need for replacing all existing light assets.

[Kiln]

For some reason all my new brushes (non-cloned) dragged into existence on the ortho view have a ridiculously huge default texture scale on all faces (like 6x the default - i.e. 3.0 vs the default of 0.5) Don't know how it happened, it started about 2 hours ago and nothing I can think of will fix it. Where is this setting hiding?

[Obsttorte]

Surface inspector (press s).

[Kiln]

I found the setting, somehow Preferences->Settings->Primitives->Default texture scale got set to 3 (???) Dunno how that happened. That was what I was looking for, I knew the setting was somewhere, but damned if I could find it in my mental state last night. The problem was I'd have to go back through and select sides manually and re-enter 0.5 each time I dropped a brush (or mmb from a neighbor.) It sounds trivial, but I rely on default tex sizes to rough in geometry and it's surprisingly irritating when you feel like a Lilliputian all the sudden.

 

I think the initial problem may have arose when I opened a second map to ctrl-c / ctrl-v some geometry from an old map. Radiant really has some eccentricities going on doesn't it?