Most likely causes for linearCastPhantomCast and collision queries achieving poor performance

Most likely causes for linearCastPhantomCast and collision queries achieving poor performance

I am in need of a more experienced user's input on a particular issue of having to optimize an engine that's used for multiple platforms.

In all other cases but one, the internal havok code performs well (e.g. the hkpWorld::stepDeltaTime(..) takes around 1 ms ) while on the platform I work with it oscillates wildly between 5 ms and 80 ms. I used a profiler and it seems the problem is related to the collision system (i.e. the hkpContinuousSimulation::collideInternal method tends to occupy 90% of the whole world step). Since this engine has a gigantic code base and considering that on other platforms the Physics performance is pretty much decent, what are a few good place to start investigating for a bottleneck? 

As an additional information pertaining to this issue: it can happen that collision queries involving phantoms are really eating up a lot of time. Is there any known/reported issue when such a scenario is likely to occur?

publicaciones de 3 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Hi Teodor,

I would have said that a good place to start investigating a bottleneck is to profile your code so thanks for already giving this a go.

To further narrow in on which part of collideInternal() is taking so much time try running your application connected to the visual debugger and open up View->Windows->Perf Summary Text. This displays a hierarchy of labelled timers so you can further narrow down on which function is hogging your resources. If the label doesn't make sense or you can't find where the timer is created in code (which is likely since PCXS is mostly headers) we should be able to tell you which function it's coming from.

By the way, what platform are you having problems with?

As for phantoms eating up alot of time, they are supposed to be the optimisation for physics queries. They are meant to limit the area (and therefore the number of object) which is being queried, so a large phantom covering large area wouldn't create much of an optimisation. Also callbacks update a phantom whenever a shape has entered or left its area of interest, so a lot of objects are entering/exiting your phantoms each frame might be causing this.

Amy Developer Support Engineer Havok www.havok.com

First of all, thanks for the helpful insights.

Cita:

Havok_Amy escribió:

To further narrow in on which part of collideInternal() is taking so much time try running your application connected to the visual debugger and open up View->Windows->Perf Summary Text. 

By the way, what platform are you having problems with?

I've enabled the Perf Stats logging for the VDB and got just a few footprints of some timed Havok-related sections:

 Debug build. Timers unreliable (1)   0.000  (1)

 >RayCstCached (17)                    4.490  (17) 

checkSupport (1)                     0.053  (1)

 >updateCharacter (1)                  0.602  (1) 

>Physics (6)                          0.070  (6)

 >PostSimCb (2)                        0.430  (2) 

UpdateBeforeCD (0)                   0.000  (0) 

rcHeightFieldCoarse (0)              0.000  (0)

In the thread0 monitor widget (the Physics updates are ran on a single thread due to otherwise poor performances), I could scoop some other elements: 

Whole step takes 8ms with approximatively 50 scatered shapes in the scene

SCS::castRayWithCollector/RayCastquery::processLeaf takes around 0.5ms

//RayCstCached takes 1.8 ms

//RayCstCached/rcCapsule 0.002 ms

////RayCstCached/rcList 0.9ms

//RayCstCached/rcHeightFieldCoars 0.05ms

etc..

Lastly, a colleague of mine got a nice set of information from his console feedback:

I/O: hkNativePackfileUtils.cpp(479): [0x26A8CC12] Warning: Found meta data in packfile. Consider saving without metadata to reduce filesize
I/O: hkpStaticCompoundShape_Internals.inl(477): [0x6C407E42] Warning: Found a child shape container without a bounding volume. This can be slow.
I/O: hkpRigidBody.cpp(329): [0x458A1BB2] Warning: Shape key storage insufficient to store all possible branches. This may cause truncation of the shape key information.
I/O: hkpSimpleShapePhantom.cpp(186): [0x5FE59C18] Warning: Phantom queried for collidables without call to ensureDeterministicOrder(). The result is potentially nondeterministic.
I/O: hkpRigidBody.cpp(329): [0x458A1BB2] Warning: Shape key storage insufficient to store all possible branches. This may cause truncation of the shape key information.
I/O: hkpBvTreeAgent3.cpp(377): [0xAD345A23] Warning: Peformance warning: hkpBvTreeShape::queryAabb() returned more than 256 hkpShapeKey hits.

It seems that something is wrong with the shape keys, but I can't really ponder what and why would it lead to such an inconsistent behaviour. The platform I'm trying to debug is the WiiU (on other platforms, the simulation is consistent, constant almost). Juding by the console output, perhaps the collisions are performed nondeterministically and even between objects that shouldn't be tested.. but this is just a guess and also a question that I end up with. 

So, all in all, does this lead towards an inconsistent or invalid export procedure of the Physics objects, or does it more obviously relate to the actual update logic in the engine's code?

Best regards,

Teodor

Deje un comentario

Por favor inicie sesión para agregar un comentario. ¿No es socio? Únase ya