fxFoliageReplicator CreateFoliage() being called before objects are fully loaded
by Thomas "elfprince13" Dickerson · in Torque Game Engine · 10/26/2009 (2:16 am) · 24 replies
(continuing the discussion from my blog post here: http://www.garagegames.com/community/blogs/view/18603)
When I declare my 2 fxFoliageReplicators, I set the following flags
As you can see from the picture, this doesn't seem to be working, however I noticed that when I open the World Editor and select one of them (without applying any sort of changes) the foliage in the water disappears. Stepping through the code in a debugger, it appears that both times packUpdate is called on the foliage replicators, mAllowOnWater is false, as expected. This means the problem has to be happening here, in CreateFoliage (which is called directly from unpackUpdate)....but ONLY on the first update (which happens during mission loading).
This suggests to me that somehow the foliage is being loaded BEFORE the waterblock and thus allowing the water to evade the call to CastRay. Oddly enough, the waterblock is defined BEFORE the foliage in my mission file. Has anyone run into this before?
When I declare my 2 fxFoliageReplicators, I set the following flags
AllowOnTerrain = "1";
AllowOnInteriors = "0";
AllowOnStatics = "0";
AllowOnWater = "0";
AllowWaterSurface = "0";As you can see from the picture, this doesn't seem to be working, however I noticed that when I open the World Editor and select one of them (without applying any sort of changes) the foliage in the water disappears. Stepping through the code in a debugger, it appears that both times packUpdate is called on the foliage replicators, mAllowOnWater is false, as expected. This means the problem has to be happening here, in CreateFoliage (which is called directly from unpackUpdate)....but ONLY on the first update (which happens during mission loading).
// Perform Ray Cast Collision on Client.
CollisionResult = gClientContainer.castRay( FoliageStart, FoliageEnd, FXFOLIAGEREPLICATOR_COLLISION_MASK, &RayEvent);
// Did we hit anything?
if (CollisionResult)
{
// For now, let's pretend we didn't get a collision.
CollisionResult = false;
// Yes, so get it's type.
U32 CollisionType = RayEvent.object->getTypeMask();
// Check Illegal Placements, fail if we hit a disallowed type.
if (((CollisionType & TerrainObjectType) && !mFieldData.mAllowOnTerrain) ||
((CollisionType & InteriorObjectType) && !mFieldData.mAllowOnInteriors) ||
((CollisionType & StaticTSObjectType) && !mFieldData.mAllowStatics) ||
((CollisionType & WaterObjectType) && !mFieldData.mAllowOnWater) ) continue;
// If we collided with water and are not allowing on the water surface then let's find the
// terrain underneath and pass this on as the original collision else fail.
if ((CollisionType & WaterObjectType) && !mFieldData.mAllowWaterSurface &&
!gClientContainer.castRay( FoliageStart, FoliageEnd, FXFOLIAGEREPLICATOR_NOWATER_COLLISION_MASK, &RayEvent)) continue;
// We passed with flying colour so carry on.
CollisionResult = true;
}This suggests to me that somehow the foliage is being loaded BEFORE the waterblock and thus allowing the water to evade the call to CastRay. Oddly enough, the waterblock is defined BEFORE the foliage in my mission file. Has anyone run into this before?
About the author
Computer Science and Physics major at Saint Michael's College. Lead developer + project coordinator for FreeBuild. Administrator, Cemetech tech community. Webmaster for the Village2Village Projects and the Vermont Sustainable Heating Initiative.
#22
11/13/2009 (9:22 pm)
Actually, that seems to do the trick. 
#23
11/13/2009 (9:32 pm)
eeenteresting. I could dig into WHY that function isn't working as expected.. However, I frankly cannot see a use for it at all. See, the Container system is going to do a ray cast against the bounding box before it passes the ray into the object's own castRay function anyway, so right there we eliminate hits beyond the bounds of the waterblock. Now the only way we can "miss" the water within those bounds is if the terrain at that point is higher than the water surface. If that is the case, then the container system will see that the Terrain returns a closer hit than the waterblock and so it will send back a hit on the terrain instead. Really, I'm struggling to see a purpose for the IsFluidAt function. And if simply eliminating it solves the problems... well then all is well, no?
#24
11/14/2009 (10:25 am)
It's a change worth making for now, though it would certainly be more satisfying to know what's actually going on.
Torque 3D Owner Scott Richards
Alright. So none of those value look ridiculously out of bounds. Time to dig deeper.
I'd like to eliminate a particular function to start off. In waterBlock.cc, line 1057. What happens when you comment out the line "if( mFluid.IsFluidAtXY(...))"? Just let the castRay function return true if the ray crosses the surface. I want to test that now because it's a particularly difficult function to read, and if it's not involved I'd rather not be giving myself a headache for nothing.