So I decided to use Modo to manage/edit my uv map. I created a file node to write the obj file to disk. Created and edited the map in modo. Now I can use a file node to import the obj and uv map back right?
At that point do I just work from the file import node, or is it better to use an AttribCopy node to copy over the UVMap? I tried the latter but got some weird results.
Here's the uv map the file node has after reading in the file



Here's the results after using the AttribCopy SOP



In the normal view it looks OK, however if I try and bake an occlusion map to the UV, it gets all sorts of nasty artifacts from the overlapping UVs. Now in the AttribCopy SOP if I switch the group types from “Points” to “Vertices” the UV map looks OK:



But now when it renders, or if you use a UV test material you get this:


So is this a case where the AttribCopy SOP doesn't make sense? Is it better to just branch the network off from the file import node as opposed to trying to bring it back it into the current network that you were working on?

Hi Jim,

When you load the OBJ with UVs, and MMB on it, what type is the ‘uv’ attribute? Point or vertex?

It's weird that it would look good in the UV viewport but be messed up rendering.

Ah, perhaps there are conflicting UVs? If you MMB on the node that renders, do you see Point UV and Vertex UV sets? If so, try deleting the Point UVs with an Attribute SOP.

Regardless, unless you have other attributes you care about on the Houdini model, using the OBJ model with UVs that you're happy with should be fine. Having said that, what you're trying with Attribute Transfer should work…

You might try Attribute Copy if the points are identical. Just an idea.

Cheers,

Well it appears there are some issues with Modo that I need to sort out. Sigh. Modo, for some reason, is, at the very least, altering the geometry or normals, or something, because even the simple act of loading in an OBJ file, and then saving it back out results in some differences. So I'm not sure if this is really even a Houdini problem, or some weird issue with Modo.

I am truly learning to HATE anything to do with UV maps. On the positive side at least I'm learning how they work in Houdini

Not just Modo. Other more main-stream apps also suffer from “shuffle-itis” when you just so much as breathe on the geometry.

I just don't get it… :?


To save uv's keep the original file with working uv's as a bgeo on disk or lock the SOP.
Then use an Attribute Transfer SOP to see if you can move the uv's over.

If the topology just got shuffled since the last save you can use the Match Topology SOP.
Btw Houdini adds new primitives on the end of the stack and doesn't re-shuffle the geometry. In most cases that is.

There are other methods to save work as well but the above two are most common.

Here's the thing - I'm not using Houdini for *any* UV map creation (it just can't handle what I need it to do, see previous postings on this). So I'm exporting a fresh copy of the network out to an .obj file (no uvs at this point). Then that obj file goes into modo for the UV map creation. So there's no way to get around bringing the original .obj, which is OK, and at some point exporting it back out from modo, which at some point messes up the geometry. I'm going to do a file diff tonight and try and see where exactly it's going wrong.

Just a thought: is it possible that the conversion from string to float or double for the various vertices could be getting screwed up due to floating point errors? Is it possible that my model has points close enough that rounding errors are creeping up and when modo exports it back out the problems I'm seeing are due to this? If that's the case, if I add a Transfrom Node, prior to writing out the model to disk, and scale it up say 500%, would that help?

//Then use an Attribute Transfer SOP to see if you can move the uv's over.
//If the topology just got shuffled since the last save you can use the Match //Topology SOP.

OK I'll try this tonight and see if that helps. Any reason why the Attrib Transfer would work better than a Attrib Copy?

Thanks for the suggestions.

i am assuming you are trying to do something similar work flow with Zbrush getting UV from other app.

if that's the case, check
1. OBJ can only handle 1 UV per object
2. sometime mess up with partial UV (means that not all the geometry is UV) some people fix this by UVing and move it to a side or UV in the same UV space and assing it other material)
3. you can check with other formats from modo out just in case. like DAE collada, or FBX Houdini is wonderful that also reads LWO .

you can have your geometry that exported out, a file to import the geometry. and then a attribute transfer.

after that i am not sure if you need to set something special in the Attribute transfer node, or by default it brings all attributes possibles. i am still working on that .

Thanks, that's almost exactly what I was doing. I found that sure enough, modo was adding vertext normals for everything, so the simple act of reading in a file to modo, and then saving it back out, means the obj almost doubles (at least in my case), and there are now vertex normals that Houdini is picking up (correctly). By adding an Attribute SOP and deleting the normals, that fixes the weird render issues.

The UV map may have gotten screwed up in modo by me (accidentally), and perhaps when I was moving pieces around I missed some vertices. I'm going to try and redo it again, and see if that fixes things. So I'm closer.

Houdini to ZB and back I've gotten to work perfectly in the past, so at least ZB knows how to handle or not mangle an obj file. Also At least it warns you up front that it doesn't like the geometry and that it's going to change some things if you've got ngons.

Well it seems like I got this sorted. After redoing the UV map again from scratch in Modo, and then importing it back in to Houdini and removing the Modo added normals, all is good!

Modo UV map


View with UV test mat, seems like there aren't any major scaling issues


Thanks to everyone for helping out with this!

Looks good and I'm glad you've sorted out the workflow. One thing that came to mind regarding the UVPelt tool you may have missed. You can change the shape of the “stretcher” frame, it doesn't have to be a circle.

How would you do that? Is it just a matter of creating a four sided, closed curve, and then pipe that into one of the inputs? Would that allow you to create something like the Modo generate map? That would potentially simplify things.

so jim, i saw your final solution on your ‘learning 3d’ blog.

basically you just used the uv map created by houdini.

i've been struggling with this a bit. our workflow here involves multi-uv models, detailed and UV'd in zbrush.

the UVs are separated by group in a single mesh. head, torso, limbs, etc
so we can assign large texture maps to each group, but still have a seamless model.

obj is output out of zbrush to be painted in maxon bodypaint. displacement maps and normal maps are output also.

anyway, my point is, that i need a way to keep the uv in a ‘grouped’ model to stay intact into houdini. (bodypaint has no problem with this. automatic)

it seems you were getting very close above.

i noticed that the .mtl file, which is output with the .obj does include groups.

i have not seen anyone deal with multi-UV'd third party models in houdini yet.

i started a thread last year on this… lol.