Full In-Experience Release of CSG v3

Updates Announcements
#52

Thanks, I’ll also check my other assets for this issue with that setting. Previously a lot of other assets had this issue but somehow now they don’t have it. This one still has it.

#53

Update. We just (Monday) released an improvement to CSGv3 that should have an effect in both studio and in experience. This should significantly improve the speed on subsequent operations. Especially on large number of operation on same body. More to come.

6 Likes
#54

Should we post csg v3 issues here or on the “Csg has a new enginr, vroom vroom,”?

#55

I was hoping “speed on subsequent operations” would have an effect on my try to implement undiscovered-fog-of-war.
But it still lags and visibility clitches after a lot of SubtractAsync operations.
I already gave up on this implementation. But still have hopes.
My example:

Will this kind of SubtractAsync ever be supported?

#56

This could work, but you’ve got to help the engine out a little bit to get there:

  1. You can’t handle it as one big part. Inevitably complexity will build up and the engine will have to do more work if it’s a single part with a whole bunch of detail inside of it. You would have to break up the fog into maybe a 10x10 grid of 100 smaller parts (or fewer if the map isn’t that big).

  2. Once you have a grid of smaller parts, you can watch for the Result was empty, possibly because everything got subtracted away error. Once that happens you can just leave the grid cell completely empty and not even have to call subtract anymore on that cell as you walk around.

The end result being that as you walk around in areas you’ve already explored you don’t have to make any CSG calls at all. This might be a fair bit of effort to set up but could work.

1 Like
#57

Thanks,
That is a possibility indeed.
Another option I was thinking of, was to build it with voxels (something like: Marching Cubes Voxel Terrain with Tools)

But can you give more insight into why subsequent SubtractAsync gets slower and slower? (Curiosity of a programmer)
Because the resulting “mesh” itself is not causing slowness in-game. Only the cutting performance gets bad.

#58

The main reason is that while we’re working on it, we unfortunately don’t have incremental mesh replication yet.

That means that every time you subtract, all the mesh vertices have to be re-replicated to the player. Ideally only the vertices in the section of the part you actually modified would have to be replicated, and that’s what we’re working towards. For now cutting up the part can manually fake this to some extent.

2 Likes
#59

Thanks, now it all makes sense.

#60

Hey, Trimateh.
Just a quick question: Is this fog different for every client?

There are two things that slow down as more of the fog is revealed (and more operations are done)
a) computational complexity
b) network transfer

We are working on ways to improve both but in the short term, what tnavarts suggested is probably the best idea (simply having smaller blocks of fog :slight_smile: ). This will resolve both of the issues at once.

The computation itself has a couple of different steps in it but assuming you don’t change anything else, the parameter you can affect the most is the convex decomposition. Depending on what physics you need on it, you can use lower settings if needed (PreciseConvex in particular is very slow as the complexity goes up)

#61

Yep, this for is different for every client.

#62

Interesting, We’re looking into some client local CSG features, send me a DM if you’re interested.

3 Likes
#63

Hey, I’m having a problem with in-game CSG color transfer (SubtracyAsync).

My game relies on the fact that CSG SubtractAsync did not had any sort of color transfer related to
the NegativePart used.

In my game a part is replaced with the result of two CSG SubtracyAsync operations, with the purpose of creating a cutting effect.

In order to address this issue in this update, I changed the color of the operation’s NegativePart to match the BasePart that was the target, but this had an odd, unexpected side effect.

Even with UsePartColor enabled, the resulting face may or may not be darker than the BasePart color. However, this color change is not permanent and will be undone if you perform another CSG operation on the part that results.

The resulting face may or not be darker than the BasePart color, even when enabling UsePartColor, this color change is not persistent, it is going to be reverted if you apply another CSG operation on the
resulting part.

image

I wish there was a way to completely turn off this color transfer. Given that my game depended on the prior behavior, it is a game-breaker for me.

Public area where this problem also occurs:
(14) Smooth Slicing (Beta Testing Place) V 0.1 - Roblox

2 Likes
#64

Interesting, I’ll take a look at this

#65

For anyone interested. We’re going to do a beta for client side CSG soon. If anyone is interested in joining, please let me know

7 Likes
#67

I am very interested in client side CSG. Please let me know if there are any more details about participating!

#68

I’m interested in joining. So is @tobiO0310.

Please DM the both of us when we get added to this beta.

#69

Count me in for client side CSG too! Let me know when the beta releases.

#70

I’d also like to join in the beta for client-side CSG. I have a few ideas I’ve been itching to try.

#71

I’m interested in joining the client side CSG beta!

#72

Any ETA when this will be enabled globally in-game?