Home Technical Talk

UV Packing with 3dMax

polycounter lvl 7
Offline / Send Message
[PB]Snoelk polycounter lvl 7
Hi there

i made a script for automaticly assign a texture size based on the texel per unit settings. this is used for a lowpolymesh to bake with a highpoly. since the bake functions in max are a little limited, i implemented a port to xnormal as well. works pretty fine but there is a huge problem.
to get the lowpoly mesh to work with real-time engines, the textures of the lowpoly should be a power of 2. this is also solved.
but as a matter of fact, sometimes the wanted size of the lowpoly texture will be 1518 pixel and 1300 for example. so the next power of two would be 2048 x 2048. the script also places the uv chunks without scaling inside this power of 2 texture. so we still got the texel / unit proportion.
now we come to the real problem. the uv packing inside max. it uses the uv space from 0 to 1 as box. it doesnt try to get the minimum uv space with the possibility for rectangles. if i manually try to move the uv chunks inside the uv space i can create a better usage of the uv space and the resulting image is 2048 x 1024. sounds not much but the texture size in bytes decreases dramaticly.
is there a way to solve this problem inside max ? i hope i dont have to create a weird script to pack the uv chunks myself.

Replies

  • renderhjs
    Options
    Offline / Send Message
    renderhjs sublime tool
    I have the feeling that I know who you are,- sounds familiar :D (and in case, sorry for the delay, been busy here),
    and welcome to polycount

    maybe there is a way of reversing the translation or scale so that if you use the packing (no rotation, just moving) and scale it back after it it fills out the rectangle size instead of the max square size.
    The downside would be that the padding size would be squeezed at one axis (in your case y-axis because its the shorter of the 2) - but that might be worth a shot before trying to write a packer algorithm yourself.

    code snippet:
    local p_s = (8/2048)--padding scale
    local u_s = 1/(2048/2048);--u/x scale
    local v_s = 1/(1024/2048);--v/y scale
    
    uv = selection[1].modifiers[#unwrap_uvw];
    uv.selectVertices #{1..uv.NumberVertices()};
    
    --scale it up to square size
    uv.scaleSelectedVerticesCenter u_s 1;--scale on the u axis
    uv.scaleSelectedVerticesCenter v_s 2;--on the v axis
    
    uv.unwrap2.pack 1 p_s false false true;
    
    --scale it back to rectangle proportion
    uv.scaleSelectedVerticesCenter (1/u_s) 1;--scale on the u axis
    uv.scaleSelectedVerticesCenter (1/v_s) 2;--on the v axis
    

    within the maxscript documentation there is the needed pack method explained (no rotation/ normalize,...)
    http://www.kxcad.net/autodesk/Autodesk_MAXScript_Reference_9/unwrap_uvw_modifier.htm
    <void>pack <integer>method <float>spacing <boolean>normalize <boolean>rotate <boolean>fillholes
    Lets you pack the texture vertex elements so that they fit within a square space.
    method - 0 is a linear packing algorithm fast but not that efficient, 1 is a recursive algorithm slower but more efficient.
    spacing - the gap between cluster in percentage of the edge distance of the square
    normalize - determines whether the clusters will be fit to 0 to 1 space.
    rotate - determines whether a cluster will be rotated so it takes up less space.
    fillholes - determines whether smaller clusters will be put in the holes of the larger cluster.

    hope that works out

    and no I still have not checked the total code out, still kind of busy here
  • [PB]Snoelk
    Options
    Offline / Send Message
    [PB]Snoelk polycounter lvl 7
    no problem for the delay ^^
    im tuning and fixing the scripts all the time.
    think im nearly ready now.
    the xnormal port rulez. will send you a version the next day.

    tested the idea from you but i dont get the result i want.

    think i need a recursiv function to test all possibility and remember them.
    the best solution is grabbed then. but as script .... :poly142:
    i dont think its fast *g*
Sign In or Register to comment.