this is very annoying since i have a lot of weapons i need to optimize if there is a workaround pls tell me (i cant post in engine bugs so am posting here)
also if possible cn anyone pls make a bug report on this since its very bad for my project and affects me gr8ly (updates r taking 10 times the usual time)
Any update as to when this will be re-enabled? I know the posts above have said “a couple weeks” but it’s been longer than that… By any chance, does anyone have an estimated date?
Sorry for the lack of updates–we discovered that a few of the issues you all flagged involved some major rework. We also built a new test harness to better catch issues before you all do We’re aiming to re-enable this by mid-June.
Thank you all for the feedback so far and test cases. This has been invaluable for us. We’ve fixed all the issues you’ve found so far (except for one case with a very large model, which we’re working on), and the time has come for us to let you try the new CSG engine again. To enable it, select CSG Version 3 in the Studio Beta features.
Here is a partial list of issues we fixed:
Crashes when using not supported special meshes or mesh parts.
Crashes when changing the smoothing angle
Visual glitches (texture mapping and smooth shading)
Failed CSG unions (most of the models you provided do work now)
We also discovered a few additional issues that we will be fixing during the beta:
Unclear error messages
Scaling issues when separating unions
Very complex CSG union configurations fail in some situations
We’re looking forward to hearing how this works for you!
I’m a bit of a layman in this field, could you elaborate what ‘primitive’ means? if primitive has to do with part count, what about simply two parts? what would be the maximum size limit for those (* before expected behavior breaks down)?
Sorry, my bad. Primitives here meant basic parts (cylinder, sphere, box, or wedge). So 8000 basic parts.
This new engine doesn’t have an explicit limit (either in number of parts or in complexity).
However the more parts you have the slower it’s going to be to compute an union. We are working on an update to improve that and to make performances of incremental updates of CSG parts independent of the total number of basic parts in your model.
Another factor to take into account is that the result of a CSG operation is limited to 20k triangles. This is enough for a lot of models but may not be for the most complex ones. In that case, you may want to break your model into several pieces not to lose in fidelity.
I see. A bit unrelated, but how much less performant are unions overall, compared to primitives? Our game’s map builder uses unions in quite a lot of places to for instance stop texture fighting between primitives - would it be better to use wedges and slightly more blocks to address the texture fighting, or is it fine to just union these parts? I’m most worried about the collision and rendering implications, though networking as well.
Regarding collision detection performance and union vs collection of primitives.
It really depends on the complexity of the union (how complex the geometry, or shape of the final union is).
The algorithm for collision detection between primitives is pretty simple and efficient (e.g. blocks, wedges, spheres).
For unions, (I am assuming these are static unions, like not composed in-game) the shape is first broken down into convex components once (say when you perform the union in studio) and these components are then checked against for collision using an algorithm which is a bit less performant than the simple primitive-primitive collisions.
However, if you have mixed parts (e.g. primitive colliding against a union) then its always the second type of algorithm that is used.
So I would advise, not to worry too much about the collision efficiency when you do unions - you would not get too much performance improvement if you keep everything in a union as a primitive instead - unless, that is everything in your game can be kept as a primitive.
One thing though - if you are doing unions, and you have to navigate through the shape formed like that (e.g. say you carve stuff out of a block using negative parts and unions, and you want to walk through these cavities) then to get the best fidelity for collision detection, you must select “Precise” collision mode on your part (union). Otherwise you might be bumping into things that are not really there (visually). In this case, a collection of primitives (and not their union) always produces 100% precise collision.
At first, all the parts where all separate and welded together using WeldConstraints.
When simulating the floating on the server, network receive on the client would be around 20kB/s!
After some trial and error, I tried to union the parts of the boat with the same materials. Mainly the hull.
This way the hundreds of part where drastically reduced. What I noticed was shocking! The client reveive rate per boat was now only around 8kB/s! More than a 2x improvement!
Was this speedup always present with unions? Or is this new?
Does this hold true for all simulated unions?
CGS V3 has DEFINETELY improved over last time, however its still unreliable since it cannot really be used on too complex objects and it may or may not break the geometry of some round objects (Ex: Sphere), making those objects look slightly to maybe even very different in some extreme cases, here’s some examples, (2 Is CGS V2, 3 Is CGS V3) Wire Frame Example:
However so far I do like how better the new engine has gotten, I really like how the new engine is able of making cuts into unions and have those cut areas use different colors. Hopefully we will be able to do the same for textures too, this could save A LOT of time and be INCREDEBLY useful!
While this does look more promising, this is only networking - I’m more-so worried about collision and rendering times (see mrrblato’s post, if you have any gaps to go inside the ship you’d need to use ‘Precise’ collision mode which is much more expensive)
Thanks for the feedback.
The differences you’re seeing between V2 and V3 for the spheres example is due to how the sphere is triangulated. We did use another way of modelling the sphere, which we now think may not have been the right decision. We are going to revert back to the V2 sphere which is made of stripes of quads. This should make the geometry of the CSG meshes more regular.
As for the ability to transfer the textures on cut parts, could you please share a model exhibiting the issue? I will have a look and check whether this is something we can do.
This was not an issue I’ve experienced, I was only saying how it could be useful if we had that ability, so far we can only do this with different colors. And here is an union that I’ve cut colors into… colounionn.rbxm (25.4 KB)
Also again, I am only saying that it could be useful if we could cut different textures and colors into parts.