Is this faster then using raycast?

Unity Engine
1

Im curious as to if this code, is faster then using raycast from the mouse?

This is the code that i think is faster:

transform.position = Camera.main.ScreenToWorldPoint(new Vector3(Input.mousePosition.x, Input.mousePosition.y, 10));

then something like this:

function FixedUpdate() 
{
    var ray = Camera.main.ScreenPointToRay(Input.mousePosition);
 
    var hit: RaycastHit;
    if (Physics.Raycast(ray, hit)) 
{
        var point: Vector3 = hit.point;
        point.y = 1.5;
        transform.LookAt(point);
        transform.position = (point);
}

Thanks :smile:

2

The provided code snippets do different tasks.

3

:O, they both move an object from the mouses position? or atleast that is the task im using it for so that is the task i need to know wich one is faster for.

4

No.

One moves the object to the mouses position at a distance of 10 from the camera.

The other fires a ray, and if the ray hits something then it moves it the position of whatever it hits while setting y = 1.5.

5

Ok so presuming, the floor(hit object ) object is 8.5 units from the camera, wich would be faster?

6

Even given that assumption the functionality of the two is different.

Assuming you’ve got the raycast setup to mimic the first one perfectly, that means you’ve gone and made half a dozen changes/assumptions to/about your project, as well as used substantially more code to achieve the objective of a one liner.

That’s huge and completely unnecessary complexity, go with the first one.

If it’s not functionally identical - go with the solution that provides the functionality you need.

Performance is irrelevant here - code/project complexity and maintainability is what you should be thinking about.

http://en.wikipedia.org/wiki/Occam’s_razor

7

Definitely.

Also, this gets called once per click/frame/fixed update. There is no point worrying about code that doesn’t run often unless you’re doing something really expensive in it.

8

NPSF3000 is correct. And in any case you aren’t dealing with massive numbers of things are you? Always optimise when the game is finished even if it means rewriting or redoing something.

9

Hell no, last minute optimisation is asking for trouble. Continually monitor performance on the target platform during development, and make measured decisions about where you’ll optimise and how. It’s far easier to keep performance acceptable than to make it acceptable after you’ve dragged your software through the mud.

“Premature optimisation is the bane of all evil” (or whatever the quote is) isn’t saying that you shouldn’t optimise until you’re functionally complete, it’s saying that you shouldn’t optimise before you fully understand what the problem actually is. Measure things, find bottlenecks, understand why the bottlenecks are they way they are, understand why they’re coded how they’re coded, understand how other code interacts with it, and then think about how to improve it. That’s assuming that it’s even a code issue - it’s just as likely that the problem is the content being shoved into your code.

As you can probably tell already, that’s not too painful if you’re doing it as you go. It’s a real nightmare if you suddenly have to start pulling things apart at the end of your project, or if you decide that the issue is actually the content and - oh crap - you need to modify 50% of your art assets, or redesign a level because it has to work with less/different assets, or whatever.

10

Thanks guys :), i had the first doing the same as the second so im going to use the second on a game simmilar to pillar snake :smile: