Ground Cover doesn't take into account terrain rotation

#1 Why should it?
I am sorry maybe i just don't understand the question but I don't see why it should take terrain rotation into account.
Interiors shouldn't take terrain rotation into account either.
And Ground cover is a generator object, not a static object if you want to rotate the ground cover i think you have to apply it in another way. I haven't played much with it tho.

#2 Why should it? The ground cover uses the terrain height to figure out where to place sprites and if your terrain is rotated and you can't rotate the ground cover to match it you end up with sprites in the air and below the ground.

Why would you want to rotate the terrain? Good question. I'm recreating a Geo-specific location so we're bringing in a height map. We rotated the height map and then counter rotated the terrain so that the basements would aligned better with the terrain grid when when hide sections of the terrain. It is a little complicated to explain, but trust me we needed to rotate the terrain to make everything work out right.

The point is, the ground cover should be able to take a rotated terrain into account. I can fix it ground cover code myself, but it is a bug.

#3 Oh then i did misunderstand it.. Yes that does indeed sound like a bug ;)

#4 "I'm recreating a Geo-specific location so we're bringing in a height map"

dave,i also have tried to do same thing using
"VTBuilder ("virtual terrain builder") is a tool for viewing and processing geospatial data"

what are u using for higtmap generation?
also which source your are using for elevation data?

#5 Are you adding the ground cover before or after you've rotated the terrain?

#6 Scott,

The terrain was rotated before I tried to add the ground cover.

I created a level from scratch to verify that the rotation was the problem.
The ground cover does seem to take into account any translation that is applied to the terrain.

Ahsan,

The hightmap is coming from a .png that was take from high res. data we got from the state and processed through Matlab.

#7 I can confirm this year-old bug, and have added an issue to Github:

github.com/GarageGames/Torque3D/issues/330

#8 Yeah its always done it, it also doesnt take into account holes in the terrain. and it covers thin air over the edge of the terrain aswell

#9 Yes, also had the problem with covering the edges of the terrain so the cover floated in the air, only solution was to add a layer with no cover around the whole terrain.

#10 Off topic:
So why does the Army need a map of my basement? Or is this a DHS project?

#11 Google Basement project!

#12 Fixed, I think.

#13 Thanks Daniel for the fix. I've been working on other projects and I'm just now getting back to working on T3D so I haven't had a chance to look at the forums.

#14 Sorry to point it out this late; but I didn't had any rotated terrains until this far.

The fix doesn't work fully. Groundcover objects don't appear immediately when the specific terrain is painted, only when the game is restarted (or the specific groundcover has been hidden and shown again manually)

So if groundcover A is linked to terrain texture A, groundcover A will appear immediately when the terrain has a rotation of 1 0 0 0. If the terrain has a rotation of 0 0 1 -90, groundcover A will not appear immediately when terrain texture A is painted; only when groundcover has the rendering disabled and enabled again.

(Hopefully it's a bit clear hihi ;)

#15 Oh huh. That's... interesting. If this is reproducible then add a GitHub issue. I'm not familiar with how groundcover is created when painting happens. Unfortunately I won't be able to look at it till after 3.6...

#16 For artists it might be a bit frustrating; I made a temporary workaround to ease that a bit.

It's a short script that 'refresh' the GroundCover objects on a keystroke so they pop up at will. Could be better, but it's the fastest solution I can come up with right now :)

1. In groundcover.cpp:

// +++ Temporary workaround for GroundCover on rotated terrains

DefineEngineMethod( GroundCover, applyChanges, void, (),,
                   "Apply a full network update to all clients."                   
                  )
{
   object->inspectPostApply();
}

// -->

2. In editor.bind.cs:

// +++ Temporary workaround for GroundCover on rotated terrains

function applyCoverRefresh(%cover)
{
   %cover.applyChanges();
}

function refreshCover()
{
   if(isObject(GroundCovers))
   {
      %group = GroundCovers.getID();
      %count = %group.getCount();
      for(%i = 0; %i < %count; %i++)
      {      
         %cover = %group.getObject(%i);
         if (%cover.getClassName() $= "GroundCover")
         {
            %isCover = endsWith(%cover.getName(), "Cover");
            if (%isCover == true)
            {  

               %delay = %i * 100;
               schedule(%delay, 0, "applyCoverRefresh", %cover);
            }
         }
      }
      return true;
   }
   else
   {      
      error("Cannot find GroundCovers for refreshCover()");
      return false;
   }
}

EditorMap.bind( keyboard, "ctrl enter", refreshCover );

// -->

3. Create a simgroup with the name "GroundCovers"
4. End all the names of the GroundCover objects (that need to refresh) with "Cover"
5. Place the GroundCover objects in the new simgroup
6. Press [ctrl] + [enter] in the editor to 'refresh'

#17 So this used to work, and was broken after my 'fix'? All that did was change the way the groundcover position is calculated. Surely this had nothing to do with it?

#18 My sincere apologies @Danny, I didn't mean the fix was a bad job... I think it was an excellent fix! Many thanks for then, and many for looking at it now :-D

As far as I can tell from the quick tests, was this issue already there before #406 and #407. So yes, it was broken before your fix (#406) and I believe it also hasn't anything to do with the other (#407).

Further do I think it's not that all important right now and this can wait until there aren't more urgent or nicer issues to take care of...

One should avoid rotating the terrain anyway. I did it because I didn't use a proper value for the parameter "Azimuth override", which means the sun was moving incorrectly in the sky. Now with the right figure the sun is rising in the east, no need to rotate the terrain at all!

NB The keystroke in the script above (if one ever need it :-S) can be changed to something else, Perhaps a [ctrl] + [F5] will do for webdesigners ;)