The API used for getting a screen point in the world is thru a ray using ScreenPointToRay, then using Ray.Origin to find the world point. This returns a unit ray, but why? There are no use cases for a unit ray, so why does the API return a ray instead of a Vector3 position and direction?
Adding Camera:ScreenPointToVector3() and Camera:ViewportPointToVector3() makes more sense then returning a ray that you can not use anyways
So, from what I understand, you want to avoid using :FindPartOnRay and its derivatives when detecting which part your mouse is pointing at? If so, there is already an archaic method for that. Rays are more flexible and can be used to selectively filter out certain models or individual parts, or only include certain objects in your game. They will also be usable with WorldModels once they get released, which is something you cannot implement with what you are proposing.
Nope, basically I want a method that returns Camera:ScreenPointToRay().Origin, but without creating the ray first
I’d be wary of API bloat here. I wouldn’t be in favour of adding those methods, as it’s trivial to get said Vector3 already.
To respond to your comment about how the Ray functions ‘have no use cases’, I highly disagree. I’ve used those functions on plenty of occasions, and the alternative is doing a lot of maths by hand. I don’t consider the Ray object to be a hindrance; as you said:
it’s super simple to get the position already.
This is more for efficiency reasons. Why make it return a ray if you can’t use it and will have to make a new one anyways?
There isn’t an efficiency problem here.
In terms of developer experience, you’re just indexing one extra property after a function call. It’s only three characters shorter:
Camera:ScreenPointToRay().Origin
Camera:ScreenPointToVector3()
and the proposed function itself only serves one specific and inflexible use case.
In terms of code performance, the overhead of creating that Ray object is negligible (and might even be eliminated in the future, depending on how Luau optimises code). Whatever you’re doing in your code will be a lot more intensive than one object being allocated.
But it’s kinda like doing local Vector = CFrame.new(0, 0, 0).Position, yeah it works and you get the result you want, but why not just do it directly and avoid creating an object that never gets used every frame
Because it’s not a large enough problem to warrant the engineering time required to add two new functions to the Roblox API that serve extremely specific purposes, in order to avoid an overhead that barely exists and typing three characters?
I don’t think it’s worth it when considering what benefits it would bring.