DTS shadows

#1 Wow, that sounds great, do you have any screen shots of the DTS shadows? Sorry I can't be more help. I was just starting to look at that myself.

-Ian

#2 Sure, there ya go:
But those strange "shadow clouds" in the sky are really annoying... :(

#3 Hm, those are really "displaced" shadows of DTS objects it seems...
look at those 2 pics...
tork.zenkel.com/uploads/pics/shadow4.jpg
The "objects" in the red circle are the "flying shadows" of the stones marked with a yellow circle...
Here is another perspective:
tork.zenkel.com/uploads/pics/shadow5.jpg
Strange...
EDIT: yep, those are the shadows of TSStatics...
and the function that screws things up here is

void TSStatic::renderShadow(F32 dist, F32 fogAmount)
{
...

I've simply disabled it by using a "return" statement and those displaced shadows are gone... now to find the exact error...

#4 Uh.. *cough* I guess I forgot to tell you that part when I pasted that info from Brett on IRC, eh?

Ooops.

Well it looks like you're hot on the trail of finding the problem..

#5 When I got shadows to work for DTS objects in Legends all I did was add the mGenerateShadow = true; and it worked completely fine. I didn't change any of the other stuff, at least from what I remember.

#6 Also, for static shapes you'll want to add mGenerateShadow = true; to the constructor as well.
That is all I did, I just confirmed it :)

#7 Hm, TSStatic doesn't have a "mGenerateShadow" field... and they DO already generated shadows (just not at the right position obviously) - and it did NOT work for me with the default values in shapeBase.h ...
are you sure you have

#define StaticShape_GenericShadowLevel 2.0f
#define StaticShape_NoShadowLevel 2.0f

in your code and it works as expected?
And the TSStatic shadows are placed correctly for you?

#8 Also another thing. In item.cc there is a bug.

In the function renderImage change

if (mShadow)
{
   mShadow->setMoving(!mAtRest);
   mShadow->setAnimating(!mAtRest && !mRotate);
}

to

if (mShadow)
{
   mShadow->setMoving(!mAtRest);
   mShadow->setAnimating(!mAtRest || mRotate);
}

Once you do that, any of your items that have a rotation sequence or are not at rest will update their shadow. So for instance, if you have an item that spins, then the shadow will spin as well. This is better looking than having a spinning item and having the shadow not update, trust me ;)

#9

Quote:
Hm, TSStatic doesn't have a "mGenerateShadow" field... and they DO already generated shadows (just not at the right position obviously) - and it did NOT work for me with the default values in shapeBase.h ...
are you sure you have

Yes, here is what I have:

#define Player_GenericShadowLevel 0.4f
#define Player_NoShadowLevel 0.01f
#define Vehicle_GenericShadowLevel 0.7f
#define Vehicle_NoShadowLevel 0.2f
#define Item_GenericShadowLevel 0.4f
#define Item_NoShadowLevel 0.01f
#define StaticShape_GenericShadowLevel 2.0f
#define StaticShape_NoShadowLevel 2.0f

and they are generated in the correct areas, and are not producing the artifacts in the clouds. Also, StaticShape is inherited from ShapeBase, and this is where those values above are defined(in ShapeBase). So, since StaticShape inherits from ShapeBase it also inherits all the shadow code that shadows the player, for instance.

So in the constructor, placing mGenerateShadow = true; should be just enough. You'll need to do that for both ShapeBase and StaticShape, at least I did.. I never tried without one or the other...

#10 Here is another cool thing. If you are using the day night code, to get ShapeBase shadows to change with the position of the sun, here is where you would want to do it.

In renderShadow function in shapeBase.cc, find a line of code that reads:

Point3F lightDir(0.57f,0.57f,-0.57f);

This is how the direction of the shadow is determined. Now, to get this to update with the day night stuff, create a function to get the light vector from the sun. Since our team rewrote the day night code this wont be the same for you, but this is what we did:

VectorF lightDir = DaylightCycle::getSunVector();

Now, your shadows should change position around the player as the sun moves.

#11 Stefan,

I must appologize. Static Shapes are in fact not generating shadows :o What I thought was created as a static shape was actually created as an interior by the modeler(/me strangles modeler). So yes, static shapes are not rendering shadows still. Sorry about the confusion.

Hmm, I'll have to have a second look at this code now damnit :)

#12 Beffy, maybe the shadows are being rendered onto the fog layers

#13 That shouldn't be the case though, cause the StaticShape object is using the ShapeBase object code to render its shadows, and we know that works just from the other shadows.. so I dont understand really what the problem is.

#14 #define StaticShape_GenericShadowLevel 2.0f
#define StaticShape_NoShadowLevel 2.0f


Those two lines effectively turn off shadows


They should be something like:
#define StaticShape_GenericShadowLevel 0.6f
#define StaticShape_NoShadowLevel 0.3f

This sets the point on the shadow detail slider (if we had one) at which the shadows will not be rendered and at what point at which the generic shadow and detail shadows will be rendered.


1-2-3-4-5-6-7-8-9-0
<-A-x<--B-x<---C--|

So with the above settings you get the diagram.
When the slider is set in the A range, you get no shadows
When in the B range you get the blob shadows
When in the C range you get detailed shadows

#15 Actually, these two lines of code in ShapeBase.cc shouldn't be changed

// no shadows by default   
genericShadowLevel = 2.0f;   
noShadowLevel = 2.0f;

Why? Because it is overridden in the derived classes. Every derived class, StaticShape, Vehicle, Player, and so on, is overriding those values in its constructor. So I would recommend leaving those values, just in case derived classes do not override those values since they wont want to generate shadows, for whatever reason.

I think I know what the problem is now, I'm adding the code to see if it works.

#16 Robert, did you get it to work?

#17 Honestly, I got shadows working for statics. It wasn't a simple change, and it only somewhat works. The reason that shadows don't render for TSStatic is that the render routine is almost identical to the code for ShapeBase. At least, that's the path I followed. I went ahead and did a refactor of the rendering code to make ShapeBase and TSStatic come in line with eachother when it comes to the part about shadows. The key that fixed the problem with mis-placed shadows was the difference between:

mShadow->renderToBitmap(mShapeInstance,mObjToWorld,pos,mObjScale);

and

mShadow->renderToBitmap(mShapeInstance, getRenderTransform(), pos, mObjScale);

This is in "TSStatic::renderShadow(F32 dist, F32 fogAmount)"...

Notice that instead of using mObjToWorld, I changed it to use getRenderTransform(). That is what the biggest difference was. I'd suggest giving the that a once through and seeing where y'all come out. But, like I said, it's still not perfect. You will see shadows pop in and out (on DIF objects) when you are close to an object. Plus, the shadows fade in and out way too soon. However... The shadows seem to calculate on the terrain extremely well.

- Brett

#18 yeh, I also noticed that, I think a few lines up in the code is another erference to mObjWorld, did you change that too? I changed both but my shadows still pops up in the clouds :<

#19 I changed those also and the shadows are still in the clouds. As a test, I created two shapes using the same dts, one a TSStatic and the other a StaticShape. Then I put them next to each other and stepped through their render shadow methods in debug mode.

For some reason there are a lot of member variables not filled out in the TSStatic that are there in the StaticShape.
Another thing I noticed is that the shadowLen of the TSStatic was half that of the StaticShape.

Maybe someone with more knowledge of the rendering pipeline could do this same test and determine what the problem is.

#20 Guys,

Enjoy.

- Melv.