Newbie DarkRadiant Questions

[Melan]

I've got some kind of problem with my water. It produces waves but it doesn't splash. It is 24 units deep, so it should work... but something is not right.

 

[Obsttorte]

Did you apply a water texture on top.?

What exactly do you mean with 'splash'?

 

The shaderParms only influences the wave speed and magnitude.

[Melan]

Yes, I did. It doesn't produce sound while the player (or an AI) is walking in it.

[Obsttorte]

That'S strange. I just looked into Old Habits. There I've just used a patch textured with water_reflective and it does work properly. Maybe you should try another water texture. Also only the upper side should be textured with water, the rest should be nodraw.

[Springheel]

I remember putting some kind of nodraw liquid brush over the puddles in St Lucia to solve that very problem.

[Fidcal]

Can't tell from that picture. Have you got eg, any pillars or other solid brushes immersed in the water? Can't remember exactly but I think something like that needs separate water entities that go around - or maybe it's just the center of the water entity must be in water. I forget. This also stops swimming but your water might not be deep enough to reveal that. Try dropping in a small floatable. Does it float?

 

Try creating a big block of water in a spare area and make it work. Then move it into position and adjust until it fails. That should indicate the problem.

 

PS. I assume you dmapped after any entity changes? Eg, create worldspawn brush. dmap. then make it a water entity - remember to dmap again.

[Melan]

Thanks, Fidcal! Cutting up the single large water brush into multiple smaller slices worked.

 

I have got a new problem, though. I textured the patch above the surface with water_reflective, and it is beautiful... but it only affects the "active" water brush, the one the player is standing in. Is there a way to change this setting? The wiki seems silent about it.

[Fidcal]

Likely nobody has come across this problem before. I thought reflectivity was to do with the texture and nothing to do with the entity. Maybe this is a special case - like when colour is passed to a texture.

 

I wonder how much terrain cuts into your water? I'm just wondering what would happen if any intersecting solids were made func_static. Would that cure your original problem and if so, would it be practical in your case? And if so, would it cure the reflectivity problem?

[Baddcog]

just tried a few reflective textures spanned across a few water brushes earlier and they were rendering correctly. However jumping in the water with caulk sky made the caulke have a reflection too 8O

[Melan]

Terrain is all over the place, but I will try func_statics. Might be a good fix.

[Fidcal]

Thinking further about this - only one mirror surface is allowed in doom3 (per leaf presumably) so that's probably the reason. Perhaps a solution is to give the water a different texture, eg, clear - then lay a single giant patch over the lot with the reflective texture on it.

[RPGista]

 

Im getting a crash when about to play my updated map, that I never got before, dont know what causes it - a malloc error, its pointing to a brush door that I dont even remember touching at all, put up a picture to see if there are any clear visual clues of the problem...

[Obsttorte]

Normally these errors should be dissapeared since the 4GB patch is part of the 1.08 exe. Anyways, is it possible that you've run another memory hungry application in the background. I don't think that the entity it's pointing to plays a role. Maybe it just ran out of memory when trying to load it. What was the last things you've done in your map (roughly)?

[grayman]

The Warning about the door is a standard warning for doors that AI can't actually walk through. You'll see them when using footlockers, etc. That warning in and of itself isn't causing the crash.

 

My suggestion would be to back up to a previous rev of the map that works, then work forward until you find the change that caused the crash. Perhaps that will help. If you have snapshots turned on in DR, you'll find copies of the map in maps/snapshots, and you can walk backward from the crash until you find a snapshot that works.

[Moonbo]

Right now I'm going through my map and finding spots where to put grime decals and I'm running into a problem: in several instances I'm placing a dirt decal on a wall which I've also covered with non-functioning windows/doors. When I start up the map the decal is drawn *on top of* the windows/doors. As I go closer to it, there is a distance at which the decal suddenly pops back behind the windows/doors. Here's a "before" and "after" shot:

 

First, when I'm a little while away. The dirt decal is actually on the wall behind this func-static gate, but for some reason it's being drawn over it.

 

 

 

And now a few steps closer, and the decal has now popped back to the proper place on the wall behind.

 

 

This is happening in several places I've set up grime decals behind func-statics and it's really noticeable when the pop-in takes place. Is there any way to avoid this?

[Baddcog]

Moonbo, that's z fighting. You can increase the distance of the decal from the surface (set the grid to 0.125) and bump it once. Unfortunately up close you can see a line where the gap between decal and wall exist.

[Sotha]

I'd like to know the answer to this as well. I think I asked about it once, and IIRC the answer was that there is not much one can do about it. Its it a problem in the game renderer?

[Sotha]

Isn't z-fighting a situation where the textures blink and swap constantly? In this case the decal is drawn below and on-top of the brush based on the player distance from the objects. When the player closes in there is and ugly transition when the overlapping occurs.

[demagogue]

I've read about shader commands in other engines (Unity to be exact) that let you put decals flush and it gives the decals render priority so there isn't z-fighting (as if it were floating in front), but there isn't the "hovering texture" problem either because it's still overlapping. It made me wonder if id4 either had an equivalent or if there were a way to code an equivalent in. It sounds straightforward enough to force render priority and something engines often deal with.

[Baddcog]

Hammer actually has a great decal set-up. Much like how ours works as far as applying them.

 

But they have a setting of priority on decals. So you can layer 5 decals and number them 1-5. 1 being rendered with highest priority I think. And of course this is always on top of terrain.

 

You can also set which brushes it is applied to. So say you have a doorway and want the decal to be splattered across the walls on either side of the door, you just select those brushes. If we did that in DR we'd have splatter across the door opening also. (so it takes two decals)

[Sotha]

Huh? You can put decals flush on a face. When you use DR "apply decal patch" function, you get a decal flush on the face you selected it. It does not z-fight with the face you applied it to.

 

The problem is this:

Imagine a brick box. You apply dirt decal on the box. The decal is flush on the box. You put a painting on top of the box and the grime decal.

 

Now, when you are near the box, the painting looks correct, it is on top of the box and the decal. When you go away from the box, the decal texture appear ON the painting, even though the decal texture is physically BELOW the painting. There is a critical distance where this "decal popping on top of the object that is over the decal" -phenomenon occurs.

 

You can get around it, of course, by setting the decal so that there is no decal below the painting. But this means more work and clumsy splitting of the decal... Only to accomodoate a prop-detail painting!

[Baddcog]

It is a form of z fighting. Doom3 has some bug where at distances it has a hard time calculating the z factor (technical terms)

 

Had the issue on my door models. The hinges and lockplate are alpha 'decals' basically, they were offset from the door face (not flush) but at a good distance they would disappear or z fight anyway (it was a pretty long way off).

Something with the rounding errors or whatever.

 

I think Sneaksie Dave fixed them (just made the offsets greater)and he knows what the issue is, haven't seen hi around for awhile though.

[Fidcal]

I've always understood there to be two types of decal. The grime or stain type use blend and they can be flush. The thick speckled dirt or vine or straw or poster type of decal needs to be offset. I've never noticed the offset in-game. I guess it would have to on a wall near a convex corner so you can get close enough?

 

But this problem with popping above at a distance I've never noticed before that I can recall. Is that above a model painting or another decal poster?

[Sotha]

I've always understood there to be two types of decal. The grime or stain type use blend and they can be flush. The thick speckled dirt or vine or straw or poster type of decal needs to be offset. I've never noticed the offset in-game. I guess it would have to on a wall near a convex corner so you can get close enough?

 

But this problem with popping above at a distance I've never noticed before that I can recall. Is that above a model painting or another decal poster?

 

Just try it yourself. Make a brick wall, use the dirt_scattered decal texture (the one that is full of grime, not the one that has grime splashes) for easy detection. Place a model painting on the wall with the decal. Any model that is too close to the wall will have the decal overlapping the model inappropriately when the player is at a certain distance.

 

I've even detected the decal spill on top of a model chair back that was very close to the wall+decal.

[Fidcal]

I believe you - but it depends on the distance whether I would notice. In a big hall I'm not sure I would notice if a distant picture or chair back had smears or specks on it. Clearly it's a problem for others though so I'd have to watch out for that in maps I create. The most common decal I use is grime corners which is both smooth and confined to corners where paintings would not be hung and any chair might be angled out so that might be one reason I've not seen it. I mean, a picture that is slightly darker at 30 paces I don't think I would detect. I'll certainly be putting other dirt and smears in the big factory room I'm working on at the moment so I'll try and remember to test when I get to that.