I'm totally new to Houdini. I just imported a test model with a solid color texture. It's a GLTF (.glb). It's showing its seams for some odd reason. I also brought it into a game engine and did not see any seams. I assume that this is a feature of Houdini. Can someone explain how to turn it off? Is something wrong with my test model? Thanks for any answers.

Okay, I added a light and a camera and rendered an image. The seams are still visible. I guess I need to have Houdini redo the seams for the object, like recalculating normals and such. I'm just confused as to why it looks fine in Blender and a game engine but bad in Houdini. *sigh*

I've never worked with GLTF, so I'm not sure how it handles normals.
But it's easy enough to fix, you just add a Normal node. Its default settings should give you smooth results on this model, although generally I like to set the Weighting Method to By Face Area (and 60 degrees is a bit high for most models).

Digipiction
I've never worked with GLTF, so I'm not sure how it handles normals.
But it's easy enough to fix, you just add a Normal node. Its default settings should give you smooth results on this model, although generally I like to set the Weighting Method to By Face Area (and 60 degrees is a bit high for most models).

Thank you very much. I'll try that out. I guess a Houdini thing would be a node. :P

gltf import seems to correctly import geo with or without vertex N attribtue

which in your case would mean that
- either there is custom vertex N attribute creating those seams and therefore the issue is in your export program
- or the mesh itself is split on seams and then even auto normals will not be smooth there as there is no continuity in the mesh

of course you can easily solve both cases in Houdini by either deleting/recreating normals or fusing the mesh depending on what the issue is
however sometimes it's better to solve the source of the problem than adding fixes on top

I'm confused. I simply set my seams and unwrapped it in Blender; no nonsense. It looks great in Unigine Editor and in Windows 3D Viewer. I even did a detailed texture using projection painting (stencil) that looks great in both.

Actually, I had one big look at the long list of normal related nodes and decided that Blender was more my style of program.

tamte
gltf import seems to correctly import geo with or without vertex N attribtue

which in your case would mean that
- either there is custom vertex N attribute creating those seams and therefore the issue is in your export program
- or the mesh itself is split on seams and then even auto normals will not be smooth there as there is no continuity in the mesh

of course you can easily solve both cases in Houdini by either deleting/recreating normals or fusing the mesh depending on what the issue is
however sometimes it's better to solve the source of the problem than adding fixes on top

Is it possible the glb importer is creating unshared points where uv seams are present, importing uv as a point attribute? This would cause a seam in the auto-generated normals if the glb file didn't author normals.

I'm not really sure why it would be stored as Point attribute in the first place if it clearly has discontinuous values
Its possible that GLTF stores data only as disconnected polygons with nonshared points(in which case they equal to vertices),
which would explain the option for merging
however I'm not that familiar with how GLTF stores data, but testing export/import of discontinuous vertex uvs and with/without custom normals worked as expected

tamte
I'm not really sure why it would be stored as Point attribute in the first place if it clearly has discontinuous values
Its possible that GLTF stores data only as disconnected polygons with nonshared points(in which case they equal to vertices),
which would explain the option for merging
however I'm not that familiar with how GLTF stores data, but testing export/import of discontinuous vertex uvs and with/without custom normals worked as expected

Gltf doesn't make a distinction between point or vertex attributes, they are stored as indices into a buffer containing values.

https://github.com/KhronosGroup/glTF/blob/main/specification/2.0/figures/gltfOverview-2.0.0b.png [github.com]

Edit: I think it's just broken in Houdini. The gltf reader isn't reading the normals attribute at all. (or the rop isn't writing normals. I don't have another gltf writer to test with)

jsmack
Edit: I think it's just broken in Houdini. The gltf reader isn't reading the normals attribute at all. (or the rop isn't writing normals. I don't have another gltf writer to test with)

it does write and read vertex N correctly for me

and I agree from observation it also looks like there is no distinction between Point and Vertex

tamte
it does write and read vertex N correctly for me

and I agree from observation it also looks like there is no distinction between Point and Vertex

it doesn't in the latest prod build of 19.0. You can write out total garbage for the normals and it comes back in with geometric normals. It also has seams on the normals where the uv splits are.

Does it look like this for you?


I noticed that loading as packed prims reads the normals correctly.

I was testing in H18.5 and Load By parameter defaults to Primitive there
which seems to load custom vertex N perfectly

if I switch it to Mesh or Scene, suddenly it ignores them, I noticed your Load By is Scene, maybe that's the default in 19.0?
try switching Load By to Primitive if it works there as well
but also maybe loading as Packed Prims does that in Scene mode, I don't know why they are different and whether its a bug or something from GLTF specs

tamte
if I switch it to Mesh or Scene, suddenly it ignores them, I noticed your Load By is Scene, maybe that's the default in 19.0?
try switching Load By to Primitive if it works there as well

Ah, that was it. Indeed, anything but Primitive and with flat geo doesn't load normals properly.