Bugs of Polybevel.
1442 9 4- RGaal
- Member
- 143 posts
- Joined: 6月 2024
- Offline
So, our unloved bevel.
I've been writing to support about these bugs for a whole year and unfortunately I see complete ignoring from the developers.
If you agree with me that having such errors in the basic function in Houdini in 2024 is simply unacceptable from any point of view - like, comment, attract the attention of the developers.
1) A stupid error in the scale by attributes, making it useless. Here is a demo cube and you logically want to reduce the bevel on narrow faces using an attribute. Without an attribute, your bevel is perfectly set to the limit. You apply the scale by the pscale attribute and ... your bevel stops moving on one side. Why? Disabling collision immediately fixes the problem and gives an answer - Because the offset is multiplied by the pscale, and the collision calculation is not multiplied. Incredibly absurd! They use different distances! Therefore, the smaller your pscale is, the sooner your bevel hits an invisible wall, and the larger your pscale is, the stronger the overlap will be before the collision calculation "sees" the collision. A simple arithmetic error that turns your bevel into garbage. I remember this every time I need this function. It's sort of there, but there's no point in it.
2) Bevel accuracy on inclined edges. Here's a square extruded into a pyramid with strongly inclined edges. It's better seen on it. A completely symmetrical figure, right? We apply the bevel and see that there is no symmetry at all. A simple square! And if you rotate it, you can see that the calculation error is somehow related to the angle of the edge to the world axes, since with a slight rotation the bevels constantly change their sizes. Horribly inaccurate. It catches the eye when you need to bring the bevels close to each other. We remember that beauty is always symmetry.
I've been writing to support about these bugs for a whole year and unfortunately I see complete ignoring from the developers.
If you agree with me that having such errors in the basic function in Houdini in 2024 is simply unacceptable from any point of view - like, comment, attract the attention of the developers.
1) A stupid error in the scale by attributes, making it useless. Here is a demo cube and you logically want to reduce the bevel on narrow faces using an attribute. Without an attribute, your bevel is perfectly set to the limit. You apply the scale by the pscale attribute and ... your bevel stops moving on one side. Why? Disabling collision immediately fixes the problem and gives an answer - Because the offset is multiplied by the pscale, and the collision calculation is not multiplied. Incredibly absurd! They use different distances! Therefore, the smaller your pscale is, the sooner your bevel hits an invisible wall, and the larger your pscale is, the stronger the overlap will be before the collision calculation "sees" the collision. A simple arithmetic error that turns your bevel into garbage. I remember this every time I need this function. It's sort of there, but there's no point in it.
2) Bevel accuracy on inclined edges. Here's a square extruded into a pyramid with strongly inclined edges. It's better seen on it. A completely symmetrical figure, right? We apply the bevel and see that there is no symmetry at all. A simple square! And if you rotate it, you can see that the calculation error is somehow related to the angle of the edge to the world axes, since with a slight rotation the bevels constantly change their sizes. Horribly inaccurate. It catches the eye when you need to bring the bevels close to each other. We remember that beauty is always symmetry.
- eikonoklastes
- Member
- 396 posts
- Joined: 4月 2018
- Online
RGaalThis seems like a pretty nasty bug. It's curious that the same bug doesn't apply when beveling the points, where it does seem to be applied symmetrically. I'll add a bug report myself.
2) Bevel accuracy on inclined edges. Here's a square extruded into a pyramid with strongly inclined edges. It's better seen on it. A completely symmetrical figure, right? We apply the bevel and see that there is no symmetry at all. A simple square! And if you rotate it, you can see that the calculation error is somehow related to the angle of the edge to the world axes, since with a slight rotation the bevels constantly change their sizes. Horribly inaccurate. It catches the eye when you need to bring the bevels close to each other. We remember that beauty is always symmetry.
- RGaal
- Member
- 143 posts
- Joined: 6月 2024
- Offline
Let's look at a frequently needed bevel for a pit. 2 options - with and without inset.
Let's take a bevel in blender as an example. We use 1 modifier, which has three rounding options and 1 with round corners is perfect. Excellent mesh and excellent shading in both options. In one action.
Let's look in Houdini. You can select an edge shift and this will slightly improve the rounding in one option and will not help in the option with inset. Shading is bad and very bad.
Let's expand the area for the bevel and get a dense mesh and the shading from very bad will become simply bad.
What else can be done?
We make 1 bevel for the inner edges and the second bevel for the outer edges separately and MANUALLY correct the overlaps. Finally, we get an acceptable result.
Total - three iterations, 2 manual selections, 2 bevels and 4 manual adjustments for corners. In this case, the mesh will be bad and it is better to delete 16 edges and make 8 new polysplits. And this is only for 1 hole. Too many nodes and manual operations! Parameterization is fictitious. If you have many holes, it is not viable. Compare with one operation in blender for any number of holes. It's ironic, but "destructive" blender in the case of bevel looks much more parametric than "parametric" Houdini.
Guys, bevel is an essential basic function, without which it is impossible to imagine modeling. But bevel in Houdini is an inconvenient and inefficient old node with bugs and shortcomings, which has no place in 2024. Please, make it relevant to the times, it's not 1990 outside!
Users, please, demand that developers stop building castles in the air and let them make basic tools normal.
Let's take a bevel in blender as an example. We use 1 modifier, which has three rounding options and 1 with round corners is perfect. Excellent mesh and excellent shading in both options. In one action.
Let's look in Houdini. You can select an edge shift and this will slightly improve the rounding in one option and will not help in the option with inset. Shading is bad and very bad.
Let's expand the area for the bevel and get a dense mesh and the shading from very bad will become simply bad.
What else can be done?
We make 1 bevel for the inner edges and the second bevel for the outer edges separately and MANUALLY correct the overlaps. Finally, we get an acceptable result.
Total - three iterations, 2 manual selections, 2 bevels and 4 manual adjustments for corners. In this case, the mesh will be bad and it is better to delete 16 edges and make 8 new polysplits. And this is only for 1 hole. Too many nodes and manual operations! Parameterization is fictitious. If you have many holes, it is not viable. Compare with one operation in blender for any number of holes. It's ironic, but "destructive" blender in the case of bevel looks much more parametric than "parametric" Houdini.
Guys, bevel is an essential basic function, without which it is impossible to imagine modeling. But bevel in Houdini is an inconvenient and inefficient old node with bugs and shortcomings, which has no place in 2024. Please, make it relevant to the times, it's not 1990 outside!
Users, please, demand that developers stop building castles in the air and let them make basic tools normal.
Edited by RGaal - 2024年9月14日 13:21:56
- freshbaked
- Member
- 121 posts
- Joined: 6月 2020
- Offline
- RGaal
- Member
- 143 posts
- Joined: 6月 2024
- Offline
- RGaal
- Member
- 143 posts
- Joined: 6月 2024
- Offline
- LukeP
- Member
- 374 posts
- Joined: 3月 2009
- Online
- RGaal
- Member
- 143 posts
- Joined: 6月 2024
- Offline
- LukeP
- Member
- 374 posts
- Joined: 3月 2009
- Online
- alexeyvanzhula1984
- Member
- 87 posts
- Joined: 11月 2023
- Offline
RGaalNo, that's not quite right. VEX is used in almost every HDA, including for creating geometry. For example, the Connect tool, which connects components with new edges, uses VEX to create new polygons. The Edge Flow tool interpolates point positions using the Bezier method and consists of just one VEX node. And so on...
The modeler is just a set of convenient things around nodes that greatly facilitate interaction.
As for the Bevel operation, it can also be implemented with VEX, but I haven't gotten around to that yet.
-
- Quick Links