Apparently it isn’t… Even when out of the Frame the object is still visible which shouldn’t be possible.
7 Likes
They said they would not do so because Roblox is a 3D game, not a 2D one.
With that statement, I disagree, seeing they are used in interfaces and 2D games (like many recent ones).
1 Like
Really? It seems like you’d want to make your platform as good as it can be I do not see any downside to this really.
1 Like
Apparently it’s a math issue that ROBLOX doesn’t want to deal with (because calculating clipping for squares is MUCH easier than calculating clipping for rotated squares, and the GUI is updated every frame, so more math = bad)
Rotated parts INSIDE of squares shouldn’t be an issue (you just check if any corners are outside of the box), but I believe they didn’t bother with that because they didn’t solve clip descendants for rotated parts themselves. I don’t know if ROBLOX has considered this, but I assume using a local axis (that way the rotated part is actually a flat square) for clip detection would work out nicely.
2 Likes
The reason that this wasn’t handled at the time is the case of rotated objects inside of rotated objects.
Clipping rotated objects inside of unrotated objects isn’t particularly hard (But still non-trivial), but once you introduce a rotated clipping region it becomes a lot more tricky to implement things efficiently, and it would have significant performance implications that would not be immediately obvious to the developer using it.
I’m sure that the feature will come eventually in some form for the sake of completeness, but it’s definitely one of those “eventually” features that I don’t expect to see it the near future.
1 Like
[quote] The reason that this wasn’t handled at the time is the case of rotated objects inside of rotated objects.
Clipping rotated objects inside of unrotated objects isn’t particularly hard (But still non-trivial), but once you introduce a rotated clipping region it becomes a lot more tricky to implement things efficiently, and it would have significant performance implications that would not be immediately obvious to the developer using it.
I’m sure that the feature will come eventually in some form for the sake of completeness, but it’s definitely one of those “eventually” features that I don’t expect to see it the near future. [/quote]
How feasible would that local axis thing be to make rotated parts become normal, flat boxes? You’re smart, so that’s why I’m asking.
1 Like
Clipping isn’t as easy as you’re making it out to be: A GUI can be visible in a clipping parent even if none of it’s vertices are inside of that parent, and it can also be visible even if none of the parent’s vertices are inside of it. And, the hard part is that for an arbitrarily rotated hierarchy of GUIs, you may end up with an effectively arbitrary convex polygon clipping region for a given GUI. In one approach you would end up doing a bunch of operations of clipping an arbitrary polygon with a a bounding box (Because when you clip a box against boxes multiple times, it will end up as an arbitrary convex polygon), which is way more expensive than the clipping that has to be done right now.
2 Likes
Thank you stravent for addressing this. The thread should be locked now as it got a proper answer.
1 Like
My extremely poor knowledge of OpenGL made be come across glScissor. Could such a thing not be used for clipping?
1 Like
This is not my area of expertise either, so, I may or may not be wrong on some of these details, but:
Using glScissor will only help you for for non-rotated clipping regions. Unless you want to use a transform-to-local-space + render-to-texture approach with glScissor, where using a render-to-texture for every single rotated GUI object is a very inefficient solution. Also, it’s a per-pixel test. I believe that it’s faster to do the math to just get the clipped region yourself before passing it off to OpenGL / DirectX than have them do the clipping especially way faster if the majority of the pixels for a given object will eventually end up being thrown away (10000 x 10000 frame with only a 100x100 portion visible, you can see how clipping ahead of time before passing the rendering layer the triangles would be much better).
1 Like
[quote] This is not my area of expertise either, so, I may or may not be wrong on some of these details, but:
Using glScissor will only help you for for non-rotated clipping regions. Unless you want to use a transform-to-local-space + render-to-texture approach with glScissor, where using a render-to-texture for every single rotated GUI object is a very inefficient solution. Also, it’s a per-pixel test. I believe that it’s faster to do the math to just get the clipped region yourself before passing it off to OpenGL / DirectX than have them do the clipping especially way faster if the majority of the pixels for a given object will eventually end up being thrown away (10000 x 10000 frame with only a 100x100 portion visible, you can see how clipping ahead of time before passing the rendering layer the triangles would be much better). [/quote]
I am aware of it only working for non-rotated clipping areas, but that is an improvement over non-rotated clipping and instances? Although you are right about it being a waste, unless you were to ignore all elements which could never clip, and doesn’t the current system do something like this, anyway?
Well what about fragment shaders? (I know little about these, either, but its an idea)
1 Like
“Well what about fragment shaders?”
You definitely don’t want to be running a fragment shader for millions of pixels that aren’t even inside of the clipping boundary just to tell you that when a few hundred instructions worth of code could have told you the exact same thing.
1 Like
[quote] “Well what about fragment shaders?”
You definitely don’t want to be running a fragment shader for millions of pixels that aren’t even inside of the clipping boundary just to tell you that when a few hundred instructions worth of code could have told you the exact same thing. [/quote]
Excluding all elements which cannot intersect with the clipping element would cut down on the number of pixels you need to use it for, and even then its only done once per update (Which, I admit, could be very rapid, but then again, its a feature you probably would want to use sparingly, anyway)
1 Like
Stravant is correct - the reason this feature is not implemented atm is the requirement to change the UI code to work with arbitrary convex polygons everywhere instead of axis-aligned rectangles.
We can’t use scissor rectangles since they don’t provide full clipping support anyway as mentioned above; the only complete solution that does not need convex polygon clipping is stenciling, but it would require us to de-optimize current rendering code that aggressively merges geometry for visible UI elements to avoid CPU overhead.
We may end up implementing correct clipping some day but it would require a carefully optimized approach that only switches to slow convex clipping when absolutely necessary.
6 Likes
This actually is really funny, I emailed roblox about this one week after rotating frames were out. Seems that they haven’t done nothing about it yet.
1 Like
Memory and performance concerns were the reason ClipsDescendants had no effect on rotated descendants in the first place.
CanvasGroups render at poor resolution on lower graphics settings and may not even render at all if the client doesn’t have enough memory to store the texture (and it will instead render a pure black frame in those cases). It isn’t a direct substitute for something like this.
Hey, a quick update to this. Back in August they confirmed that they were working on adding this feature but I haven’t heard of any recent updates about it since.
1 Like
Not what that release note is.
1 Like
Guess I missed this. Dissapointing 