The Infinity Blade Forums Have Moved

We've launched brand new Infinity Blade forums with improved features and revamped layout. We've also included a complete archive of the previous posts. Come check out the new Infinity Blade forums.
See more
See less

[possibly Physic issue] why it's that slow?

  • Filter
  • Time
  • Show
Clear All
new posts

  • [possibly Physic issue] why it's that slow?

    Hi guys,

    I've 200 boxes with simple physics on them, and a ball with simple sphere collision. The ball is just running on boxes. Simple, really.

    I have 20fps on iPad device. I aren't using any dynamic light, collisions are simple (Box + sphere)...I spend all day with box and sphere properties and still I've 20 fps.

    I will be grateful if someone can help me out with this. Or maybe physics is just slow and Epic need to optimize it.

    Basically there will be a lot of people who will want to make physics games using UDK - it would be nice if physics will be fast enought.

    Screens from profiler:

    Uploaded with

    Uploaded with

    Uploaded with

    Uploaded with

    I will be really grateful if someone can tell me what's wrong...

  • #2
    still trying to get this to 30 fps ;/
    I'm using Kactors for my Block (tried simple StaticMeshActors, DynamicSMActors) I've only one tick there that have one if statement...

    I've deleted 70% of my blocks and now I've 30fps. UDKM can't render a lot of blocks. My game won't be playable now because I need 300 boxes there

    UDKM doesn't have problem with 8k tri skeletal mesh with bones but it does with boxes...we aren't able to create Angry Birds in 3d I guess :P (or maybe there is an magic render check box that will speed things up)


    • #3
      200 objects is a lot to process, especially for the limited technology of the iPad which is strained as it is. You need to use things sparingly, 3D physics are expensive.


      • #4
        Well i cant agree with you. 200 boxes arent much for iPad. There is a lot of games that have much more objects. I think that Epic will need to optimize the engine or there is some preference that i arent using


        • #5
          Can I have an example of such an app that I can run on the iPad, entirely 3D physics based?

          What you are trying to do is generate over 200 3D physical objects that interact on a perframe basis. Also, it's worth noting that the box and sphere collision model is not the most optimized one in the UDK. Sphyls are the best choice. But still, you won't get away with 300 objects, for such a dynamic actor count, you should be happy with 20 FPS.


          • #6
            Curious these blocks doesn't have physics. They have PHYS_NONE (+ never become dynamic). The only one job for UDKM here is to render the scene.

            There is only 2 physical assets there - ball and plane.

            That's why I'm little bit confused.

            As for the games - just check App Store and search for 3d games.

            Can I change block from Static to Dynamic in run-time?

            I've tried to render them as static meshes only - (without dynamic features) - still 20 fps. That is weird because it's 5k tri to render.


            • #7
              Actor count. Always will be an issue.


              • #8
                It's not about the triangles, but it has to do with the iPad not having a gpu or a lot of memory.

                Can you combine them all into one mesh? Maybe fake the physics by with animations & even a skeletal controller? Might do the trick for ~50 boxes...

                Edit: You might want to read up on complexity in terms of computer science and programming. The optimal solution is obviously the least complex solution -plainly speaking, the least bit operations. Think of what you're doing here, you want to do whatever it is that you're doing in reference to as few dimensions as possible (same goes for problem size). For Example simply compare the performance vs 1, 10, 100, and 1000 boxes, which represents 4 dimensions of problem size (i.e. 10^0, 10^1, 10^2, 10^3). Right off the bat, 200 boxes to render * 200 boxes/spheres * 200 positions to update per frame vs 50 boxes is 200^3 vs 50^3... 200^3 - 50^3 ~= 200^3.

                Bonus: If an exponent makes something more complex by geometric increase, logarithms go the other way. A basic log example is assigning to each Musical Note (e.g. c3, d3, e3, ab4, c5, d#6 etc...) its particular frequency.


                • #9
                  yeah you guys are right. I'm trying to optimize it but I'm not sure which way can I go. My gameplay needs boxes there. Player can swap finger so the boxes will go up, and ball will have less space to roll on. The goal is to close ball in couple of boxes.

                  Can you combine them all into one mesh?
                  I don't think so. Player can swipe up/down, or left/right.