Newbie DarkRadiant Questions

[Shadowhide]

up

question is on previous page

Edited November 26, 2011 by Shadowhide

[Thor]

Formally it doesn't matter how you assemble the brushes. Large rooms, small rooms, many, few, the brushes don't care. Now performance might care.[..]

 

[..]I think even a very big room isn't going to be a problem as long as it's VP'd to the surrounding rooms. It's when you get big outside spaces like streets, yards, or fields where you need to think ahead.

Thanks for the tips! I treid out the large ocean-esque space and it seems to work perfectly with the little detail I have in it so far. Yeah I'll definitely use visportals, had researched that a tad myself a while ago. What do you mean by thinking ahead with the visportals in open spaces I don't know, though. I'll just stuff a few in the area itslef and to each gap towards the other areas. If I pull this off it should be pretty cool. Lots of work on terrain now + experimentation follows, though.

 

Also I made it so that I might even consider the possibility of importing the brilliant idea of a controllable boat. But that's just... thinking ahead and over my head.

 

One thing though. I have a lot of water and if viewed from far above or below the pattern is really obvious. Not much can be done there, I imagine? Except maybe if I enlarge the texture and reduce the water's movement speed... hhmmmm.

Edited November 26, 2011 by Thor

[grayman]

1.07 ai will be noticing open doors and being suspicious because of that ?

friendly ai will behave that way too ?

what if friendly ai that is scripted to talk with player will see open door ? everything will be ruined because of that

is that behavior will adjustable ?

 

Give the friendly AI this spawnarg:

 

"chanceNoticeDoor" "0"

 

and they won't notice any suspicious doors.

[PranQster]

Is there (yet) a way to apply noshadows to a torch carried by an AI using def_attach? Or am I stuck with the good old bind technique to do that?

[Fidcal]

Is there (yet) a way to apply noshadows to a torch carried by an AI using def_attach? Or am I stuck with the good old bind technique to do that?

 

I think the following should work. I've not tried it so fingers crossed:

 

Summary: You can copy the torch def and give it noshadows then def attach that.

 

Details:

In one of the pk4 files is tdm_prop_items.def

Open in a plain text editor

Search down for // Carryable Lights

Copy one of the torch defs, eg,

 

entityDef atdm:prop_torch_on {

~~~~~~ down to....

 

"is_torch" "1" // can be used to relight doused flames

}

Paste that in a new text file and save it as eg myname.def in a darkmod/def folder or in your own mymap/def.

 

Edit the text file to include a line in there:

"noshadows" "1"

Rename the heading to eg,

 

entityDef prop_my_torch_on { // (ideally don't include atdm: in the name as that's for official tdm stuff.

 

Save the file.

 

Then use the above name prop_my_torch_on in your def_attach spawnarg on the AI.

[Springheel]

Can't you also pass that spawnarg on the same way you can alter the size of lights on candles?

[Baal]

Is there a convenient way to do that, that I don't know of? Other than defining and attaching a new light entity?

[Springheel]

Yes. If you do this to a candle or candle-holder:

 

set light_radius on flame

200 130 120

 

It will override the light_radius of the attached flame with the new size you typed in.

 

In principle, it should work for torches as well. You'd do something like this on the AI entity:

 

set noshadows on [name]

1

 

[name]=the name of the torch entity, which I don't know off the top of my head.

[Baal]

Thanks. To be clear, you mean setting a "light_radius" key on the holder entity, that's then passed to the attached light entity?

 

I don't think that will work with "noshadows". That key already exists on the holder entities.

[PranQster]

Thanks all. So far the def_attached torch is not affecting performance, but that may change as I build more and add more lights and AI.

[RPGista]

Damn, does anyone knows whats the deal with patches and projected shadows?

 

It seems patch surfaces can catch lights easily enough on their faces, but they can't project shadows themselves, effectively messing up random ammounts of shadow area behind them. I observed that water tight patch volumes will cast shadows as if a normal brush, but appearently not even that is certain as I'm still getting messed up shadows. Is it safe to say that "open" groups of patches will not cast shadows correctly, EVEN when they form a closed volume, when associated with brushes (imagine for example, a sandbox (patches) with brush walls)?

 

PS: By cast shadows correctly I mean as an object casting shadow over the environment, not just receiving light/shadow from other objects, as a terrain patch, which it does correctly.

Edited December 12, 2011 by RPGista

[Sotha]

I don't get the problem.

 

There is usually no issues with patch shadows. Their faces will cast shadows. The shadows will look correct for the patchwork. Sometimes patches do not need to cast shadows. Like vaulted ceiling. You can make 'em into func_statics and use "noshadows 1". This optimization saves tris. Just be sure you have the insulating worldspawn brush above the ceiling to have a texture. Not caulk. Otherwise the light from the room above will leak into the floor beneath the vault ceiling.

[RPGista]

 

If you create patch surfaces around the map, they will not cast shadows correctly over the rest of the environment, though you can see clearly that they will behave normally when its about casting shadows over it's own surfaces. Just not when casting shadows as a true solid surface over whatever is behind them. If I were to thicken these same patches, they are supposed to form an enclosed shape and thus would behave as a normal physical model inside the map. The problem is that it isn't always so - I have created a large patch box that is supposed to cast shadow over another box next to it, and I'm getting glitches on that cast shadow. I thought that light was leaking inside somewhere and thus ruining the whole shadow volume, but I remade the thing and still it isnt behaving correctly. Let me try a couple more tests...

 

EDIT: I was able to correct the problem, now to do it again step by step to see where I went wrong. This is for my opening scene by the way, so I mean to get it right.

Edited December 12, 2011 by RPGista

[Springheel]

Thanks all. So far the def_attached torch is not affecting performance, but that may change as I build more and add more lights and AI.

 

 

Oh, you mean make the torches' light a non-shadow casting light? That's different than what I thought you meant. The same princple should apply, but I'm not sure what the keyword is for turning off shadowcasting on lights.

[Baal]

Lights moving with AI shouldn't have shadowcasting disabled anyway. They could light adjacent rooms when close to a wall, for example.

[Springheel]

Yes, that's a good point. Nonshadowcasting lights go right through obstacles, so need to be used carefully.

[Baddcog]

Also make sure you're not using any shader that ends with _ns

 

That's no shadows specifically for objects that has a low poly shadow mesh. There is always a version of those that casts shadows normally.

[PranQster]

Cool. No problem, I'll just use the def_attach torches sparingly.

[RPGista]

On the subject of shadows, is there any reason a bunch of (irregularly shaped) brushes won't cast shadows? I was having some problems with a model, made a simpler version of it with brushes, put them all into a func_static, but now they wont cast shadows. I havent changed any parameters of course. And I made sure they are attached to the grid, etc.

[Springheel]

The only reason I know of would be if you're using non-shadowcasting texture (usually indicated by a _ns suffix).

[RPGista]

That's exactly what happened. Thanks.

[Xcen]

I have a problem with a skybox and a foglight.

If the skybox is outside of the foglight's volume everything is fine but when I put the skybox inside it's rendered straight over my foglight.

 

Is there a solution/workaround for this? Without cannibalizing the map layout or deleting the foglight.

[Baddcog]

Xcen, a pic of the map layout might help (but it's a spoiler so...) Does the sky box need to be inside the volume?

[Xcen]

Does the sky box need to be inside the volume?

It would be difficult to keep it outside.

 

 

Here is a mapfile:

https://rapidshare.c...ht_skybox_2.map

 

1st room: Skybox inside the foglight

2nd room: Skybox outside

3rd room: Possible workaround

4th room: The Problem with the workaround

Edited December 18, 2011 by Xcen

[Baddcog]

Not sure exact what you need, or how your map will play out as far as design goes.

 

But number 2 looked the best so I worked with it. Basically you need the foglight to touch all textures, but NOT the sky texture.

 

So run the light up to the top of the terrain, then put an empty volume above it that is sky on all sides. But give yourself some room so the foglight never touches the sky.

 

I imagine what you want so so everything to be fogged and not have the weird clear sky.

 

http://dl.dropbox.com/u/15441325/foglight_skybox_3.map

 

It's perfectly fine to let the skybox be larger than the map and go out around it a bit to give your self room. Unlike Source, Radiant doesn't kill you for using large spaces. The biggest thing is getting portals in nicely.

 

I through one in there and there is no issue with the fog. But I tried to seal with caulk and was getting some weird scissoring in there then.

 

If you are doing tombs, and can just look up at the sky every once in awhile it will be easy enough. A city would be tougher and you'd really have to build with it in mind.

 

If you have any questions you can PM me so everyone doesn't know where your map is going. It would be easier for me to explain/show if I know exactly what you want to do.