Prepare UVs For Mari?

[Atom]

Hi All,

I am trying out Mari NC to see what kind of workflow is needed to get UV models out of Houdini and into Mari.

In this image I have nice a Box projection that provides a decent looking UV grid across the object. However, if you examine the UV grid you will see that there are a lot of overlapping areas which will not work with Mari. Overlapping areas mean if you paint on one face color may appear on another unintended face.

 

So I have tried out the Houdini UV layout tool and set the scale to limit my UV layout to the maximum of 6 UDIM squares that Mari NC allows. And while this fixes overlapping faces and makes a UV set that Mari can work with it destroys the ability to select associated faces via a UV island. Also there is a ton of wasted space. It looks like the algorithm finds the largest area and populates all the large UV areas on one UDIM tile then moves on to the next UDIM tile, not considering that it could actually use 6 UDIM areas to start with. As you can see the UV faces get smaller and smaller as the UDIM count increases. This ultimately limits paint resolution in Mari when you have to paint on slivers. If the Houdini UV Layout area distribution were smarter I could increase the scale and reduce the number of sliver elements generated.

 

Also, selecting faces in Mari is fairly primitive yet selecting UV islands is quite possible but with the islands split into so many tiny areas selecting by UV areas becomes quite tedious in Mari.

I am just wondering if anyone has any tips on UV layout workflow? This probably applies to Substance Painter users as well.

ap_runabout_uv_projection_layout_1a.hipnc

Edited June 6, 2016 by Atom

[davpe]

have been looking into this lately as well. generally, what I ended up doing in cases similar to yours was grouping parts of the geo that I wanted to end up at the same UDIM and then layout them separately. one layout SOP per UDIM. not great, but it works quite fine.

what I am having much more tedious problem with is that layout SOP can't keep the orientation of the uv's I'm feeding it. let's say I have a bunch of columns that I need to keep oriented in a specific direction for easier texturing. in that case, I can't use the layout SOP as it tends to rotate the pieces to minimize wasted space. shame :-/

another thing that I am missing badly is an absence of a relax tool for uvs (and uv stretching can be seen only for the pelt SOP i think)

in general, uv mapping tools are going in a good direction but for hard surfaces it is not great currently.

[Guest tar]

1 hour ago, Atom said:

 

I am just wondering if anyone has any tips on UV layout workflow? This probably applies to Substance Painter users as well.

 

Yes, start out with a very simple object first, i.e. a box. You appear to be confused by elementary uv, texel and painting concepts. 

[Atom]

I have been working with simple objects for years, I can already unwrap a box.

I really need to move to the next level and work with more complex objects.

It is my understanding that Mari will use the viewport as a camera and project rays into the scene detecting face intersection. It then grabs the index of that face and looks up the UV coordinates for that face. Those UV coordinates are used to paint a color on the final texture image. So having my UV's scatter across the grid does not really matter to the painting program, it is going to detect and project into the correct UV areas.

I am not really seeking a single file I can drop into photoshop and paint onto. Manually painting on the texture map is not my goal. I want to be able paint fluidly on the model and then pass the exported maps back to a Mantra or Principled shader without any editing to the generated textures.

Edited June 6, 2016 by Atom

[Guest tar]

Once again, you are missing elementary texture skills - you *cannot* paint on scattered UV as you cannot then edit the paintwork in the UV tile in any cognitive manner. This is texturing 101. As Jens said on the Mari NC forum, read the manual even if you do not understand it, and, do tutorials so you are disabused of a technical approach to what is an artistic goal. Until then you'll keep writing wacky things that make no sense to what the goal of texture painting is.

[Atom]

As Jens mentions, the gaps are caused by the Mari projection algorithm. That is why I was searching for better ways to construct selections in Mari. There is also a paint directly on selections feature which avoids projection and correctly maps color out to scattered fragments of a UV map. Part of my problem is the NC limitation of only 5 objects and only 6 UDIMs. I was watching a WETA demonstration of Mari and they had 40 UDIM tiles, 4K each, for only the top half of a character. I think that is why the Mari projection is failing in this case, the slivers are just too small to detect sometimes and I experience uneven coloring using Mari's projection mode.

So what is the correct way to unwrap a spaceship like I have attached in post#1?

Edited June 6, 2016 by Atom

[Guest tar]

Mark the seams and unwrap with a hard surface style.

 

[Atom]

The model is, of course, Chris Kuhn's blendswap model. So it came from blender. I went back to the original Blender file and marked a seam right down the middle and unwrapped the object and used CTRL-P to pack the UVs into the available space. But that available space is only 1 UDIM tile. Using this method I only get 4K of pixel space. Using the Houdini UV Layout node I get 24K of paintable pixel/texel space.

Using the box projection method found in the example file the user F1 provided. I can get almost seamless grid pattern across the ship. While this works ok for a procedural tileable material it really won't work inside of Mari because of the overlapping UVs.

So it brings me, once again, back to the UV layout node.

Edited June 6, 2016 by Atom

[Guest tar]

The model is almost totally unwelded - it falls apart if you touch it  - you are making learning Mari extremely hard.  Hopefully someone can help. Cheers!

[acey195]

I've done some smart UV generation for non-organic objects that are (more or less) symmetrical along one axis in the past...

Its half-obsolete because of the native support that was added with H13.0 and forward,
so part of me wants to update it to make use of the new support and make it magnitudes faster :P...

but feel free to download the trial of course:
https://www.orbolt.com/asset/Twan_de_Graaf::TdG_UVgen

[Atom]

Thanks for the link Acey. That looks very similar to the built-in Smart Unwrap that Blender has.

@Marty: Thanks for the unwelded observation, I put a fuse node in line and reduced point count by ~50%.

After using a series of group and UV Transform nodes I was able to extract profiles from the box projection. This is getting close. However, because the profiles still overlap one another, when I paint on the top it appears on the bottom, on the left it appears on the right etc..

I can almost imagine some wrangle, at this point, that could examine the faces in the group and determine if it was facing up or down, left or right or front or back. Then I could apply a further transform on that detection to extract the overlap for each profile. I'm not sure what that code would be, though...

ap_runabout_uv_projection_layout_1d.hipnc

[davpe]

speaking about determining down facing prims... you know that you can do that with the group SOP, right? (create groups by normal)

[altbighead]

you would want to layout the uv properly like marty was saying.

example.

[Atom]

@altbighead: Thanks for the example image. I do realize that I can painstakingly map out every single face into some traditional layout but I really want to avoid that step all together and come up with a way to automatically make UV maps for paint programs.

Thanks for the Group Normal Tip Dave. I think that get's me what I want!

I have setup 6 cubes surrounding my source geo and I gather faces that only face those cardinal directions using the Normal feature of the Group node. I follow this up with a UV Transform and now I have each side of the geometry basically isolated and within the 6 UDIM limitation of the Mari NC app.

 

When I paint on the faces in Mari the paint goes to the appropriate UV locations.

 

I think this might be about as automatic as UV generation can get for complex non-organic objects.

ap_runabout_uv_projection_layout_1e.hipnc

Edited June 7, 2016 by Atom

[davpe]

another tip for auto uvs - when you are using the UV unwrap SOP, it has a second input that takes any reference geometry and creating projection planes out of its polygon normals. that means if you plug the box in the second input you have a cubic projection, etc. also, it is very handy to plug the oriented bound SOP in as it makes your ortographic projections aligned to the object.

[f1480187]

You probably need to unwrap it manually. Automatic packing is okay, but box unwrapping introduces lots of small disconnected islands. Also, you should try to reexport model, to get properly fused model in Houdini, instead of manually fusing it. It may fuse different details together by some common points, and also it may not fuse at all. I see some disconnected floating triangles and different parts fused at the same time. After that, I would go by isolating large pieces first, unwrapping them, then repeat for small parts. It won't take a lot of time. 1-2 hours, maybe.

UP: didn't notice you solved the problem. However, it is still a solutuion, if you will experience problems with overlapping uvs due to projection mechanism. In later case, you may simply bake drawn maps to a new UV channel and export back to Mari.

Edited June 7, 2016 by f1480187

[Atom]

@Dave, that works too and is a lot simpler than the FOREACH loops method. I have setup the scene with a switch so you can view either UV generation method.

 

@F1: I really don't think manually laying out UVs are necessary when using a paint program for generating maps. If the goal was to hand this off to a photoshop texture artists, yes, perhaps some thought to the placement within the UV space could make the texture arist's life much easier. But I am eliminating that step. No texture artist will ever draw on these maps. Only the UV paint program will (Mari, Substance, ZBrush, Mudbox). It seems like the most important rule is that none of the UV patches overlap one another.

Here is Dave's described method of using a box for the planes of the secondary input of a UV Unwrap. I followed it up with a UV layout in scale mode so I could extend the layout area into the 6 UDIM squares that Mari NC will accept.

When I draw a line across several faces the paint program correctly projects the color onto the various UV areas as needed.

ap_runabout_uv_projection_layout_1f.hipnc

[Guest tar]

2 minutes ago, Atom said:

 

@F1: I really don't think manually laying out UVs are necessary when using a paint program for generating maps. If the goal was to hand this off to a photoshop texture artists, yes, perhaps some thought to the placement within the UV space could make the texture arist's life much easier. But I am eliminating that step. No texture artist will ever draw on these maps. Only the UV paint program will (Mari, Substance, ZBrush, Mudbox). It seems like the most important rule is that none of the UV patches overlap one another.

 

Umm no - you are taking us back about a decade in UV land, to Box projections - you are describing what PTex is meant to do. 

[Atom]

16 hours ago, marty said:

you are describing what PTex is meant to do. 

Oh good, because Ptex export is unavailable in Mari NC, only UV map export is supported. So I guess this style emulates Ptex in a UV fashion. I didn't realize that.

 

I was able to get pretty good tiling out of Mari using this method. Even box projected along a curved surface.

Edited June 8, 2016 by Atom

[f1480187]

@Atom, sorry, I was talking about manual island creating, not about manual layouting islands. Houdini automatic layout is very good. Opposite for unwraping tools creating texture seams. With manual unwrapping you may get bigger, optimally unfolded and more sophisticated islands which then may be automatically packed. However, if everything already works, you shouldn't even bother.

Edited June 7, 2016 by f1480187