Newbie DarkRadiant Questions

[nbohr1more]

Yeah, there were a few dmap fixes since 2.10. I can't say for sure whether you hit any of the known ones but splitting brushes near lights is an old remedy anyway ( called Brush Carving by Doom 3 mappers ).

[Frost_Salamander]

2 minutes ago, nbohr1more said:

Yeah, there were a few dmap fixes since 2.10. I can't say for sure whether you hit any of the known ones but splitting brushes near lights is an old remedy anyway ( called Brush Carving by Doom 3 mappers ).

OK thanks - you've helped my identify the problem regardless so I know what to look out for in the future now 

[Something Hank]

Yeah I'm just gonna start posting in here otherwise I'ma make seventy thousand topics.

 

Current issue: I've placed a hanging lamp model in an area, and then put in a Create Light, cause I wanna customize the light strength and color.

Problem is that I don't want the light playing really funny shadows with the lantern ITSELF on the ceiling or the ground. I essentially want to mark the lamp itself as "do not cast shadows" so that it can just light the area in an expected box, and I know it must be possible cause many prefabs/light entities do exactly this.

I just can't find out how to do so, and google and wikis are struggling. Any help?

Edited October 7, 2022 by Something Hank

[Frost_Salamander]

35 minutes ago, Something Hank said:

Yeah I'm just gonna start posting in here otherwise I'ma make seventy thousand topics.

 

Current issue: I've placed a hanging lamp model in an area, and then put in a Create Light, cause I wanna customize the light strength and color.

Problem is that I don't want the light playing really funny shadows with the lantern ITSELF on the ceiling or the ground. I essentially want to mark the lamp itself as "do not cast shadows" so that it can just light the area in an expected box, and I know it must be possible cause many prefabs/light entities do exactly this.

I just can't find out how to do so, and google and wikis are struggling. Any help?

If you don't want the lamp to cast shadows, set the spawnarg 'noshadows' to '1' on the lamp model.  If you don't want that light to cast shadows on anything, set it on the light itself.

[Something Hank]

1 minute ago, Frost_Salamander said:

If you don't want the lamp to cast shadows, set the spawnarg 'noshadows' to '1' on the lamp model.  If you don't want that light to cast shadows on anything, set it on the light itself.

Thaaank you bub. I figured it'd be something that simple, just couldn't find a result for the life of me.

[Obsttorte]

15 hours ago, Something Hank said:

Current issue: I've placed a hanging lamp model in an area, and then put in a Create Light, cause I wanna customize the light strength and color.

Problem is that I don't want the light playing really funny shadows with the lantern ITSELF on the ceiling or the ground. I essentially want to mark the lamp itself as "do not cast shadows" so that it can just light the area in an expected box, and I know it must be possible cause many prefabs/light entities do exactly this.

 

There is no need to create light source and model seperately. You can easely tweak the light on combined entities, and having two seperate entities serving one purpose is a guarantee for additional work and errors. If you shift the light, you have to shift both entities, if you want to create a copy of the light, you have to copy both etc...

You should really not get used to this kind of workflow. Create lights via the create entity menu.

[Something Hank]

On 10/8/2022 at 8:28 AM, Obsttorte said:

There is no need to create light source and model seperately. You can easely tweak the light on combined entities, and having two seperate entities serving one purpose is a guarantee for additional work and errors. If you shift the light, you have to shift both entities, if you want to create a copy of the light, you have to copy both etc...

You should really not get used to this kind of workflow. Create lights via the create entity menu.

Didn't occur to me to click an entity and press L. I might well be a moron tbh.

 

Ah well. Thank you, least I understand no shadowing for the future.

 

EDIT: Well new problem regarding light.

It's just bare brushwork and shit right now, but how do I stop light leaking across brushes like this?

 

https://imgur.com/a/wfkPB41

Edited October 11, 2022 by Something Hank

[Baal]

A question for anyone that has some insight into the inner workings of the current version of the engine:

Will this setup of visportals cause me any kind of pain? Like path finding, sound propagation or performance issues?

 

[Obsttorte]

@BaalStill there, nice

Performance-wise those visportals will probably not have much of an effect, as they cover most of the screen and therefore don't really block anything off. It is hard to see due to the dark image, but especially the vp on the right looks like it is bigger then the gap left by the architecture, which doesn't make it very useful in regards to performance. As long as you don't tend to add houndrets of visportals in each area, they normally don't decrease performance at least.

In regards to sound propagation I would expect them to do their job. You just have to make sure that if there are sufficiently large obstruders in the way (like walls), that the respective areas are seperated via visportals, which appears to be the case here.

Pathfinding is not affected by visportals. That is solely handled via worldspawn brushes (unless the material used on them explicitely excludes this behaviour, like for triggers).

I hope that helps and next time, a brighter image please

[Baal]

Thank you.

I am mainly concerned about the grouping of portals and their shape. What happens if i deviate from the basic brush shape (90° angles) or when i join portals of different sizes instead of using one big portal to fit? Can that cause issues?

[nbohr1more]

3 hours ago, Baal said:

Thank you.

I am mainly concerned about the grouping of portals and their shape. What happens if i deviate from the basic brush shape (90° angles) or when i join portals of different sizes instead of using one big portal to fit? Can that cause issues?

As I recall, the only issues around visportals causing performance are either an oversized portal opening and closing causing large amounts of audio calculations to start or a scene with too many little visportals ( the latter being barely a concern ).

@stgatilov has been updating the wiki:

https://wiki.thedarkmod.com/index.php?title=Visportals

so I presume that the preamble about "multiple joined visportals" holds true or else he would have edited it?

[datiswous]

On 10/8/2022 at 2:28 PM, Obsttorte said:

There is no need to create light source and model seperately. You can easely tweak the light on combined entities, and having two seperate entities serving one purpose is a guarantee for additional work and errors. If you shift the light, you have to shift both entities, if you want to create a copy of the light, you have to copy both etc...

You should really not get used to this kind of workflow. Create lights via the create entity menu.

There is this video from Sotha, where he advices the oposite (if I understand correctly):

 

On 10/8/2022 at 2:28 PM, Obsttorte said:

If you shift the light, you have to shift both entities, if you want to create a copy of the light, you have to copy both etc...

You can just group them and then they move and copy together. With the (possible) benifit that you can always ungroup them and alter them independedly, if needed.

Edited October 11, 2022 by datiswous

[Something Hank]

5 hours ago, datiswous said:

There is this video from Sotha, where he advices the oposite (if I understand correctly):

 

You can just group them and then they move and copy together. With the (possible) benifit that you can always ungroup them and alter them independedly, if needed.

Light and model seperately will *probably* be my preference going forward, as it allows me to customize the lights reach and shadow VS the model a lot more fine tunedly. I'm just aware it'll be more work. Currently, I have a lantern that casts light just barely everywhere in its room, EXCEPT the ceiling. Which I achieved by jankily shoving a china bowl into the model, and I love the janky solution enough to keep that one.

 

Also, do YOU by chance know what causes light to bleed through brushes?

https://imgur.com/a/wfkPB41

As it is now the level isn't even near complete so I don't gotta worry much about this YET, but I've got this issue kinda all over the place and wanna nix it in the bud.

[thebigh]

1 hour ago, Something Hank said:

Also, do YOU by chance know what causes light to bleed through brushes?

This happens to me all the time with worldspawn brushes. I've never been able to figure out why, or to reproduce it reliably. But plopping some func_static in front of it usually blocks it. That solution is kind of a kludge, but I figure that if I have a big unadorned wall of worldspawn I'll probably want to decorate it anyway.

Occasionally cutting the floor and ceiling brushes into two pieces works sometimes as well, but not consistently.

Edited October 11, 2022 by thebigh
typo

[AluminumHaste]

Some textures are listed as no shadows, so if you apply that to a brush, it won't block light, something to keep in mind.

If you see a texture that ends in _ns or noshadows, don't use it.

 

[Something Hank]

3 hours ago, AluminumHaste said:

Some textures are listed as no shadows, so if you apply that to a brush, it won't block light, something to keep in mind.

If you see a texture that ends in _ns or noshadows, don't use it.

 

OHP, that was EXACTLY it. I was using blocks_brown_ns as my default brushing texture. Thank you very much! Thank god that was a simple error.

[Obsttorte]

14 hours ago, datiswous said:

There is this video from Sotha, where he advices the oposite (if I understand correctly):

 

You can just group them and then they move and copy together. With the (possible) benifit that you can always ungroup them and alter them independedly, if needed.

Yeah, grouping is an option. I normally don't think of it as it was added years after I've started working with DR.

8 hours ago, Something Hank said:

Light and model seperately will *probably* be my preference going forward, as it allows me to customize the lights reach and shadow VS the model a lot more fine tunedly. I'm just aware it'll be more work.

You can edit combined entities as easy as non combined ones. And electric lights are one entity either way, so it really makes no difference there.

One big advantage of combined entities, for example torch models with a light def_attached to them, is, that you can alter the appearence of ALL those entities by making one adjustment in the respective definition file. If you use your approach and notice later on that something with the torches isn't quiet right (let's say, they are a bit too bright, making the mission too hard), you would have to go through all said torch lights to change that.

Another aspect to consider is that this can easely cause similar models to have lights with different properties (big differences, not slight variations that may even be a good thing), either by oversight or because you forgot to consider it, which would create inconsistencies that the player may not even be able to put his finger on what's causing them. That's not really a good thing design-wise nor considering how often the unreliability of the gameplay in TDM and the considerable high difficulty level tends to frustrate players, especially new ones.

[Something Hank]

EDIT: Posted nonsense, nevermind me.

Edited October 12, 2022 by Something Hank

[datiswous]

5 hours ago, Obsttorte said:

One big advantage of combined entities, for example torch models with a light def_attached to them, is, that you can alter the appearence of ALL those entities by making one adjustment in the respective definition file. If you use your approach and notice later on that something with the torches isn't quiet right (let's say, they are a bit too bright, making the mission too hard), you would have to go through all said torch lights to change that.

Afaik you could create a seperate definition for the model and a definition for the light (in one def file), then you can change that def file.

 

5 hours ago, Obsttorte said:

You can edit combined entities as easy as non combined ones. And electric lights are one entity either way, so it really makes no difference there.

Some of these combined entities don't have a viewable and changeble light radious it seems and you can't change the position of the light itself (I couldn't find a way).

Edited October 12, 2022 by datiswous

[Obsttorte]

9 hours ago, datiswous said:

Afaik you could create a seperate definition for the model and a definition for the light (in one def file), then you can change that def file.

You have to do anyway. But why shouldn't you attach the light to the model than?

9 hours ago, datiswous said:

Some of these combined entities don't have a viewable and changeble light radious it seems and you can't change the position of the light itself (I couldn't find a way).

You set the radius via the args and you have a grid in the background, so not really a problem. It get's easier if you use simple numbers (so multiples of powers of two).

The positioning can be altered by changing the attachment position. (Note that you usually do such things once, not dozens of times).

 

In the end it is up to everyone themself on how they setup their workflow. To me it just always appeared as if the arguments against the usage of combined entities are not really objective ones, as all the things that can be done with separated entities can be done with combined, too, but more in the manner of "it appears odd and I don't wanna try getting used to it".

IMHO the advantages outweight the downside of it beeing a more abstract approach by far, and I have seen a lot of missions going into beta with misaligned lights, misaligned door handles, inconsistent light values etc..., things that are avoidable and that might even carry into the final release especially on bigger mission. And the amount of work you can spare on the long term is way bigger then the tiny bit of time it takes you to get used to it.

[Frost_Salamander]

How do you create an inverted bevel end cap from a bevel that's been flattened slightly?  In the pictures below, I want the end cap to cover the space entirely, and avoid that gap being created after I drag the verts.  Is there a way to make the patch stretch to the upper corner so that gap doesn't appear?

[Obsttorte]

You probably have to set the subdivisions manually. Otherwise it will be choosen depending on size and bending.

[Baal]

1 hour ago, Frost_Salamander said:

I want the end cap to cover the space entirely, and avoid that gap being created after I drag the verts.  Is there a way to make the patch stretch to the upper corner so that gap doesn't appear?

The way I did that, was to simply build brushes to fill the gaps.

[Obsttorte]

[Frost_Salamander]

14 minutes ago, Obsttorte said:

You probably have to set the subdivisions manually. Otherwise it will be choosen depending on size and bending.

I've tried that, but all that seems to do is just add more subdivisions, and doesn't affect the way the patch bends (at least for end caps). 

I've also tried adding/extending rows/columns but it never has the intended effect.  Maybe it's not doable?

7 minutes ago, Baal said:

The way I did that, was to simply build brushes to fill the gaps.

I've admittedly done that before   and although it's crude it's fine for a one-off, but I'm trying to figure out how to do it properly.

It seems like the kind of thing that a video tutorial would help with, but I haven't come across any that do this.  If anyone knows of one that shows this I'd be grateful