Full In-Experience Release of CSG v3

Updates Announcements
#42

It is enabled now (game servers need to be restarted for it to have effect)

1 Like
#43

How to understand if CSG v3 is currently working on servers in roblox? Or does it need to be enabled somewhere?

#44

Wait, I forgot is this enabled for in-game apis?

#45

It is enabled only on servers. Devs have nothing to do to migrate to CSG v3 in experience. both SubtractAsync and UnionAsync now use CSGv3

#46

@ROBORAPTOR2468 @BravenwolfTFS
Still working on that issue. The cylinder / sphere issue is less a problem here as weā€™re talking in-game APIs where accurate alignment / positioning is not as required as in Studio for modelling.
I will update you on the progress as soon as I have information.

1 Like
#47

Gotcha, just wanted to be sure it wasnā€™t the full roll-out yet. Thanks for clarifying!

#48

Hi @Aerodymier,
If you are still having this issue, are you willing to share an example so I can take a look at this issue faster?

#49

Sure, itā€™s definitely not happening as frequent as before but when I get home Iā€™ll share an example.

#50

@Intersect_Man

Hereā€™s a video I recorded:

Iā€™ll also PM you this asset since itā€™s a game asset which I actively use.

As you could see, their CollisionFidelity was that precise convex option however one door space still had a non-collidable area. When I separated that union and then reuinoned it then set the collision fidelity again, the issue went away.

1 Like
#51

Thank you for the model file and the video. Your own solution is best way to fix issues like this. Separate the Union, then Union again and choose the CollisionFidelity.
The reason you are seeing this issue is that Roblox is improving things continuously and this case is an example where you have an asset that is created before a minor patch to the collision geometry computation.
I recommend turning on the Show Decomposition Geometry from File>Studio Settings>Studio. This option will show you how the gameā€™s physics engine is dealing with object collision.

Before:

before
before888Ɨ856 223 KB

After:
after
after1920Ɨ1180 74.8 KB

I will take a deeper look to see whatā€™s special about this older model that prevents the CollisionFidelity Update.

5 Likes
#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.