This project includes modeling tools such as meshes, modifiers, nurbs, curves, metaballs, transform, UV Editor, OpenSubdiv and more.
Important links
Contacts
Sub-Modules:
@Hans Goudey (HooglyBoogly) Will it be possible to copy objects along a curve? Now it is quite problematic to do this.
Thank you for this awesome patch, long time waiting for it.
Yeah, it is caused by rBa3f091d7ceda: Change Exact Boolean modifier to skip round trip through BMesh.
I cannot reproduce the problem or maybe I have wrongly followed the steps to replicate it.
Could you provide a simple .blens file demonstrating the problem?
@Alexandre Mano (Blazitron) : please report this separately (it probably has a different cause)
Back again with a similar issue on the same project, although im unsure if I should be posting it on this since it is already tagged as closed...
Note that now that the new "Exact" mode doesn't go through bmesh it preserves the data. Updated patch to compile on recent version in case anyone still wants bmesh boolean to also work.
Using BLI_task_parallel_range(...) now, and the playback is slightly improved, on my 3990X, it was roughly:
Since I wasn't the clearest (probably even in my own mind) I was suggesting that since the different types of curve objects seem to share that functionality that there could be a way to break apart the curve types into how they are edited and how they are skinned. With how different (layers?) of edit types could be stacked in the curve data while how they generate geometry could be moved entirely into modifier space. This is since I have seen quite a few people in their workflows doing things like converting text objects into curves in order to achieve things like a neon tube effect when really what they are after is a different method of skinning. But now that I think more about it that does introduce problems as well so this was probably just a false bit of connecting dots on my end.
However it does make sense that 2D curves should be their own "type" as well as they offer both changes in skinning as well as editing.
@MacKenzie Strand (kenziemac130) I'm not sure I completely understand your point, but the input to the nodes modifier would be the curve data generated by the text object in this case.
@Brecht Van Lommel (brecht): added you here as a reviewer since you were involved in T59376 already.
Will check on this
Ah wait, since the solution is to let the UV Project modifier create a new UVMap if preceeding modifier destroys it, it is indeed the same issue as T59376: UV project modifier not working after modifiers that dont provide a UVMap (e.g skin, remesh) and I will merge these reports.
This is very much related to T59376: UV project modifier not working after modifiers that dont provide a UVMap (e.g skin, remesh)
Could it be possible to version all of the "Geometry" features of the curve over to the modifier stack so all that is left is explicitly related to defining the shape and base sampling of the curve? I remember when I changed some things about the curve to default to filled it had a knock-on-effect on text as well and I was a little surprised. The curve/surface/text object just feels kind of an odd duck since they can be mutated into each-other by changing the data-block and It kind of feels like the differences mainly come from how the curve data is edited or skinned.
This is an example that doesn't work properly:
Sorry, I was wrong, the crash is back.
Crash fixed (I think), though this approach is understandably very slow. I wonder if it makes more sense to split the work into chunks and do it that way.
Any updates on this @Germano Cavalcante (mano-wii)?
amazing job.
how can i use this in blender 2.93 and more ?
Looks good. Thanks! Please go ahead and commit this.
FWIW, I also stumbled upon this limitation : it took 16 minutes to decimate my mesh.
thank you for looking into this bug,
unfortunately, in the latest blender build
I reproduced this bug in the version informed, but not the latest daily build, so it appears the bug has been fixed already.