Terrain collision not working?

#21 I'm having the same problem!

Ragdoll works certain places, but not everywhere even though its inside "theMissionArea".

Any ideas or fixes? Size limits?

#22 Did you try the fix I have earlier in this thread?

#23 Yes!

I tried to implement it in alpha 1.1, but I got some compile errors.
I think i fixed them, but still, no ragdollcollision with the terrain.

Fixes needed:

res =  buildPolyList(PLC_Collision,mPhysPolyList, box, SphereF());
res =  buildPolyList(PLC_Collision,mPhysPolyList, newBox, SphereF());
res =  buildPolyList(PLC_Collision,mPhysPolyList, objBox, SphereF());

You can see I needed to add another parameter to the function. Also I needed to change a bit the

Box3F box = Box3F(area.point.x, area.point.y, -10.f,   
                  area.point.x + area.extent.x, area.point.y + area.extent.y,   
                  /*fixedToFloat(gridMap[BlockShift]->maxHeight)*/maxH);

Maybe this break the functionality? It does compile at least. When loading the mission it the program stands still a while, then continues to run, so i guess its because its making a collision mesh. However, when a ragdoll is spawned on the terrain it simply falls through.

I have a working ragdoll.
I have added a well enclosing MissionArea object which is called MissionAreaObject.
The terrainblock itself is made from blank terrain and then edited with the editor tools.

I also have moved the terrain to "0 0 0", it seems like torque likes to move newly created terrain blocks a bit ;)

Any ideas? Thanks in advance!

#24 Well there is only one sure fire way to know if your terrain is being created properly. Open you server scripts and in the logickingMechanics folder there is a script file named physics.cs oprn that.

Change:
$GMK::Physics::Draw = 0;

to

$GMK::Physics::Draw = 1;

Re open your map, it might take a while if your stuff is working right, if you do not see red lines all over indication your terrain polys, then your code is truly not working. Otherwise your problem is elsewhere.

#25 Also, my code was designed around TGEA 1.81, I don't own Torque 3D yet.

#26 Hey!

I finally found the physicsDraw(1), and got it to work!

No matter how large or small I make the missionareaobject, just a small part of the terrain is covered in red. If I move the terrain, then the red "strip" stays still and covers a new area of the terrain. No matter if I use my most likely faulty port of your code or the original code.

Also, it takes a really long time to load, the game freezes completely
up, any ideas for making this load time smaller?

Thanks in advance!

#27 No one else is struggling with this? :/

#28 >No one else is struggling with this? :/

Please check out GMK 1.2.8 .

Starting from T3D Beta 1 GMK is using core functionality of T3D for physics calculations. So your problem might be gone already.

#29 I set $GMK::Physics::Draw = 1;

It draw line to physics area but it do not complete to draw the terrain.

#30 I solved this problem. Now physicsDraw function is drawing full area of my terrain.

I changed MaxExtent value in terCollision.cpp at line 14.

Change :

static const U32 MaxExtent = 256;

to:

static const U32 MaxExtent = 512;

Then rebuild my project and the results are as following picture:

#31 @Kodgraf
Hey that worked! :)
I now have a collision mesh over the entire map.

However, it takes forever to generate the terrain collision mesh!
It stops at
*** Stage 2 load
and hangs there for about 5 min or so..

using:
Area = "0 0 1024 1024";
and U32 MaxExtent = 1024;

Any ideas anyone? =)

#32 If you add the code below to the buildPolyList method in terrCollision.cpp at around line 591-ish, you'll build your poly list a little faster.

I'm using v1.0.1

/**
 * Faster poly list building in TerrainBlock::buildPolyList( ... )
 */

   // After this Torque code

   const U32 BlockMask = mFile->mSize - 1;

   bool emitted = false;

   // Add this New Code

   ConcretePolyList *pConcretePolyList = dynamic_cast< ConcretePolyList * >( polyList ) ;
   if ( pConcretePolyList )
   {
      U32 xRange = static_cast< U32 >( xEnd - xStart + 1 ) ;
      U32 yRange = static_cast< U32 >( yEnd - yStart + 1 ) ;

      U32 uNumPolys    = 2 * ( xRange - 1 ) * ( yRange - 1 ) ;
      U32 uNumVertices = xRange * yRange ;
      U32 uNumIndices  = 3 * uNumPolys ;

      pConcretePolyList->mPolyList.reserve( uNumPolys ) ;
      pConcretePolyList->mVertexList.reserve( uNumVertices ) ;
      pConcretePolyList->mIndexList.reserve( uNumIndices ) ;
   }

   // Before this Torque Code

   for (S32 y = yStart; y < yEnd; y++) 
   {
      S32 yi = y & BlockMask;

Hope this helps.

#33 Thanks.

#34 @H.T. Shipman:
Wow! With that fix, the loading times went down dramatically! using MaxExtent = 1024 now went from 4-5 min to under one min. :D

So a dramatic increase! :) Any ideas to even further bring down the loading time? Ive tested Beta1.1 with GMK128, and as far as i can tell there is hardly any loading. Any clues why? :)

Awesome work ;D and thanks again!

#35 This is the terrainblock I'm using:

new TerrainBlock(Terrain) {
      terrainFile = "levels/terrain01.ter";
      squareSize = "1";
      baseTexSize = "1024";
      screenError = "16";
      position = "0 0 0";
      rotation = "1 0 0 0";
      scale = "1 1 1";
      canSave = "1";
      canSaveDynamicFields = "1";
      Enabled = "1";
         missionAreaPhysicsOnly = "1";
         tile = "0";
   };

Not a particulary enourmous terrainsize, but still the loading is far to long! I understand that the reason it takes very little time to load the physics in Beta1 is because of much tighter physicsintegration.

But still, is there no other way to increase the loadingtimes? Can anyone else confirm loadingtimes of several minutes, even with the fixes posted by others here? I just want to know if it is me that is doing something wrong or not! Anyone? Alpha1 w/GMK127 equals veeeery long loadingtimes?

Thanks again for any replies! Im very grateful for all the answers :)