Scaled Terrain Doesn't Render Sectors

[michael.zhang]

Hello,

 

I have a terrain, which looks like picture 1.

If I scale the terrain, for example by 4x, when I get close to the terrain, it renders as shown in picture 2. (Which also showcases the ocean flicker bug mentioned in the other topic)

 

Without scaling the terrain, a closeup shot has no problems (See third picture).

 

 

What might be the problem? I'm guessing it has something to do with camera settings detecting certain terrain sectors as "not visible" and so it doesn't render them. Perhaps because of the larger scale. But, I have been unable to find out what setting that might be.

 

Any advice/suggestions would be appreciated.

 

 

 

 

Michael

[binstream]

We strongly recommend not to use scaling feature.

[michael.zhang]

We strongly recommend not to use scaling feature.

 

Is scaling of shapes similar strongly not recommended?

 

I'm only trying to scale this terrain because I can't scale my character down without Shape collision bugs (see my e-mails). Which by the way, works. If I don't scale my character, then Shapes don't have constant collision.

 

Seems like scaling is a big problem in alot of places, how come?

Is there a technological barrier to supporting scaling properly? Or, just a bug?

 

The other way would be to re-export my assets scaled down. Which... is annoying. But it looks like I have to do this now.

[ulf.schroeter]

The other way would be to re-export my assets scaled down. Which... is annoying.

 

Modelling ALL assets at a consistent scale (e.g. 1 unit = 1m) and frame rate (e.g. 30 FPS) for animations is paramount to avoid all kinds of headaches during runtime.

[manguste]

Modelling ALL assets at a consistent scale (e.g. 1 unit = 1m) and frame rate (e.g. 30 FPS) for animations is paramount to avoid all kinds of headaches during runtime.

The golden rule :)

 

Scaling increases the complexity of calculations, that is why it is always detrimental for performance. And that is the main reason you would not want to use scale. Using non-scaled meshes pays off much better, because it means a stable result and no physics-related limitations:

 

• You can scale static meshes, but remember that it is better to be a uniform scale. Non-uniform scale by interaction with physical objects may result in incorrect collision detection.
  
• Do not scale objects with physical bodies and shapes. Physics does not account for scale factor in its calculations at all, because it is too costly. So basically your scales are reset to 1.
  

In your case, as the terrain is going to be used for interactions with physical characters (when they walk upon it), you need to reexport your model in any way.

[michael.zhang]

The golden rule :)

 

Scaling increases the complexity of calculations, that is why it is always detrimental for performance. And that is the main reason you would not want to use scale. Using non-scaled meshes pays off much better, because it means a stable result and no physics-related limitations:

 

• You can scale static meshes, but remember that it is better to be a uniform scale. Non-uniform scale by interaction with physical objects may result in incorrect collision detection.
  
• Do not scale objects with physical bodies and shapes. Physics does not account for scale factor in its calculations at all, because it is too costly. So basically your scales are reset to 1.
  

In your case, as the terrain is going to be used for interactions with physical characters (when they walk upon it), you need to reexport your model in any way.

 

I see. In other games, I see that they use the same model but scaled for different types of creatures, for example. (Reducing the need to export 10x versions of the same mesh with different scalings... and what if I have a spell that "enlarges" my character)

 

Shouldn't the decision to use scaling or not be made by the game developer, rather than it simply not functioning?

I may be willing to take the performance penalty in favor of other headaches.

[manguste]

You can use scaling for static meshes - it's up to you, though it is not recommended. Just avoid using it together with physics.

Did changing Near/Far clipping settings not help in case of terrain?

[michael.zhang]

You can use scaling for static meshes - it's up to you, though it is not recommended. Just avoid using it together with physics.

Did changing Near/Far clipping settings not help in case of terrain?

 

Changing near/far clipping has no effect on the terrain sector rendering problem. But it does fix my ocean flicker problem.

[ulf.schroeter]

Changing near/far clipping has no effect on the terrain sector rendering problem. But it does fix my ocean flicker problem.

 

Does terrain sector rendering problem also happens for scale = 1 ?

[michael.zhang]

Does terrain sector rendering problem also happens for scale = 1 ?

 

No it does not. Terrain renders perfectly when scale is 1.0

[ulf.schroeter]

Bug is easy to reproduce with UNIGINE ObjectTerrain "terrain_00" sample by setting node x/y scale values e.g. to 2.0

 

 

Problem most probably related to invalid BoundFrustum clipping plane calculations in case of non-1 node scale transform. BoundFrustum::setTransform() gets called by ObjectTerrain::get_terrain_culling(int pass) for bound frustum transformation into local ObjectTerrain coordinate space. Not really sure, but in case of non-1 scale transform the calculated clipping/portal plane normal vector parts x/y/z e.g. no longer have unit length which might be the cause of false point vs. plane relation testing during terrain patch/surface culling.

 

math\Bound.h

void BoundFrustum::setTransform(const mat4 &transform) {

mat4 itransform = inverse(transform);
....
// clip planes
for(int i = 0; i < 6; i++) {
	planes[i] = planes[i] * itransform; //< this transformation most probably causes invalid clipping plane values  
}
....	
// portals
for(int i = 0; i < portals.size(); i++) {
	Portal &portal = portals[i];
	portal.plane = portal.plane * itransform;   //< this transformation most probably too causes invalid portal plane values  
...
	for(int j = 0; j < 4; j++) {
		portal.planes[j] = portal.planes[j] * itransform;  //< this transformation most probably too causes invalid portal plane values  
	}
....
}
}

[frustum]

Thanks, the scaling issue is fixed.