headus 3D tools

[headus]

"lower factor set to zero."

Yikes, I wouldn't have been surprised if that caused a crash, but you say its working so I'll believe you :) If you do encounter any problems in the future, setting it to a small value (e.g. 0.01) would be playing it safer.

Regarding the "road as one shell" problem, maybe Shift-B would work better than Shift-F? That enlarges the shell briefly, and in the latest release which you have now, you can keep typing it while the shell is still flattening. Often the problem shells flatten better if stretched out first.

Anyway, send me the weighted mesh and I'll take a look if its going to be a problem for you. Save a UVL file just after you've applied the weights map, and all the poly weights will be saved in the file.

Phil

[b514c4fa]

Zero definitely works. I noticed that it compressed all of the linear black zones described in my previous post to nothing. Initially it looked like I had fewer shells! But when I selected those polys within Modo, then Shft A to focus on them in the UV tab, I zoomed in to the lower right corner, where they used to be located at a larger size. But I will keep the 0.000000001 trick in my back pocket in case things blow up. Or, if you know it is going to be a problem, maybe a value of zero in that box is converted to something like 0.00000001 within your subroutine?

In case anybody runs into this problem in Modo, the process that worked best for me was to have two files open, my original file, and the result of Headus .obj opened in a second file. Then I could go into my UV tab within Modo, Copy UVs from the Headus .obj file, and paste those into a new UV map in my original file. I initially tried copying the geo in, and that created problems with rotated polygons (I think) or overlapping polys, or something. I tried cleaning that combined geo with a Modo meshcleanup script, and that didn't work. Copying UVs only worked great, so that is the way to do it, at least within Modo.

I tested the process on my cave scene, where I have something like 13 4k maps that I would like to combine into one map, the source of my suggestion for UV size based on camera distance. My initial maps were 4k, and my final baked out map was 8k. So I have a couple of questions. I can't seem to figure out how to change my max map size to 8k, or 8192x8192 within Headus. In my Headus prefs I can't seem to go over 4. I tried the arrow, and I tried manually inserting a number. I have a Boxx 8750, with 25 GB RAM, so I think I can handle it. Is it possible to change the maximum above 4k? That way when I use the Bleed value it is giving me the best possible packing and a real pixel number around the shells.

The second question relates to the preservation of pixel density near the camera. I have done the bakes a couple of times (Headus is working like a champion by the way) in order to try to preserve my near field pixel density. The last time my weight numbers were at .5 and 50, and I still lost quality in the near field, where I am most concerned about it. So I am having to cycle through the bake out process, which is a time consuming process, several times. I can imagine going into my maps, comparing a few shells, and coming up with the next number to try. However, Headus already automatically collects a lot of this type of info, and it seems like it would be a fairly simple calculation to figure it out exactly. Headus calculates the % coverage, I think as a subroutine of the packing process. If you input one of the initial feeder maps, and used the values measured by Headus and the map size (the % coverage x resolution?), that should give you a pixel density that should be used at the high pixel density end of the packing scale. For those shells nearest the camera (with a weight map color of 1) that pixel density should be preserved if I am baking to a larger output map. If the output map is not larger, then for sure I am going to lose resolution in the near field, so I wouldn't normally be doing that. After figuring out the pixel density of the near field, I think a squared function with distance rather than linear might be the right weighting relationship. Making those calcs in detail once would make the whole thing extremely user friendly. So I encourage you to do that in the long term.

I might also be able to adjust this from my distance to camera gradient, and making white map to a value greater than zero, so that a larger portion of my near field isn't compressed. Thinking about that leads to this question: if my gradient map value is 1, i.e. white, is there zero compression? Maybe that is the solution, to somehow clamp white at zero compression? So then the process would be to make sure that the near field shells are in their 4k res scale packed within my 8k map and had a white value on my weight map before I go into Headus? If that were the case, then only non-one values could possibly have compression. That might be an easier solution than doing the calculations.

Anyway, after using it several times, I would say it is working very well as is. Thanks again for writing that.

Sorry, I don't have Camtasia, so I can't make a video for you of what I am doing. However, I would be happy to do the video if you pay for the Camtasia. Are you interested in that kind of a deal?

Dave

[headus]

"maybe a value of zero in that box is converted to something like 0.00000001 within your subroutine?"

I'll leave it as it is I think. If it aint broke, don't fix it :)

"In my Headus prefs I can't seem to go over 4."

Is that the "Trace Max Rez" setting? It doesn't affect the packing at all, its just a resolution setting for maps loaded into the UV view for tracing over.

As far as the packing goes, there's isn't a way currently to set a specific pixel value for the bleed or map resolution. You only have those quality settings (Fast, Mid, Best) and the "best" is only working on a map rez of 512. Any higher and you'd be waiting a long long time for the final result. If you're prepared to wait overnight for a result, I could look at adding a fourth option.

"... preservation of pixel density ..."

I didn't really follow all of that, but I'm wondering if multiple passes are necessary? The relationship between distance to camera and the ideal weight may not be linear, so tweaking the gamma of the greyscale image in a paintbox could work. If you do work out a gamma setting or some other manipulation that works, I can then incorporate that into the GUI.

"if my gradient map value is 1, i.e. white, is there zero compression?"

Only if the Weights Load max value is 1.0. If the weights map is white, and the max value is 1, then those polys aren't scale up or down, they would preserve their size. However, if other polys are shrunk, and you repack, those shells would increase their UV coverage because there's that extra room now.

Phil

[b514c4fa]

Phil,

The map resolution setting I am wondering about is the Map Rez under the Optimize tab. Mine seems stuck at 4k, and I can't seem to figure out how to change it. I have a bleed setting of 4, i.e. I want 4 pixels around each shell. If I want an 8k map, and I am stuck at 4k, I could use a bleed of 1 knowing that when I use it I am going to expand it by 4. But I would rather know exactly how big my map is and control the bleed exactly, especially since I want to lock some of my shells. So is there a way to set my Map Rez to 8k?

I have existing 4k maps, and it is the near camera portions of those 4k maps that I don't want compressed at all. If they get bigger, I am okay with that, even though they aren't going to gain any quality that way. However, knowing that a value of 1 doesn't compress or expand, we might be able to use that to our advantage. My process already includes copying all of my UV maps into one map. So if I can change my output map to 8k while preserving the near camera areas by using values of 1 in my gradient and in the stretching weights, I can make sure that a) my near camera polys aren't compressed during the copying into one map, and b) that my gradient is set to one for the near field polys I don't want to compress. I don't really care how small everything else is in my map, only that it isn't overlapping, as the only other info I need is the gradient value. So the plan would be to make all non-unitary portions of the UV map scaled down enough to fit, then baking out their gradients.

If you could "lock" the unitary values so they don't expand or compress, then a "gamma" value could be applied within Headus on the remainder of the shells. The value of 1 would produce no change for the unitary areas even if you changed the gamma (exactly what we want). But other values would be expanded or contracted as required to fit within my final map size. That would produce the best possible result, i.e. no data loss in the near camera area, and as much compression as required in the areas farther away as required to fit within my final map resolution (which is hopefully bigger than 4k). That process sounds easier than any calculation of before and after resolution.

Is that possible?

Dave

[headus]

Sorry, missed this posting ...

" Map Rez under the Optimize tab. "

Ahhh, OK ... that's just for the flattening ... the optimize will stop when the shape changes by less than a pixel, based on that rez setting. Its not connected to the packing at all.

" So is there a way to set my Map Rez to 8k? "

No, sorry, not currently. I'll look at a way to set the packing rez explicitly, as an alternate to the descriptive "Fast, Mid, Best" settings.

"If you could "lock" the unitary values so they don't expand"

I could add the option to lock shells if you want, if all of its polys are white. The when you re-optimize, they wont be touched; only shells with some grey in them will be affected.

Phil

[b514c4fa]

That locking feature would be perfect. As you said, then only non-white would be re-sized (shrunken - based on camera distance). This is generally the behavior you would want: to compress distant UVs/maps.

Being able to make larger maps would also be nice. Of course you can always pretend it is 4096x4096, then actually paint at 8192x8192. But the bleed thing is a nice feature to have, especially when transferring things between different programs. But that is a simple enough calc to make if for some reason it is hard to do.

Thanks,

Dave

[headus]

Just thought I'd let you know I haven't forgotten about this. I've been working on the packing ... making it faster, so that when you opt for higher resolution fit calculations, it doesn't grind completely to a halt.

Also, while I'm in "optimizing code" mode, I've been looking at the handling of large meshes (i.e. >100k polys). At the moment, if you cut a flattened shell in two, UVLayout thinks for several seconds before producing the result.

Phil

[headus]

OK, finally, the new beta has been uploaded (look on the uvlayout.com Support Extras page). It doesn't have the locking thing yet, but the packing is faster and final padding results are much closer to the value you set.

Also you'll see that you can explicitly set the map resolution now in the packing panel. The quality setting still has a part to play though, so you can set you rez at 4k for example, then select "Fast" and the packing will be a lot faster but less accurate. Select "Best" quality and you'll be waiting a while for the result, but it'll be tighter.

And finally, there's a new "Dont Resize Shells" option which you might find useful. When that's ticked, the packing is super fast, but there will be space left over. Its for those who want to pack, but don't want the shells (or UV box) scaled in any way. If there's no enough space, the shells spill out into other tiles.

Phil

[oesponda]

Hello Phill,

Im using v2.07.02 and found that this new feature is gone, there is no estra row below local, smooth, reset buttons.

I realized because I was going to use the feature for a job Im working on. Not really a big deal this time, but wanted to ask you if you plan to get the feature back in a future release or if it's gone forever... Althought is not a feature you might use everyday, it's very useful from time to time.


Regards,
Orlando.

[headus]

I decided it was probably of limited interest to most users, so hide it away to keep the GUI less cluttered. Also I was a bit pressed for time at the last release date, so by hiding it I didn't need to document it ;)

Go to the GUI Preferences and tick "Show All GUI Controls" to bring those controls back.

Phil

[oesponda]

Aha! Nice trick hehe.

Thanks.