I have authored a tool for importing Spriter animations into UE4. Each part of the animation is a SpriteComponent. Everything I’m talking here is about 2D PaperSpriteComponents and “plane meshes”
I know at the moment the sprites are not being batched.
But the collision calculation performance is also really really bad !
My setup:
several sprites with custom geometry (not should be very expensive, only some extra vertices to the quad, hand made).
set all the sprites to overlap only with Pawn -ignore the others- and the Pawn to overlap only with WorldDynamic -ignore the others-
then, when I have on the screen a Pawn entity (made of ~10 spritecomponents) and ~10 WorldDynamic entities (made of ~4 spritecomponents) my Samsung Galaxy 3 performance go down … i got spikes of ~20 fps and the time of “Game thread” is increased by a lot.
If I deactivate the collisions (setting ignore to all in every sprite) I get a noticeable performance boost (like very stable 62 limit fps with spikes to 50)
If no other method is proposed, I will have to rely with very imperfect collision using only 1 poly per each entity -instead 1 poly for each part of the entity-.
Questions:
How can I profile the collision performance in the device? and see where are the bottlenecks?
How can I improve the performance of several collision overlap testing in screen?
Can I tune the time between overlaps/collisions updates ? What triggers exactly this function -so I could look if im doing something wrong-?
Is this a workaround for the flipbook having no sprite based collisions? So are you having a sprite component for each frame of animation in the same actor and then switching though them to be visible frame by frame? OR are you using each sprite as a separate part of the same object (i think from your post that its the latter). It might be more performance friendly if you made your collision out of capsules and boxes. I know it’s only simple custom geo but its still geo collision which is known to be more expensive.
Also have you constrained the physics engine to be 2d? it might cut physX testing in 1 dimension and help things.
I haven’t played too much with the 2d collisions so feel free to ignore me though!
My entities are composed by several sprites which are the parts of the animation. So I do not use flipbooks. I use the sprite collision polygon, adding some vertices -but not a lot-.
I will tray switching to boxes for testing if the penalty is due to geometry complexity!
Regarding to constraining physics, I think i have constrained physics in Y plane in project settings and I think I have checked “Can use 2DPhysics - Box2D” to true in project settings also. BUT I think each sprite has checked the “use 3d physics”
Also, each sprite of my entities is tweened -driven by a UTimelineComponent-, so every frame every sprite can potentially -and likely will- update its transform
There are two physics systems here. Box2d and PhysX. It’s not immediately clear where the settings from one or the other are set. I would probably stick to just physX for now as it could be possible that box2d is also colliding and causing performance issues. So maybe uncheck the box2d option and also uncheck use 2d as then the physics will be 2d physX.
I mean the standard physics in unreal engine which is the nvidia physX engine under the hood. There is an option from 4.4…
"New: Simple 2D Physics Constraints
The engine now supports easily constraining 3D physics objects into a 2D plane. This can help when making 2D games like side-scrollers."
Looking here…
…I see that yes you were right in having use 3d physics. I got confused with the physics 2d ‘constrain to plane’ .The forum docs say…
“Use 3D Physics: Collision geometry will be generated for use with PhysX. The 2D collision geometry defined in the sprite will be extruded to “Collision Thickness” units deep in the perpendicular axis to make 3D collision geometry.”
So I would have Use 3d physics ON and then in the physics section of the actor, have “Locked Axis” set to be the plane that your 3d world is aligned against. I would like to test this myself.
I’m sorry I meant disabling it (the Use 2d Physics) … currently I have it enabled. So It might help … the other options I think I have them already set (constrining 3d physics to lock the Y-axis plane, applied in project settings)
To sum it up: Collision calculations + overdraw + other calculations in scene = no no.
You should never have too many sprites in your screen, Try creating a per distance culling so if they get too close or too far they are hidden.
Overdraws are not a problem … the render geometry is pretty simple (sprites) and there is not alpha blending at all -all materials are unlit and masked opaque, only 1 texture sample-.
Problem is in “Game thread” and disappears when I turn off collisions so no rendering issues -my scenes are pretty simple-.
It would be interesting knowing how the “broad phase” of collisions is configured and knowing if it can be tuned someway
Box2d is still in experimental phase in Unreal so it does not work well.So from my understanding what they did was to lock the “regular” Unreal physics engine and costrain it to whatever axis you want.In our case is the Y axis.It still has its issues Lock 3D physics on a 2d Axis Issue - World Creation - Epic Developer Community Forums though.
As for mobile performance unreal is not optimized for all devices.They have a list that have already tested and approved.And to be honest our telephones (i have an LG 4XHD) are 3 to 4 times less powerful that the ones that are out right now.I do not believe that is realistic for us to develop anything for this kind of devices using Unreal.I tested something that was 10-15 fps at my phone to a friends S5 and it was a rock solid 60fps.Huge difference.The new K-1 chip from Nvidia is rumored to have ps3 if not better performance!
I am using spriter as well for all my animations!If you could help me out to import my stuff in Unreal(I HATE EXPORTING PNG’S AND USING TEXTUREPACKER) i will be for ever grateful!
Yesterday I tested without Using 2D physics and it seems it made no difference at all. I have to test changing all my fully custom geometry to a basic geometry and see what happens …
