Need assistance: Geometric shadows

For characters and highpoly shadowcasting elements, I will use shadow textures (rendered from light's perspective, etc...), but for 4-poly objects that casts shadows, I will use geometric shadows. One problem is there (a BIG problem). Here's how it have to look for geometric shadows to work:



The four vertexes in the shadowcasting, 4-poly object is no problem (that's just to shoot out 4 pivots, and see where they collide). The problem are the vertexes inside those 4 polies, which must be duplicated, and then created triangles between in the same way as the mesh the shadow land on is, so it can be colored black, and then be given an alpha value of 0.5 or something. Any good suggestion on how to get that part working?

A cube is likely to be 8 verts, so it may actually be quicker to deform a real mesh copy flat.

ChrML hope you make a great new shadow system, that would be fantastic.
good luck mate

The problem with that is when your projected mesh goes over uneven surfaces. There's not enough verts/polys to hug the surface correctly so it ends up looking very odd. And you get a lot of z fighting amoung the projected meshes polys resulting in mad flickering.

At least it did for me(On both counts) ;)

Blitz really needs a good/fast shadow system... Swwifts relies too much on texture writing which is just a frame-rate killer on a lot of old(Pre-g2) cards.

As far as I'm concerned, only two things are really missing from blitz:

fast shadows
occlusion

Those two can really help forward projects. As for pixel shaders, well I'm pretty sure they are out of the question until bmx cos thats a dx8/9/thingy re-write isn't it?

I agree, occlusion is even more important than Shadows. To the point where we were forced to do our own gl engine for our next game.

Our test level(40,000 polys ran at over 380fps in our gl engine on a G4. Around 30fps in blitz's!
So I'm personally glad Mark's taking the time to do a new engine for bmax... As long as he does it right rather than simplified and slow as a result of that.

Otacon, don't take this as a personal insult, but if you can't write an occlusion system for a 40K poly level in blitz, should you realy be writing an OpenGL engine? (I mean OpenGL is a bit more complex then blitz as you should know) The reasons I would start writing an OpenGL engine would definately not be occlusion, but rather high level shaders, stencil buffer access, render to texture and the ability to use an object oriented programming language for development. (not to state that blitz isn't a great language on it's own)

After the completion of the engine and games we (Shattered Reality and myself) are currently working on, we will probably have to decide between C++ and DirectX/OpenGL or blitzmax as our new platform.

It wasn't a case of many objects making up 40k. We had one surface per unique texture type. So each surface/mesh was pretty much viewable from anywhere.
So what blitz needs is something like BSP(In rendering terms, not bsp the format) that very quickly generates a list of 'viewable' polys on the fly, regardless of surface.

I did write something that generates a list of viewable polys from any point in 3d space, but without lower-level access to rendering it meant having to reconstruct unique surfaces on the fly...
And don't take this as an insult, if you think you can do it any other way, I'll need to see it before I believe it.

But anyway, in GL we didn't even use occlusion and got speeds that high. Other reason was for our custom fx system using vertex/pixel shaders called Fx skins.
And GL isn't complex.. Compared to DX it's a breeze.

chrML, I've briefly looked at this method of projecting geometry, and come to the conclusion it would take too much CPU time to get them looking right.

Even if you were to project a cubes geometry to a wall & floor, you'd have to do some CSG operations to see if a Tri overlapped both the floor and the wall, and slice it up appropriately, then project the new Tris geometry. This would be needed to have shadow geometry 'hugging' scenery correctly. Too much math I think.

Why not stick with the shadow mapping?

I'm still working on my own shadows using this method, for now I'm concentrating on what I think is most important, which is good looking shadows from characters onto static scenery:

Load my level
Load a copy with no textures e.t.c (the level shadow geometry)
Weld all vertices
Offset all vertices along their Normals (so later on the shadow map surface shows 'above' the level geometry)
Store all the shadow levels Tri Normals, Vert positions e.t.c
Delete the shadow mesh

Now in the update shadow function check what Tris are viewable from active lights, there's a few ways to do it, you could check if a Tris verts arewithin the lights range, check the dot product of the Tri Normal and triVert to Light vector to see if the Tri is facing the light.

There's some other checks I'm looking into, like seeing if the Tris Verts are within the lights view frustrum (for projection/cone/spot lights)

You can also check if the distance of a Tris center point to light is shorter than the shadow caster to lights distance, useful to see if the caster is behind level geometry.

From these checks we end up with minimal geometry to which you texture with the shadow map.

Still a lot of work to be done:




Cya!
Tom

I see, I've now read carefully through your posts, and I will now look at this.

Tom: I think I will use shadow mapping for static shadows, but for special areas where lights moves, I may use character shadows method (as suggested from you), only with a 4 poly shadowcaster (if that isn't too much, thinking about the shadow receiver). I will reply if I wonder at anything more. Thanks.

I think I will post my library if I get a good result, to help others with this thing.

really good shadow rendering !!!

looks really good.
can you make it less black/more tranparent

Hi all,

Yup, it can be whatever color you want. The mesh the shadow map is projected onto uses EntityBlend 2. The shadows from the pillars are lightmaps, so the character shadow is just blended over it, matching the shadow color could be a problem, idealy you want the cast shadows the same color as the lightmap shadow at its darkest.

My current problem is transforming vertices to camera space, for working out the UVs when mapping the shadow map onto the shadow mesh geometry. Blitzs CameraProject() clips values behind the camera, this is not so good for the following reason.

Take the floor in the above pics for example, the main square (not including the alcoves, is made of 2 large Tris. If the light is in the middle of the room, and the camera takes the shadow map piccy from that position, then 1 maybe 2 of each of the Tris vertices will be behind the camera, so I can't project these points into camera space using CameraProject() without getting a 0,0 return value.

In those pics I'm cheating, I'm changing the camera to an ortho view and zooming out so all verts are in view, and in front of the camera, but that kills the perspective element and makes the shadow appear smaller than it should be.

The other option would be to perform a CSG slice on any tris whos vert(s) are behind the camera plane, more unwanted math :|

Tom