Newbie DarkRadiant Questions

[Dragofer]

func_static player_clip clip brush

trigger_once targeting a trigger_relay called clip_control

trigger_relay with delay 5 targets playerclip

call script entity called playerclip which calls player_clip_remove

 

The clip is present when you get there, 5 seconds later the game crashes every time.

Chains of triggers with delays have been crash-prone in my experience, I'd suggest letting the trigger_once target the callscriptfunction directly and adding a sys.wait(5); to the script.

 

If that trigger relay was also targetting other things you can add sys.trigger($any targets); to the script to compensate.

 

If TDM for some reason still crashes you can opt for .setOrigin('0 0 0'); instead of .remove();, in that case adjust the coordinates to something like the blue room.

[NeonsStyle]

Ahhh finally. That fixed it Dragofer. Thank you. It crashed, but getting rid of the .remove and replacing it with the setOrigin with the coords to the blue room

fixed it. Now it works beautifully.

 

void player_clip_remove()

{

sys.wait(10); //wait 10 seconds

$player_clip.setOrigin('1000 440 368'); //move func_static player_clip to blue room

}

Thanks heaps.

[demagogue]

Oops, somehow I missed that you solved it and wrote a post to suggest some things.

(I'm thinking I left the window open on the previous page and posted from there before I saw there was a new page.)

Well, I can't delete this, so I'll just add all's well that ends well.

[NeonsStyle]

haha Dem. Yeh... well I didn't solve it, Dragofer did and I am very grateful. I'm going to check it one more time

with a full play through, make sure there's no other issues and if not I'll release what I hope to be the last update.

 

There is one other thing, 2 electic lamps at the front of the house flicker at the same rate. How

can I control the flicker rate?

Edited August 25, 2017 by NeonsStyle

[Obsttorte]

As it is the light that is flickering the typical approach would be to check the light shader, as this is most probably responsible for the flickering. For example on "atdm:cagelight" you will see that the light shader used is "lights/tdm_lanternlight_4fold_small_snd" (open up the light inspector by pressing L, you'll see the shader used on the right side; alternatively search for the "texture" spawnarg). The snd ending stands for sound, which leads to the assumption that the sound made by the light has something to do with the flickering.

Now we search for this light shader in the media browser. You can just type in the name, but for reference light shaders can be found under "Other Materials/lights". Right click on the shader and select "Show Shader Definition". A window opens showing you this:

lights/tdm_lanternlight_4fold_small_snd
{
    lightFalloffImage    makeintensity( lights/biground1 )
    {
        forceHighQuality
        map        textures/lights/tdm_lanternlight
        red Parm0 *(1-sound)
        green Parm1 * (1-sound)
        blue Parm2 * (1-sound)

        zeroClamp
    }
}

Now you can see the parameters for red, green and blue. They control the color values of the respective channels (I know you guys aren't that much into coding, but this one should be obvious ). The values range from zero to one. Now you can see three things:

 

• There are parameters used to control the color intensity (Parm0, ..., Parm2). A search in the wiki will turn out that those are the values stored in the "_color" spawnarg. So this is how the color gets adjusted on the light.
• There is a sound keyword. Doing some research (google anyone) will turn out that this parameter stores the volume of the sound. So the sound played on the light does indeed influence the light level.
• There is no parameter to adjust the look of the flickering.

So, how do we use this information to solve your little problem. Well, the first idea is that as the light flickering is synced with the sound, we could let the light entities start without playing a sound and let it start using a random delay. There is no spawnarg handling this, so the easiest way would be to let the lights all start of and turn them on after a random amount of time. Trigger_relays can do this. If you let each of them target a light and target all of the triggers from worldspawn, they will activate the lights after a random time. You can set the time interval using the "random" spawnarg on the triggers.

 

Additionally, there are several sounds available for flickering lights. If you change the sound shader, the light flickering will also differ. You should probably start with this, as there are 4 flickering sounds as far as I've seen thus far and you don't have much more lights next to each other by default.

 

The last addition would be to consider changing the material, but this is only neccessary if the before mentioned steps aren't enough to reach the desired effect. If you do so read up on shader parms in the darkmod wiki and this. Also note that this may require some basic math.

[Oktokolo]

In addition, I don't think the removal is based upon the size of a triangle, but on its condition instead. The condition of a triangle is the ratio of the radii of the inner and the outer circulum. Triangles with high conditions will introduce heavy rounding errors, which can result in graphic glitches etc..., thus they should normally be avoided. If you have such triangles, for example on a heavely bend high patch, it might help to split them up, or in case of patches simple use several patches instead of one.

triangle_condition.jpg

Thanks for the explanation. That also explains the lots of smaller triangles (instead of less big ones) in a lot of the assets that are included in the game.

The only other sources on the internet i found for "well defined triangles" are for sureyors and suggest a minimal angle of 30°.

Do you know about further readings of that topic especially when it comes to the id Tech 4 engine?

What are safe numbers for angles so that my surfaces get not eaten by a regular dmap?

[Obsttorte]

I haven't read this in the course of TDM, but during my studies at the university. But for a rough orientation

 

https://en.wikipedia.org/wiki/Condition_number

 

https://en.wikipedia.org/wiki/Numerical_stability

 

Unfortunately I do not know the exact scientific terms in english, which makes it hard to find a good side in the internet. But I think I still have the script lying around somewhere. I'll post if I find it.

 

 

The only other sources on the internet i found for "well defined triangles" are for sureyors and suggest a minimal angle of 30°.

There are several ways to define the condition of a triangle. Another way is to use the ration of the biggest to the smallest angle or the ratio of the longest to the shortest side. So you always divde the bigger number by the smaller one. The best case is a equilateral triangle. In that case all sides or angles are equal to each other and the condition is one.

 

The condition is a multiplicative value that determines how strongly rounding errors in the input will get blown up. So if you have a triangle with the biggest angle being 100° and the smallest being 2°, you can expact that errors will be blown up 50 times stronger (100/2) then in the optimal case. As you always have rounding errors due to limited digits in the floating point numbers, this can easely cause you errors to become bigger then the actual calculated value. Especially if you are using an iterative algorithm, where the old value (with the blown up rounding errors) gets reused to calculate a new value (with the now blown up blown up rounding errors). I guess you can see where this is going.

 

In summary I can only say that you will have to dig quiet deep into the math if you really want to understand it. As said I studied it and I consider it a difficult matter. So ... have fun

[Oktokolo]

So it is about rounding errors. Are we speaking about IEEE 754 standard precision (24 sitgnificant bits, 8 exponent) floats here?

24 significant bits look like they should provide a lot of error margin.

But i am not that interested in the math anyway. Just want to make sure that the engine shows it like i built it (and i am fine with the engine or math having limits as long as i can work around them somewhat easily).

 

Your maps look fine. So for what factors (highest / lowest value) are you going when creating detailed patches or brushwork?

[Obsttorte]

• So it is about rounding errors.
• Are we speaking about IEEE 754 standard precision (24 sitgnificant bits, 8 exponent) floats here?
• 24 significant bits look like they should provide a lot of error margin.
• ... i am fine with the engine or math having limits
• Your maps look fine.
• So for what factors (highest / lowest value) are you going when creating detailed patches or brushwork?

• Indeed
• The engine mainly works with single precision floats iiirc. Can't tell you the exact standard, though, as I am no programmer.
• That is not the issue. The problem is that certain algorithm or algorithms used under certain circumstances will cause rounding errors to increase (that's what I've meant with blown up). If this increasement is sufficiently high, it will cause your solution to become useless. How high the increasement is depends on the condition, which in our case mainly depends on the shape of the triangles. Hard to explain in a few words, thus the linked articles. You've stated you are not interested in the math, but I could give it a try if you want to know more. Independent from the precision used this problem will always be there. A higher precision only dampens or delays the issues, it doesn't solve them.
• the limits do neither come from math nor from the engine. It is an issue caused by the way computers store numbers. Math is actually the only way to get away with the issue.
• thanks
• I do not use certain factors. On a bend patch where several tris look the same only a few get removed if they get. I guess the orientation in space plays a role, too. I simple build what I am aiming for and if I encounter an issue I fix it. It is more the try and error like approach.

[Oktokolo]

Well, i am good at spotting missing triangles. But regardless i still would prefer a deterministic way of getting repeatable results from the dmap process and engine.

Is there a way to make dmap color drop candidates purple so i can see them better?

Maybe i should use modules more. I could build them in purple rooms so i instantly see every hole. But would they get new holes when placed rotated in another part of the map?

[Obsttorte]

If you want to avoid missing tris on bend patches you could try to increase the subdivision in the direction where the patch is not bend. This will make the tris less stretched and may help avoiding missing ones.

 

Another idea that came to my mind is that the engine checks for degenerated tris and removes them. Triangles are degenerated, if all three vertices forming the tri are on a straight line (so it isn't a real triangle, as it has no area). So besides the very bad conditioned ones tiny tris could indeed be removed (even if of good condition), as the vertices are pretty close together which, again due to rounding errors, could cause the engine to remove them.

 

So overall it may be a matter of balance.

 

I am curious though what you are doing. I encountered missing tris only every now and than, but you seem to permanently be struggling with them.

[Oktokolo]

A typical case is brushing wooden boards. Their sides are often relatively long and narrow. Naturally such side faces get split into two very spiky triangles.

Last time i saw holes in my geometry, i had brushed a crystal in a holder to be used as a light source. Only two materials but lots of tiny faces.

I solved missing tris by exporting as ASE as that seemed to fix it.

But now that i know the reasoning behind the hole punching i will split geometry into sections (even when not needing more vertices for sculpting) to prevent the spiky triangles. I probably should get more experience with patches too.

 

Is there an easy way to convert faces of brushwork to patches?

[demagogue]

You don't get rounding problems when you build cleanly, on-grid, grid size 4 or larger, brushes meeting at right angles, and definitely no tiny slivers or cracks or overlaps, etc. Use non-sealing patches or models for anything that isn't simple brushwork.

[Obsttorte]

A typical case is brushing wooden boards. Their sides are often relatively long and narrow. Naturally such side faces get split into two very spiky triangles.

Last time i saw holes in my geometry, i had brushed a crystal in a holder to be used as a light source. Only two materials but lots of tiny faces.

I solved missing tris by exporting as ASE as that seemed to fix it.

But now that i know the reasoning behind the hole punching i will split geometry into sections (even when not needing more vertices for sculpting) to prevent the spiky triangles. I probably should get more experience with patches too.

 

Is there an easy way to convert faces of brushwork to patches?

No. Patches and Brushes are handled seperately and you cannot convert one to another. Additionally you should avoid building tine details using brushes, especially using the substract tool (which I guess you are using). Regarding the boards, there are board textures, so you don't have to create each board as a seperate brush. And if you really need single boards, there are existing models you can use (I think they are stored under models/junk).

 

It is generally adviceable to avoid large planes, as they will most probably be hit by several lights in game, which is bad for performance. Tons of tris can be bad either, though, although idTech4 can handle them much better. Once again, this is a matter of balance.

[demagogue]

99% of the time, you want to use the cut tool rather than the subtraction tool, so you can control the triangle explosion. Once in a blue moon you can use the subtraction tool, but only if you really know what you're doing and can either avoid the triangle fragments or you know they aren't sealing or if it's for a really, really important thing that no other method can do. And even then you'd want to try the cut tool way first.

[Obsttorte]

The substract tool isn't that bad per se. Normally it does not create more intersections then needed, although sometimes there order isn't optimal. If you want to cut a rectangular hole in a rectangular brush, though, for example for a door or a window, substraction does not cause any issues and is the fastest way to go. I always use it for that, and never had any issues.

 

No, I think the main issue isn't the tool but the user. Don't get me wrong, I don't want to sound offensive, but you don't think about the amount of intersections and there possible (bad) placement in the few milliseconds you need to press a key combo.

[AluminumHaste]

It is generally adviceable to avoid large planes, as they will most probably be hit by several lights in game, which is bad for performance.

 

I thought we put this rumour to bed a long time ago?

It doesn't seem to matter the number of lights hitting a single triangle, only that the lights don't overlap.

For example, I made a simple map with a long hallway (640 units long) and filled it with 13 lights.

 

Long hallway, 2 triangles per face, 13 lights, no overlap, over 100 fps:

 

Same hallway, 2 triangles per face, 13 lights, slight overlap, over 100 fps:

 

Same hallway, 2 triangles per face, 13 lights, lots of overlapping, around 20-30 fps:

[Obsttorte]

My bad. I thought it wouldn't matter whether the lights overlap if they are hitting the same tris. Obviously I am wrong

 

Thanks for the clarification.

[demagogue]

You're right Obs, if you're just using the subtract tool to cut out something like a rectangle then it's not bad. I'm just so used to the "cloning & drawing the curtain" method and can do it so fast by now that it didn't occur to me the subtract tool might save so much time for that. I always think of it like the air tool in dromed, to cut out crazy shapes in brushes like ovals and stars, which you really can't do any other way, but it tends to shatter the brush into little triangles.

[Aosys]

Hey guys, just a purely academic question (for now ) but do we have any frost textures/decals? I can find some ice/snow ones, but that's about the extent of it from what I can tell.

[Amadeus]

If you look at business as usual in DR, Bikerdude used some neat snow/ice decals that he put on most of the windows. I know this because I was looking for the same thing you are

[Aosys]

A'ight, not so academic anymore I'm trying to use the existing snow textures to blend some edges. My attempt looks like this:

 

 

Just a simple patch mesh warped into shape, with the center lifted up very slightly. The in-game results don't show up at all though (except some z-fighting where the edge of the patch touches the floor):

 

 

 

 

 

 

 

 

So is this not what that texture is for?

[Dragofer]

This is possibly a similar case to grass blended textures, in that it also needs a spawnarg to determine how visible it is, by default being invisible. Turn it into a func_static and give it:

 

shaderParm3

1

 

 

Also, take a look at William Steele III, if I remember right Grayman has made winter versions of many existing textures and included them in this mission archive.

[Aosys]

shaderParm3 doesn't appear to be doing anything; if I clip the entire patch into the brush surface, it looks like the texture is kind of showing up, but it's not blending nicely and there's a ton of z-fighting.

 

It'd be nice to have decals you could just splash around at will. I was thinking of making some, and I found a set of photoshop brushes that looks really nice, but I'm not sure how the licensing would work for us?

 

https://redheadstock.deviantart.com/art/Frost-Texture-Photoshop-and-GIMP-Brushes-106687110

 

http://www.obsidiandawn.com/frost-photoshop-gimp-brushes

[Obsttorte]

Regarding the z-fighting: Let the outside of the patch intersect with the geometry below.

 

Regarding the shader parms: I doubt this one is using them. But to make sure right-click on the respective shader in the media browser and select "show shader definition". See if there are any parms used in there (they are called parm0, parm1 .... in the shaders). ShaderPArm3 is normally used on foglights to determine the density of the fog (it's the distance at which the fog becomes opaque).