Performance Tanks after Instancing an enemy just 6 times.

[Daemoc]

Aye, you can attach objects to any bones in the hierarchy via the editor. I have done it with both mesh objects and lights.

And while I can not speak for Blender, in Cheetah I can put separate meshes in the hierarchy and they are not actually assigned bone weights. The mesh as a whole is just driven by the bone. My test model’s hair, mask and goggles are attached this way. What I was suggesting is making the character out of individual pieces and having each piece be driven by the bones without any bone weight/skinning calculations.

I am curious about this now myself. When I get home I will try and see how many of my test characters I can spawn before I see a serious performance hit.

[TheConceptBoy]

3 hours ago, Daemoc said:

If you can instance static geometry with the same kind of mesh complexity without this issue it would have to be the skinning performance. Leadwerks supports hardware skinning, and while that GPU is not great, it not THAT bad.

One other test you could try, although tedious, would be to attach static meshes to each bone rather than using a skinned mesh. Preferably with objects that match the same poly count as the skinned mesh. That would isolate the skinned mesh performance from physics.

Also, the hand animation to head bob de-sync might be caused by world update and physics update calls? Are both functions under the same update?

Come to think of it, I don't know if they are. So far this isn't a player class, its just some code in the loop I palced in main.cpp

bool main(){



  while(true){
	// player head bob and other player stuff


  }

}

I don't know if the while true is perhaps a suitable place for placing these sort of time critical things? That is where the player head bob code currently resides. Perhaps that is the cause of that particular issue and I should be creating a player class from the Actor  and programming the head bob inside of it's world update function?

[Rick]

If the headbob is at different speeds based on the speed of your app I'd say you aren't taking into account AppSpeed()  in your calculation of it.

[Josh]

Debug mode has a lot of checks for errors, and STL especially has a ton of checks to make sure you aren't doing something wrong. It should only be used for development, never released to the player.

You can multiply any time-dependent values by Time:GetSpeed() to make your game run at the same speed regardless of framerate.

[gamecreator]

On 6/28/2019 at 1:50 AM, Josh said:

You can multiply any time-dependent values by Time:GetSpeed() to make your game run at the same speed regardless of framerate.

With the caveat that this is not exact.  I don't know about the character controller (after the latest updates) but if you're coding your own character movement, you are better off using a fixed framerate, or things like jumps won't be the same height on all computers, as per here.

[Ma-Shell]

One should also note that there are basically two different Debugging modes: The option you changed affects only the Code Generation process. This means that the Debug version will set some compiler flags, which might enable some runtime checks in the libraries that were included and it also might disable binary optimizations.

However, independent of whether you compiled a Release or a Debug version, you can start your executable with a debugger attached or without one. The debugger running on the release version will usually not give you as useful results as on the Debug version, as the Release version might optimize your code by removing some variables or unnecessary code. However, it is still possible to debug the release version and set breakpoints etc. So for maximum performance you should switch to Release version and then choose "start without debugging" (in the debug-menu)