Getting the surface manually is a really expensive process and rays also already do that as far as I know. Can’t it also return the surface normal?
Not objecting to this as a feature, but xXxMoNkEyMaNxXx wrote a script that does this insanely fast.
http://www.roblox.com/Forum/ShowPost.aspx?PostID=132773082
“I get a speed that would allow ~21k calls per second, it’s the fastest function of this kind that I have ever made.”
1 Like
[quote] Not objecting to this as a feature, but xXxMoNkEyMaNxXx wrote a script that does this insanely fast.
http://www.roblox.com/Forum/ShowPost.aspx?PostID=132773082
“I get a speed that would allow ~21k calls per second, it’s the fastest function of this kind that I have ever made.” [/quote]
I know and I’m using it but it’s still not enough unfortunately. If only it could return the surface also.
Would it not also be good to have something like
part:GetNormalFromPoint(point)
which would also allow you to get the normal when it comes to other than raycasting.
“I know and I’m using it but it’s still not enough unfortunately. If only it could return the surface also.”
You probably want my “GetGeometry” function, which will return the geometry (faces, edges, verts), of the hit object (it even works on stuff like CornerWedgeParts and Terrain), from that you will be able to find the hit face and return it’s normal + verts. You can find it in this script:
http://wiki.roblox.com/index.php?title=User:XLEGOx/newdragger
1 Like
Stravant were you working on getting the newdragger to be one of studio’s default tools? Hopefully toggleable of course
“were you working on getting the newdragger to be one of studio’s default tools?”
No, it’s absolutely a power-tool, I don’t think that it belongs in the default toolset, at least in the form that I had it. I do have a constantly updated version of it available with some fixes in my Plugins now though.
[quote=“Merely”]Not objecting to this as a feature, but xXxMoNkEyMaNxXx wrote a script that does this insanely fast.
http://www.roblox.com/Forum/ShowPost.aspx?PostID=132773082
“I get a speed that would allow ~21k calls per second, it’s the fastest function of this kind that I have ever made.”[/quote]
This is misleading. 21k calls per sec actually isn’t a whole lot. Because that means the client would be frozen the entire time. So to put it into perspective, each call would take 1 / 21000 sec, which translates to roughly 0.05 ms. And let me just tell you, 0.05 ms is a whole lot. To put things into even more perspective, a raycast usually takes less than 0.05 ms.
So I took the liberty of testing his method against mine. I also took the liberty of optimizing mine as much as I could. For testing, I did 1000 iterations on each face of a cube, to make sure there is no bias. For extra information, I also scaled the results to the best result. Here are the results:
6000 iterations
Oysi: 76.98 ms (0.0128 ms per call) (1.41x)
Oysi Fast: 54.25 ms (0.0090 ms per call) (1.00x)
Monkey: 340.79 ms (0.0568 ms per call) (6.28x)
It might be the fastest he has made, but it is still insanely slow. As you can see, my optimized function runs more than 6 times faster.
For those who are interested: http://pastebin.com/ejXnFMM0
And for those who will start to complain:
- It does work off the assumption that the point is already on the normal. So if the point is not, it will not get the best normal. But that isn’t even advertised, and even if you do want to get the best normal, all you have to do is get the largest absolute component of the ‘dif’ and then return the normal for that component, negating the normal if the component is negative.
- It only works for cubes, but you can apply the exact same technique to everything else. In fact, stuff like wedges and cornerwedges are even faster and easier to calculate than cubes. I made a post on scripters forum as a reply to stravant’s post somewhere, where I included those as well.
As for the thread itself, I would like to clarify: The raycast function should not only give the normal, but also the distance as well. Any raycasting technique works by getting the ‘t’ of (orig + dir*t), and to do that it also needs to check the normals. Which means both the distance and normal are already calculated all nice and well. And I would dare say they are necessary to have for raycasting.
I propose:
local hit, pos, dist, normal = workspace:FindPartOnRay(…)
That way it works just as it currently does, as to not break any code. But at the same time, it also gives you the distance and the normal, for those who need that.
2 Likes
local hit, pos, dist, normal = workspace:FindPartOnRay(…)
I just need that. Would it be so hard?
I seem to remember a way to calculate the surface based on how close it was to the center of the part with each face being off center by 1 in its own direction. This was years ago I used to do this when I was certainly not as skilled as now for example, but I’d run a quick test on that, it might be what you’re looking for if I have remembered correctly.
1 Like
Idc how old this request is, I need it badly.
1 Like
[quote] [quote=“Merely”]Not objecting to this as a feature, but xXxMoNkEyMaNxXx wrote a script that does this insanely fast.
http://www.roblox.com/Forum/ShowPost.aspx?PostID=132773082
“I get a speed that would allow ~21k calls per second, it’s the fastest function of this kind that I have ever made.” [/quote]
This is misleading. 21k calls per sec actually isn’t a whole lot. Because that means the client would be frozen the entire time. So to put it into perspective, each call would take 1 / 21000 sec, which translates to roughly 0.05 ms. And let me just tell you, 0.05 ms is a whole lot. To put things into even more perspective, a raycast usually takes less than 0.05 ms.
So I took the liberty of testing his method against mine. I also took the liberty of optimizing mine as much as I could. For testing, I did 1000 iterations on each face of a cube, to make sure there is no bias. For extra information, I also scaled the results to the best result. Here are the results:
6000 iterations
Oysi: 76.98 ms (0.0128 ms per call) (1.41x)
Oysi Fast: 54.25 ms (0.0090 ms per call) (1.00x)
Monkey: 340.79 ms (0.0568 ms per call) (6.28x)
It might be the fastest he has made, but it is still insanely slow. As you can see, my optimized function runs more than 6 times faster.
For those who are interested: http://pastebin.com/ejXnFMM0
And for those who will start to complain:
- It does work off the assumption that the point is already on the normal. So if the point is not, it will not get the best normal. But that isn’t even advertised, and even if you do want to get the best normal, all you have to do is get the largest absolute component of the ‘dif’ and then return the normal for that component, negating the normal if the component is negative.
- It only works for cubes, but you can apply the exact same technique to everything else. In fact, stuff like wedges and cornerwedges are even faster and easier to calculate than cubes. I made a post on scripters forum as a reply to stravant’s post somewhere, where I included those as well.
As for the thread itself, I would like to clarify: The raycast function should not only give the normal, but also the distance as well. Any raycasting technique works by getting the ‘t’ of (orig + dir*t), and to do that it also needs to check the normals. Which means both the distance and normal are already calculated all nice and well. And I would dare say they are necessary to have for raycasting.
I propose:
local hit, pos, dist, normal = workspace:FindPartOnRay(…)
That way it works just as it currently does, as to not break any code. But at the same time, it also gives you the distance and the normal, for those who need that.[/quote]
Yeah, congratulations. You managed to compare two completely separate things. His is a convex normal solver. His works for everything as long as it’s convex, meaning that it works for everything in ROBLOX, meaning it allows you to make custom convex meshes to test for normals. It’s no wonder your code is faster. Did you even look at his code? http://pastebin.com/sXZ9FTNz
EDIT:
Just realized how old this is, Sorry.
1 Like
@AxisAngle
Except the thing is, you could check for every object in roblox with the same technique I used in mine (which is worth mentioning that I already stated in the post, as I predicted a response such as yours), and still get the same 6x better speed. So your argument is quite flawed. However, don’t get me wrong. I’m not boasting over my code. Instead, I’m proving that monkey’s doesn’t actually do it “insanely fast” and that it being “the fastest script of that kind that monkey has ever made” doesn’t necessarily make it all that fast.
This is something that would be really useful 
I find myself wanting this for simulating a number of things. Like bouncing.
1 Like
I still want this.
Thanks for bumping people.
1 Like
[quote] I still want this.
Thanks for bumping people. [/quote]
2nd this.
Due CSG parts, this could be useful…
Exactly B)
This should be implemented as its own method, I don’t want the surface normal calculated if I don’t need it
This may or may not be enabled now.
I don’t know enough about raycasting to know how to test if it’s enabled, but I do know a flag called “RaycastReturnSurfaceNormal” was enabled today.
[size=1]also accidentally thanked OP but whatever[/size]