Raycasting Outside of Workspace?

[CDDevelopment]

So we all know that we can raycast effectively as long as the parts/objects are a child of workspace, after all, it’s a workspace function.

But now with the added feature of ViewportFrames, there’s a new environment where visibly rendered parts exist. So far I haven’t found a way to use raycasting, region3’s or any kind of collision detection inside viewport frames, which is very important since I don’t want to have to have a copy of the viewport’s contents somewhere else just so I can raycast…

Is there a way to manually raycast? or is there a way to raycast and detect objects that are not descendants of workspace…

[1Joeb (joe)]

What is your end goal? There might be an easier way.

[colbert2677 (Dreamseeker)]

I’m pretty sure that the only relevance Workspace has to any of the Ray methods or the Ray constructor is that it’s where the methods are stored. Have you attempted to use the Raycast methods anyway within a ViewportFrame? I don’t assume it’d error.

That being said, I haven’t tried it myself and I don’t see anything that states the raycast methods can only be used within the Workspace.

See below.

[EmilyBendsSpace]

I’m pretty sure that the only relevance Workspace has to any of the Ray methods or the Ray constructor is that it’s where the methods are stored.

No, raycasts are done against the physics collision geometry of parts in the Workspace only. Parts in a viewportframe are purely visual, there is no Physics anything going in there, by design.

[colbert2677 (Dreamseeker)]

You are still able to use the Ray constructor, no? It’s just that physics aren’t run in ViewportFrames and thus the methods can’t be used.

Sounds like a workaround would have to be done, such as cloning the contents of the ViewportFrame to the workspace and then performing physics functions there, then translating that to the ViewportFrame.

[EmilyBendsSpace]

You are still able to use the Ray constructor, no? It’s just that physics aren’t run in ViewportFrames and thus the methods can’t be used.

The Ray constructor just takes vectors, it doesn’t know where your parts are. The issue is that parts in the viewportframe (assuming the vpf is not itself in workspace obviously) are not in the workspace, therefore not in the physics system’s octree, and therefore not able to be hit by rays.

[IdiomicLanguage]

You could use my GJK distance and intersection module. Here is a post where I explained how to use it with a part and a ray:

Is it possible to get all parts intersecting a Ray?

I have a GJK distance and intersection implementation. That should work until a c++ implementation is made. I ran into issues like this years ago (particularly when working on my navigation mesh pathfinder). Below is pretty much all the code you need. You could remove the spherical check, since the maximum number of parts FindPartsInRegion3 returns is relatively small. I’d recommend replacing FindPartsInRegion3 with my AABB structure if the parts wont be moving around too much. --< BEWARE >--…

Here is the github page in case you want to contribute:

GitHub - idiomic/GJK-3D-Intersection

and here is the model:

GJK - Roblox

And finally here is a post where I wrote and tested some code to find collisions between a part and sphere:

Checking if a part is touching another part every .1 seconds?

I’ve tested two ways of doing it and found both to be reliable. The first is using my GJK distance and intersection module. If you are not familiar with the Gilbert-Johnson-Kerthi algorithm, basically you make a “support” function for each of the primitives to test (the part and the sphere in this case). The support function is called with a direction and should return the point on the primitive furthest in that direction. For a part, it will always be one of its corners. For a sphere, it will b…

The part and sphere collision test was faster than a call to print().