Shadow class from scenobject

#21 Ben, I had a brief look at it but it seems to write to the screen framebuffer which means, what you write is what you see, on screen! during game play.

I need to render to memory 1st or straight to bitmap. The only way I see it working is to render to the AUX buffer of the video card (mine has 4) and then copy to bitmap. At least that way you still get hardware support for the drawing functions. I understand that some older video cards don't have any aux buffers which is why I do the buffer count check. Older cards will have to make do with the standard bitrender routine.

Also I need to set a viewport to match the bitmap size, plus ortho projection, plus position the object as a nice fit in the viewport.

I did make a feeble attempt but got undesired results so put it on the back burner for a while because I clearly need to spend more time on it. Meanwhile I continue doing code cleanup and QA.

#22

Quote:
If I can implement the above deleting of bitmaps when not on screen

Done!

#23 Update, REAL shadows which include transparent sections are now working with no noticable differance in frame rate between the original and the new method. It might be because the old method was a software rendered method and the new uses hardware supported rendering.

Anyway- here are the pictures. Below shows 4 objects, the left 3 are real shadows and the tree on the right
is a fake shadow. Did you ever see that Bravetree tree cast a shadow like that?


There is a gap between the shadow and the tree which I still have to sort out. It's not present on the vehicle shadows so its a bit of a head scratcher for now.

And next I've positioned the old familiar Bravetree tree alongside a wall to prove its a projection. Note the leaf detail along the top of the shadow.

This means that vehicle windshields will no longer cast black shadows but instead will show some light passing through. Same with fairy wings etc.


Its not perfect yet buts its getting there.

#24 I'm very eager to see this made available to the community, do you have any plans for that? If so, will you sell it or will it be free?

#25 Hey Duncan,

How does it run on a GF2? :)

Ben

#26 @Midhir, these changes are currently destined for HEAD when its done but I'll never say no to money if anyone is offering.

@Ben, my dev machine has one of the latest Geforce graphic cards and my older PC has a Geforce 2 mx, but the monitor on that machine is bust so I can't test on it. Basically the shadow casting object gets rendered to bitmap but without lighting and depth testing to speed things up, and its a hardware assisted render. Compare that to the original render to bitmap via software and its not too different, timewise, in theory anyway. Perhaps the new method is even a bit faster ...

In practice I have not done any time tests other than check the FPS. I have set up the code to use a bool to determine which shadow production method to choose, based on the presense of an aux color buffer in the graphic card.

But there are still some minor issues to sort out like that shadow offset.

#27 Wow this is some awesome work, Keep it up!

#28 I have managed to sort out the offset problem in the new shadow production method. I had to shift the drawing Z position by the difference between the shapes bounding box heigh and width, i.e.
pos.z += (width - height)

The old shadow production method has the same offset problem and I assume its for the same reason, but when I apply the above correction, it seems to rotate the shape, rather than shift it. Here is the code section.

// we want pos to map to bitmap center...
	   // the following is a bit convoluted...but it is correct...
	   Point3F p,p2;
	   mat.getColumn(3,&p);
	   mWorldToLight.mulP(pos,&p2);
	   p -= p2;
	  // p.z += (mRadius - mShapeHeight/2); 
	   p *= k;
	   F32 halfDim = mSettings.bmpDim>>1;
	   p.x += halfDim;
	   p.z += halfDim;
	   mat.setColumn(3,p); // shape center now falls on bitmap center...

The commented out part is what is supposed to shift the image on the bitmap, but does not. Any ideas Ben or anyone else?

Regarding the terrain LOD causing shadow sections to disapear. I took the camera under the terrain and looked at the shadow from the bottom and the problem does not occur, the shadow remaining steady.
Also consider that the shadow consists of a texture mapped onto polygons. The polygons were obtained from the terrains getPolyList() method and thereafter, the shadow render() method does not care if the terrain exists or not because it now has its list of polygons. (until it wants a new list)

What I'm trying to say is, even if some terrain tiles subdevide/merge, the shadow is not affected because it uses its stored polylist. I'm leaning away from terrain LOD being the problem and favouring Opengl texture blending or similar as the suspect.

#29 For testing purposes, I forced the TSStatic shadows to build a new partion-new polylist on every frame and the 'blocky' problem still exists which, for me, confirms its not caused by terrain LOD changes.

So that narrows it down to... everything else...

I still suspect blending or render order, will look into it.

#30 It's not blending or render order. It seems its "texture bleeding " caused by depth buffer precision errors. The only way to reduce the effect, according to the experts, is to reduce the difference between the near and far planes which will increase depth precision. Well that's not practical, unless your game takes place in a shipping container...

Perhaps its possible to 'help' the depth buffer by adding a tiny positive amount to all Z values of the polygons in the shadow polylist. Or in plain english, add some space between the shadow and whats behind it.

#31 Do note - what I'm getting with terrain LOD is that the terrain will draw DIFFERENTLY than the polylist it returns, which represents collision data, not the rendered data.

So it would act a lot like z precision (since the LOD is distance based), but have different causes.

#32 I seeing a problem in the current 1.4 Head where a translucent object doesn't show a shadow when you are close to it. When you get a certain distance from the object, the shadow starts showing up. Is it possible that what is happening, is that the engine is ignoring the translucency of the object from that distance, so the shadows starts appearing? And, if so, would this resource solve the problem? And, if so, is this resource going to be released, or has it been?

#33 Yes it has been.