Announcement

Collapse
No announcement yet.

Generate overlap events option causes fps drop

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

    Generate overlap events option causes fps drop

    I currently have 50 actors of the same class that move on every tick. The function I use is to move them is ADD ACTOR LOCAL OFFSET, with SWEEP off and TELEPORT on. Each of my actors has around 20 scene components, which have no collision. I tried adding collision, but that brings up the time needed to execute the ADD ACTOR LOCAL OFFSET function by ~1.5ms. All of these scene components have the same root: 'Body'. 'Body' has collision. In order to execute code upon overlapping with another actor I have GENERATE OVERLAP EVENTS ticked to on for the 'Body', but that raises the time needed to execute the ADD ACTOR LOCAL OFFSET function by 2 or 3 ms. I tried turning GENERATE OVERLAP EVENTS off, and using BLOCK instead of OVERLAP for the collision with SWEEP on, but that didn't generate neither an OVERLAP event nor a HIT event.

    To sum up, the ms needed to execute the code of all my 50 actors is:
    5ms with GENERATE OVERLAP EVENTS set to on for the 'Body' and collision on for all my 20 scene components;
    3.5ms with GENERATE OVERLAP EVENTS set to on for the 'Body' and NO collision for all my 20 scene components;
    2.4ms with GENERATE OVERLAP EVENTS set to OFF for the 'Body' and collision for all my 20 scene components;
    1.7ms with GENERATE OVERLAP EVENTS set to OFF for the 'Body' and NO collision for all my 20 scene components;

    I can go on with no collision for the 20 scene components, but my main static mesh which is 'Body' has to have collision at all cost and an ability to generate either OVERLAP or HIT events.
    Is there an alternative to ADD ACTOR LOCAL OFFSET or GENERATE OVERLAP EVENTS?
    Thanks in advance.
    Last edited by MMitov; 03-14-2017, 09:44 PM.

    #2
    Ok, I managed to generate HIT events, with GENERATE OVERLAP EVENTS off, by making my main collision the root of the blueprint, because SWEEP only works with the root, but I have another problem. When I hit something my actor stops, because it is being blocked. Is there a way to generate the HIT event and then continue the movement trough the actor that is blocking it?

    Comment


      #3
      So, for now I left the actors with GENERATE OVERLAP EVENTS on. I noticed that the more actors of another class I have spawned, the more more ms the movement costs. So if I have 50 moving actors and 0 other actors the movement is reduced to 3.5 ms. But if I have 50 moving actors and 50 other ones(different class... they move as well but they have NO COLLISION), the movement costs 17ms, which is just unacceptable. I wrote the code that moves the actors inside of a c++ class and then just derived from that class so my actors are still blueprints. People in other forums said that blueprints cost more ms so I figured that would help me... but no. Does anyone have any Ideas?
      Last edited by MMitov; 04-11-2017, 08:27 PM.

      Comment


        #4
        Physics will always cause some level of fps drop;
        But teleporting is expensive operation, which makes things worse.
        I would try to apply forces instead or not simulate physics at all, beyond collisions, and use VInterpTo functions instead.
        | Savior | USQLite | FSM | Object Pool | Sound Occlusion | Property Transfer | Magic Nodes | MORE |

        Comment


          #5
          The thing is, I don't have any physics. Simulate physics is off at all times, and VInterpTo shouldn't make any difference, it returns a vector which has to be used by a SET ACTOR LOCATION function.
          Last edited by MMitov; 04-11-2017, 10:53 PM.

          Comment


            #6
            I don't know if you can use instancing for this task but worth a look at anyway

            https://www.youtube.com/watch?v=oMIb...Q1-_k&index=12

            Comment


              #7
              I don't think instancing will help me here, because the code process is the same. Instancing is quite handy when it comes to having multiple one typed static meshes in my actor, but even when I reduced the count of my actor's components by using them the ms stood the same.

              Comment


                #8
                Originally posted by MMitov View Post
                I don't think instancing will help me here, because the code process is the same. Instancing is quite handy when it comes to having multiple one typed static meshes in my actor, but even when I reduced the count of my actor's components by using them the ms stood the same.
                oh well sorry

                Comment


                  #9
                  No problem. I guess the only solution now is either to rewrite my blueprints in code, hoping that'll help(but that'll be a pure pain in the ***), or to figure out how to calculate my collisions without using overlap events and hit events.

                  Comment


                    #10
                    I figured it out, I found a way to handle my collisions without using neither overlap, nor hit events. This dropped the movement of my 50 actors to 0.4ms as opposed to 1.5ms like it was before. How I did it: First of all I moved my movement code in C++. Now, the interesting part, the collisions. I personally calculate my collisions by knowing the collision range(it's a sphere) of the objects that are going to get the events, when colliding with my moving actors. However, if you can't keep track of your actors real time, you can use Sphere overlap(it gives you the overlapping actors without needing GENERATE OVERLAP EVENTS). Just don't use it too many times per tick. Also, if you are going to have a large amount of actors that have heavy ticks(like... movement, rotation, tracing etc... happening every tick) write your actors in code. A function I had that cost 3ms in blueprints, cost 0.097 when written in C++. I hope I have helped someone in a similar situation.
                    Last edited by MMitov; 04-14-2017, 11:24 PM.

                    Comment

                    Working...
                    X