Projectile/Decal Questions

#21 When you are creating an object in c++ you are responsible for several things that creating the object in script does for you automatically:

--instantiating the object itself (c++ new operator)
--registering the object with the simulation (->registerObject() );
--ensuring that the registration of the object occured
--ensuring that the appropriate ::onAdd() chain is called. (should be automatic, but you need to make sure)
--ensuring that the appropriate ::addToScene() chain is called (should be automatic but you need to make sure)

I suggest you take a look at the dOxygen documentation for the SimObject class.

EDIT: %this is the TorqueScript version of the c++ standard token "this", which in fact does do the same thing--in c++, "this" is a pointer to the calling object while within a class method of that object.

Note that in a ConsoleMethod, the token "object" is the same--a pointer to the calling object.

#22 Thanks Stepen. You kind of convinced me that maybe I should be doing some of this in script as well.

#23 :P

---

#24 OK can someone tell me how I can use this that I have in code and access the pMatFlag from script?

In projectile.cc

Projectile::Projectile()
{
//***Nelson's Material Mapping (Projectile Section) Update Start***
   pMatFlag          = 0;
   pMatType          = 0;
   //***Nelson's Material Mapping (Projectile Section) Update Stop***

then there is in processTick

//***Nelson's Material Mapping (Projectile Section) Update Start***
		 if( rInfo.object->getTypeMask() & TerrainObjectType )
		 {
             TerrainBlock* tBlock = static_cast<TerrainBlock*>(rInfo.object);

             S32 mapIndex = tBlock->mMPMIndex[0];
             if (mapIndex != -1) 
             {
                  MaterialPropertyMap* pMatMap = static_cast<MaterialPropertyMap*>(Sim::findObject("MaterialPropertyMap"));
                  const MaterialPropertyMap::MapEntry* pEntry = pMatMap->getMapEntryFromIndex(mapIndex);
                  if(pEntry)

                  pMatType = pEntry->matType;

				  onCollision(rInfo.point, rInfo.normal, rInfo.object);
				  explode(rInfo.point, rInfo.normal, objectType);
			 }
		 }
		 else
		 {
             MaterialPropertyMap* pMatMap = static_cast<MaterialPropertyMap*>(Sim::findObject("MaterialPropertyMap"));
             const MaterialPropertyMap::MapEntry* pEntry  = pMatMap->getMapEntryFromIndex(rInfo.material);

             pMatType = pEntry->matType;
			 pMatFlag = pEntry->matFlags;
		 }

         onCollision(rInfo.point, rInfo.normal, rInfo.object);
         explode(rInfo.point, rInfo.normal, objectType);

		 //***Nelson's Material Mapping (Projectile Section) Update Stop***

in projectile.h
under the protected section of class Projectile : public GameBase

//***Nelson's Material Mapping (Projectile Section) Update Start***
   U32              pMatFlag;
   U32              pMatType;
   //***Nelson's Material Mapping (Projectile Section) Update Stop***

I have modified my material mapping section to access these values and that all works wonderfully. Since I am obviously going to have a great deal of trouble using just code to achieve my goals, how can I get the value of pMatFlag to a function in Torque Script?

#25 Expose it as a persistent field by using the Projectile::initPersistFileds() method.

NOTE: There may not actually be a current example of initPersistFields--it is used primarily in things like ProjectileData (datablock classes), but it -is- available for all objects that derive from ConsoleObject. If it is not there (I haven't checked recently), you can simply re-implement it.

#26 Got it to work, all works pretty good, now I just have to get it all working for shape and static shape objects.

Still have to look into the dynamic texturing issue, as for the raycast to look where to put the decal that really wouldn't solve the fact that as soon as you drive the car or hit and object that can move it doesn't make the decal move with the object.

#27 Ok one problem still left and it has to do with the damn raycast. For some reason my detection system works perfectly at a distance, but if you are too close it detects the material of the obejct behind it. Is there someway to force it to look at the object closest?

#28 Well I got question #1 working but still have the other two and an addon to #1.

Is there some way to up a decal that when the bullet strikes one side of the object and leaves a decal that an exit hole decal can be applied to the opposite side of the object?

In regards to the second question, is it possible to use a .dif object as a vehicle chassis? Since .difs use a better detailed collision system it would solve my accuracy of collision towards decal placement issue, but is it something that would cause major performance issues if it is possible?

Then there is still question #3 which can be expanded to not only vehicles but any moveable object. Is there some way to make the decal stick to the position on the object where it was placed and still travel with the object? I looked into the dynamic texturing option and I would like that to be a last option if it is the only way since it seems it is going to be the largest undertaking.

#29 You could extended a ray in the reverse vector past the bounds on the other end of the object to get a exit hole in most cases. Using .difs like that isn't really practical. You could try bother John Kabus for dynamic texture decals, which he seemed to implement quite easily... but then again, he would.

#30 Well I emailed him hopefully he will say yes. As for getting a reverse vector past the bounds, how can I detect the bounds of the object?

#31 Actually I don't know a good way to calculate the distance to move the ray ahead based on the hit angle and bounding box size. I just figure you can use the max bounds of the two axis you hit along to the maximum distance to move ahead the start point of your reverse ray (and use the hit point as the endpoint for it). It wouldn't be the most efficient way, but if the reverse ray is masked to only check for the type of object it hit, it should work okay. If you could mask the ray to only check for... the object it hit period it'd be really easy, but I dunno if you can do that.

#32 I know this is a major resurrection, but I'll be implementing this at some point in the uture, so I figured I'd add my input and see if anyone else has been successful since the last post.

The easiest way, it seems to me, is to just use the normal Projectile movement code. We raytrace along our current velocity, until we hit an object. Once we have an object, all we need to do is check if we can penetrate it. If so, cast a ray against the object (using object->castRay instead of container->castRay) to get the location we'll be emerging from. This ray can just be the length of the projectile's velocity, since I'd guess that an object large enough that the projectile won't even pass through it in a second's worth of movement is going to be too thick to penetrate in any case. Then move the projectile to the emergence location, drop decals, initiate particle effects, and voila!

Apart from this, I plan to create a fully-featured projectile system which includes ricochets, underwater behaviour, acceleration, and a whole bunch of wacky crap for really special projectiles.

#33 Well Daniel for the most part there is already that ability available included in the stock code and with the resource I release a while ago. Just throwing that out there before you end up reinventing the wheel.

#34 Huh, I never saw that resource... it looks brilliant, thanks for pointing me to it! I'm not going to implement this right away, but when I do I'll certainly take another look at your code. Do you use a similar method I outlined for penetration, or another way?

I've already done some work on projectiles in an earlier codebase - I just did some making-sense of the entire system, such as separating collisions and explosions (in the default scripts, damage is done when we collide, not when we explode). Also added new parameters to drastically change projectiles' behaviour when underwater - it looked very cool with the crossbow bolt, which I set to slow down and sink :P. I also enhanced the material property mapping system, and I'm anticipating working more with it in the future.

So it basically seems we're barking up the same tree here ;). Glad you told me about the work you've done before I did any more of it independently :P.