Jump to content
The Dark Mod Forums

Ungoliant's mapping questions


ungoliant
 Share

Recommended Posts

well i'm back on track with my FM now, but i can foresee a lot of questions that don't necessarily fit into the newbie thread in the near future.

 

So - what exactly does it mean when you get better FPS in the void than in your proper FM area? and when i say better i mean like +15 to 25 fps. So far the map is divided into one major visleaf (outside) and 4 minor ones (inside house). After deleting all decals, lights, and AI i still get 35-40 fps standing in the courtyard outside area. When i put on no-clip and hop into the void, looking back over the entire mapped area, i get 60fps. what - tha - fuk?

 

edit: vsync is already turned off

Edited by ungoliant
Link to comment
Share on other sites

well i'm back on track with my FM now, but i can foresee a lot of questions that don't necessarily fit into the newbie thread in the near future.

 

So - what exactly does it mean when you get better FPS in the void than in your proper FM area? and when i say better i mean like +15 to 25 fps. So far the map is divided into one major visleaf (outside) and 4 minor ones (inside house). After deleting all decals, lights, and AI i still get 35-40 fps standing in the courtyard outside area. When i put on no-clip and hop into the void, looking back over the entire mapped area, i get 60fps. what - tha - fuk?

 

edit: vsync is already turned off

 

This is totally weird. Popping to the void should expose everything in view, resulting in drastic deterioration in fps rate.

 

Maybe if you were at the edge of your map and pop into void and look away from your map? Then there would be nothing to be drawn and result could be higher fps than inside the map where you're looking at 3d-geometry.

 

Does the map work properly in other terms? check show_portals and show_tris 3 if the visportals are working.

Check that visportals are not penetrated by worldspawn brushes. This results in all kinds of weird stuff. :wacko:

Clipper

-The mapper's best friend.

Link to comment
Share on other sites

Yes this is odd. I seem to recall quite a few times (not always) when in the void over a huge map I could still function quite well where I'd expect to be paralysed at 0.001 fps. My guess is some things stop being processed when the player is in the void.

Link to comment
Share on other sites

My guess is some things stop being processed when the player is in the void.

 

this is correct. found the problem. the skybox is not drawn when in the void. in my map i have a very large, full 180 view of the default starry night skybox with complete with its heathazy water reflection effects.

 

2nd problem. It seems that I do not have a very good understanding of the way shadows are drawn in D3/TDM. if i have 30 clones of iron fencing sitting behind a wall, and a light is on the other side of the wall. no light hits the models. so that must mean that i don't need to put noshadows on them, right? wrong. it seems that unless the light has noshadows, or you have entity brushes/models with noshadows, then every single thing in the entire light volume will cast a shadow, period (unless volume is split by a closed visleaf). totally didn't know that. i thought things only cast shadows if it actually got hit by a light. that sucked an additional 10 fps out of my front door area.

Edited by ungoliant
Link to comment
Share on other sites

2nd problem. It seems that I do not have a very good understanding of the way shadows are drawn in D3/TDM. if i have 30 clones of iron fencing sitting behind a wall, and a light is on the other side of the wall. no light hits the models. so that must mean that i don't need to put noshadows on them, right? wrong. it seems that unless the light has noshadows, or you have entity brushes/models with noshadows, then every single thing in the entire light volume will cast a shadow, period (unless volume is split by a closed visleaf). totally didn't know that. i thought things only cast shadows if it actually got hit by a light. that sucked an additional 10 fps out of my front door area.

 

If the area behind the wall is in the same area, then the engine cannot know that the shadow of the wall will obscure the shadows of the fences. If you make the wall a static entity, then the engine can compile the shadow as static, can know the fences are in an unchangable shadow and leave of their shadows (but I am unsure to what extend that optimization works).

 

Generally, light volumes that pierce walls and "leak" into neighbouring areas cause often problems. So using thicker walls and make the light volume end inside the wall helps here.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

If you make the wall a static entity, then the engine can compile the shadow as static, can know the fences are in an unchangable shadow and leave of their shadows (but I am unsure to what extend that optimization works).

 

can anybody else comment on this assertion further? would this require using the special dmap function, i forget what its called, shadowopt or something? How would introducing a moveable light source next to this entity-wall influence things? worldspawn generally seems a lot more static than entities in general, so why don't they cast static shadows too?

 

edit: also, things like candles/torches, even if rendered immobile, generally flicker back and forth, making shadows move around, probably destroying the notion of casting a static shadow on anything during compilation? or some of the lights used in electric lights that flicker on/off or inbetween, making shadow strength weaker/stronger? or is there no such thing as a strong/weak shadow?

Edited by ungoliant
Link to comment
Share on other sites

can anybody else comment on this assertion further? would this require using the special dmap function, i forget what its called, shadowopt or something?

 

I believe so, but would have to google it.

 

How would introducing a moveable light source next to this entity-wall influence things?

 

That shadow is sep. from the other shadows (because there can be areas where only one of these shadows is visible, or areas where both are). Also, moveable lightsources (once the moved at least once) are dynamically recalculating all shadows they cast, so they have a high amount of overhead.

 

Basically, the shadow rendering is done per-light. That means one static light is better than two static lights which is better than one static and one moveable which is better than two moveables.

 

worldspawn generally seems a lot more static than entities in general, so why don't they cast static shadows too?

 

They do, and I think two worldspawn shadows might be merged, but one worldspawn and one entity shadow - only if you use shadowopt.

 

edit: also, things like candles/torches, even if rendered immobile, generally flicker back and forth, making shadows move around, probably destroying the notion of casting a static shadow on anything during compilation? or some of the lights used in electric lights that flicker on/off or inbetween, making shadow strength weaker/stronger? or is there no such thing as a strong/weak shadow?

 

Weak/strong doesn't play a role - a shadow is always 0 light, whereas what flickers is the light color, e.g. everything not in shadow.

 

Moving light sources (candles/torches) do indeed have a higher overhead, but they also make the scene more "life". It basically depends how big their volume is and how many entities/tris they hit - the more, the more shadows the slower it will get. That is why some of our high-poly models have very low poly shadow models.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

That's interesting...

 

If you made buildings out of models and then made shadow meshes for the walls, moulding, etc... then there would be a performance gain

 

(kinda cumbersome though :laugh:understatement o' the year )

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

That's interesting...

 

If you made buildings out of models and then made shadow meshes for the walls, moulding, etc... then there would be a performance gain

 

(kinda cumbersome though :laugh:understatement o' the year )

 

You laugh, but that is exactly one of the basic performance-optimization methods. The basic walls have to be worldspawn (so they seal and provide pathfinding (the floor)), but for instance ceiling bars should be made as an entity. That means any light that is not hitting the ceiling bars will not cast a shadow from them - and this is easier to calculate (entire entity not hit by light - no shadow), whereas for worldspawn the engine needs to check this for each triangle on its own (it uses a tree, but still its more work). Plus, if you want, you can set the ceiling bars to noshadow, if they are f.i. high up and no light can shine on them.

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

They do, and I think two worldspawn shadows might be merged, but one worldspawn and one entity shadow - only if you use shadowopt.

 

i'm not sure I follow what you mean here about shadow merging. example please?

 

also, i've done some testing, and regular dmap with no special options will cause func_static entity brushes to cast static shadows. those same fence models behind the new entity brush wall did not cast any shadows.

 

Seems a little bit hard to interpret what I'm seeing using r_showshadows 1, (maybe another graphics card problem, or maybe r_showshadows 1 just looks really funky and glitchy) but I'm pretty sure that I have managed to decipher that pieces of a specific entity brush/model will still cast shadows even if they are fully in the shadow of another piece of that same entity.

 

So if you are strategically trying to prevent something from casting shadows by hiding it behind a (func_static)entity, don't include those pieces in the entity that's supposed to block it.

 

edit: or maybe it means that if one piece of a func_static casts a shadow, then all pieces must cast or calculate a shadow?

Edited by ungoliant
Link to comment
Share on other sites

So...

 

Can shadowed nodraw brushes act like a low-poly shadow-mesh for high-poly noshadow brushes?

 

(Taking this concept to it's logical conclusion) :blush:

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

There is a texture under common called "shadow" and "shadow2" (the latter does not cast shadows on itsself). That's what you're looking for, and that's the right conclusion.

 

I've used a high-poly 15-sided cylinder patch for a pillar, and imposed a 10-sided shadowmesh beneath it for performance.

yay seuss crease touss dome in ouss nose tair

Link to comment
Share on other sites

hrrmmm... somethings very off. I can't quite understand whats going on here.

 

shadowsuck.jpg

 

The light a projected spotlight below this trimwork, and theres something going on thats... weird. can someone clue me in as to why shadows behave like this?

Edited by ungoliant
Link to comment
Share on other sites

There is a texture under common called "shadow" and "shadow2" (the latter does not cast shadows on itsself). That's what you're looking for, and that's the right conclusion.

 

I've used a high-poly 15-sided cylinder patch for a pillar, and imposed a 10-sided shadowmesh beneath it for performance.

 

Thanks Mortem Desino!

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

i see. upon closer inspection, the bottom portion of that patch does not actually intersect with the wall, there is a gap. so the light shined between the patch and the wall, and straight through the top half of the patch that is facing the wrong way. thx rib.

Link to comment
Share on other sites

also, i've done some testing, and regular dmap with no special options will cause func_static entity brushes to cast static shadows. those same fence models behind the new entity brush wall did not cast any shadows.

 

i am dumb. I had the models on noshadows 1. when i turned it back off, same behavior as before. you need the special dmap to get the static shadows, i guess.

Link to comment
Share on other sites

i see. upon closer inspection, the bottom portion of that patch does not actually intersect with the wall, there is a gap. so the light shined between the patch and the wall, and straight through the top half of the patch that is facing the wrong way. thx rib.

 

Btw, you might try to set that patch-trim to noshadows, then add a simply patch consisting of a single face running around the tower, embedded 90° to the wall and set that to "textures/common/shadows". I am not sure if it would really save much on the curved wall,but potentially it replaces 7 or more shadowcasting surfaces (the round trim) to one (a flat face). The shadow would look almost identical and I don't think the player could spot the difference.

 

post-144-128938154196_thumb.png

"The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man." -- George Bernard Shaw (1856 - 1950)

 

"Remember: If the game lets you do it, it's not cheating." -- Xarax

Link to comment
Share on other sites

  • 3 weeks later...

texturing issue. I don't remember ever having this problem before, but all of a sudden, the "fit" button doesn't work like its supposed to on the surface inspector, and i can't drag around individual verts in the the texture tool without all the other verts getting dragged around with it to maintain the basic "shape". Every texture on brushes is being forced to maintain the basic shape of its face.

 

I'm not sure if this is a problem, or just something i've never noticed before (because 90% of brushes i use are rectangle shapes), but if a brush surface has 4 sides, when i hit the "fit" button, it should damn well move the texture verts to each corner of 1 individual texture tile, and not force the texture to take the basic shape of the brush. that should be optional. shenanigans.

Edited by ungoliant
Link to comment
Share on other sites

Not sure if I've understood you right but AFAIK textures cannot fit irregular brush surfaces; only rectangular shapes. Textures won't distort and bend to fit like they do with patches. I think the tile fits squarely to top (highest point) and bottom and left and right and will clip crop off the edges if the brush is not rectangular.

 

Can you use a patch instead in your situation?

Link to comment
Share on other sites

yeah, its not sealing anything, i can create decals for the faces i need, but the geometry in this instance is much much easier to work with as brushes. I guess i can move the brushes off into the void somewhere just in case i need to change things later.

 

At least now I know the difference between texturing brushes and patches, can't believe i've never noticed that before.

Link to comment
Share on other sites

is it possible to force an alphatested texture to cast shadows in the way a player would 'expect' it to look? as far as i can tell checking out decals, if alphatest even touches a shader, its auto-noshadow. looking for a workaround, but I can't think of any short of designing a model shaped like the texture painted with shadow, which is not a really a viable option...

Link to comment
Share on other sites

:(

 

truth.

 

With this in mind, I'd have to recommend that future additional fencing assets be implemented as models as opposed to decals. Somewhat aggravating when your patch-rails cast shadows but not the fencing that holds it up. Stuff like dirt or ivy that is naturally going to be flush against a solid surface really don't need shadows, but stand-up architecture is another thing entirely.

Edited by ungoliant
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...