Announcement

Collapse
No announcement yet.

Physics or fixed vector movement?

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

    Physics or fixed vector movement?

    Greetings everyone. I am pretty new to UE4 and started with blueprint development. My first attempt was to create some sort of Break Out/Arkanoid game for my nephew (he wants to learn this as well). I started from the blank project with the default contents and, based on my knowledge of classic programming, created some blueprints like so:
    • BP_C_Pad - a character subclass that is controlled by the player;
    • BP_A_Ball - a simple actor subclass to be the ball. It has a sphere inside with a shinny plate material applied;
    • BP_A_Wall - another actor subclass to be the walls with some lamps. It has a box inside with a wall material applied and some lamps;
    • BP_GM_BreakOut - a game mode subclass to control some properties for the game.


    I have create two properties (or variables) in the ball actor to represent the velocity (a vector) and the multiplier (a float), so I can increase the speed by increasing the multiplier. So far, so good. My question is: I want the ball to go into some direction and to not reduce its speed when boucing in the walls. My first thought was to move the ball myself inside the Tick event handler and also calculating the new direction when a wall or the pad was hit. I did it and it worked, but I thought there should be a much better way. So, I tried the Add Impulse method, but the ball behave strangelly when hitting the wall (it did not bounce back. Instead, it kind of "glued" to the wall, it's even hard to explain).

    So, my question is: which is the best way (in UE4 terms) to achieve this behavior (bouncing and keeping the speed)?

    Here are the screenshots for the blueprints:

    Click image for larger version

Name:	levelBluePrint_eventGraph.png
Views:	1
Size:	158.2 KB
ID:	1170808Click image for larger version

Name:	levelBluePrint_initialize().png
Views:	1
Size:	146.3 KB
ID:	1170809Click image for larger version

Name:	levelBluePrint_prepareReferences().png
Views:	1
Size:	183.4 KB
ID:	1170810Click image for larger version

Name:	pad_eventGraph.png
Views:	1
Size:	230.0 KB
ID:	1170811Click image for larger version

Name:	pad_eventGraph.png
Views:	1
Size:	230.0 KB
ID:	1170811Click image for larger version

Name:	ball_calculateVelocity().png
Views:	1
Size:	185.9 KB
ID:	1170812Click image for larger version

Name:	ball_initialize().png
Views:	1
Size:	176.6 KB
ID:	1170813Click image for larger version

Name:	ball_throw().png
Views:	1
Size:	202.4 KB
ID:	1170814

    Thank you all for the advices and greetings from Brazil!

    #2
    Couple of hints regarding physics approach:
    - it's a good practice to have your physics primitives or mesh with collision geometry as a root component in blueprints. Right now you have a DefaultSceneRoot as root component, just drag Sphere_ball over it to make it root.
    - for "perfect" bounce without energy loss you need to make a custom physics material with 1.0 restitution. For this, right click in content browser and add Material->PhysicalMaterial. Restitution parameter tells how "bouncy" object should be, anything beyond 1.0 will loose energy during collision and above 1.0 will gain energy. Now you need to assign this material as custom physics material for your mesh. Just open static mesh in content browser and look for the CollisionPhysicalMaterial parameter. Check this guide for the reference https://docs.unrealengine.com/latest...wTo/index.html
    - the ball will be losing speed because of friction and this is normal. You could try to lower friction in physical material but that's not a best idea as it's necessary to properly process collision with object. To compensate velocity lose you need to have a tilt of the board itself, just as in real life.
    - do you have physics enabled on walls and ball? Do they have collision mesh?

    Final remark, accurate simulation of pinball or billiard is very difficult to achieve using PhysiX or other game physics engine, they are simply not meant for this. I'm not telling this to discourage you, simply for you to know that certain things won't work as expected. As an example:
    https://forums.unrealengine.com/show...r%29-just-once
    Youtube Channel

    Comment


      #3
      BoredEngineer, thank you very much for your answer. It helped clarify some things. The game itself does not resemble a pinball or billiard in any way. In the original game (Arkanoid - https://www.youtube.com/watch?v=Th-Z6QQ5AOQ), the ball keeps its speed or even increases it depending on the place the ball hits the pad. So, if the ball hits near the corner of the pad, the horizontal speed increases, while when hitting close to the middle of the pad makes the horizontal speed slow down. Of course, that part is pretty much artificial and I would have to apply corrections to make it behave like the classic game (or not, I will choose later).

      I have used the materials that come with the starter content. Is that a problem?

      And about physics, yes, I marked the options both in the ball and the walls. I will change the scene to remove the default object that is created. If possible, could you please clarify why is a good practice to remove the DefaultSceneRoot object?

      Thank you again for your time and help.

      Comment


        #4
        Originally posted by Italo Gomes View Post
        BoredEngineer, thank you very much for your answer. It helped clarify some things. The game itself does not resemble a pinball or billiard in any way. In the original game (Arkanoid - https://www.youtube.com/watch?v=Th-Z6QQ5AOQ), the ball keeps its speed or even increases it depending on the place the ball hits the pad. So, if the ball hits near the corner of the pad, the horizontal speed increases, while when hitting close to the middle of the pad makes the horizontal speed slow down. Of course, that part is pretty much artificial and I would have to apply corrections to make it behave like the classic game (or not, I will choose later).

        I have used the materials that come with the starter content. Is that a problem?

        And about physics, yes, I marked the options both in the ball and the walls. I will change the scene to remove the default object that is created. If possible, could you please clarify why is a good practice to remove the DefaultSceneRoot object?

        Thank you again for your time and help.
        I should pay better attention while reading I don't know why I thought it was about pinball as you clearly mentioned Arkanoid.

        I haven't used starter content in ages, not sure if there are any physical materials assigned to them.
        For Arkanoid you could use 1.0 restitution and 0.0 friction, see how it works. Make sure that your collision mesh is correct, you can enable it from the console using "ShowCollision" command.
        It's a good practice because anything connected under the root is allowed to be scaled, which is bad for collisions. Another part is all kinds of considerations engine does for physics calculation and it's done on the basis of hierarchy, if your root object is not physically simulated than the rest of the things might just not work or work partially.

        I personally wouldn't use physics for Arkanoid as it's hard to get re-creatable behavior as PhysX is not deterministic. At the same time, physics based Arkanoid is something rather unusual and can be very interesting or very frustrating to play

        EDIT: Could you post a gif of how it behaves? I use ScreenToGif to record these kind of things.
        Youtube Channel

        Comment


          #5
          Sure, I can. Which one would you like me to show? The original Arkanoid behavior?

          I was thinking... you said that the engine works based on hierarchy. In the ball actor, for instance, my root element is now the collision box, which is not "Simulating physics" (this option is unchecked).

          The direct child of this collision box is the sphere, which has that option checked. Should I check the same in the collision box? I did not check it because I thought it is just a square for the engine calculate if the objects are colliding.

          Thank you again for the great help and patience.

          Comment


            #6
            Then physics shouldn't work. If you want an object to be driven by physics, it's toot body should have a collision physics and have simulate physics enabled.
            I meant screenshot where object collides in a weird way.
            Youtube Channel

            Comment


              #7
              I've had reasonable success making a physics-based arkanoid game. Using physical materials with restitution 1.0 and friction 0.0 hasn't caused any problems. In typical arkanoid games the paddle behaves as if it's curved, even though it's actually not. Unless you really like the flat-paddle-that-bounces-curved thing, just make the paddle curved and let physics do its thing. That's how most recent clones do it.

              In my project I made the paddle physics-simulated as well, which is a bad idea if you want classic arkanoid behavior. Neither constraining the physics simulation to one axis in the settings, nor using a physics constraint to do it is perfect. The ball still loses a little bit of speed when hitting the paddle, though it depends on the mass of the paddle vs the mass of the ball. And of course if your paddle is simulated and the ball hits it from an angle, it will push the paddle sideways instead of bouncing off nicely.

              You shouldn't need or want the walls to be physics-simulated, unless they're going to move around. Just make sure their physical material is set correctly.

              You also don't need or want a collision volume and a static mesh. The mesh should have it's own collision set up in it's asset file. Also if your ball's collision is a cube it's going to bounce very strangely, no? The only component your ball blueprint needs is the ball mesh, which may as well be the root, it makes everything simpler.
              • Physics-simulated components don't care about their parent's movement, since they can't inherit their parent's movement and simulate physics at the same time. If you have two physics-simulated components in one blueprint, they won't be attached together in any way, they will behave as independent physics objects.
              • If you add a mesh or volume component as a child of a physics-simulated component and "Auto Weld" is on (it's on by default), the two components will be welded together and simulated as a single body, with the parent's physical properties.
              • A component must have it's collision set to Physics Only or Collision Enabled to actually simulate physics.
              My Website

              Comment


                #8
                Every time I think I am starting to understand things, you guys prove me I know nothing yet.

                Bored: nevermind about that. I found that it happend when the ball hit a particular place where the collision box did not cover (that is what happens when you do not pay attention to the sizes).

                -Ross: so, about the meshes: in my case, the ball is using the sphere and the pad is a combination of two spheres and a cylinder (I have zero skills in Blender or any other 3D software to create a pad myself). The walls are basically boxes. So, if I understood it correctly, I would not need any collision objects as these default meshes already have them, right?

                And about the movement, hmmm... I actually can make the ball move myself like I would if I were not using any engine at all, no problem with that. I just would need to know the location (and the face, in that matter) where the ball hit things so I could adjust the direction accordingly. For the walls and the pad I developed a blueprint interface called IColidable. So, when the ball hits something, I see if the cast to ICollidable works and change the X or Y direction vector. But for the bricks it is a little more complicated because I need to know where, in the brick faces, the ball has collided.

                Comment


                  #9
                  Yes, the default meshes already have collision set up.

                  For future reference (after you learn a little bit of blender :P), this is what I meant by the mesh asset file, in the content browser:

                  Click image for larger version

Name:	Screenshot 2016-01-23 19.29.00.jpg
Views:	1
Size:	55.0 KB
ID:	1099279

                  If you open it up you get a screen like this. The blue wireframe is the collision mesh. You can transform it around however you want, add more, delete, etc. There's a few different basic collision options in the Collision menu. If you delete the collision mesh that's there and add a new one from the menu it will automatically try to fit your mesh. You can also import your own collision mesh from your 3D software.

                  Click image for larger version

Name:	Screenshot 2016-01-23 19.29.49.jpg
Views:	1
Size:	63.0 KB
ID:	1099280


                  Aha, OK. Are you using Unreal's hit events? If so then they give you the hit location, normal, normal impulse, etc., which should be enough to calculate your bounces I think? There's a little bit more, rather specific info in the "Hit" structure, if you break that open. I don't think I understand your setup enough to know what you need though.
                  Last edited by -Ross; 01-23-2016, 08:57 PM.
                  My Website

                  Comment


                    #10
                    Ok, I admit that you are correct about learning Blender. Just please give me time for that... this almost-40 software architect here has some available time limitations.

                    Actually I was only using the ActorBeginOverlap event, although the Hit event is a much better choice as it gives me a lot of details where the collision happened. But I noticed something strage. I removed the collision boxes as you suggested and also gave up using the physics simulation (I am going to handle the ball speed and direction myself).

                    When I made that changes, the events (Hit and ActorBeginOverlap) are not firing anymore. Now I am confused. The ball has only the sphere on it and the walls have the cube and three lamps each (to make some light effects in the environment). Should I use the collision boxes again as I am not using the physics simulation?

                    Oh man...

                    Comment

                    Working...
                    X