Level design/Art -pipeline improvements (Autodesk Maya)

Nightshade · November 30, 2012, 4:55pm

We are gonna start a new project soon (we are more or less in pre-production) and one thing we’ve learned about this last project is how absolutely crappy our art/level -pipeline was.
This project has been plagued by dev faults and I’m one of the people dedicated to improving it - not because I’ve been assigned to it but because I can’t stand inefficiency.

We use autodesk Maya and we on the art side all agree that we really need to start working with references coz well… with our current workflow we are wasting time.
Not having worked with it before, I sat down trying to get my head into how they work but found out things weren’t as smooth as I had hoped for.

I posted the stuff below at cgtalk but didnt get a single reply - maybe it was too techy?

Problem 1:
Creating a ref, moving it and then creating a proxy for it. Then “reload proxy as” to get the proxy visible. But the proxy spawns in origin and not where the reference model is at.
I thought the proxy was supposed to be linked with the ref but it seems like it’s a completely separate entity with it’s own transforms and everything. It just wont move along with the ref at all!!!

Problem 2:
How do you switch between proxy and reference view quickly? (on multiple references)
Proxy > reload proxy as > original, works good on multiple refs for switching “back” to reference view but you can’t do this to go into proxy view on multiple refs.

Problem 3: Namespace, group names and proxies…
I understand the prefix namespace stuff but why does the ref editor add RN*PM original and other crap to my reference names? For example, consider this flow:

Flow:

I create a reference, prefix “Foliage”, group name “palmTree_group” and proxy name suffix “LR” (lowres)
name: FoliageRN palmTree.mb
…okay, so it adds RN - which means what, reference node? I can live with that

I then add a proxy to it
name changes to: FoliagePM original palmTree.mb
PM is probably = proxy model, and “original” is the tag it seems. Can you just get rid of tags?

Now I dupe my reference, now we are starting to get name clutter
dupe name: FoliageRN1PM original palmTree.mb

why does it add RN1 on this one when the original doesn’t have it?

Whatever… So I move my refs around a bit (positioning these palm trees). And now I’m done, I have a lot of trees and I want to increase performance in the scene so I want to switch to the proxies. I select everything and select Proxy > Reload proxy as > FoliagePM1

This is where things are starting to become REALLY BOTHERSOME
First of all the refs doesn’t really switch out to their proxies properly: all the proxies appear in origin and not where the ref is. This I explained under “problem 1”.
Freezing the refs in place changes nothing, the proxies just doesn’t stick to the references.

Second nuissance: The names are now really, really horrible.
FoliageRNPM FoliagePM1 palmTree_lowres.mb
FoliageRN1PM FoliagePM1 palmTree_lowres.mb
FoliageRN2PM FoliagePM1 palmTree_lowres.mb

So am I missing something or are things really this horrible? I thought working with references was supposed to make level designing smoother - not give you a brain aneurism!!

Another issue:
So I let the palmTree.mb scene be the grandchild scene, and then I make a child scene with x5 palmTree’s in them, I name this child scene “palmTree_group.mb”. Now in the parent scene, I create a new reference, select the child scene (palmTree_group) and then I get another issue: palmTree_group is NOT referenced as a single object - no ofc not… Instead I get 5x references. Why?

I have a couple of other things to ask about sets and partitions but I’ll hold on to those questions a bit.

Theodox · December 1, 2012, 10:12am

Don’t want to hijack the thread on your practical questions, but in all seriousness:

Is there a way _not_to do this in maya?

Maya is frankly awful at large scale assembly tasks – everything from performance to selecting things in the scene to accurate preview is really subpar for something like most modern game levels. Building a custom editor is a signifcant undertaking but over time it will more than pay for itself vs using maya to do a job it’s not designed for. Nowadays you could build something more custom and to the point using Fabric or even by hacking the Unity editor.

Without knowing the scope and scale of your project its hard to be too proscriptive, but before you go down this road too far – do yourself a favor and consider alternatives (if not for this project then for the next). I’ve done two big projects using level editors built into 3d apps (max and maya) and I’m never going to do it again if I can help it.

Nightshade · December 1, 2012, 12:26pm

[QUOTE=Theodox;19191]Don’t want to hijack the thread on your practical questions, but in all seriousness:

Is there a way _not_to do this in maya?

Maya is frankly awful at large scale assembly tasks – everything from performance to selecting things in the scene to accurate preview is really subpar for something like most modern game levels. Building a custom editor is a signifcant undertaking but over time it will more than pay for itself vs using maya to do a job it’s not designed for. Nowadays you could build something more custom and to the point using Fabric or even by hacking the Unity editor.

Without knowing the scope and scale of your project its hard to be too proscriptive, but before you go down this road too far – do yourself a favor and consider alternatives (if not for this project then for the next). I’ve done two big projects using level editors built into 3d apps (max and maya) and I’m never going to do it again if I can help it.[/QUOTE]

Yea well all of us on the art side (we are three, me, another artist and a level/game designer) want to use UDK instead but since we are not calling the shots here, that isn’t an option.
And creating a custom level editor is something we also can forget about - the coders and the ppl in charge are just not interested.

I’ve only worked on two game projects but I think I know exactly what you are talking about. At my past workplace the level designers had their in-house editor for making worlds - and they were heavily backed-up by our engine group and excellent lead programmers. Anytime there was a problem, a lead coder, engine coder or TA would help out. But then, that was a much larger company… Here at Polarbit, levels/environments has always been made in Maya. Scale of the project? Well I can’t talk about our next one but I can say that we create 3D games for mobile platforms (windows phone, ipad/iphone, android, etc). And I can say that the level design pipeline has been absolutely horrible on this project (level designing in Maya without the use of references isn’t a very good idea). And the next project will be large enough to cause us brain aneurisms if we can’t start using references and proper scene hierchies.

Theodox · December 1, 2012, 2:05pm

In a previous job I tamed this beast somewhat by generating proxy models on the source side: every model would produce its own cheap, low-res proxy and only proxies would be placed by the level designers. That at least kept performance from being too horrible and avoided things like endless hunts for missing texture files. In your situation you could have two parallel file trees: one of ‘real’ assets the game uses and one of proxies with the same names and relative paths. That would make it easy to keep them in synch w/o naming convention blues.

I’ve never played with it, but the Unity editor apparently allows you to export FBX files. Maybe you could build in maya, lay out in unity, and parse the FBX export from their to get the level layout for conversion into the actual game?

Nightshade · December 1, 2012, 2:28pm

[QUOTE=Theodox;19196]In a previous job I tamed this beast somewhat by generating proxy models on the source side: every model would produce its own cheap, low-res proxy and only proxies would be placed by the level designers. That at least kept performance from being too horrible and avoided things like endless hunts for missing texture files. In your situation you could have two parallel file trees: one of ‘real’ assets the game uses and one of proxies with the same names and relative paths. That would make it easy to keep them in synch w/o naming convention blues.

I’ve never played with it, but the Unity editor apparently allows you to export FBX files. Maybe you could build in maya, lay out in unity, and parse the FBX export from their to get the level layout for conversion into the actual game?[/QUOTE]

That’s what I want to achieve: parallel file trees.
Maya’s way of handling references and proxies though seems very tacky (read my first post) with proxies not sticking to the real (ref) model - or the other way around - but having unique transform values. Also, the funky and non-sensical naming conventions you have little control over is driving me nuts. In an ideal world, whoever is doing level design need to quickly be able to switch between proxy and reference model. Laggy Maya scenes is something that has been a big problem for us - even with heavy use of layers and groups.
I’ve looked for some scripts to handle this better but there doesn’t seem to be any. I found this one called whitebox: http://www.creativecrash.com/maya/downloads/scripts-plugins/modeling/poly-tools/c/white-box-tool - but I think it’s pretty unsafe for several reasons (can’t replace stuff that are frozen, things are not instanced, it doesn’t work for scene hierchies but only “inside” individual scenes and so on)

Jredd · December 1, 2012, 8:24pm

Hi I’m still new to all this but I have an interest in pipeline development so my two cents worth… You could develop a script to handle the name changes when you are creating proxies and such to reduce clutter, I have an auto rigging script and any nodes/objects I create I control every name… And when you switch to proxies they all spawn in the center world space. You could query all of the models positions and put the coordinate data into the proper proxies? This could all be completely wrong since I have never worked professionally. Just been developing my own tools in my free time.

A lot of your issues seem fixable with scripting. But I have a feeling you’ll have to build something custom for your environment.

Nightshade · December 2, 2012, 8:25am

[QUOTE=Jredd;19199]Hi I’m still new to all this but I have an interest in pipeline development so my two cents worth… You could develop a script to handle the name changes when you are creating proxies and such to reduce clutter, I have an auto rigging script and any nodes/objects I create I control every name… And when you switch to proxies they all spawn in the center world space. You could query all of the models positions and put the coordinate data into the proper proxies? This could all be completely wrong since I have never worked professionally. Just been developing my own tools in my free time.

A lot of your issues seem fixable with scripting. But I have a feeling you’ll have to build something custom for your environment.[/QUOTE]

I know I can do all this with scripting but I don’t see a reason to. First off: Autodesk should have this sorted out already - it’s just stupid that they brag about scene hierchy organization in their promo videos, and then it’s not even working properly (or I’m doing it wrong).

Also, regarding proxies spawning in origin: Sure I could just make a script that copies the translate values from the ref models to the proxies - but the problem with that is that if the user accidently freezes the reference model, they are screwed.

Theodox · December 2, 2012, 12:52pm

Alas, there’s a reason why everybody bitches about referencing.

It sounds like you’re assembling the entire scene for final export from one maya file. Am I hearing that right? If so, you can simplify your problem set switching to a pure placement model for the assets – that is, you never reference the ‘real’ models at all. The editor would only ever see a flat , maybe even simplified, no-hierarchy, my-pivot-is-always-on-origin proxy. (I like to set the selection handle on the incoming object and make sure the original file is set to ‘reference’ display mode so there is no way to select the geometry at all). Abandon all hope of doing in-place edits to the referenced objects (that’s safer no matter what, it’s a feature that was always conceptually dangerous). The editor only exports its own meshes plus a list of reference placements. No proxy swapping, the assets are fairly simple to load and view, and the division of responsibility between assets and the level editor is clear and cleanly enforced.

The downside is obviously that the person making the level only sees the proxies not the ‘real’ objects. If your export-view cycle in the game itself is nice and quick (especially if you have live reload) that’s not a huge loss. If you have to spend 20 minutes rebuilding the game every time you move a rock , the desire for the editor view to be more accurate is correspondingly stronger.

TheMaxx · December 2, 2012, 1:04pm

Has anyone looked into the maya 2013.5 stuff? It looks like an attempt at instancing within maya. As I understand it you can set up source assets and save different resolutions, even GPU cache, and then place them into a level. Then you can flip between resolutions within the level file.

I didn’t dig too deep, but may be of some interest.

Nightshade · December 2, 2012, 1:12pm

[QUOTE=Theodox;19201]Alas, there’s a reason why everybody bitches about referencing.

It sounds like you’re assembling the entire scene for final export from one maya file. Am I hearing that right? If so, you can simplify your problem set switching to a pure placement model for the assets – that is, you never reference the ‘real’ models at all. The editor would only ever see a flat , maybe even simplified, no-hierarchy, my-pivot-is-always-on-origin proxy. (I like to set the selection handle on the incoming object and make sure the original file is set to ‘reference’ display mode so there is no way to select the geometry at all). Abandon all hope of doing in-place edits to the referenced objects (that’s safer no matter what, it’s a feature that was always conceptually dangerous). The editor only exports its own meshes plus a list of reference placements. No proxy swapping, the assets are fairly simple to load and view, and the division of responsibility between assets and the level editor is clear and cleanly enforced.

The downside is obviously that the person making the level only sees the proxies not the ‘real’ objects. If your export-view cycle in the game itself is nice and quick (especially if you have live reload) that’s not a huge loss. If you have to spend 20 minutes rebuilding the game every time you move a rock , the desire for the editor view to be more accurate is correspondingly stronger.[/QUOTE]

Yea we want to assemly everything in one (parent) scene before the final export - but there is no requirement to do in-place edits because it’s stupid (or as you put it: dangerous).
We just want a working scene hierchy. If someone decides that “those trees needs to be worked on a little bit more”, then there shouldn’t be any problems: an artist should then just be able to enter the child (or grandchild scene), do the necessary changes and then when the level designer reloads the parent scene, all changes appear there. Proxies are just to remove slugginess.

And our exporter ain’t the problem here - it’s actually rather fast considering the bad state of most things around here. Takes only a minute to export a level and have it in-game. So as long as we can get a working scene-hierchy going things will be much smoother. I’m not even asking for any fancy stuff here: I just want the proxies to STICK to the references without having to run some script or parent them or whatever. And I just want clean namespaces/name standards - and not the cluttery shit that Maya gives you as seen in my example in my original post

And I forgot to add that we are working with Maya 2012 - but an upgrade might come around (although I’m not really holding my breath) -_-

Thanks for all the replies but so far things are not really going in the right direction I’m afraid

EDIT: This is off-topic but Theodox are you a valve -employee?

Jredd · December 2, 2012, 1:37pm

[QUOTE=Nightshade;19200]I know I can do all this with scripting but I don’t see a reason to. First off: Autodesk should have this sorted out already - it’s just stupid that they brag about scene hierchy organization in their promo videos, and then it’s not even working properly (or I’m doing it wrong).

Also, regarding proxies spawning in origin: Sure I could just make a script that copies the translate values from the ref models to the proxies - but the problem with that is that if the user accidently freezes the reference model, they are screwed.[/QUOTE]

That’s a fair point on autodesk part. But so far in my workings I’ve found that when I control what maya is doing I get better results. When I start allowing the program to make choices is when I start to get into trouble. Does it suck that you’d have to spoon feed the program? Of course but you’ll get the results that you want instead of what the program decides.

On the freezing problem. You can still get the coordinates of a frozen object either through vector math or querying something besides its world space.

Theodox · December 2, 2012, 2:41pm

The reason I brought up the assembly bit is related to both perf and safety. Zipper used something like what you’re describing for the SOCOM games, and it was very unwieldy. Switching to a ‘placement’ based paradigm helped a lot with performance, and it also make it super clear what would be instanced in the game and what was custom geometry (as you can imagine, we needed tools for things like ‘import the source of this proxy model and turn it into local geometry I can edit in place’). The perf benefits were pretty substantial at the time (~ 2007, when maya perf was really an issue) .

A lot depends on scope: for an ios game, the level size is probably acceptable in a single maya scene anyway – certainly on a modern 64 bit machine with a good graphics card. There’s also a sort of mental translation that might make it easier to work with: If you’re building a level editor in maya, you probably want it to really behave like a level editor, not like a complex set of manual steps that artists need to remember and do correctly in Maya. One of the things that helps make that stick is putting some time into custom toolbars and controls – make the user see quite clearly that they are in ‘level edit’ mode and hide or disable things that could cause problems. You’re totally right that maya ‘should’ support scene assembly on a higher level - but apart from pretty trivial cases it really does not. Working around Maya’s limitations is what pays all our our mortgages, so we can’t complain too much

and Yup, I worked at Valve from 1998 to 2002 – Half life, Team Fortress Classic, Team Fortress 2, and counter-strike.

Nightshade · December 2, 2012, 2:44pm

[QUOTE=Jredd;19205]That’s a fair point on autodesk part. But so far in my workings I’ve found that when I control what maya is doing I get better results. When I start allowing the program to make choices is when I start to get into trouble. Does it suck that you’d have to spoon feed the program? Of course but you’ll get the results that you want instead of what the program decides.

On the freezing problem. You can still get the coordinates of a frozen object either through vector math or querying something besides its world space.[/QUOTE]

Yea sure - I can always query the bounding box and make the real model fit inside the bounds of the queried reference, but it’s not a fool-proof system: especially when you have an object with a cube-shaped bounding box.
But another reason I’m against making my own tools for Maya is that I’m not employed as a TA - I’m employed as a 3D artist. Everytime I sit down with something technical my boss gets annoyed, saying stuff like “are you scripting now Martin?”, “We have a deadline next week, Martin”. It doesn’t matter that I’m doing things to improve OUR workflow - things to improve the company - the people calling the shots just don’t want it. The other day for example I was having an argument with a lead coder about texture splatting (he was trying to tell me how hard it would be for “us” to work efficiently with that - and I just told him to let us artists deal with those problems). I just don’t get it. They want improvements but they don’t want us spending time doing the improvements… sigh. I know I shouldn’t complain about things like that but they really get to me: frustrating the shit out of me. Being forced to work in inefficient ways is downright demoralizing - at least to me. When I see something that needs improvements I feel a NEED to fix it.

[QUOTE=Theodox;19206]…Switching to a ‘placement’ based paradigm helped a lot with performance, and it also make it super clear what would be instanced in the game and what was custom geometry (as you can imagine, we needed tools for things like ‘import the source of this proxy model and turn it into local geometry I can edit in place’). The perf benefits were pretty substantial at the time (~ 2007, when maya perf was really an issue) .

A lot depends on scope: for an ios game, the level size is probably acceptable in a single maya scene anyway – certainly on a modern 64 bit machine with a good graphics card. There’s also a sort of mental translation that might make it easier to work with: If you’re building a level editor in maya, you probably want it to really behave like a level editor, not like a complex set of manual steps that artists need to remember and do correctly in Maya. One of the things that helps make that stick is putting some time into custom toolbars and controls – make the user see quite clearly that they are in ‘level edit’ mode and hide or disable things that could cause problems. You’re totally right that maya ‘should’ support scene assembly on a higher level - but apart from pretty trivial cases it really does not. Working around Maya’s limitations is what pays all our our mortgages, so we can’t complain too much

and Yup, I worked at Valve from 1998 to 2002 – Half life, Team Fortress Classic, Team Fortress 2, and counter-strike.[/QUOTE]
Could you elaborate what you mean with a “placement” based paradigm? Also, do you know of any Maya -tools (custom scripts) for working along those methods?

And yea I think that our scope isn’t too big. We have entire levels inside single Maya scenes right now and although it is very sluggish at times, it comes down to a) bad work PC’s and b) inefficient art pipeline. We don’t use refs or placeholders but every assets gets imported right away into a Maya scene. This is extremely tacky ofc because once we wanna do a change to an asset, that change is required in ALL SCENES that has that particular asset. No wonder we all joke about “brain aneurisms” all day long…

And fixing problems like this might be what pays your mortage. In my case I’m hired as a mindless drone - or an industrial worker at an assembly line. While they seem open to improvements and suggestions, and while they sometimes listen to us, their… priorities are not always the same as the words comming out of their mouths. It’s become quite obvious that I do not feel appreciated at my job right? I see so much talent at my workplace - both on the art side and the code side - and I see it being wasted due to well… many different things that I really shouldn’t talk about. I think I’ve said enough already actually…

OT: Cool, I envy you. Valve is such a cool studio, it must have been a great experience working there. I can’t wait for the announcement of HL3 and the new engine upgrades - always loved Valve’s games

Theodox · December 2, 2012, 3:41pm

It’s not unheard of for companies not to ‘get it’ the way people on TAO do. However, if you get it and show them how its done, they usually figure out that you’re worth listening to… or they lose you to somebody who does get it.

So just to be clear: even if you instance, say, a tree model all over your maya scene it is not instanced in the game? The actual level is really just a single huge honking model? If not, how does the engine now how to place and scale the objects?

Nightshade · December 2, 2012, 3:55pm

[QUOTE=Theodox;19208]It’s not unheard of for companies not to ‘get it’ the way people on TAO do. However, if you get it and show them how its done, they usually figure out that you’re worth listening to… or they lose you to somebody who does get it.

So just to be clear: even if you instance, say, a tree model all over your maya scene it is not instanced in the game? The actual level is really just a single huge honking model? If not, how does the engine now how to place and scale the objects?[/QUOTE]

No, meshes are not split up on a model basis - but on a material basis. There is no tree objects, or house objects, or rock objects - everything is combined by the exporter into one giant chunk, and split up according to material type by the engine.
And yea, it does seem very basic - I agree. But then I do not fully understand how our engine work but what I do understand is that it’s rather low-tech compared to other stuff when it comes to mobile games.
We’ve asked to move over to Unity or UDK several times but according to them it would cost too much (license cost for UDK for example), make us lose our “lead” (what lead we have I do not fully understand), and the transition period would put us behind. But I think they might have become too much in love with FUSE (our middleware/engine) than what’s healthy, and that they fully do not realize the potential of moving to say UDK or Unity. Sure it gives us the ability to port to just about anything: iOS, android, windows phone, PC, web browser - but when it comes to tech it’s way, way behind what you see in UDK - or whatever engine they use in the Real Racing games (Mint3D?). When that topic is brought up, they simply say we are an arcade racer developer - and that Firemint (Real Racing) are in the genre of racing simulators. And well… when it comes to the economy they know best - but I think they are wrong about not moving on to something more… modern.

Theodox · December 2, 2012, 6:16pm

Well, the polygon soup method has some pros and some cons. If you’re not dealing with big worlds – or high levels of interactivity it’s not completely bonkers, it’s certainly easier on the graphics hardware (especially if you have multiple targets) because implementing the instancing equation is not trivial and is platform dependent. For racing games I can see it working, since your probably not streaming and most geometry is not actually interactive.

I think you’re pretty much going to have to bite the bullet and do some tools development, even if most of it is just putting a less manual, more stereotyped wrapper around the default functionality. Effectively that pipeline locks you in to building a single very large model, and some combination of referencing and scripting is what you’re stuck with. 3 easy ways to help yourself:

create a script that ‘exports’ the asset with correct settings in the most compact, least worrisome format for the level editor. For example, you might want all of the branches in your palm tree as individual objects when you’re working with the palm tree, but not when you’re working in the editor: so have a process that flattens out the hierarchy, collapses the geometry into one mesh, deletes the construction history, and only exports the shaders actually on the object. Most maya files have tons of wasted stuff (extra cameras, reference models, construction nodes, etc) that is of no interest to the editor. Multiply that by 100’s of references and you’re paying a huge perf cost.
put a wrapper around the basic referencing tools to do exactly the right thing for your process. Maya always gives you lots of options and in this case you really want only one set every time. Don’t compound the limitations of the system with preventable human errors.
See if you can get your levels split up geographically, so that you can let people work in parallel. The ‘whole thing’ is rarely what you care about, most of the time the editing will be local to smaller pieces. You can have a batch script that loads up the big level and exports it automatically, so you can make a local edit, save, run the export and see the results in game w/o the hassle of closing one file and opening another.

Not ideal, but I’d assume it would be a lot less unpleasant to live with over time while you’re busy trying to convince them of the right thing to do .

Nightshade · December 3, 2012, 4:29am

[QUOTE=Theodox;19210]Well, the polygon soup method has some pros and some cons. If you’re not dealing with big worlds – or high levels of interactivity it’s not completely bonkers, it’s certainly easier on the graphics hardware (especially if you have multiple targets) because implementing the instancing equation is not trivial and is platform dependent. For racing games I can see it working, since your probably not streaming and most geometry is not actually interactive.

I think you’re pretty much going to have to bite the bullet and do some tools development, even if most of it is just putting a less manual, more stereotyped wrapper around the default functionality. Effectively that pipeline locks you in to building a single very large model, and some combination of referencing and scripting is what you’re stuck with. 3 easy ways to help yourself:

create a script that ‘exports’ the asset with correct settings in the most compact, least worrisome format for the level editor. For example, you might want all of the branches in your palm tree as individual objects when you’re working with the palm tree, but not when you’re working in the editor: so have a process that flattens out the hierarchy, collapses the geometry into one mesh, deletes the construction history, and only exports the shaders actually on the object. Most maya files have tons of wasted stuff (extra cameras, reference models, construction nodes, etc) that is of no interest to the editor. Multiply that by 100’s of references and you’re paying a huge perf cost.
put a wrapper around the basic referencing tools to do exactly the right thing for your process. Maya always gives you lots of options and in this case you really want only one set every time. Don’t compound the limitations of the system with preventable human errors.
See if you can get your levels split up geographically, so that you can let people work in parallel. The ‘whole thing’ is rarely what you care about, most of the time the editing will be local to smaller pieces. You can have a batch script that loads up the big level and exports it automatically, so you can make a local edit, save, run the export and see the results in game w/o the hassle of closing one file and opening another.

Not ideal, but I’d assume it would be a lot less unpleasant to live with over time while you’re busy trying to convince them of the right thing to do .[/QUOTE]
Thanks for your reply.

I’m pretty sure our exporter currently work like this - Crap such as cameras and construction nodes gets filtered out by it, and what comes out is just the mesh, UV info and shader info - together with some other stuff (lightmap, collision, sun direction and so on). But as it is now the exporter has not been improved to handle references so that would have to be covered in the future. Or I’ll just make a script that does what you say: flatten all the stuff to one mesh.
Yeah we’ve done this in the past and we will improve this in the next project by working more with sets and partitions in Maya, together with references. That way, if two ppl need to work on a level at the same time they can work on two different partitions and then just export/import that particular partion (and clean it up with the namespaces editor).

Anyway, I solved the parenting problem. Turns out that the proxy model needs to have EXACTLY the same name - AND internal structure - as the ref: else it wont copy the transform values. So now I just need to sort out these namespace problems (clutter). The namespaces editor seems right for this but I’m not 100% happy about it… it appears flawed (or I dont fully understand how it works), and if that’s the case I might have to edit it myself ^^

I’m also working on a MEL-script for quickly switching between proxy and ref model. Doing it manually, one ref at a time is just stupid. It has to be batched!

rgkovach123 · December 3, 2012, 1:41pm

Have you looked at the AutoDesk Level Tools? They are free, like Bonus Tools, and meant to be foundation/example for creating “level editor”-like workflows in maya. I have never used them myself, but i’ve seen it demo’ed. Seems like a decent stab at the problem and worth a quick look.

Namespaces are tricky to work with, you can’t remove them until they are empty, which means you’ll be dealing with recursion.

Nightshade · December 4, 2012, 1:09am

Great, my reply vanished!

Anyway, why does Maya force me to resolve name clashes when using references?

Grandchild scene: palmTree model
Child scene: 5x grandchild scenes referenced - I want them named palmTree1, palmTree2, palmTree3 and so on - but Maya forces me to resolve the name clashes with either namespaces or prefixes. How can I use references WITHOUT resolving? I’m trying to clean up the naming clutter here.

[QUOTE=rgkovach123;19215]Have you looked at the AutoDesk Level Tools? They are free, like Bonus Tools, and meant to be foundation/example for creating “level editor”-like workflows in maya. I have never used them myself, but i’ve seen it demo’ed. Seems like a decent stab at the problem and worth a quick look.

Namespaces are tricky to work with, you can’t remove them until they are empty, which means you’ll be dealing with recursion.[/QUOTE]
I have - it’s now called Layout tools and seems to be nothing but a half-decent asset manager for importing. Afaik it does not have support for dealing with references/scene-hierarchies.

EDIT: Also does anyone know how to query the associated reference/proxy model of a reference/proxy? Preferably using MEL.
string $AIDS[] = ls -sl;
$referenceNode = referenceQuery -rfn $AIDS;

Will return the selected reference OR proxy model - but what I want is the name of the associated reference/proxy so I can make a hotkey for
proxySwitch $nameOfProxyOrRef

rgkovach123 · December 4, 2012, 7:13am

when you reference the same model 5 times into a new scene, you shouldn’t be renaming the meshes - because the meshes don’t actually belong to the scene.

This is the correct way to think of referenced data - the tree is the same, you only have 1 tree, therefore there can be only 1 name for it. what you have 5 of, is 5 references, the reference nodes are what get the numeric suffixes to uniquely identify them.