Rename multiple selected surfaces in the Surface Editor...

lardbros

Not so newbie member
Well... they sent it to a developer... trouble is it's more of a feature request than a bug... so it'll always get sent to the back of the queue.

I did have a few emails from them regarding this, and one of them did say that they were working on an over-arching modification to the import/export system I think, so maybe it's in the works?
 

jgutwin

Member
I was also struggling with material names being enumerated with every separate piece of mesh when importing an fbx file. Names like metal__1, metal__2 through metal__238 etc. I wrote a couple of python scripts to clean up some of the worst situations that were easiest to code. These are not 'all-purpose' but may be helpful in some of your FBX import situations.

The 2 scripts are named
SurfaceNameConsolodateQuickFirst.py
SurfaceNameConsolodateAggressiveAsk.py

The first one looks for the shortest matching material name that already exists. So 'metal__238' matches the shorter 'metal__1' and is renamed that. The aggressive ask version looks for the double or single underbar '_' on the right and ask if you want to shorten it with a yes no box. Enter and escape keys work for that but you have to go through a lot of asks for some files. Both of them try to avoid renaming a surface named 'material_155' to a surface named 'material'.
 

Attachments

  • pythonScripts.zip
    2.3 KB · Views: 198

Mr_Q

I've always been here
I ran this latest script you've posted on my mesh. I ran the version that asks and while it appears to work (YAY!) it does spit up a Python console error at the end.

CPython 2.7.5 (default, May 30 2013, 10:07:04) [MSC v.1500 64 bit (AMD64)]
Polygon #1 changed surface to "ThisIsANewSurface".
Traceback (most recent call last):
File "C:\Program Files\NewTek\LightWave11.6.3\support\plugins\third-party\SurfCollapser\SurfaceNameConsolodateAggressiveAsk.py", line 89, in <module>
raise exception
KeyError: 'vray'


When I run the version that doesn't ask, it produces no error but it also doesn't consolidate all the surfaces, only some. So that is not ideal.

Lastly, if I attempt to run either script a second time while in the same modeler session, even with another mesh, it will crash dump.
 

ninok5

New member
I was also struggling with material names being enumerated with every separate piece of mesh when importing an fbx file. Names like metal__1, metal__2 through metal__238 etc. I wrote a couple of python scripts to clean up some of the worst situations that were easiest to code. These are not 'all-purpose' but may be helpful in some of your FBX import situations.

The 2 scripts are named
SurfaceNameConsolodateQuickFirst.py
SurfaceNameConsolodateAggressiveAsk.py

The first one looks for the shortest matching material name that already exists. So 'metal__238' matches the shorter 'metal__1' and is renamed that. The aggressive ask version looks for the double or single underbar '_' on the right and ask if you want to shorten it with a yes no box. Enter and escape keys work for that but you have to go through a lot of asks for some files. Both of them try to avoid renaming a surface named 'material_155' to a surface named 'material'.



Thank you so much for the scripts! It worked. My import generated over 2000 surfaces all "black paint_1, black_paint_2, etc etc" and I though I was doomed to select each one at a time and then merge them all together. So really really appreciate it!

Newtek, this problem would be alleviated if there was a way to transfer the selection of surfaces in the surface editor onto the model in modeler. Something as simple as right click on a surface after multi selecting them and hitting "select polygons" or something along those lines. Then I could hit Q and assign a surface to them all. Currently the alternative to the scripts is to pull up the "w" menu, select 1 surface at a time, hit + and repeat until all are selected.
 

jeric_synergy

Axes grinder- Dongle #99
This is the kind of functionality that a low-level dev should be able to whip up IN A HURRY via Python/LScript, and should: I still feel like these little utilities should be addressed via scripting in a timely fashion, natively/officially.

+++++++++++

Hah, the inclusion of "Surface Editor" in the Firefox title bar was triggering my installation of AHK (it thought I was using the Surface Editor), causing "s" to be trapped-- I guess that just shows how tricky programming is, undermining my post. Dagnabit.... :jam: :eek:
 
Last edited:

MSherak

New member
The problem really is the FBX format. It will assign a surface per model when exported. Other packages read in the file and don't assume anything so you get everything that FBX has in it.. In this case a material per object if exported from MAX. I am sure there could be more options added to the FBX importer for Lightwave which could reduce the everything in the file to something more manageable. Place a feature request for condense multiple objects with same material name.

For now you need a script of plugin to do specifics in Modeler.

-M
 

jeric_synergy

Axes grinder- Dongle #99
I disagree: there's a fundamental weakness in dealing with mass Surfaces, and rather than exclusively dealing with FBX import, it would be better to have native tools to deal with ANY such situation.

It's a common problem: lots of software neglects the idea of dealing with multiple instances of {whatever}. EG, Adobe MUSE does not allow you to multiple select things to re-organize the Library folder (!?!?!). HUGE oversight in my eyes, and one that should be dealt with at a very low level in ALL the list-oriented interfaces. Same thing here.

That is: list operations should be robust and flexible.
 

RomanS

Roman
I was also struggling with material names being enumerated with every separate piece of mesh when importing an fbx file. Names like metal__1, metal__2 through metal__238 etc. I wrote a couple of python scripts to clean up some of the worst situations that were easiest to code. These are not 'all-purpose' but may be helpful in some of your FBX import situations.

The 2 scripts are named
SurfaceNameConsolodateQuickFirst.py
SurfaceNameConsolodateAggressiveAsk.py

The first one looks for the shortest matching material name that already exists. So 'metal__238' matches the shorter 'metal__1' and is renamed that. The aggressive ask version looks for the double or single underbar '_' on the right and ask if you want to shorten it with a yes no box. Enter and escape keys work for that but you have to go through a lot of asks for some files. Both of them try to avoid renaming a surface named 'material_155' to a surface named 'material'.




jgutwin - today you saved my day!!! Thanks for this very helpful plugin!
Roman
 

Iaian7

Motion Design Lead
I was also struggling with material names being enumerated with every separate piece of mesh when importing an fbx file. Names like metal__1, metal__2 through metal__238 etc. I wrote a couple of python scripts to clean up some of the worst situations that were easiest to code. These are not 'all-purpose' but may be helpful in some of your FBX import situations.

The 2 scripts are named
SurfaceNameConsolodateQuickFirst.py
SurfaceNameConsolodateAggressiveAsk.py

The first one looks for the shortest matching material name that already exists. So 'metal__238' matches the shorter 'metal__1' and is renamed that. The aggressive ask version looks for the double or single underbar '_' on the right and ask if you want to shorten it with a yes no box. Enter and escape keys work for that but you have to go through a lot of asks for some files. Both of them try to avoid renaming a surface named 'material_155' to a surface named 'material'.

John Gutwin, thank you so much for this. You just saved my hide on an imported object with hundreds of surfaces!
 

kopperdrake

Super Duper Member
Another thank you to jgutwin for the scripts - just had the same problem of hundreds of variations on a name after fbx import :thumbsup:
 

happy to help :)
especially thanks to Matt Gorner for creating it    
 

Ma3rk

Curmudgeon in Training
You might also check out the various multi-select, assign, consolidate, & renaming options in OD Tools too.
 

kopperdrake

Super Duper Member
The only reason I haven't yet bought Oliver's toolset is that I still haven't begun to use 2018 in anger. It sits here gathering dust whilst I wait for a project I dare use the new renderer on. I can see potential uses - where a PBR high-poly scene would kill Octane, but getting the time to play to get up to speed is a rarity.
 
Top Bottom