Calling SetPosition() expensive?

[Rastar]

I would like to move an entity together with the camera. Since I don't want it to rotate with the camera, I just called ent->SetPosition(camera->position + offset) every frame. However, that seems to be really expensive - doing so gives me a framerate drop from 100-110 down to 50-60 (in Debug). Is Leadwerks doing some expensive calculations during this call?

 

EDIT: OK, the frame rate drop seems to depend on the number of children that my entity has, so I guess the engine goes down the tree and recalculates the transform? However, that still seems to be too costly.

[Josh]

This description is really insufficient for me to guess from.

[Rastar]

I am playing around with a custom terrain once again. The terrain has a number of patches parented to it, depending on the terrain size these can be between a few dozen and several hundred. They are all directly parented to the terrain, no sub-hierarchy.

 

I have added a hook

 

void CameraPositionHook(Entity* entity) {
MT::Terrain * terrain = static_cast<MT::Terrain*>(entity);
Camera* camera = terrain->GetCamera();
Vec3 position = camera->position;
position.y = 0;
if (camera) terrain->SetPosition(position);
}

 

which I add as an UpdateWorldHook to the terrain, and the SetPosition() call causes the observed rate drop.

[Vulcan]

Why do you want have the entity follow the camera and not vice versa? But to answer you question about SetPosition(), I would say from my own experience that is not expensive to use. Heck I use it several places in my project. How many SetPosition() are we talking about each game loop?

[Vulcan]

I am playing around with a custom terrain once again. The terrain has a number of patches parented to it, depending on the terrain size these can be between a few dozen and several hundred. They are all directly parented to the terrain, no sub-hierarchy.

 

I have added a hook

 

void CameraPositionHook(Entity* entity) {
MT::Terrain * terrain = static_cast<MT::Terrain*>(entity);
Camera* camera = terrain->GetCamera();
Vec3 position = camera->position;
position.y = 0;
if (camera) terrain->SetPosition(position);
}

 

which I add as an UpdateWorldHook to the terrain, and the SetPosition() call causes the observed rate drop.

Are you trying to move the terrain? A terrain of 1024x1024 makes about 1 M vertices, that would really slow it down. If I am reading this correctly (I may be horrible wrong here).

[Rastar]

It's just the one call per game loop. And actually, I have the same drop when I parent my entity (and its children) directly to the camera.

 

EDIT: Yes, I am actually moving the terrain. I don't think the number of vertices plays a role here, since they are in object space coordinates and not moved individually. No, something else must be updated during the SetPosition() call, since the position transformation itself should be pretty fast.

[Josh]

I can't imagine the implications of moving the terrain around. It's meant to be static. I don't think that will even work.

[Rastar]

I am not moving the Leadwerks terrain, this is just a entity with some meshes.

[AggrorJorn]

EDIT: Yes, I am actually moving the terrain.

I am not moving the Leadwerks terrain,

I am not following what you are trying to do here. You have your own mesh which you move right?

[Rastar]

Yes, sorry for the confusion. I am not using the Leadwerks terrain, but my own terrain implementation, which yes, consists of mesh patches. And I like to move that with the camera since the mesh density is higher close to the entity's origin, so,it should be centered around the viewer. Think of moving a magnifying glass over a map.

[nick.ace]

I think I might be confused also, but if you are moving the terrain with the camera, then what is the purpose of mesh patches? I get that you want certain parts of the terrain to be more detailed that others, but this sort of defeats that purpose.

 

Could you maybe post a screenshot?

[Vulcan]

I think may be shaders might be something to consider. I have seen a lot of fancy things like wrapping, morphing like fluid and cool camera lens effects etc. But then again I am no expert on this subject.

[Rastar]

OK, I did some more tests, this time not with confusing terrain stuff... It seems it is not really the call to SetPosition(), but rather the number of objects that causes the slowdown. However, I still don't really understand why.

 

Attached is a little App that

 

1) creates a pivot

 

2) creates a configurable amount of boxes/meshes/pivots (boxCount in line 40) and parents them to the pivot

 

3) set the pivot's position every game loop (line 97).

 

Running in debug mode I get

 

~135 fps for 0 children

~105 fps for 100 children

~65-75 fps for 250 children

~45-60 fps for 500 children

 

Results for the three entity types are similar. There is nothing else in the scene, not even a light. I wouldn't expect that sort of slowdown - am I doing something principally wrong? Does the scene tree not like flat and wide structures?

 

Thanks for any hints!

 

App.cpp

[Vulcan]

Try adding

box->Release();

after

box->SetPosition(Vec3(i, 0, i));

[Rastar]

Well, this helps, but it does so by destroying the entity.

[shadmar]

I wouldn't think that pivots should steal this amount of fps (or hardly none at all). So wierd I think too.

[Vulcan]

Sounds like it could be a bug in Pivot class. Pivots are inherited from Entity class I believe, do you get same result with 500 entities instead of 500 pivots?

 

EDIT: fixed spelling

[Rastar]

Yes, as detailed above I get basically the same result with boxes and (empty) models. Pivots are a little faster, but I guess no draw calls have to be issued for them.

[Rastar]

Bumping this - I'd really like to have an answer for this. Am I missing a method call or something, is this generally expected behavior, is there some problem in the way Leadwerks handles the scene tree...?