I totally agree! While I dont quite understand how negative parts changing the colour of a surface it cuts into can be beneficial for modelling, it does seem quite favoured, however I know that there are hundreds, if not thousands of developers who prefer colours of unions to not be affected when cut by negative parts.
It seems both systems are preferred by a large group of developers so I would definitely agree on both features being kept, perhaps as a setting toggleable in the sub tab of the union buttons?
I use it to bake in colors when modelling. It can prevent you from making 2 separate unions when one would suffice. For example, maybe you’re trying to make a cylindrical tube that’s a different color on the inside than the outside. Without that functionality, you’d have to make a separate union and risk z-fighting.
Both behaviors are definitely preferable though, since in both cases it can cut down on workload and union count.
I see thats actually a very useful usecase!
However to prevent z-fighting I would personally in that case make the inner cylinder smaller using the size property by 0.001 studs to size the inner cylinder down just enough, but not enough where its noticeable beyond the inside face(s) And then union the two together
I just kinda picked this method up as some specific models I do require such precise modifying of the size / position of parts where your method wouldn’t help, but its interesting to see that there is indeed a use for yours!
That’s technically possible but it would probably be really difficult to add anymore onto that union since it’s so precise, that type of extremely fine detail is prone to cause problems. It’s also a problem if the cylinders don’t line up due to the current bugs with them in CSGV3, which I really hope can be properly fixed before release.
Apologies for the bump, but I didn’t see this asked in the thread. Is there a way to determine what csg version a unioned part is? I didn’t see anything in the API nor do I know if you internally track this (so may not be possible). This would be hugely beneficial in terms of converting unions in a game that has tens of thousands of parts. Especially games that span several years that more than likely contain unions of different versions.
There technically is a version tag in the data but it isn’t exposed right now.
However you should understand that the underlying data follows a slightly different idea of what “versions” there are than the tooling. CSGv2 and CSGv3 actually use the same storage format in the place file, they just use significantly different approaches to generate the data being stored in that format.
The above means that there’s no need to “upgrade” the unions unless you’re actually planning on editing them further in the future and want to make sure you know what they’ll look like if eventually edited under CSGv3.
Thanks for the reply. While I see what you mean regarding v2/v3 having the same storage structure, I still think having an exposed method or property would be good. I know of a lot of instances where people still have V1 assets in game (As I previously mentioned, I still use models from 5 years ago but at this point, I don’t know which ones are V1/V2). Furthermore, while this doesn’t really apply to my game, many people borrow free assets, so knowing if something is V1 or even a complex V2 object that could be significantly more efficient if rebuilt would be very helpful for games pushing the engine’s limits.
Just curious, any updates regarding the sphere/cylinder positioning?
Hi, sorry for the lack of update. The root causes have been found. We have a fix for all the sphere / cylinder issues between V1 and V3 (mismatch & positioning). Unfortunately this comes with a huge cost to performance so we are investigating how to make that acceptable.
Excellent! Glad to hear the cause has been found, that’s really reassuring. I wish you luck in finding a fix to the performance problems, as I know that can be frustrating sometimes.
Wanted to report in quickly and say that since my last post I’ve used V3 to remake a semi-complicated union that was very difficult to work with in V1, which I was initially hesitant to try given the offset issues. It doesn’t use cylinders or spheres, but just working with bricks alone, V3 is definitely vastly superior now that the most of the bugs were ironed out. It was very easy to make, and I encountered just about no problems whatsoever! Once the cylinder / sphere mismatch is fixed, I think this will be a positive update across the board. Great job so far!
Sorry to bump, have there been any updates on the cylinder/sphere mismatch? I’m considering starting a modelling project once V3 is fully fixed, and I’m very eager to get started.
We’re working on it. It’s proving a bit more difficult than expected but there’s been some progress. We’ll let you know when it’s available.
And thanks for the positive feedback. Always appreciated.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.