Hello there Houdini community!


Today I come with a “simpler” question, which I hope you have some working answer for.

The situation is the following:
I’m applying some quadrangulation procedure I came up with. Not the most efficient for sure, and prob pretty trashy, but hey, it’s part of learning. The basis of it is… isolating connected tris, sorting their prims consecutively, group pairs of consecutive tris, and erasing their shared edge with the Divide SOP. This procedure brings in consequence a quad for each pair of tris.

But the problem is how these quads sometimes end up looking. Aside from unwanted creases, sometimes as in this example:







Sometimes they even “crease” so much they endup showing up as self-intersecting faces.




Here is another snapshot with the vertices @N and they look “fine”. It’s not a matter of normals, cause first, a Normal SOP doesn’t fix it (doesn't do much at all), plus errors come up when I try to apply an afterwards boolean procedure, because of this degenerated geo (so the faces are really intersecting). Even if I apply a PolyDoctor and delete these self-intersecting prims, I apply a PolyFill, and… they still look the same : /.
I know there must be some other better ways to quadrangulate in these situations (and I'm looking it up), but I feel this unwished prim representation is due to something else and I’m really curious how come is not a normals thing. Even if you look to the one on the left of the snapshot, you can see the crease even inverts when turned into a quad.
They're proper quads, with only 4 corresponding points, even in the right sequence (they show up in consquecutive order when called on primpoints() ), etc.

Maybe it's just viewport bug, and it's not related to these... erros of degenerated geo that come up afterwards with the boolean action, but either way I’d love to hear more about it and your experiences with such eventualities.

Thanks in advance!

You got two faces there. Your algorithm must have a mistake, as it's creating two overlapping quads.

Well, that's not a mistake per se. This is some corporeal "double-sided" oscilating panel (you know, like those metalic rolling doors), so there's an equivalent back face for the front face, looking the other direction; they're two differents prims, but they're meant to be. It shows in the viewport cause... yeah, it's effectly intersecting one each other, despite they're quads, so the viewport picks up the opposed face prim num too.

For ex: here's another example where same thing happens:








But there's no intersection between these two quads, so you can only see the prim num of the one looking at the camera, but you can clearly see there's something off with the shading and how's it's representing itself; it doesn't show flat.
In the wireframe one, you can see they're "ok" in theory.

Manuloti
But there's no intersection between these two quads, so you can only see the prim num of the one looking at the camera, but you can clearly see there's something off with the shading and how's it's representing itself; it doesn't show flat.
In the wireframe one, you can see they're "ok" in theory.

Oh, it's not planar. Convert to triangles to 'collapse' the ambiguous non-planar quad. The viewport is just picking the division arbitrarily.

If you're using Flat Shaded mode, it'll make non-planar quads (and polygons) very visible for you. GPUs can only draw triangles, so any N-gon with N>3 will be triangulated and displayed as several triangles. Each of those triangles has its own normal for flat shading.

So it's a visual bug then? Well, not a bug I guess... just the natural behavior of faces. I was aware that ultimately everything is triangulated in its visual representation, but I guess I never thought of it in these instances.

I don't know how to "only quad those continuous tris whose merged face result in a planar enough one". I mean... how to translate that into VEX logic xD. I don't know if it's even worth it. Or maybe some way to indicate "in that face" what pair of pts should be prioritized to be used in its triangulated viewport representation xD.
Ultimately... this is not the reason I'm getting some errors in a later boolean then in some iterations. Since it's visual only... then it's not the source of some degenerated geo that may be causing the problem, thou it does look ugly in Flat Shaded mode xD. I was glad enough to have come up with a simple enough way to procedurally quad those loose pockets of tris along the way, but... keeping a clean geo is always hard.

Anyway, thanks a lot! It was very helpful. If you know other solutions for such instances I'm all ears

jsmack
The viewport is just picking the division arbitrarily.

it's not arbitrary, it's based on winding order
you can shift vertices of the quad around to decide where the crease will be

you can do that using Primitive Properties SOP (Primitive SOP) and in Face/Hull tab set Vertex to Shift and play with the offset to choose where the crease will happen

but yes, you will have those creases visible especially in flat shaded mode if the quad is not planar, I recall this from all DCCs not unique to Houdini, interpolated normals can of course minimize that, but flat shading will show sharp crease

tamte
you can do that using Primitive Properties SOP (Primitive SOP) and in Face/Hull tab set Vertex to Shift and play with the offset to choose where the crease will happen

I'll take a look on that next week. Thanks!