That is sad news, I read the comments there but did not interpreted them as being declined.
Here’s to hoping some other solution pops up, that would be a very welcome addition.
Thanks for working on it anyway.
Not really declined but the current implemention is somewhat a special case and Hans would prefer something more in line with existing data structures (mainly normals calculation). Not trivial for me at the moment without sacrificing some functionality.
So because it mainly works well for the intended purpose, but not that well for other purposes - we get nothing.
Awesome.
There are 1000 reasons why this would go through the cracks of the decision making process (one way or another) of very busy team of developers. My take is that it being long lasting minor issue with workarounds that was marked as « good first issue » for new contributors (which I am), my newbie implementation combined with the fact that it may not have been so trivial after all makes it where we are today.
A good bedtime read is to go through the whole issue in the tracker including the multiple age old archived threads from before Gitea to get a better sense of the issue history 
Also, any assistance in tackling it is welcome!
3 Likes
What kind of functionality are you talking about? I tried earlier build and it basically does everything what it needs to do. There are no fancy options for controlling orientation, but those are not required for 95% of use cases. And it’s possible to control the tilt manually anyway. Maybe you could submit a simplified version for now, and improve it later, when possible?
@HooglyBoogly what do you think?
I am referring to the “miter joint” way of calculating angles and profile stretch around sharp corners. It is not trivial for me to implement it using the current inner workings of normals (which @HooglyBoogly would prefer ).
It is possible to implement a simplified “adjusted thickness” of the profile but it lacks proper profile orientation expected of miter joints because the normals are currently oriented according to the z-up or minimal twist methods. It may satisfy some use cases but far from all the reported issues ( from bug reports, stackexchange , blender Artist or blender chats)…
So what is the advantage of using the “preferred” method?
I don’t understand why it is preferred to use a method that does not work, instead of a method that does work in most cases.
2 Likes
Well, can’t speak to the technical side of things at all, but I have to say that it’s very disappointing to see this slip away. At least we still have the prototype, thanks for that. I hope you’ll still feel motivated enought to give it another go—and you can get some help from an interested dev.
1 Like
The benefit is a separation of concerns that makes Blender easier to use in the long run.
- Normals change how curves rotate throughout their length. The normal is used by sampling the curve, by Cycles, by EEVEE, by the curve to mesh node, etc. Any “no twist” mode would be consistent and easy to use/implement in all those situations. It’s valuable that these are consistent, so that each area doesn’t have to invent its own solution.
- A new option for the curve to mesh node just changes the scale of the profile on the plane of curvature at each point.
It seems possible to me that both of these combined should give the same or similar results as the approach used here initially.
2 Likes
I understand the need to have an unified approach, but since the work is already done on current implementation, why not accept it for 4.0? It works great even without using curve normals, you just need to limit direction change to one axis at a time.
Creating such shape using existing Blender tool would be very tedious and time consuming. I’m sure current “imperfect” implementation would save hours of work for a lot of people doing architectural modeling.
8 Likes
@HooglyBoogly, so let me rephrase what you are suggesting:
- Modification to the
Set Curve Normalnode: Add aNo Twistmode or in other words aMiter Joint Twistmode - Modification to the
Curve to Meshnode: Add anEven Thicknesscheckbox
The user would need to enable both in order to achieve the Miter Joints.
Correct?
2 Likes
- Personally I would prioritize adding the ability to set custom normals (a vector per point, or a vector per curve that influences automatic normals). But essentially yes, the functionality would live there.
- Exactly, yes.
4 Likes
The normal is used by sampling the curve, by Cycles, by EEVEE, by the curve to mesh node, etc.
Are we trying to use curve normals for two unrelated use cases here? i.e. for light sampling (hair rendering) as welll as for profile extrusion that may require arbitrary transformation?
Why not separate those two concerns?
I’m not sure, I think they’re related in that they’re both about the rotation of the normal around the tangent along the curve. I think there’s benefit to this working consistently across different use cases.
2 Likes
Not sure what benefits you’re referring to (except for not increasing the complexity of the code!)?
Meanwhile, if going the no twist curve normal mode way, the user experience would be significantly degraded as 2 nodes would have to be set to achieve the desired result (no twist mode in the set curve normal node as well as the even thickness check in the curve to mesh node). Also those two settings don’t mean much when set individually.
7 Likes
where can I download this build? links are not working.
and when it will be in the main branch?
1 Like
yeah ngl . its sad to see this not implemented for 4.0+ no matter what way you look at it , there should be an option on the Curve to Mesh Node for Even thickness.
3 Likes
You can give it a try from there. I had saved the compiled binaries from a few weeks ago (based out of 4.0 alpha):
Curve Even Thickness
3 Likes
thanks for sharing. 
I’m also disappointed that this won’t be added to 4.0. I understand that consistency is important as described by @HooglyBoogly, but even thickness on 3D curves has had an open ticket for 8+ years now. Following a “good, better, best” approach might be worthwhile in this specific case. Is it the BEST way to implement an even thickness option and completely future-proof? Maybe not… but it’s certainly better than the alternative. At this point, I think most users would even settle for the two node approach (set curve normal + curve to mesh node). I know this feature might seem trivial, at least from the outside looking in, but the 80 posts on thread alone emphasize how important this process is within an arch viz pipeline.
9 Likes