What is the relation between an actor tick and its components' ticks?

What is the default and changeable relation between an actor’s tick and its own components’ ticks in term of order and if any dependencies of one on the other?
In other words, is the default UE4 method is to tick an actor then move to ticking each of this actor’s components before moving to any other actor, or does the engine just deal with all tick-able UObjects in a mishmash manner, if no prerequisite tick dependencies already set?

+1… Yeah it’d be good to know more about this as the docs don’t go into enough detail… From past experiments, Collision on Components that move (part of a vehicle etc), hit frame rate way harder than Visibility or Tick alone… So stopping Tick or increasing Tick-Interval on Components may not mean much if Collision is still active, as Collision seems to be active on Components set to < NOT Tick at all >, which seems counter-intuitive…???

@Alzaher Both actor and component have the option to select a tick group, so for example you can set the actor to tick on post physics, and keep the components default setting of tick on during physics state, and in this case the components get a chance to tick before the actor. The order of things within a tick group looks like random, hence the tick dependencies logic helps you to design an order for ticks you expect them to fire. Attached components (eg scene comps) are setup attach parent as their prerequisite.

@ClavosTech You can turn off collision on objects so they likely end up not contribute to this work at all. You can also try some optimizations on the body in order to reduce the actual processing requirements to deal with said object. Collision primitives most likely cheaper to calculate, compared to complex shapes. As for the tick intervals, it actually only depends on the code you have put in your tick. if you have nothing to be processed on every tick, it makes no difference what interval you choose. You might as well turn it off completely to save a function call somewhere deep in the engine code.

Yep that’s true, that’s why I wrote: Collision on Components that move (part of a vehicle etc), hit frame rate way harder than Visibility or Tick alone… But it would have been useful to know this from the DOCS in advance. Especially to know that Collision has a far greater benefit than messing about with Tick or Visibility etc. Maybe that’s more obvious to some, especially Engine Contributors. :stuck_out_tongue: … But I expected a more holistic benefit, where disabling both Visibility + Collision would bring some big benefits. But actually it didn’t… It was just Collision… But the benefits there were huge!!! In a full scene it recovers 10-30 FPS, so its definitely worth it.

Started to work in that direction by adding ‘blunt’ box collision that gets switched on whenever an NPC uses a vehicle, but disabled whenever a non-NPC Player uses it. Right now, I use Get Actor Array Bounds to slim down the collision box, but it doesn’t work well (too wide / too high / too low of actual vehicle dimensions). So I’ve more work to do… Maybe manually iterating through all the visible meshes and calc’ing a more accurate collision and / or using more than one box collision will do it.

As this is for vehicles in constant motion, a master Tick is needed all of the time…Otherwise the movement is noticeably jerky / choppy. But if you know any way of cheating here, please share. :slight_smile: Thanks for the suggestions @Konflict

Thanks for responding. So it is safe to consider that attached components will always tick after their parent. That’s perfect.