Terrain Editor bug

[John3]

Hi, Don't remember seeing this bug in 3.6.3, sorry right now I can't tested.

But in 3.7rc if you use the terrain editor with any tool (raise, grab, smooth, etc) almost always modify two places at the same time.

I not sure if already reported, do some filter but don't see anything.

As you see, the border on the left was modelling while I modelling in the middile.

other bug on the terrain editor, if you do something an undo and then redo the engine crash.

the console don't show nothing.

[John3]

I notice something. See this http://forums.torque3d.org/viewtopic.php?f=12&t=161#p1377 to understand what happen.

I never wait for the AIPlayer reach to the destination always try to stop before, therefore I never saw. I have again the bug (see the post) but now with the NavPath.

As you see one of the problem was a waypoint in the same spot of issue with the terrain, so is not only the terrain. Even I was putting the waypoints on my testBaseCamp for some reason is there... I deleted the waypoint but my soldier was running to the same spot.

So I see 3 thing here: 1) the terrain, 2) waypoint/objects , 3) may be bad information or wrong parameters on the script send the soldier to the same spot.

Of course if you are modelling the terrain the bug create that mountain range.

[John3]

Testing this again.

Torque3D v3.9 Default CMake options, win32 and x64 build, OpenGL and D3D11, Template Full, VS2015

Terrain position: -131.194 -28.885 -510.409 Terrain Rotation: 1 0 0 0.0395647 Level: Empty Room

Video bug 1: https://drive.google.com/file/d/0B9GUwtDHCp_eWjdzcThRdlVuNXM Video bug 2: https://drive.google.com/file/d/0B9GUwtDHCp_eYnk4RTRwZmFKWkU

EDIT: tested t3d v3.9

[AtomicWalrus]

This appears to be an extension of a legacy bug, going back at least as far as 3.0.

The terrain editor is failing this collision check periodically when you're editing the heightmap (my added comments start with "// <---"):

void TerrainEditor::on3DMouseDragged(const Gui3DMouseEvent & event)
{
   PROFILE_SCOPE( TerrainEditor_On3DMouseDragged );

   if ( mTerrainBlocks.empty() )
      return;

   if ( !isMouseLocked() )
      return;

   Point3F pos;

   if ( !mSelectionLocked )
   {
      if ( !collide( event, pos)  ) // <--- This is the check which fails
         mMouseBrush->reset(); // <--- The brush gets reset, but we still call the terrain edit action
   }

   // check if the mouse has actually moved in grid space
   bool selChanged = false;
   if ( !mSelectionLocked )
   {
      Point2I gMouse;
      Point2I gLastMouse;
      worldToGrid( pos, gMouse );
      worldToGrid( mMousePos, gLastMouse );

      mMousePos = pos;
      mMouseBrush->setPosition( mMousePos );

      selChanged = gMouse != gLastMouse;
   }

   mCurrentAction->process( mMouseBrush, event, true, TerrainAction::Update ); 
   // <---- If the brush was reset, we're passing garbage to the edit action process function
}

For some reason, in older versions failing that check would create an engine stutter, but not the erroneous terrain edit. Now it's just periodically editing at about (-245,1) when it fails collision.

As a hacky solution you can just return out of the function after mMouseBrush->reset();

   if ( !mSelectionLocked )
   {
      if ( !collide( event, pos)  )
      // [Edit]
      {
         mMouseBrush->reset();
         return;
      }
      // [/Edit]
   }

Otherwise, you go on to call mCurrentAction->process with bad data in mMouseBrush, apparently resulting in those bad terrain edits.

There's some deeper issue here, but for the sake of having the terrain editor be not-completely-broken, and considering that this bug has been around for at least a couple years, I'd recommend the hack.

[John3]

Hi @AtomicWalrus thank you for this hack. I will give a test this week. thx! :)