Shadows on brush models

[Baker]

Yes, I am raising an annoying issue. r_shadows 1 doesn't do a shadow on, say, the start map fake floor or the E1M1 temp bridge over the slime.

RecursiveLightPoint only looks through the world.

I've looked through traceline and friends and most of them are bounding box checks.

I'm trying to think of some way that this could be possible without having info only the server should know.

On the basic level:
1. Only brush models that are sub models of the map should matter.
2. Although you can't know the server physics if client-only, whether or not an entity is a func_illusionary shouldn't matter for purposes of casting a shadow on it.
3. RecursiveLightPoint can accept something other than the world node.

I can think of 3 reasons this issue disturbs me:

1. The DarkPlaces or Qrack crosshair that collides with the world instead of static position is "all wrong" and doesn't collide with fake walls, secret doors, etc.
2. Walking on a false floor or just something turned into an entity for the sake of map compilation, your shadow disappears when you walk on it.
3. Of course the texture selection code I carved out of RecursuveLightPoint cannot select a texture.

I might solve this myself within a few days (it'll probably be slightly non-optimal). I guess I am thinking that if traceline can determine the entity hit, there must be some way to relate that to the surface ... admittedly I am not all that familiar with the .bsp functions but getting more so.

[Baker]

I suppose a cheat for the shadows at least for the player model is if RecursiveLightPoint returns some "distant" value but FL_ONGROUND is true they must be standing on something so render a shadow at the feet.

[mh]

To be honest I think that you're chasing a dead end with this one.

Why?

Because r_shadows 1 mode sucks, that's why. You've already spotted one problem with it; others include the fact that it doesn't work properly on stairs, slopes or edges (or corners, or anything angled). There's a well-known workaround for slopes, and you may be able to do some ugly hacks for some of the others, but you're accumulating ugly hacks (or you've implemented shadow volumes) and you still haven't dealt with the fact that the shadows it produces are hard-edged whereas the shadows produced by light.exe are soft-edged. Holy visual discontinuity Batman!

So you do shadow maps instead but then you realize that it's always gonna break anyway with frustum culling and it's always gonna break anyway with visibility. You can hack around those a little too, but if the server didn't send the entity to the client but it's shadow should be visible there is nothing you can do. Plus you're using something vile like polygon offset and you realise that it doesn't produce consistent results on all hardware, or even at different depths on the same hardware. Another World Of Suck.

Meanwhile you're also dealing with the fact that Quake architecture and file formats are really not set up for this kind of thing at all, and accumulating more hacks as you go.

All of which highlights the fact that r_shadows 1 was nothing more than a crap little experiment that Carmack did, and that probably should have never gotten out into the wild. Why on earth people seem to love it I'll never understand.

[Baker]

[Spike]

[r00k]

Shadow mapping does look standard for 2005+ but I've kicked shadow volumes, shadow mapping, etc around never getting it to work across the board. Heck I even tried dropping a decal under the player of a soft blob like Q3 shadows, which clipped but man it was sloooow.
Dark places does a perfect looking shadow effect but i'm sure alot of backend work is due to this, not just a simple routine. I'm simply using stencil planar shadows that have a dynamic alpha based on the distance to the impact to hide the vulgarity of the whole mess. The only reason I use shadows as for multiplayer is the perspective. It makes player mesh into the scene so you can judge distance better.
I guess if i had a new singleplayer mod and just wanted to show it off so some friends i'd fire up DarkPlaces with all the bells on and play that way, but for pure multiplayer aspect, fast crappy shadows work well enough

[mh]

I reckon that was a long-winded way of me saying "if you're gonna do something with shadows, do it right or not at all".

In other words, you need either a fully comprehensive implementation or you accept the crapness, try to maybe ameliorate some of it, but it's not really something that you invest too much time in.



I like the idea of the shaded blob, by the way. It would fit in well enough with Quake's world lighting.

[mankrip]

[leileilol]

[LordHavoc]

[Baker]

LH, thanks for infos. I did check out a couple of older DarkPlaces builds to look for this kind of enhancement because I suspected this kind of inconsistency was on your "do not want" list. Apparently, I need to look through older builds more thoroughly.

Thanks for this information.

[Yes, I had been mining the RecursiveHullCheck and Traceline functions looking for clues to the answers. In -- I'm thinking SV_Move (don't have the source in front of me ... I'm on my Mac which I don't really do deep stuff on due to lack of quality tools like MCVC/TextPad/WinMerge/a gui WinRar etc. --- when I saw, Touchlinks which is server-side info, I anticipated a "fail" in a true client situation that as far as I understand it should not have that info available.]

[LordHavoc]

Versions of DP THAT OLD lack the RecursiveHullCheck fixes. Just too old...

TouchLinks and so on are using the areanode system in the server to find which entities are in a given region of the map. All the edicts (server entities) are linked into the areanode system, to allow fast culling.

QuakeWorld lacks that system, and spends a considerable amount of its time just doing bounding box checks of entities against the 'movebox' before calling RecusiveHullCheck... So this is kind of an argument for and against areanode - it's not necessary, but it does make it faster.

DarkPlaces being the "crazy limits!" engine, allows 32767 entities in the map at once (32768 if you count the world entity itself), and it would be far too slow to use that areanode system, let alone the QW approach of not culling at all.

None of this is relevant if you just want to hit bmodels however - there are not a lot of them in most levels, so a simple list of them suffices, and darkplaces does not actually use an areanode system on the client unless CSQC is active, it just checks a bmodels list like I described.

When running cl_movement prediction in darkplaces, it additionally checks against the players' bounding boxes.

A fair number of culling tricks and flags can be used for different situations...

Also DarkPlaces uses a more complete PointContents involving TraceLine, so that it can detect if you are swimming in a bmodel (some of the later versions of CounterStrike did this in some levels, the idea of water being an entity is rather charming).

[Baker]

The nice r_shadows 1 feature [where even submodels like the "false floor" in the start map atrium receive a shadow] in DarkPlaces makes its debut in the December 30, 2006 beta:

http://icculus.org/twilight/darkplaces/ ... 0beta1.zip




Probably WinMerge/diffing/whatever the above versus this one:

http://icculus.org/twilight/darkplaces/ ... 6beta3.zip

Would likely illustrate most of the code changes along with LH's above commentary on how he resolved the issue.

[LordHavoc]

[revelator]