It works fine for me in 2009. What kind of issue are you having?
The only problem I've ever run into is when unwrap is applied to multiple objects.
AFAIK the script needs UVUnwrap on top of the modifier stack (and an edit poly underneath?).
Outside of that it works GREAT.
Really? I thought I fixed that bug. I will check it out. I think I have a better algorithm now though, since I wrote a version of this for Maya and ended up improving it a lot.
I also wrote a nice UV-line-relax script in both Maya and Max, I will see if I can get clearance to post those since I did them for work.
renderhjs: Sure, just please include a link to my site ( www.greveson.co.uk ) in any "about" or "help" or "readme" stuff that accompanies the script, and say that this part was made by Paul "MoP" Greveson.
Also don't be surprised if I also use it in some sort of "uv-tools" pack at some point in the future
Feel free to try and improve it too, I think there may be one or two bugs or easy improvements if you look - if you do alter it, just re-post a link to the new version in this thread.
That sound ok?
Hope you don't mind me bumping this thread but am trying to use this on max2009 but with no luck. It makes my uv's vanish and mesh goes grey. Any ideas? I've been messing around with welding a bit and wondering if that could be the problem as it's brought up earlier in this thread.
not sure where you picked that up but I assume it meant (in the context) beeing able to unwrap multiple objects at once.
In other words selecting multiple objects and then applying the UVW unwrap modifier. Within the UVW-unwrap editor you then see all of the selected objects in its UV space each with a different shell wireframe color.
Max 2008+ has this feature though its rather incomplete and not yet supported fully on the maxscript side. At least I have plenty of situations that don't work out well with that way - so in the end I still merge My objects into 1 Poly/ Mesh and then unwrap that.
I see. Nevermind then, thought it was some magical new thing that took your mesh and unwrapped the stuff all nice and neat without having to manually do it. hehehe.
I too merge all my objects into one editable mesh or poly and unwrap.
Speaking of unwrapping;
There's got to be an easier way than how I do it.
1) I finish my model reset xform etc.
2) I make a reference copy of the model and then break the reference copy apart (into elements). I flatten out the peices so that they all lay along one axis. Sometimes I'll apply a UV map on a different axis depending on the angle, etc.
3) Once I've done all the unwrapping, mapping, I then save the UVW layout.
4) I unwrap my original model, load the UVW, and presto done.
-Is there an easier way of doing this, without going out and buying some expensive tool?
-What method do you guys use?
This is why the normalize UV tool is going to be really good for me since it'll speed up the process a lot.
1.) finish model(s)
2.) select all objects together and run some maxscript to merge them all together (its just some xReset + attach multiple objects to 1 together)
3.) unwrap this 1 object using either UVlayout or TexTools
4.) merge stack + select elements and split mesh back to separate parts + setup pivots
never really worked with the load UVW stuff since it requires that you have the same vert (and texture Vert) order on your model. In most of my cases its absolutely useless because verts change and I often add / remove split or merge meshes in between.
Maybe check out TexTools as its free and works with max 9 - 2010.
Especially for aligning shells I use it a lot even if I use another tool in between sometimes - it even has the normalize Script by Mop included which I use a lot as well. You can ask me all about it since I wrote most of it.
Roadkill is another free tool that is standalone however just like UVlayout and some other commercial tools. It main functionality is to speed up seam marking and relaxing shells. I never had luck with earlier version they run at a unusable performance but maybe that changed now or it was because of my computer who knows,- at least worth checking out.
Trying to normalize 793 UV elements on a vehicle, as I run the script the screen flashes with every element. It does all 793 but then freezes. I left it for 15mins but no change.
Tried resetting xform before doing it too and this does all 793 but then all my uv's are missing.
Is this tool just for small things? (My vehicle is about 13k)
I'm going to use retard speak because I'm not sure how it happens technically. But I am able to keep it from happening with an odd set of rituals so maybe it will shed some light on it...
Problem(s):
I've noticed it freaks out when not all of the mesh is unwrapped in a way it understands.
Part of the unwrap is garbled in some way, like part is super huge or all the edges are welded so there isn't a boarder.
Or part of the model is using the default unwrap that is trashed in some way and hasn't been properly unwrapped yet. Something funky and out of the norm.
I also notice that if it doesn't crash while normalizing I'll get one red pixel in the upper left corner and there is a huge piece that seems to go on forever. I can't map that piece but it does go away if I restart 3dsmax...
Fix:
Anytime I plan to normalize a model (which is every time) I start off with a method that unwraps every piece of the the model fully, it seems to keep it from happening.
With that said, its still a great script and I have a hard time getting along with out it.
capone: Do you have a test scene you could send me or upload to try out? PM me if you do. I never tried it on anything as intense as what you've described (I don't think I tested it past 50 shells, let alone 700!).
Vig: Hmm, yeah, I could definitely see issues with trying to normalize pieces which aren't mapped correctly, since the geometry to UV area ratios will get all crazy. I could probably do a more aggressive check for that (there's already one IIRC but maybe not hard enough).
I'd tend to use this normalizing script only on specific selected UV shells instead of entire objects, which may help since it'll only normalize the ones you've selected which are usually correct. In general I regard this whole procedure as a final step after everything's been unfolded anyway, prior to laying it out.
Left it running for a hour today, still no success. Tried putting it in a new scene as a .obj, nope. What's weird is even if I select just a few elements it counts it as 231 no matter how many are selected, weird.
Surely there has to be a solution? All game studios will need to normalize their UV's yet there isn't a tool that does it with complicated meshes?
I've just gone and done it the long way. I detached it into 8 pieces and used normalize on all, worked for all but one. Then I attached them all and changed the scale to try and get the aspect ratio as similar as possible. So I think it's about 90-95% correct now but I just wish I had the comfort of knowing it was all 100% in ratio by using this tool on all pieces in one go.
I'd be interested in hearing if anybody has ever got it to work with a 10k+ mesh?
I'm not sure what your meshes look like or how well they relax but you can normalize when you relax a selection of pieces.
Now of course that doesn't always work on things that don't relax well but before MoP wrote this script it was the only real way of quickly normalizing lots of pieces. Besides doing it manually.
capone I've got it to work on a very complex mesh with about 20k tris. It chugged for about 15 minutes on my work computer but eventually sorted itself out.
What I typically do nowadays though is normalize everything to the default pixel density with renderhj's script (I haven't actually used MoP's, I use render's that uses MoP's) rather than trying to normalize them in relation to each other. Then I just scale all my stuff up/down to fit my UV window.
I find that often I'll come across pieces that don't relax properly so doing a relax to hundreds of uv element's at the same time doesn't work (just tried, lots of skewing). I'd like to hear possible reasons why relax sometimes doesn't work, the only solution I've found is that sometimes meshes can be fixed with a reset x-form.
This command has a different name to the old one, so if you have any hotkeys/toolbar buttons/quad menus set up, remember to change them to use the new version!
The new version shows up in the Customize UI menus under "MoP's Tools", called "Normalize UVs" (the old one was called "Normalize UV Scale").
If you want to delete the old macroscript so it doesn't show up anymore, you will find it in a folder something like this:
On Windows XP it'd be C:|Documents and Settings\ instead of C:|Users\.
You can also right-click on the item in the Action list in Customize UI, it'll give you an "Edit Macro Script" option which will open the script, showing the location of the file.
I've also updated the info on the first page if you've never got the script before.
Please let me know if you run into any bugs.
The only known issue so far is that the progress window will sometimes stop updating, although the script is still running. I can't figure out what's causing it, it seems random!
Next on my list is ability to support multiple unwraps. Not sure how hard that will be, never done it before. Also I need to revise how it handles objects with modifier stacks.
oh... The script I've been using all along wasn't mop's script at all o.O
Just tested mops old script and now I see what you mean that it takes ages to calculate... in fact it looks like my max is going crazy in mem usage as a result of using mops old script so I had to alt f4 it
Tried the new mop script as well, also takes amazingly long to calculate/spikes mem usage/forces alt f4.
(tested using a 25k tri mesh btw)
This is what I've been using, I don't even remember where I got it from but it works perfectly for me and much quicker (and less code!);
(
local uv = selection[ 1 ].modifiers[ #unwrap_uvw ]
undo "Standard Relax" on
(
uv.unwrap2.MoveSelected [0.0,0.0,0.0]
uv.relaxByFaceAngle 200 0.0 1.0 false
-- Now compensate for any scaling caused by the image aspect ratio.
local fixWidth = 1.0
local fixHeight = 1.0
-- Solution if no texture is being used...
if uv.getCurrentMap() == 1 then (
fixWidth = uv.getRenderWidth() as float
fixHeight = uv.getRenderHeight() as float
)
if uv.getCurrentMap() > 1 then (
fixWidth = uv.texMapList[ uv.getCurrentMap() ].bitmap.width as float
fixHeight = uv.texMapList[ uv.getCurrentMap() ].bitmap.height as float
)
uv.ScaleSelectedCenter ( fixWidth / fixHeight ) 2
)
)
)
on a side note, anyone have any idea where I got this script from?
Yozora: That one is mine too, heh... but it's not a normalizing script. That one just relaxes the selection and matches the scale to any bitmaps applied. It's pretty basic, not much more than a standard Relax.
This Normalize UV Scale script actually takes the real UV scale compared to the polygon surface area of each UV shell and scales each shell accordingly so that they all have the same pixel density on average. It doesn't affect the shape of the UVs at all other than to scale them to the best density, so it will keep your unwrap as it was, but corrects the ratios.
You tested it on a 25k model and had to end process on 3ds Max? I tested here on a 33k model and it took about 20 seconds, although it does depend on the number of unique UV shells. Eg. a higher-poly object with less UV elements will probably process faster than a lower-poly object with hundreds of UV elements.
If possible, could you PM me a link to the scene that was causing trouble? There may be some cases I haven't dealt with correctly, I've only tested on a few scenes here, and I'd like to make it as robust as possible.
Normalize is something I never use then. If you highlight everything and relax them then it does what normalize does anyway, keeping the pixel density equal for each shell. I generally relax everything before laying them out instead of laying it out first and then normalizing and then fixing the layout Isn't that a bit backwards and unnecessary?
I straighten wonky edges right at the end since I'm relaxing so often there's no point doing it earlier.
Or maybe its not as accurate as I think it is? hmm but I have never ran into problems with lining up lines of pixels running from 1 shell to another while texturing before... (the kind of problems that would occur if the shells didnt share equal pixel density)
WOW awesome MoP! Those are some great improvements! The speed is amazing, its almost instantaneous for a lot of the stuff I'm working on.
It doesn't seem to undo, I need to keep undoing until it gets to a previous action that can be undone?
I also have one of those meshes that has a few wonky UV shells and it won't normalize correctly without selection. All of the shells seem to disappear. If you're interested, HERE is the mesh (3dsmax2010).
The bad shells are always in the upper left corner of the editor window no matter how you zoom or scroll the window. They can't be selected on their own, unless you select all (or know what pieces they are and select them in the 3D viewport). This isn't a result of the script they where jacked up before I ever installed it.
It's easy to get around this problem, (select all, deselect the good UV's, map the bad, problem solved) but normalize doesn't seem to undo so it causes a bit of a problem.
Vig: Good call, I didn't even try to undo, haha! Thanks for the sample scene, I'll take a look today.
Yozora: It's true, Relax when laying out multiple UV shells does normalize them while you're working, but that's not really something that's applicable in all situations.
For example, what if you're working on an old mesh, or someone else's mesh, or if you've added some new parts to a model and want everything to share the same pixel density? You can't use Relax then, since it'll break your current layout and undo any custom unwrapping you may have done.
The point of this script is purely to fix scaling without adjusting the unwrap, and I see this used nearly every day by tons of people during production (and for hobbyist models).
Just because you don't personally use it in your workflow doesn't mean it's completely redundant
Normalize is something I never use then. If you highlight everything and relax them then it does what normalize does anyway, keeping the pixel density equal for each shell. I generally relax everything before laying them out instead of laying it out first and then normalizing and then fixing the layout Isn't that a bit backwards and unnecessary?
I straighten wonky edges right at the end since I'm relaxing so often there's no point doing it earlier.
Or maybe its not as accurate as I think it is? hmm but I have never ran into problems with lining up lines of pixels running from 1 shell to another while texturing before... (the kind of problems that would occur if the shells didnt share equal pixel density)
Relax can normalize but it also relaxes trashing a lot of work. MoP's script just fixes the scale, preserving any tweaks you've done.
It MIGHT be ok to keep trying to relax certain shells like boxes and cylinders as it normalizes the other shells because they're so simple but anything that keeps trying to solve/relax as the other pieces normalize is a mess.
This script allows you to fix the scale at any point in the unwrap process.
I used the relax to normalize method and it worked ok until this script came along, never looked back since.
OK, updated the download. It now correctly supports undo.
It wasn't actually my fault that it wasn't working, I just forgot to account for the annoying Max bug where doing UV manipulations through script isn't picked up properly unless you add a ".moveSelected" command to the script. I had to do this on all my UV scripts so far to make Undo work, without it, Max just doesn't pick up on certain UV commands (such as ".scaleSelectedCenter", in this case).
Just re-download and re-run it, should undo properly now.
Vig: I tried out your Refuel03 scene, I don't get any issues at all with running the script on the Refuel object (which appears to be the only object in the scene). I've tried running it with and without an Unwrap UVW modifier applied, it all seems fine in both cases.
I'm using 64-bit Max 2010 on Windows 7 here.
Ahh, yea my main system at home is a dinosaur, XP 32bit, I'll have to test it out on other machines that aren't so old.
It's not a big deal especially now that undo works. I've only hit that wonky UV problem once or twice and it has always been at home... so I wouldn't be surprised if its specific to that machine or 32bit. I saved that mesh specifically because it was jacked up, heh.
I remember you mentioned the crazy undo thing before, I used it in one of my scripts after you mentioned it a few months back works great, really really stupid of max to work like that but at least it has a work around unlike a lot of other broken stuff in maxscript...
Anywho thanks for the update its damn near bullet proof now! Thanks a bunch I can't live without it
mm ok I see it's uses, I rarely add bits to existing meshes.
And I just tested it again, it didnt crash, took about 45 secs to normalize my 25k mesh.
I just tried to undo it, wow it sounded like my pc was dying For some reason undoing it takes a lot more effort than doing it. I let it choke for about 2 mins before I decided to force 3d max to close.
Tested it on a "normal" model (4k tris ish), undoing works flawlessly and almost instantly.
Went back to 25k model, this time the "getting elements" progress bar stopped moving at 40% but after 45 secs or so it worked anyway... (last time I forced it to close when this happened because I thought it crashed)
Weird, the progress bars were working fine on the first attempt. Tried undoing it again, and this time my pc really felt like it was dying, you know when it uses 100% cpu and everything you do including moving the mouse pointer or bringing up the task manager takes ages/lags... anyway, that happened for like 4 mins until I eventually forced it to close.
Weird. Any chance you can share that mesh? I'd really like to try and debug and see why it's taking so long.
And yeah, the progress bar stopping is a known issue, although I have no idea what causes it. It seems completely random and I can't consistently recreate it. I ran the script 5 times in a row on capone's 33,000 triangle mesh, and it work flawlessly 4 out of 5 times, on the third time through it froze up the progress bar during the "Getting areas" step about 3/4 way through, although it still processed the mesh and got the right result in the same time. It just decided to stop updating the progress
I've also seen it not update the progress bar on other meshes, at various stages, none reproducible or consistent. I'm going to guess it's a maxscript refresh bug of some sort. If anyone else has experienced this on other scripts I'd love to know what causes it!
Nope sorry can't send you, but I can help diagnose!
Ok I have tested it more again, undoing the 25k mesh (which we'll call "the ship" from now on, since its a ship) actually does work (after enduring 4mins of pc dying ).
But then I opened up an old character and duplicated and attached the model several times until it totalled 27k tris, and then I separated the uv island shells from each duplicate and scaled them all randomly.
Normalizing this took about the same time as the ship, but undoing it was almost instant!
So theres definitely a problem with the ship... the only differences I can see between my duplicated characters and the ship was;
The ship:
* has 2 textures applied
* is huge in units
* has a lot more shells
* shells overlap alot more
* 1 of the shells that use a the other texture uses a small tiling 256x512 wood-floor texture, so that shell is MUCH bigger than the rest of the ship which uses a 2048x1024 texture
So I applied a default texture and then scaled down the model, and then applied reset xform and collapsed stack.
Surprisingly this actually reduced the processor usage so I scaled down the ship even more until it fit into the default 3d max "grid" and reset xform again
Now when I undo it does it almost instantly.
There, diagnosed! Model size in units affects the speed and processing power required to undo a normalization.
To confirm my theory I went back to my characters and scaled them up by like 100x, and then reset xform+collapsed. And....... undo worked fine..... so my theory was wrong lol damnit :<
Sooo.... I tried scaling the ship down to 3d-max-grid-size + reset xform + collapsing once more just to confirm it did really make undoing instant, and .... OMG ! It didnt work! So I thought to myself, I must of forgot a step... and thankfully I realized I did miss one step which was at some point on my first attempt, I scaled down the massive tiling wood floor shell to match the rest of the ship better. Doh!
So new conclusion! The bigger the differences of shell size that need to be normalized, the more it affects the speed and processing power required to undo a normalization.
I was kinda right, it used less processing power (I know this because I can move with my mouse and type etc) but it still took about 4 mins...
So now there really is only 1 thing to do.... reopen original ship, make the massive tiling wood floor shell smaller to match rest of ship, scale ship to size of grid, reset xform, collapse. And it WORKED.
Final conclusion! Model size and the original differences in shell size affects the speed and processing power required to undo a normalization!
1 more test to confirm. Went back to my characters.... I made them 100x bigger AND made one shell like 10x bigger than everything else. And undo worked flawlessly. Godamnit
Real Final Conclusion: My ship is a messed up model
Haha! Well, thanks for the thorough testing, it definitely gives me something to try out.
The most obvious factors for increasing the time it takes to process are 1. number of UV shells, and 2. number of polys per UV shell.
The size (relative or not) of the shells should make no difference at all - all the script does is calculate area per polygon. This is probably the slowest part. I will definitely try it out on some more complex meshes and see if I can optimise further.
broken uvVerts:
I had recently some frustrations (and before) with dead UV verts that cause operations like scale selections to let some UVverts go infinity (it even traces as #infin or something close to that).
From what I know if you merge objects (attach, merge,...) sometimes a UVunwrap vert table can be incomplete or broken.
The results are if you select associated faces or verts and apply some maxscript uvunwrap operations like scale, move, rotate,... (just basic stuff) it goes to infinity resulting into a select type cursor all the time (because the face or shell is infinite big) and impossible to repair going any forward (of course you can undo, but you just can't touch those faces/ verts).
Another time I noticed this was the difference between using the macroscript selectAll (recorded from the macrorecorder) and using for example the uvUnwrap methods of getting the uvVerts amount and or the polyOp.getTvverts something. So there is no consistency and you can actually access dead texture UV verts.
Its super frustrating at points and the only thing that solves it for me is exporting to FBX or something else and re-import it. Because that will rebuild the UV table in a clean way. I plan on writing a maxscript that can hopefully repair broken meshes (fixing broken smoothing group errors as well) by simply rebuilding a copy purely using maxscript.
I have to check out the newer version and see perhaps if I can port it to multi object selections as well (max2008+).
Today I found some stuff (including me being an idiot for the past 2 years) which has speeded it up by a further 25%. Capone's test mesh which used to take 80 seconds on the original script, and 20 seconds on the modified one yesterday, now takes 15 seconds after my tweaks today
I've mostly implemented the "multi unwrap" support, it wasn't too hard in the end, but a couple of weird bugs have surfaced as a result of supporting multiple objects. It'll probably take a day or two to iron out, but hopefully after that it'll be even more useful.
I'd also like to tweak it so that it'll accept a target "pixel density" value instead of just doing an average normalize. Shouldn't be too difficult.
Thanks Mop! I use this script all the time with the the speed improvements it`s even more awesome!! Any chance it could work with multiple meshes selected?
vik: I've already got a prototype working at home which supports multiple meshes, and is 25% faster than the current one too
Just need to do some final refinements and bugfixing then I'll roll it out!
alz: Could do. Measurement of what, though?
For example, you'd need to have a bitmap of some sort assigned to determine texel density. If not, I'd have to start adding dialog boxes for entering texture height and width, and I kinda like it as a one-shot button at the moment.
vik: I've already got a prototype working at home which supports multiple meshes, and is 25% faster than the current one too
Just need to do some final refinements and bugfixing then I'll roll it out!
Just so I'm sure I'm not imagining things, is this already in the version that's on your site?
Cause I'm trying to normalize across multiple objects and it gives an error (asking to select a single object).
Nope never was released that I know of. It only works on a single UVW Unwrap, not on multiple instances of UVW Unwrap.
You can join the objects together, run it then detach.
You might want to check the version that was included in TexTools I think renderhjs did some modest upgrades to it and that might of been one.
yup though erics code hasn't changed much. The normalize script is 80% about the same I think.
If you want to read or apply a texel ratio (as averal value) from a object and apply it to multiple you need to use the Get and Set texel ratio tools.
Get:
picks a ratio always from just one object. The ratio is calculated as average triangle area from TexureSize / WorldUnit size.
Set:
once you have entered or picked a value you can select multiple objects and assign that same texel ratio to the shells of those objects
if everything goes fine it should create uvUnwrap modifiers to those objects that don't have one on top and do the relative scaling of each shell.
Replies
but well support for multi unwrap would be nice
The only problem I've ever run into is when unwrap is applied to multiple objects.
AFAIK the script needs UVUnwrap on top of the modifier stack (and an edit poly underneath?).
Outside of that it works GREAT.
A very helpful script, cheers MoP
Only works if it's top of the stack, though. Took me a few frustrating attempts before I figured that out, heh.
I also wrote a nice UV-line-relax script in both Maya and Max, I will see if I can get clearance to post those since I did them for work.
http://boards.polycount.net/showthread.php?t=60553
it would be a nice addition I was almost about to try it myself but yours already works great
Also don't be surprised if I also use it in some sort of "uv-tools" pack at some point in the future
Feel free to try and improve it too, I think there may be one or two bugs or easy improvements if you look - if you do alter it, just re-post a link to the new version in this thread.
That sound ok?
of course you can use my snippets as well- or improve them.
will create a icon now for your script
You can PM me the mesh you have issues with, I implemented the same code in TexTools,- I might be able to find out something.
Sorry don't have Max '09, only have Max 8. Was thinking of upgrading eventually.
This is an awesome script.
In other words selecting multiple objects and then applying the UVW unwrap modifier. Within the UVW-unwrap editor you then see all of the selected objects in its UV space each with a different shell wireframe color.
Max 2008+ has this feature though its rather incomplete and not yet supported fully on the maxscript side. At least I have plenty of situations that don't work out well with that way - so in the end I still merge My objects into 1 Poly/ Mesh and then unwrap that.
I too merge all my objects into one editable mesh or poly and unwrap.
Speaking of unwrapping;
There's got to be an easier way than how I do it.
1) I finish my model reset xform etc.
2) I make a reference copy of the model and then break the reference copy apart (into elements). I flatten out the peices so that they all lay along one axis. Sometimes I'll apply a UV map on a different axis depending on the angle, etc.
3) Once I've done all the unwrapping, mapping, I then save the UVW layout.
4) I unwrap my original model, load the UVW, and presto done.
-Is there an easier way of doing this, without going out and buying some expensive tool?
-What method do you guys use?
This is why the normalize UV tool is going to be really good for me since it'll speed up the process a lot.
2.) select all objects together and run some maxscript to merge them all together (its just some xReset + attach multiple objects to 1 together)
3.) unwrap this 1 object using either UVlayout or TexTools
4.) merge stack + select elements and split mesh back to separate parts + setup pivots
never really worked with the load UVW stuff since it requires that you have the same vert (and texture Vert) order on your model. In most of my cases its absolutely useless because verts change and I often add / remove split or merge meshes in between.
Maybe check out TexTools as its free and works with max 9 - 2010.
Especially for aligning shells I use it a lot even if I use another tool in between sometimes - it even has the normalize Script by Mop included which I use a lot as well. You can ask me all about it since I wrote most of it.
Roadkill is another free tool that is standalone however just like UVlayout and some other commercial tools. It main functionality is to speed up seam marking and relaxing shells. I never had luck with earlier version they run at a unusable performance but maybe that changed now or it was because of my computer who knows,- at least worth checking out.
Tried resetting xform before doing it too and this does all 793 but then all my uv's are missing.
Is this tool just for small things? (My vehicle is about 13k)
Problem(s):
I've noticed it freaks out when not all of the mesh is unwrapped in a way it understands.
Part of the unwrap is garbled in some way, like part is super huge or all the edges are welded so there isn't a boarder.
Or part of the model is using the default unwrap that is trashed in some way and hasn't been properly unwrapped yet. Something funky and out of the norm.
I also notice that if it doesn't crash while normalizing I'll get one red pixel in the upper left corner and there is a huge piece that seems to go on forever. I can't map that piece but it does go away if I restart 3dsmax...
Fix:
Anytime I plan to normalize a model (which is every time) I start off with a method that unwraps every piece of the the model fully, it seems to keep it from happening.
With that said, its still a great script and I have a hard time getting along with out it.
Vig: Hmm, yeah, I could definitely see issues with trying to normalize pieces which aren't mapped correctly, since the geometry to UV area ratios will get all crazy. I could probably do a more aggressive check for that (there's already one IIRC but maybe not hard enough).
I'd tend to use this normalizing script only on specific selected UV shells instead of entire objects, which may help since it'll only normalize the ones you've selected which are usually correct. In general I regard this whole procedure as a final step after everything's been unfolded anyway, prior to laying it out.
Surely there has to be a solution? All game studios will need to normalize their UV's yet there isn't a tool that does it with complicated meshes?
If you wanted to make it more bullet proof I wouldn't object, but its not keeping me or a lot of other people that know from using it.
I'd be interested in hearing if anybody has ever got it to work with a 10k+ mesh?
Now of course that doesn't always work on things that don't relax well but before MoP wrote this script it was the only real way of quickly normalizing lots of pieces. Besides doing it manually.
What I typically do nowadays though is normalize everything to the default pixel density with renderhj's script (I haven't actually used MoP's, I use render's that uses MoP's) rather than trying to normalize them in relation to each other. Then I just scale all my stuff up/down to fit my UV window.
I spent the last couple of evenings completely rewriting this script.
I've changed it over to using a custom rollout window with a progress bar display there, I really don't like Max's global progress bar!
The good news...
capone sent me his test mesh, which is around 33,000 triangles with 795 separate UV elements to process.
Here's some figures from processing this entire UV set for this mesh on my computer:
So this script is approximately 4x faster, with less flickering and general annoyance.
Download mopNormalizeUVScale.ms here!
- If you want to delete the old macroscript so it doesn't show up anymore, you will find it in a folder something like this:
- C:|Users\<username>\AppData\Local\Autodesk\3dsMax\2010 - 64bit\enu\UI\usermacros
- On Windows XP it'd be C:|Documents and Settings\ instead of C:|Users\.
- You can also right-click on the item in the Action list in Customize UI, it'll give you an "Edit Macro Script" option which will open the script, showing the location of the file.
I've also updated the info on the first page if you've never got the script before.Please let me know if you run into any bugs.
The only known issue so far is that the progress window will sometimes stop updating, although the script is still running. I can't figure out what's causing it, it seems random!
Next on my list is ability to support multiple unwraps. Not sure how hard that will be, never done it before. Also I need to revise how it handles objects with modifier stacks.
Just tested mops old script and now I see what you mean that it takes ages to calculate... in fact it looks like my max is going crazy in mem usage as a result of using mops old script so I had to alt f4 it
Tried the new mop script as well, also takes amazingly long to calculate/spikes mem usage/forces alt f4.
(tested using a 25k tri mesh btw)
This is what I've been using, I don't even remember where I got it from but it works perfectly for me and much quicker (and less code!);
(
local uv = selection[ 1 ].modifiers[ #unwrap_uvw ]
undo "Standard Relax" on
(
uv.unwrap2.MoveSelected [0.0,0.0,0.0]
uv.relaxByFaceAngle 200 0.0 1.0 false
-- Now compensate for any scaling caused by the image aspect ratio.
local fixWidth = 1.0
local fixHeight = 1.0
-- Solution if no texture is being used...
if uv.getCurrentMap() == 1 then (
fixWidth = uv.getRenderWidth() as float
fixHeight = uv.getRenderHeight() as float
)
if uv.getCurrentMap() > 1 then (
fixWidth = uv.texMapList[ uv.getCurrentMap() ].bitmap.width as float
fixHeight = uv.texMapList[ uv.getCurrentMap() ].bitmap.height as float
)
uv.ScaleSelectedCenter ( fixWidth / fixHeight ) 2
)
)
)
on a side note, anyone have any idea where I got this script from?
This Normalize UV Scale script actually takes the real UV scale compared to the polygon surface area of each UV shell and scales each shell accordingly so that they all have the same pixel density on average. It doesn't affect the shape of the UVs at all other than to scale them to the best density, so it will keep your unwrap as it was, but corrects the ratios.
You tested it on a 25k model and had to end process on 3ds Max? I tested here on a 33k model and it took about 20 seconds, although it does depend on the number of unique UV shells. Eg. a higher-poly object with less UV elements will probably process faster than a lower-poly object with hundreds of UV elements.
If possible, could you PM me a link to the scene that was causing trouble? There may be some cases I haven't dealt with correctly, I've only tested on a few scenes here, and I'd like to make it as robust as possible.
Normalize is something I never use then. If you highlight everything and relax them then it does what normalize does anyway, keeping the pixel density equal for each shell. I generally relax everything before laying them out instead of laying it out first and then normalizing and then fixing the layout
I straighten wonky edges right at the end since I'm relaxing so often there's no point doing it earlier.
Or maybe its not as accurate as I think it is? hmm but I have never ran into problems with lining up lines of pixels running from 1 shell to another while texturing before... (the kind of problems that would occur if the shells didnt share equal pixel density)
It doesn't seem to undo, I need to keep undoing until it gets to a previous action that can be undone?
I also have one of those meshes that has a few wonky UV shells and it won't normalize correctly without selection. All of the shells seem to disappear. If you're interested, HERE is the mesh (3dsmax2010).
The bad shells are always in the upper left corner of the editor window no matter how you zoom or scroll the window. They can't be selected on their own, unless you select all (or know what pieces they are and select them in the 3D viewport). This isn't a result of the script they where jacked up before I ever installed it.
It's easy to get around this problem, (select all, deselect the good UV's, map the bad, problem solved) but normalize doesn't seem to undo so it causes a bit of a problem.
Yozora: It's true, Relax when laying out multiple UV shells does normalize them while you're working, but that's not really something that's applicable in all situations.
For example, what if you're working on an old mesh, or someone else's mesh, or if you've added some new parts to a model and want everything to share the same pixel density? You can't use Relax then, since it'll break your current layout and undo any custom unwrapping you may have done.
The point of this script is purely to fix scaling without adjusting the unwrap, and I see this used nearly every day by tons of people during production (and for hobbyist models).
Just because you don't personally use it in your workflow doesn't mean it's completely redundant
It MIGHT be ok to keep trying to relax certain shells like boxes and cylinders as it normalizes the other shells because they're so simple but anything that keeps trying to solve/relax as the other pieces normalize is a mess.
This script allows you to fix the scale at any point in the unwrap process.
I used the relax to normalize method and it worked ok until this script came along, never looked back since.
It wasn't actually my fault that it wasn't working, I just forgot to account for the annoying Max bug where doing UV manipulations through script isn't picked up properly unless you add a ".moveSelected" command to the script. I had to do this on all my UV scripts so far to make Undo work, without it, Max just doesn't pick up on certain UV commands (such as ".scaleSelectedCenter", in this case).
Just re-download and re-run it, should undo properly now.
Vig: I tried out your Refuel03 scene, I don't get any issues at all with running the script on the Refuel object (which appears to be the only object in the scene). I've tried running it with and without an Unwrap UVW modifier applied, it all seems fine in both cases.
I'm using 64-bit Max 2010 on Windows 7 here.
It's not a big deal especially now that undo works. I've only hit that wonky UV problem once or twice and it has always been at home... so I wouldn't be surprised if its specific to that machine or 32bit. I saved that mesh specifically because it was jacked up, heh.
I remember you mentioned the crazy undo thing before, I used it in one of my scripts after you mentioned it a few months back works great, really really stupid of max to work like that but at least it has a work around unlike a lot of other broken stuff in maxscript...
Anywho thanks for the update its damn near bullet proof now! Thanks a bunch I can't live without it
And I just tested it again, it didnt crash, took about 45 secs to normalize my 25k mesh.
I just tried to undo it, wow it sounded like my pc was dying
Tested it on a "normal" model (4k tris ish), undoing works flawlessly and almost instantly.
Went back to 25k model, this time the "getting elements" progress bar stopped moving at 40% but after 45 secs or so it worked anyway... (last time I forced it to close when this happened because I thought it crashed)
Weird, the progress bars were working fine on the first attempt. Tried undoing it again, and this time my pc really felt like it was dying, you know when it uses 100% cpu and everything you do including moving the mouse pointer or bringing up the task manager takes ages/lags... anyway, that happened for like 4 mins until I eventually forced it to close.
I don't really feel like trying to do it again
And yeah, the progress bar stopping is a known issue, although I have no idea what causes it. It seems completely random and I can't consistently recreate it. I ran the script 5 times in a row on capone's 33,000 triangle mesh, and it work flawlessly 4 out of 5 times, on the third time through it froze up the progress bar during the "Getting areas" step about 3/4 way through, although it still processed the mesh and got the right result in the same time. It just decided to stop updating the progress
I've also seen it not update the progress bar on other meshes, at various stages, none reproducible or consistent. I'm going to guess it's a maxscript refresh bug of some sort. If anyone else has experienced this on other scripts I'd love to know what causes it!
Ok I have tested it more again, undoing the 25k mesh (which we'll call "the ship" from now on, since its a ship) actually does work (after enduring 4mins of pc dying
But then I opened up an old character and duplicated and attached the model several times until it totalled 27k tris, and then I separated the uv island shells from each duplicate and scaled them all randomly.
Normalizing this took about the same time as the ship, but undoing it was almost instant!
So theres definitely a problem with the ship... the only differences I can see between my duplicated characters and the ship was;
The ship:
* has 2 textures applied
* is huge in units
* has a lot more shells
* shells overlap alot more
* 1 of the shells that use a the other texture uses a small tiling 256x512 wood-floor texture, so that shell is MUCH bigger than the rest of the ship which uses a 2048x1024 texture
So I applied a default texture and then scaled down the model, and then applied reset xform and collapsed stack.
Surprisingly this actually reduced the processor usage so I scaled down the ship even more until it fit into the default 3d max "grid" and reset xform again
Now when I undo it does it almost instantly.
There, diagnosed! Model size in units affects the speed and processing power required to undo a normalization.
To confirm my theory I went back to my characters and scaled them up by like 100x, and then reset xform+collapsed. And....... undo worked fine..... so my theory was wrong lol damnit :<
Sooo.... I tried scaling the ship down to 3d-max-grid-size + reset xform + collapsing once more just to confirm it did really make undoing instant, and .... OMG ! It didnt work! So I thought to myself, I must of forgot a step... and thankfully I realized I did miss one step which was at some point on my first attempt, I scaled down the massive tiling wood floor shell to match the rest of the ship better. Doh!
So new conclusion! The bigger the differences of shell size that need to be normalized, the more it affects the speed and processing power required to undo a normalization.
I was kinda right, it used less processing power (I know this because I can move with my mouse and type etc) but it still took about 4 mins...
So now there really is only 1 thing to do.... reopen original ship, make the massive tiling wood floor shell smaller to match rest of ship, scale ship to size of grid, reset xform, collapse. And it WORKED.
Final conclusion! Model size and the original differences in shell size affects the speed and processing power required to undo a normalization!
1 more test to confirm. Went back to my characters.... I made them 100x bigger AND made one shell like 10x bigger than everything else. And undo worked flawlessly. Godamnit
Real Final Conclusion: My ship is a messed up model
The most obvious factors for increasing the time it takes to process are 1. number of UV shells, and 2. number of polys per UV shell.
The size (relative or not) of the shells should make no difference at all - all the script does is calculate area per polygon. This is probably the slowest part. I will definitely try it out on some more complex meshes and see if I can optimise further.
Thanks, Yozora!
I had recently some frustrations (and before) with dead UV verts that cause operations like scale selections to let some UVverts go infinity (it even traces as #infin or something close to that).
From what I know if you merge objects (attach, merge,...) sometimes a UVunwrap vert table can be incomplete or broken.
The results are if you select associated faces or verts and apply some maxscript uvunwrap operations like scale, move, rotate,... (just basic stuff) it goes to infinity resulting into a select type cursor all the time (because the face or shell is infinite big) and impossible to repair going any forward (of course you can undo, but you just can't touch those faces/ verts).
Another time I noticed this was the difference between using the macroscript selectAll (recorded from the macrorecorder) and using for example the uvUnwrap methods of getting the uvVerts amount and or the polyOp.getTvverts something. So there is no consistency and you can actually access dead texture UV verts.
Its super frustrating at points and the only thing that solves it for me is exporting to FBX or something else and re-import it. Because that will rebuild the UV table in a clean way. I plan on writing a maxscript that can hopefully repair broken meshes (fixing broken smoothing group errors as well) by simply rebuilding a copy purely using maxscript.
I have to check out the newer version and see perhaps if I can port it to multi object selections as well (max2008+).
Today I found some stuff (including me being an idiot for the past 2 years) which has speeded it up by a further 25%. Capone's test mesh which used to take 80 seconds on the original script, and 20 seconds on the modified one yesterday, now takes 15 seconds after my tweaks today
I've mostly implemented the "multi unwrap" support, it wasn't too hard in the end, but a couple of weird bugs have surfaced as a result of supporting multiple objects. It'll probably take a day or two to iron out, but hopefully after that it'll be even more useful.
I'd also like to tweak it so that it'll accept a target "pixel density" value instead of just doing an average normalize. Shouldn't be too difficult.
Just need to do some final refinements and bugfixing then I'll roll it out!
What about adding a dialog that can tell you what the current measurement is (or will be)?
For example, you'd need to have a bitmap of some sort assigned to determine texel density. If not, I'd have to start adding dialog boxes for entering texture height and width, and I kinda like it as a one-shot button at the moment.
Just so I'm sure I'm not imagining things, is this already in the version that's on your site?
Cause I'm trying to normalize across multiple objects and it gives an error (asking to select a single object).
You can join the objects together, run it then detach.
You might want to check the version that was included in TexTools I think renderhjs did some modest upgrades to it and that might of been one.
If you want to read or apply a texel ratio (as averal value) from a object and apply it to multiple you need to use the Get and Set texel ratio tools.
Get:
picks a ratio always from just one object. The ratio is calculated as average triangle area from TexureSize / WorldUnit size.
Set:
once you have entered or picked a value you can select multiple objects and assign that same texel ratio to the shells of those objects
if everything goes fine
more info here:
http://renderhjs.net/textools/