Actually I think I just found an culling issue pertaining to the use of ApplyMesh, do you by any chance use ApplyMesh (either for the fragment or the subtract call) ?
Hi sorry for the delay I probably should have been more specific about how I’m getting these issues.
Here are my steps. CSG was done on the client on a client created instance.
Part → Negate with Part, Converted to PartOperation → Fragment, Converted into Meshpart: Part’s culling breaks, starts using its position to cull.
Part → Fragment Converted into Meshpart → Negated with a Part, Result was a Meshpart and I used :Apply(). Part to start to become darker with subsequent negate operations.
Part (or runtime created PartOperation) → Negated with Meshpart and converted into a Meshpart: Part’s culling breaks. Easiest repo, but I’m not sure it happens every time. I was able to notice it clearly with parts about the size of the character. Interestingly subsequent operations on this part using :Apply() do not seem to incur the darkening issue.
What seems to work for me is when I do fragment only on parts or negates only. The moment they get mixed together they seem to have problems.
Switched CSG negations for fragmentation and its looking good! The only problem I’m noticing with it is that inner faces that are revealed when shorn away are completely white if used on a previously generated fragment once again. Trying to match the fragment part colour with its prior main part colour will darken the whole mesh.
3 Likes
Could we get incremental collision fidelity support for fragment ops? Its something that is relatively easy to do with some plane slicing on boundary sites and would help a ton in getting the fidelity right. Thats kind of important for fragmenting because if the fidelity is a bad approximation fragments will behave incorrectly. I made a naive demo here to see if it would generate too many hulls and honestly its not that bad (85 Hulls but you could probably get it lower with a cleanup pass) - probably near or within your budget for the incremental algorithm but it would need some proper acceleration I think since there are a lot of planes that would need to be sliced but I definitely think its doable
1 Like
Thanks, and your game looks cool! That part color issue is one we’re hoping to solve in the not-too-distant future, but for now I think a solution for you would be to set the part color right before calling FragmentAsync() and then setting it back to white immediately, without waiting for the fragment to happen. I haven’t actually tested that though, so let me know if it doesn’t work!
1 Like
I assume the input to the first fragment call are unions? To add to what @12trianglecube just said, the reason this is happening is after the first fragment call the union turns into a ‘baked’ MeshPart, that means its vertex colors are the vertex colors from the union and its part color is white. Then once you do the fragment on the resulting MeshPart, the newly created interior faces inherit the part color which is white. You can change the part color of the intermediate MeshPart, but this will result in tinting of that MeshPart, which might not be desirable. I think adding a interior color parameter to the api might be needed for your use case.
1 Like
A interior color parameter would be extremely useful for my usecases as well
Update to FragmentAsync() output format:
For anyone who’s using FragmentAsync(), I want to let you know that I’ve rolled out a small change to the ordering of the output. I haven’t broken the API contract, of course, but if you’ve been relying on the output looking a certain way, that may have changed.
FragmentAsync previously returned its fragments in an order that only incidentally tended to be sorted by site group index, and the “main part” (leftover/remainder) was appended last regardless of its index.
Now with this update, the index ordering is a guarantee: output parts will always be in ascending order by their group index. I’ve also changed the tie-breaker to sort by descending order by volume, rather than using triangle count. This means the largest chunk will reliably be the first element of the output.
I hope that makes sense and doesn’t break anyone’s workflow. Happy fragmenting!
1 Like
This currently works with editable meshes. Is it known whether this will continue to work on editable meshes in the future?
We intend to make EditableMesh and Solid Modeling work together even more smoothly. Permissions issues is probably the biggest hurdle but if you have edit permissions for a mesh then I can’t imagine why you wouldn’t be able to do solid modeling on it too.
(post deleted by author)
Sorry for the long delay on this but I found that the issue actually came from some old unions that were not owned by me. In game when you do CSG on the client on these parts the game crashes, but if you do this in studio then it works fine. This doesnt seem to crash on the server. I originally thought it had to do with the complexity of the scene but that was a seperate issue caused by improved physics replication.
A quick fix is just to update the unions with a empty union operation that seems to stop the crashing, but I was curious and I did some digging with the serialization service and found that the unions looked to be cloud asset from CSGv2 and it had a triangle count of 0. I wonder if its breaking because its a cloud asset on a union. Meshparts seem to work fine. You may notice the union I attached here seems to be visually non manifold (Not even sure how this is possible), which I believed to be the cost at first but I think it happens on any csgv2 union on the client side since it crashed on many different unions all of which were csg v2 and some looked manifold.
OldUnion.rbxm (3.9 KB)
Not sure if you can answer any of these questions yet but do you guys have more information on the new voronoi convex decomp announced at RDC? Im assuming this is the team working on it. Will it be useable in runtime with good performance or will we be stuck with the current voxelized algorithm for the incremental fallback? If its usable in runtime will it solve the bad collider generation for fragment ops? Also how does the algo compare to other algos like coacd?
Hey! Yeah the new tunable convex decomp method should eventually be available in the solid modeling APIs. I haven’t yet tried it myself for fragment use cases, but I think the fact that it is tunable could be very useful to make sure the resulting decomps have the desired quality. Regarding the time it takes to compute the actual decomposition, the default decomp is quiet fast so I wouldn’t necessarily expect the tunable decomp to be faster, but best to check on your explicit use case once it is out.
Right I’m looking forward to it. As for the current incremental algorithm, is there anything being looked at for potentially expanding its use cases to include fragments? A big issue Im seeing in my projects is that the geometry that is produced from fragments is only approximate, which causes fragments to fly out of place, get stuck in geometry, and generally it compounds in them behaving very incorrectly. A incremental solution would probably be the best fit for that usecase specifically.
I can’t seem to convert csg results from mesh csg or unions into emeshes, I’m assuming this is a limitation since they do not contain any mesh content, or maybe I’m missing something?
It would be nice to be able to have a editable version of the mesh returned from the CSG operation, I did notice that on the roadmap. It would be great to be able to project and bake decals onto csg operations ideally without needing to convert the results into a emesh then back into static content again.
any word on a fix for this @pho01proof? I had some issues with it earlier today but maybe I just didn’t replace all my assets. Regardless it might be helpful to not have the game crash for clientside csg with old unions.
Hi I noticed that when looking at the Microprofiler on the AsyncCSGOperations thread, negate operations have a debug profile on them, but the newer fragment operations dont, so it’s not possible to actually profile the work they are doing.
Also is this thread still being monitored by anyone on the CSG team?