Announcement

Collapse
No announcement yet.

Instant Static Mesh gravity/physics?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Instant Static Mesh gravity/physics?

    Is it not possible to use ISM with gravity and simulated physics? I can't seem to find a recent answer on this question.

    #2
    Yes it is possible. You just need to make sure the static mesh is connected to the scene component and apply physics to the static mesh. That should work. If it does not you need to specify what you are talking about just a little more.

    Comment


      #3
      By "instant" do you mean "instanced" ?

      Comment


        #4
        No, Instanced Static Meshes don't support Physics.

        Comment


          #5
          Originally posted by jwatte View Post
          By "instant" do you mean "instanced" ?
          yes, typo


          Originally posted by Milachi Productions View Post
          Yes it is possible. You just need to make sure the static mesh is connected to the scene component and apply physics to the static mesh. That should work. If it does not you need to specify what you are talking about just a little more.
          Originally posted by Raildex_ View Post
          No, Instanced Static Meshes don't support Physics.
          Right now I am attempting to apply orbital velocity to 1000 or so shape_sphere meshes (think planetary rings)i, of which are 4 different actors. I thought that the point of instanced meshes was to quickly render the same object many times which I think would help in the current project.

          I know how to do this via setLocation of the ISM, but not with addForce, which I believe I need physics for.

          Is there a way to do this with physics and application of force to orbit a point, or is it more efficient to orbit via setLocation increments on the tick (current working method), and is the difference in performance for something like this between ISM and SM going to be noticeable?

          Comment


            #6
            If you can just compute the correct position of the shape closed-form, that is going to be a lot more efficient than doing it with physical simulation.
            Even if you don't use collision detection, physical simulation is a lot of overhead per moving body.

            Also, if you intend to run collision between 1000 different bodies, that might in itself end up being a significant time consumer... and if all those bodies pile into the same area, you actually get 1000*1000 interacting bodies, which is 1000000 joint constraints to solve, which will end up taking all the CPU.

            Comment


              #7
              Originally posted by jwatte View Post
              If you can just compute the correct position of the shape closed-form, that is going to be a lot more efficient than doing it with physical simulation.
              Even if you don't use collision detection, physical simulation is a lot of overhead per moving body.

              Also, if you intend to run collision between 1000 different bodies, that might in itself end up being a significant time consumer... and if all those bodies pile into the same area, you actually get 1000*1000 interacting bodies, which is 1000000 joint constraints to solve, which will end up taking all the CPU.
              I'm shooting for orbital simulations more so than collision, but what is the difference in CPU usage between
              1: letting an object fall by gravity
              2: using a setLocation tick to achieve the same movement?
              Last edited by Skifree; 02-23-2017, 02:20 PM.

              Comment


                #8
                Pushing an object into physical simulation may be 100x more expensive than just placing an object based on a closed-form formula (i e, use sin(rho) and cos(rho) to get X and Y)
                That being said, pure physical simulation with no interaction between the objects is not terribly expensive -- I don't know how many percent CPU you'll save on 1000 items.
                But if SetPosition() works and physics doesn't, that's going to push you into that particular direction I think :-)

                Also, the physics simulation isn't stable like an analytical Runge-Kutta 4th order solver. It's more likely to be an over-relaxation iterated matrix solver, where each step is just a first-order Euler constraint. So the physical simulation will not generate stable, elliptical orbits if all you do is start with position/velocity and a per-frame gravity vector towards a center.
                Last edited by jwatte; 02-23-2017, 05:17 PM.

                Comment

                Working...
                X