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]

To be honest I think that you're chasing a dead end with this one.
.
.
.
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.

I agree with you in principle. Don't get me wrong.

My principle hatred of the problem is that I feel world sub-models should essentially interact with the world in the same manner as they do with physics.

Now ... I do understand the underpinning problems (although no doubt less than you do) ... i.e. the server data not being available for a true client connection (touchlinks, etc.).

And I know the shadows don't clip to the world correctly.

Yet I see player shadows in other games and Quake engines bothering to implement stencil shadows and R00k once told on a server "if I could quit my job, the first thing I'd do is figure out how to make shadows clip properly."

Clearly, at the moment I am not hefty enough in this category to immediately solve this issue myself. But isn't "piss me off issues" that motivated you to make DirectQ

There isn't a thing in the world wrong with me hating this issue. Baker 2013 will be shaped by these annoyances just like MH 2011 is a far more powerful version of the MH from 2008

[Spike]

those shadows are wrong anyway, if the light is off to the side, the shadow is still nice and crisp and directly under them.
imho ditch the glquake shadows and implement it using blob shadows instead. basically clipped decals. walk the bsp tree to find the surfaces under the player, and chop them against a few planes, or just draw them in their entirety... and generate some appropriate shadow texture+texcoords+alpha for it. if the alpha values are based on distance and if its facing away, then your shadows should be sufficiently robust.

And yes, I agree, doors/walls/plats/etc should all be treated the same as world for things like lighting etc, at least on an individual frame basis. this also applies to stain maps, of course.

[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]

Shadowing is a terrible thing to work with, indeed.

Engoo's negative dynamic lighting shadow effect is something I'd like to implement in the long run.

[leileilol]

warning though - dynamic lightmap shadows are a bitch to the cpu. especially when there are lots of them. factor in colored lighting and all the slow C-based mipblock code you can bring down core2duos with a software renderer! Forget about the Crapcast for that feature. also, it has problems with brush models and different texture scales

Darkplaces's r_shadow shadowmap alternative is better. basically it's what Tribes and UT2003 does roughly (but better). It might even possible to have some form of projective shadowmap in software as well, if you think about how half-life's decals worked by being part of surface caches.

Remember, GLQuake's shadows are just a "buggy novelty but cool to look at" feature much like the mirrors and wateralpha. If you take them seriously as a feature, then you're doing it wrong.

[LordHavoc]

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.

Oh man, I fixed this so many years ago...

The short tutorial-ish version is:
Grab the matrixlib.c and .h files from darkplaces.

Add num_network_bmodels and network_bmodels (an array of ints) to your client_state_t in client.h and each time a new network packet is received, set cl.num_network_bmodels = 0, and each time one of the entities is parsed, check if its model->name[0] is '*' (these are submodels), if it is, do cl.network_bmodels[cl.num_networkbmodels++] = num;

Also call Matrix4x4_CreateFromQuakeEntity and store the matrix into the entity_t for the entity, also call Matrix4x4_Invert_Simple to make an inverse matrix from that one, keep both around - you'll need them.

Now in the r_shadows code, instead of calling RecursiveHullCheck, call CL_TraceLine, you'll be creating this function (cl_main.c is probably a good place for it), it will loop over the cl.network_bmodels and look up cl.entities[num] for each one, call RecursiveHullCheck on each one.

Now to deal with the rotation/translation which is why you needed the matrixlib, in CL_TraceLine use Matrix4x4_Transform with &entity->inversematrix on the start and end of the traceline, this gives you "local coordinates" in the entity space, so you can call RecursiveHullCheck and get your data calculated in local space, then use Matrix4x4_Transform3x3 to transform the trace->plane.normal (you'll need a temporary vec3_t for this result, and then copy it back in), and use for(j = 0;j < 3;j++) trace->endpos[j] = start[j] + (end[j] - start[j]) * trace->fraction; to update the endpos (in worldspace).

Now you have a CL_TraceLine function that you can call and it will hit bmodels, make sure you also call RecursiveHullCheck on the world while you're at it.

Note: the entity->matrix and entity->inversematrix are very useful in rendering, for fixing other bugs - such as the dlights not hitting the bmodels properly, just transform them using the inversematrix as before, and they'll work on moving bmodels.

In fact you can call Matrix4x4_ToArrayFloatGL to get a float m[16] array you can pass to glMultMatrixf instead of using glTranslate/glRotatef/glScalef when rendering entities, this is useful if you handle attached entities.

It's even better to use matrixlib to entirely replace the GL matrix stack... But that's a topic for another day.

[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]

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:

This one is the stencil model shadows, so it's fundamentally different in how it is implemented - you may also notice it is shadowing the player model partially.

Due to being stencil it relies on things like triangleneighbors data on models (computed at load with a very optimized algorithm - otherwise this can be extremely slow to generate) and the shadowvolume creation code. It also only works in 32bit color due to use of stencil.

Not really related to the glquake planar shadows which use a traceline to figure out what the ground plane is and project the model flatly on that ground plane.

Look a bit further back, you'll find an improved implementation of that, where it even conformed to sloped floors, but not stairs. The year was probably 2003 but I am not certain.

[revelator]

also one i been stomping on a LOT.

what really irritates me about shadow volumes is that the implementation is actually pretty straight forward if you look at some code that was actually made with shadow volumes in mind (quake is not) and it acts like the proverbial throwing stones in glasshouses (ouch ouch ouch).

looking at tenebraes i once thought hey it cant be that hard but im still to have a breakthrough with that one (does tenenbraes shadow volumes assume per pixel lighting ?).

one day maybe ...