UV Packer IPackThat

the last weeks i have been working on a uv packer. I could not find a good packer that can handle very complex shapes or holes.
The packer from Headus UV Layout is very close to it, but they are cases when it can't find a good solution.

I don't know what complications there are for implementing FBX (Licensing?) but it'd be great to have a file format that supports more than one UV set so you could pack lightmaps. To expand on that, if you import a mesh with multiple UV sets, you could pack each set with different settings, or leave one of the sets untouched.

when a UV shell has a hole, it could use that space with smaller UVs pieces.

this is already a main feature. the packer can handle holes in all variation. It can put a shell inside a hole which also contains a hole. And in this one also some shells can be placed, which also can contains holes etc pp.

That sounds handy. How about a snapshot feature? It sounds like your app can present different iterations, so being able to quick save different steps would be nice.

Can you lock rotation on shells? Sometimes it's good to say "I always want these shells to have this orientation".

mhh, will think about the snapshot feature.
Locking of rotations can be done on each uv shell you want. You can select some shells and lock the rotation for them. Other you only allow rotation about 90°. Some others you allow rotation steps with 5°.

I don't know what complications there are for implementing FBX (Licensing?) but it'd be great to have a file format that supports more than one UV set so you could pack lightmaps. To expand on that, if you import a mesh with multiple UV sets, you could pack each set with different settings, or leave one of the sets untouched.

Will have a look into FBX. FBX is a open platform with different SDK's for reading and writing it. But its a large and complicated SDK when i checked it last time.
Obj Fileformat can handle different UV layouts in some later versions. But not all can write this format.
Multi-Meshes are treated as one UV-Layout so far. Have to think about this feature to treat each Mesh seperatly.

One thing I also find annoying is that I need to find my overlapping UV's but every script/tool I have used only works sometimes. I often have to go searching around my UV map to find the extra UV's that are overlapped. With smaller objects this isn't a big deal, but for a 50k tri model, it is freaking annoying and a time killer.

So if you can detect overlapping uv's 100% accurately AND offset them by 1 in U or V that would be very useful for baking.

Keeping certain islands together is also useful if they both have the same type of material on the texture, because you can eliminate most of the gutter between them without having as many seam bleeding issues at lower mips.

Would be handy if the user was able to group a couple shells together and that the exterior shape/bounds of said group is treated as a single shell. But maybe that´s what you meant with cluster groups?

Either way, Im looking forward to watching the development of this tool. If it´s better than the packers that are currently available, IPackThat could easily become the most popular packing tool if you sell it for like 5 or 10 dollars or something. (Never underestimate microtransactions!!) Good luck!

Would be handy if the user was able to group a couple shells together and that the exterior shape/bounds of said group is treated as a single shell. But maybe that´s what you meant with cluster groups?

Either way, Im looking forward to watching the development of this tool. If it´s better than the packers that are currently available, IPackThat could easily become the most popular packing tool if you sell it for like 5 or 10 dollars or something. (Never underestimate microtransactions!!) Good luck!

thats what i mean with merging shells.
The grouping feature is something different.
You set 5 shells to group 1 and 5 shells to group 2.
The Shells with group 1 will try to stay together and group 2 shells also.
That way the shells are not spawned all over the area if the user uses grouping.

Looks awesome. Ran it on a test but seemed quite slow. Wish there was a progress bar haha

yeah, its not optimized yet.
the progress bar is feature i want to implement also

The packing algorithm i use wont be as fast as packing with via bounding boxes.
So it will be always slower. But it can squeeze a bit more out of a uv.
As a matter of fact it will be faster than packing by hand *g*

Will it ever actually finish on it's own? I always stop it with ESC after a few minutes.

nope, it will run forever until you stop. i could build in a max solution find count. so if it hits the count its automaticly stopping.
could be usefull for a later batch process where you fill in num obj files and pack them all thru.

Yeah sorry per shell. Guess it would be something you check before sending it off to be packed (assuming this is the primary goal and not something like UVlayout where you can manipulate)

will look into it. someone at my work wanted a text overlay over the shell with rotation steps and area size compared to max area. this info could be displayed as well. only need to think about very small uv shells.

Exporting from max 2015 w/ the "Maya" or "Zbrush" presets gives:
************** Exception Text **************
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index (goes on quite a bit from there).

None preset seems to work perfectly. Looks like it'd be quite a tight pack, nice.

Exporting from max 2015 w/ the "Maya" or "Zbrush" presets gives:
************** Exception Text **************
System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index (goes on quite a bit from there).

None preset seems to work perfectly. Looks like it'd be quite a tight pack, nice.

those presets got a strange obj asci layout. need to adress it.
anyways it should not crash. thats need to be adressed as well.

there is also a bug with stacked polygons. this i fiddled out yesterday. they are handled correctly but the area % will gone mad because they are all taken into account. but they should be taken into account only once.
Another bug happens when you import a uv set wich is not inside range from 0 to 1.
if the ranges of the uv set are all positiv (from 0 to 1+ in booth axis) all works out well. but if you got shells that are in the negative ranges (0 to -1) it will result in weird behavior)

Additional i think i got a solution for real stacked polygons. the first and that one with the largest amount of vertices (if you use ngons not tris) will be stay where it is. all other polygons that are using the same vertices will be offseted to x+1.

You know this really is super impressive. I've seen so many 'packing algorithms' that just do a barely acceptable job, but this is better than what one could do themselves almost (barring you working out some bugs). There's so many applicartions and engines that would benefit from this. Would you open-source your code?

Yep, set your margin size to half of what you want to be between the uv islands as this adds the margin value to every uv island. So if you want 8 pixels then set it to 4. You can visualize this with the display options in the upper left.

So it looks like I manually handpacked my 4096 Mech to 85% coverage. So I let it run in IPackThat over night for 10 hours. IPackThat was able to get to 83% coverage. I would love for it to be able to get to 90% in that time. I am running another test now with a fresh restart and all programs closed to see if I can maximize the count number to get a better amount of coverage over 10 hours.

I have some requests:

I had my UV's offset by 1 to bake. So when I loaded up my model it placed those as separate uv islands. Is it possible to have an option to move the offset uv's back? I could do this in my 3D package of course so it may be completely unnecessary if it doesn't fit within the scope of this tool.

I export all of my 3D files as FBX for my workflow. Is it possible to have multiple file types supported? .obj is just fine, but it would be 1 more extra file to export in my already massive sea of files. Again a picky request.

I used a 70k tri model at 4096 with a fast computer and it was still hanging a bit with no indication it was working. If there was a bit more visual indication it was doing some work that would prevent some slight confusion/frustration.

All in all this is potentially the best thing ever. So please keep on kicking ass.

You know this really is super impressive. I've seen so many 'packing algorithms' that just do a barely acceptable job, but this is better than what one could do themselves almost (barring you working out some bugs). There's so many applicartions and engines that would benefit from this. Would you open-source your code?

let me finish the basics of the tool first and get it out *g*
the core itself is already some sort of sdk. but they is no wrapper around it.
that are plans for the future

Yep, set your margin size to half of what you want to be between the uv islands as this adds the margin value to every uv island. So if you want 8 pixels then set it to 4. You can visualize this with the display options in the upper left.

not quite right. the margin is the total amount in pixeln. if you set it to 8 the min distance between each shape is 8 pixel. so if you want 8 pixels around each shape you would need to set it to 16.

So it looks like I manually handpacked my 4096 Mech to 85% coverage. So I let it run in IPackThat over night for 10 hours. IPackThat was able to get to 83% coverage. I would love for it to be able to get to 90% in that time. I am running another test now with a fresh restart and all programs closed to see if I can maximize the count number to get a better amount of coverage over 10 hours.

I have some requests:

I had my UV's offset by 1 to bake. So when I loaded up my model it placed those as separate uv islands. Is it possible to have an option to move the offset uv's back? I could do this in my 3D package of course so it may be completely unnecessary if it doesn't fit within the scope of this tool.

I export all of my 3D files as FBX for my workflow. Is it possible to have multiple file types supported? .obj is just fine, but it would be 1 more extra file to export in my already massive sea of files. Again a picky request.

I used a 70k tri model at 4096 with a fast computer and it was still hanging a bit with no indication it was working. If there was a bit more visual indication it was doing some work that would prevent some slight confusion/frustration.

All in all this is potentially the best thing ever. So please keep on kicking ass.

im on it already with the layered polygons (only one in 0-1 all others 1-2)
if you load an obj with uv's over 1 it will ask if you want to resize to 0-1 or remap 1+ to 0-1
i think i could make it ready this weekend.
fbx is somewhat new. need to read and understand the fbx sdk.
Thats not a task you make in one hour *g*