Normalize UVs Maxscript
polycounter lvl 18
Normalize UVs maxScript
Let me know if you find any bugs.
I find it works best if you put it in your Unwrap UVW context quad menu.
As with all macroscript containers, put the .ms file into 3dsmax/scripts and use "run script" to run the script once, which will add the macroscript to your Customize UI menu - look in the "MoP's Tools" group for "Normalize UVs" and put it on a hotkey/quadmenu/toolbar.
Let me know if you find any bugs.
I find it works best if you put it in your Unwrap UVW context quad menu.
As with all macroscript containers, put the .ms file into 3dsmax/scripts and use "run script" to run the script once, which will add the macroscript to your Customize UI menu - look in the "MoP's Tools" group for "Normalize UVs" and put it on a hotkey/quadmenu/toolbar.
Replies
i cant seem to download the script.
question - do you put this script in ...\scripts\startup?
thanks,
Rom
snowblindstudios.com
Put it in ..\scripts\ and run it once from Max, then assign it through the Customize menu.
It kind of freaked me out when the UVW-Editor window disappeared and things started flashing but it made it back ok.
Maybe I should make it check the number of polys and only start a progress bar if there's a lot of work to do, that'd probably be more friendly.
cheers,
Rom
snowblindstudios.com
I also squashed a bug where the script would error out if you ran it on an object with an Unwrap UVW modifier already applied, but you didn't have the modify panel open.
So yeah, re-download and re-run it
cheers,
Rom
snowblindstudios.com
Known issues: It will not work if you have a topology-changing modifier in the stack below your Unwrap UVW, for example Symmetry, since it can't get corresponding poly selections.
I'll try to update it with a graceful solution to this at some point.
[/ QUOTE ]
Have you tried using snapshotasmesh ? Use a snapshotted mesh for things you would need to calculate from the polymesh.
Edit: Eh, I said screw it and just did the copying method. Doesn't seem much slower really, and it means it now works if you have stuff like Symmetry in the stack below your Unwrap UVW.
Updated:
http://www.greveson.co.uk/scripts/normalizeUvScale.ms
TODO: Make it so that you can select just one or two elements and have it normalize those in relation to the unselected elements, or in relation to only the selection. This will probably require a pop-up dialog so you can choose "normalize all" or "normalize selection", then pick if you want to normalize the selection only in relation to itself, or in relation to all the UV elements.
The script can be run from a hotkey, toolbar button, or quad menu shortcut - all of those methods should produce the same results.
If you can send me a sample scene where this can be reproduced consistently (providing it's not NDA'ed or private), that'd be a great help.
thx.
It REALLY doesn't like mirrored/welded UVs though. yeow.
Good for fully unique unwraps
Vassago: You're right, it does seem to go a bit crazy on welded & mirrored elements.
Just to confirm, if you run it on UVs that are welded & mirrored, all the other UV elements get scaled really small, right?
I notice it works fine if your mirrored sections are unwelded (which they should be most of the time, for normalmapped assets anyway?), problems only arise if a mirrored section is welded - I imagine it's a problem in the UV area calculation at that point. I'll check it out tomorrow night.
I'll also give it a spin on Max2008 at work tomorrow and see if I can figure out what's breaking there. Hopefully it's something simple
You have a lot of elements stacked on top of each other and then welded together, which means that for each of those elements, it's calculating the whole element's geometric area, but then only getting about half the UV area since it comes across the same UV coords more than once.
Personally I would avoid doing UVs like that anyway (ie. stack them but don't weld)... but that's just me, and I should probably find a way to make the script deal with situations like this anyway.
Might take a while though... we'll see.
Oh, and I think I know why you were getting a transparent wireframe in Max2008 - were you using a similar file you sent to me? The material has an alpha map for opacity, and I think the script is just scaling your UVs so small that they end up completely covering a transparent area of the texture. If you applied a different material I bet you'd see the mesh is still all there and healthy
I'm also considering trying to make an EPoly version of UVPaint, sounds like an interesting challenge for me to try and improve my scripting skills with
cheers,
Rom
snowblindstudios.com
Vassago: After some more debugging it turns out that in fact some pieces of your mesh are returning UV areas of 0.0, which I think is cos of their small size ... again not something I tested myself, but obviously a huge problem, so I'll try to fix it ASAP!
The reason I'd never do this is because recently I've only been working on normalmapped assets, and welding UVs changes how most engines/viewers calculate their tangents, so you get more predictable and generally better results when you don't weld mirrored/stacked parts - plus a lot of the time you will move stacked parts out of the 0-1 range by 1 UV unit for baking purposes, so it's impossible to weld them anyway.
So yeah, it's not a bad thing, and I don't mean to sound like I'm telling you not to do it, it's just something I don't do anymore
I will use your scene as a test-bed for fixing various aspects of the script, since it seems like a really good scene for troubleshooting with (lots of different sized elements, both welded/unwelded and mirrored/unique).
SERIOUSLY looking forward to that EditPoly UVPaint. Would be nice if that can be done.
I've fixed the issues with mad scaling when you've got mirrored/welded parts... it was actually a pretty easy fix and partially an oversight on my part. The script now works perfectly on the majority of the objects in your test scene (and everything I threw at it myself).
...then I ran into a different issue (again on your test scene, Vassago), but this doesn't seem to a problem with my scripting or your models, but more like a Max issue itself.
Here's an image of the issue:
Basically as soon as you convert this particular object to Editable Mesh (either through the modifier stack in the standard way, or through the Maxscript "snapshot" command), it decides to kindly remove about 8 edges.
Which means that the polygon counts no longer match up between the original object and the snapshot. Great.
So now, I've given it two separate routes for the script to go through - so that it will only use the snapshot method if there are other modifiers in the stack, and just skip that whole process if you just have a base EPoly with an Unwrap UVW modifier on top.
Still, this is something that shouldn't happen... I blame Max!
Stuff to come later will include ability to normalize only selected UVs either relative to the selection, or relative to the whole UV set's average scale. I will probably end up implementing a pop-up floater window for that.
(and YAY for not having to write it myself!)
Thanks again for the script! Normalize selection would be great!
Nice tip, Vig. I'll keep that in mind if I run into that issue.
A UV Paint re-write sounds great. MoP on a roll. With sauce!
Sometimes I want the UVs to bend around a curve, like how the UVs bend around the top of a torus.
It would be cool if the script had an option to auto-straighten the curve into a straight UV. So a texture could tile around the bend.
To solve stretching, it could also either break the verts along one side (because the faces are usually trapezoids) or keep the string of faces completely whole (more stretching, but avoids seams between faces).
I have some notes at work from Zola about his script, when I asked him about it way back when. I'll dig them up on Monday.
I just noticed another stupid thing I did in my script here (basically just duplicates the object twice for no reason and deletes them both afterwards), not a huge issue, but I've uploaded the tweaked one anyway... thanks for the feedback so far
/drools at the thought of UV paint working in 2008
OK, I've added ability to normalize only selected elements. If you have no selection, or if you're at the base subobject level, it'll normalize everything.
If you have even just one vert/edge/face of an element selected, it will include that entire element in the calculation.
Hopefully that method makes the most sense, I thought about including different options but decided I didn't want a popup menu or options thing, it all works from the same command this way.
Again if you come across any errors or bugs, please let me know and I will try to fix them.
I will also look at trying to make the whole script faster, I'm sure it will be possible, but I have other things to work on for now
[ QUOTE ]
If UVPaint can't work in some situation then there is a good reason. It takes your cursor position in the viewport and projects it to the main grid; between these two points there is a line which intersects the actually painted face. If your view direction is near parallel to the main grid then I got an invalid projection. If your "viewport camera" is above (* below) the grid and looks upward (* downward) then I also have an invalid projection point. So it is important to look against the grid while painting.
This is another problem that I have to solve in one of the future versions....
UVGrabIt is a tool that makes you able to pick a vertex and grab its UVs with your cursor around it. So you can fix some bad distortions of mapping on a lowpoly mesh object by hand.
[/ QUOTE ]
UVGrabIt was a grayed-out link on his site (still is!). It sounded interesting, like you could pick a vert in model-space and wiggle the mouse to get the UVs to slide around on the model, right in the viewport. Getting that working with your soft-select radius mouse gizmo might be cool too.
Anyhow, some ideas to play with. Thanks for looking into it MoP.
http://www.scriptspot.com/3ds-max/autoscale-uvw
Even in Edge mode, I cannot scale - all I can do is move.
Any ideas???
Updates/notes:
- I'm using Max 9 for this.
- Reset XForm doesn't do anything
- If I select the faces through the viewport, they can be selected. From there, I can scale, rotated, etc
- Only the object i ran the script on is effected. Anything new I make is fine
- Starting a new max scene and merging in the problematic one doesn't fix the issue
- Hmm - I've brought it in to Max 2009 and in the UV Editor it seems to be selecting something thats very large, although if I zoom out for awhile I can never see its boundaries. Nor can I delete it. I'll keep on fiddling in Max 2009 to see if I can find a solution.
- Here's a screenshot of what my Max 9 screen is looking like. If I apply the modifier, go to Face mode, then click anywhere inside the UV editor that Red + shows up, as if its selecting something. But I cannot delete whatever it is, but I feel as though it is whats causing the issue. At lease in Face mode. In Vert mode, that UV Editor is completely white.
To summarize the problem - I've lost all major functionality through the UV editor.Update #2!
Problem found! It seems as though this script runs in to problems on meshes that were created from splines - even when they were switched to editable poly's long ago. Quite odd. Anyhow, the problematic areas meshes were box mapped and I've continued on.
Works wonders for getting the lightmap UV's all scaled correctly to start with. Very helpful.
(sure i can workaround with copy & pasting the uv channels, but thats shitty
PeterK: It proportionally scales the UV elements, so the UV proportions match the 3d space proportions. Here's an example of the same idea...
If you put a checker map on the model and your checkers are all different sizes, the script will fix it so the checkers are all the same size.