dynamic_cast< Material* > from TSStatic?

#1 I didn't think this was implemented.

Though do remember that dynamic_cast is terribly slow, at least in MSVC. It does a string comparision.

#2
So if its not implemented; where do i start? How do i start? Cant be impossible, i dont believe in imposable. I dont have a clue as to where to look.

#3 Oh, I was just under the impression that it wasn't implemented. Not saying it's the case. Last time I checked was in 1.03. As for your question, I don't know either. We just react to different object types in our game, not materials.

#4 Im really in love with the idea of having my ICE covered mesh and terrain, and DIF being slippery, and muddy covered things be well, resistive. And whats the point of foot fall sounds if they stop as soon as im walking on static mesh?

Total lack of consistency, what could be solved if i knew the what, where and whys.

#5 Ok this is killing me! Im so ignorant of whats actually going on here, and usually i can learn things by fiddling with them, but i just cant find the KEY concept here to teach me whats going on.

I have:

RayInfo rayInfo;
   if( getContainer()->castRay( startPos, endPos, STATIC_COLLISION_MASK, &rayInfo ) )
   {
	   Material* material = ( rayInfo.material ? static_cast< Material* >( rayInfo.material->getMaterial() ) : 0 );
	   matfric = material->mFriction;

   }

This is working great, upto the point of:

Material* material = ( rayInfo.material ? static_cast< Material* >( rayInfo.material->getMaterial() ) : 0 );

Being done for a static mesh, this is = crash. But i know rayInfo.material have good valid data (It seems valid).

What i just cant seem to understand is what makes it work for interior and terrain? If i could figure that out, at least i would have an idea of getting it to work for static mesh.

Usualy some code search can bring me right to where the other class handle the function or whatnot, but This is just some magic! As far as i can tell static_cast is opening a wormhole into .material->getMaterial() and sucking that info back into the Material* material and magically i can now ask matfric = material->mFriction; to get into the material data defined by script.

I try my best to follow the material data's path as it is consumed and processed into the static mesh, but it get lost in the crowd way to quickly for me to follow and comprehend. And trying to follow along with Interior and terrain, they just laugh and make fun of me.

I feel like a cow trying to compute Escape velocity.

#6 Don't cast statically unless you're certain that what you will get in return is what you expect. Cast dynamically while testing, and check for NULL values to avoid crashes. Then just follow the stack trace.

You're basically telling the compiler that "Hey, I know what I'm doing" and it won't make any effort to try and avoid a bad situation.

#7 Thanks, and yes. I went down that dead end, and indeed skipping out if that cast return NULL, will stop crashing( i actual just did not cast if i already KNEW it was NULL what is only coming off the static mesh), but that did not solve the fact im still not getting the data i want.

You know what, is totally funny? Im actually not a C'code programmer at all! Surprise! Before TGE, i understood the basic syntax of C'code, i could understand basically what functions were doing by reading the code and that was all, not the WHY/HOW it worked. So my full conceptual understanding of programing in C is based 95% off what things Torque have taught me, and 5% from clarification i can gleam from the GG forums. I did in my youth program assembly and a plethora of other languages But i stopped program Back in the mid/late 90's when the AMIGA finally died, and switched to the computer generated graphic industry.


So if someone could help me understand why that Material* material = ( rayInfo.material ? static_cast< Material* >( rayInfo.material->getMaterial() ) : 0 ); is not consistent between Terrain/Dif/DTS, It would really help expand my understanding and just may be the KEY concept i need to solve a list of other bugs and problems.

#8 The reason it's not necessarily consistent is because each object type is responsible for handling ray cast queries in it's own way, and may or may not add materials.

In TSStatic the responsibility is delegated to TSMesh via TSShapeInstance. TSShapeInstance passes in a material list, but it's trying to pass in it's own instance of a material list which is often NULL. You can change it to pass in the material list from the underlying TSShape object, and that might give you the results you want.

In ts/tsCollision.cpp look for this method:

bool TSShapeInstance::castRay(const Point3F & a, const Point3F & b, RayInfo * rayInfo, S32 dl)

Now look for this line:

if (mesh->castRay(od,ta,tb,rayInfo, mMaterialList))

And change it to this:

if (mesh->castRay(od,ta,tb,rayInfo, mShape->materialList))

You may want to go further and do something like this:

TSMaterialList* matList = mMaterialList;
if (matList == NULL)
{
   matList = mShape->materialList;
}

if (mesh->castRay(od,ta,tb,rayInfo, matList))

so that it will use the TSShapeInstance's material list if it has one, and uses the TSShape material list if it doesn't.


Cheers

#9 I thought rayInfo.material->getMaterial() was getting the only mShape->materialList. And the materialList was the same for each clase, whas what i thought. I did not know that each class can have its own instance, what seems rather useful.

Do that mean i can actual change the "instance" materialList dynamically between different "instance" of the TSShape?

#10 Just to clarify what the getMaterial call does. rayInfo.material is a material instance that is set by the castRay method, and getMaterial gets the material definition from the material instance.

To answer your question, by default each instance uses the base shape's material list but you can change it per instance. Look at TSShapeInstance::setMaterialList. Also, TSShapeInstance::cloneMaterialList will clone a copy of the shape's material list, which can then be modified.

#11 Ah, this opens a full new world of knowledge. Thank you.