If I need to have a kinematic rigidbody2d follow something on screen, how important is it I use rigidbody.moveposition() instead of transform.position?
Also if moveposition is way better, am I supposed to use it in fixed update with a velocity or can I just set it in update?
It’s so much more of a hassle getting moveposition to work correctly by setting the velocity and stopping it when it’s at the right position, then just setting the transform.position.
I don’t really need physics except for trigger detection, but I need to increase my performance.
Setting transform.position will ignore certain physics events like collisions, so when colliding is an important aspect you will definitely want to use Rigidbody methods for moving.
Not sure why you find MovePosition more difficult than transform.position. It’s the same thing, except MovePosition uses the rigidbody’s interpolation, moves it fluidly and maintains physics. It’s also not the same as setting velocity.
It’s best to put alterations to physical bodies in the FixedUpdate, as that is called when physics is updated. This occurs more often than Update, so will be a small performance that is entirely dependent on how much you’re trying to do.
If performance is your concern, then can you get away with manual detection of overlap? That’d be faster than relying on the physics engine, especially if you’re only using unrotated boxes or circles. Will require more setup for you, but you can cut out a lot of unnecessary processing.
If you’re rotating and/or getting all fancy with your shapes, just use the physics engine and save yourself the heartache (You know, unless you enjoy learning tons of nitty gritty maths! Don’t let me stop you since it’ll only help! )
Because setting moveposition(position) like so doesn’t work. It causes the transform to lag behind a frame. (which might be solvable, check bottom of post, I dnno)
So my other option is adding a velocity to it, which is why it’s more difficult cause then not only does it have to move as fast as the camera, I also need to set the velocity to 0 when it’s near my desired position.
This works but I need to give it such a high speed to keep up with the camera that it’s constanly flying past my desired position, which makes it impossible to stop at the correct position.
I tried that already cause you mentioned it in my previous post, it’s just not viable.
For one I didn’t notice that much of a performance increase by keeping rects in a list and checking Rect.overlaps.
It made things alot more complicated then simply using the ontrigger functions.
I also use the boxcast and overlapcollider functions occasionally and I can’t do that without the physics system or rigidbodies.
But what I really need an answer too is if there’s a performance impact when using transform.position instead of rigidbody.moveposition, cause I don’t know anymore.
Does the rigidbody do extra stuff when setting transform.position causing it to cost more performance?
I’ve looked through every forum post and it’s either a guy saying “you marked it kinematic, so you can control it with the transform” or “you should always move a collider by it’s rigidbody even if it’s kinematic”.
So I have to wait for the next physics update for it to be correct? As in yield WaitForEndOfFrame?
FixedUpdate callback? Do they mean the regular fixedupdate function or is there some other callback?
And the note clearly sais it’s intended for kinematic rigidbodies.
So ye, I’ve been racking my brain on this for the past month and there’s just not enough correct information about it and nobody who’s giving a clear answer.
Clear answer:
Setting position via transform will have better performance. But this will also ignore any “enter trigger” events that would have been thrown by the physics engine.
So, you’re posed with two options as far as I can tell:
Use transform.position without a rigidbody and check overlap manually
Use rigidbody.moveposition, somehow deal with the frame delay that’s irritating you, and use OnTriggerEnter2D
Long winded muddy answer: ([TL;DR] I recommend option #2 with a hint of option #1 for educational purposes)
Honestly, I see little reason for you to use the physics engine here (but then I also see little reason to worry about the difference in performance between these options), because from what I can tell from your explanation you’re only going to suffer from the overhead that the engine brings with it. However, this also relies on your implementation of manual overlap detection being highly optimized and thus better than the already optimized physics engine which does more than you need. This is also the part where my knowledge breaks down because the physics may be using some additional heuristics to filter out checks that don’t need to be performed, saving time and thus increasing performance in certain situations.
If you want real-world proof of which scenario performs better, I suggest creating a test harness that will manipulate a few thousand bodies simultaneously. This will make any performance difference more obvious and measurable. I imagine a setup where you’d have the bodies follow your cursor on one axis only, and move them into a series of triggers/rects for verification that it’s actually working. If all bodies are exposed to the same circumstances, then you’ll effectively be compounding the time taken to perform the task, making it easier to measure. Goal here is to take what you’re testing performance on to the absolute extreme until differences can be seen. Also, make sure your manual implementation has completely eliminated use of the physics engine, so NO rigidbodies
TBH, I don’t suspect the performance difference to be all that great, but if you’re really curious and don’t want to rack your brain for another month with nothing to show for it you might as well go find out for sure with a concrete experiment.
Heck, I could be totally wrong here (again) and someone more experienced will show up with a better answer. There’s always that possibility too.
That is entirely dependent on your implementation. You could set up your own event system that mimics OnTriggerEnter… you just have to build it that way. If you’re throwing all of your logic into a single source file, then of course it appears more complicated (but probably isn’t, though complication of code is entirely subjective).
Hmmm, missed that part… look, lemme level with you for a sec; [rant] you should either be playing with the physics engine, or you should not be playing with the physics engine. If you want the niceties that come with using the physics engine, like those functions… then you’re gonna be playing by the physics engine’s basic rules. And Rule #1 of playing with physics: The Physics Engine moves things, not you. That’s the whole point of having it! Let it take care of all that messy business. You can tell it where to move things, but you need to let it do the moving part. Sadly, that means the object’s going to be a little bit behind where your code is at that’s doing the telling. You can circumvent this in a myriad of ways, from the fairly clean “yield return new WaitForFixedUpdate();”, to setting up complicated wait timers, to detecting when movement is complete, etc. before carrying on with what you had planned for when the object arrives at the destination.
Fact is, you can toss all that out the window and do all of that messy stuff yourself. The math doesn’t change between how it does it and how you can do it. Since you’re supposedly dealing strictly with box triggers and no proper collisions, you can bypass a lot of what the physics engine has to worry about.
Now, I may be biased here by not having all these niceties when I was first making games in QBasic and having to detect boxes/lines intersecting other boxes/lines through math I found online (and thank god I had an “online”), but trust me when I say the math for what you’re wanting is blazingly fast, even in DOS with a BASIC language on a POS processor. I mean, you wanna talk about making things a lot more complicated?
[/rant]
[TL;DR] Pick a side and stick with it. You’re only giving yourself a headache by wanting the physics engine (using physics functions) and, at the same time, not wanting it (moving things directly via transform). [/TL;DR]
Personal opinion as a closing remark:
Don’t worry about the performance difference, because doing things yourself (intelligently!) will always be faster… and more complicated. Just take your niceties and learn to deal with all their little quirks. You’ll get way more done in way less time
(You know, unless you enjoy learning tons of nitty gritty maths! Don’t let me stop you since it’ll only help! 
)