Dynamic lights on moving brush models

It's now in svn but i believe I hit a wall lighting bug. I tried to apply this onto the faster lordhavoc marklights function, a video

A guess... move "currententity = &cl_entities[0]" to a different place. Just before calling R_PushDlights on the worldmodel.

I don't know. The funny thing is that the shadows show up fine where dynamic lights can't (such as the DM2 megahealth/grenade train). The shadow system is a simplified duplicate of the dlight system.

As mh said, this kind of fix doesn't take BSP rotation into account. I may implement support for dynamic lighting on rotating brushes someday, but since none of the original maps uses it this is good enough for now.

Does Engoo support rotating brushes? dm2 has a 90 degree angle rotation set in its worldspawn entity. I don't think that may be the cause, but it's worth a look.
Either that, the blob shadows code or something else may be causing it. There's no problem with the dynamic lighting of those dm2 places in Makaqu.

For rotation what you'd ideally do is (1) load an identity matrix onto the brush model, transform it as normal, then (2) multiply the resulting matrix from 1 by the current MVP for drawing the entity, and (3) inverse the resulting matrix from 1 for lighting. (4) multiply the light position by the inverse matrix to get it's transformed position then proceed as before.

That works perfectly with a hardware accelerated engine, but for software you'll obviously need to do a little more work.

e3m3 also has rotation set in it's worldspawn.

e3m3 also has rotation set in it's worldspawn.

You're right, I was probably thinking of e3m3.

e3m3 also has rotation set in it's worldspawn.

You're right, I was probably thinking of e3m3.

Could easily be both. dm2 also seems to have the wrong worldtype set - it's base but surely it should be metal? - so if one bug can happen then so can another.

This caught me out in e3m3 once when I was rotating a set of surfaces based on the entities angles and not checking if the entity was the world.

Well, here's it's worldspawn, unmodified from pak1.pak:

  Code:

{
"message" "Claustrophobopolis"
"classname" "worldspawn"
"wad" "gfx/metal.wad"
}

Both the worldtype and the CD audio track aren't set. I've fixed the audio track by setting it to 8 in my UQMP toolkit, but I've not added a worldtype parameter to set it to metal. worldtype 0 is the medieval one, which isn't too wrong but isn't right either.

Now I remember, I found out about this when I noticed this map would just keep playing the same audio track from the previously played map, which was quite weird after playing one of the base-themed maps.

Engoo's lighting problem must be somewhere else in the engine then.

Engoo's lighting problem must be somewhere else in the engine then.

I suspected it being a surface marking thing rather than the theory of being shifted by rotations. I noted about the shadows because they work where dlights can't and the shadows are dlights copied, but i've compared the functions of shadows and lights and can't even spot a visible clue between the two why one works and the other doesn't.

I forgot there was a tutorial on this.

Problems - 1

Have fun when you come to do the matrix inversion. You really need it for rotating bmodels and GL's stack just doesn't cut it. Best you can do is glPushMatrix/glLoadIdentity/run transforms in reverse order/glGetfloat/glPopMatrix, then do it all again normally. When I implemented this in Quake II I just used D3D's matrix library - it worked fine in GL.

I've hated this problem for so long ... I've rather satisfied with the results of this.

This was a great one. I have never liked that world submodels don't behave as part of the proper world.

http://www.youtube.com/watch?v=bWFFe9bCB5s

It's one of those things that can be quite subtle a hell of a lot of the time, but once you start noticing it there's no going back.