I'll say it again. Render layers need to be more flexible, I often need custom setups, sometimes with object from other render layers visible or proxied, or black hole, etc. Some need raytracing, some do not. Give me a render globals(not so global...render locals?) tab for each render layer, with image name, quality options, renderer, etc Render layers need to be sets, not partitions, for overlap Absolutely vital to have an override capability for non-destructive shader assignments Lights and shadows should also respect render layers
Look at XSI if you want an example of what I am talking about.
The following is a preview of your modifications. If everything looks ok then you can click 'Continue' and your post will be entered. If not then use the bottom form below to edit some more.
Subject: Re: Render Layer improvements
Sure, but just how do you suppose to tell the computer how to do the layer if you wouldnt use mel?
Actualy the thing is that the shading tree should be rewanpped to include arbitraty output connections to shadergroups so that each one render coudld output many images form one calc instead of many as it works now. Bit like arbitrary output variables in prman, and the similliar output variable thing in mentalray.
some comments tough:
Renderlayers are not partitions per se, but nodes that connect to objects renderinfo wich can only have one imput connection. Wich essentialy is allmost like sets but technicaly NOT.
Anyway you have all this functionality available today (yes even like in xsi), all you need is mel that tells how each layer should be rendered. Its not hard and it has the added benefit of allowing you to do anything you could imagine, even things guys at alias forgot about. NOTE: you can not gain superior flexibility without coding sorry theres no piece of ui that can do all that you coudl imagine.
But I do have a ui for doing most of what you ask for in pure mel... sorry im not sure if i can distribute it tough i must ask. id bet my balls i cant. It produces something much like thisone altough it was the version piror to the ui im using now, wich is far more flexible, even spits out processing info linux nowdays (and works even without processing info). Sorry the demo is REALY OLD!
Ps this is a maya wishlist not a demand list for what alias should implement
I am aware of mel solutions, I often bite the bullet and code it myself,but it requres too much setup and testing to insure you don't get bitten at rendertime.
XSI had an elegant solution using states and overrides that do everything I would need. I know that similar functions could be created in mel ; I am just wishing for a standard system that comes from alias.
I know that they had this kind of functionality in mind way back in beta 0.7 when they made a renderGlobals node - remember there was once a UI to create a new renderGLobals node, and you could easily switch between them (in the UI not mel) Anyway, they cleaned that mess up.
SImple stuff to add really. I am a big proponent to build in essential features that only exist as plugins - just to make the migration to new versions easier on everyone. I am still using 6.01, mainly because I do not have the time to roll out 6.5 and get all of the latest build of all the plugins I depend on. For instance - why have they not made a noise deformer a standard nonlinear deformation? Many plugins exist, even as examples in the API. I just want (wish for...) standardization across installations.
WHat would be the difference between a wish list and a demand list? I wish these thing were standard to maya, I am not demanding change or I jump ship. I'm still using maya, I just would like some things to be eaiser. Maybe that tone was interpreted by my mention of XSI functions, but not intended. I merely wished to cite a working example of what I am talking about.
The difference between a wish and demand is in how you word them. Worlds like should or must are all demands.
Maya inst realy the prog optimized for one user outfits, but rather medium and big outfits.
The thing i sthat maya is a platform for building your work pipe on, its not realy meant to be complete do this animation software, not even close thats where poser and such progs come in. But rather maya is desinged for you build your own cutom solutions, rigging, dynamics mel and api all fit into this category of things (to make you have a n edge because you have different tools than others, for the medicore user i can undertand the need for all medimized is a key but tehts not what the bleeding edge wants). The truth is that even if they implemented something like this there still would be a hunderdfold of people complaining. Theres no be all do all way of doing things.
As for why api plugins arent incorporated in the core maya. Well theres a difference between code here. Alias does not do code with the api hopefully, so integrating something like this is a bit bloating things (oce its there its there and stays thatway). Everyone of us has acces to compilers (you can get the compiler free form microsoft) so why not let them compile for yourself. Thatway in future users are in amuch better position to help themselves later on.
Its also a stability issue, you end up with much of the problems max is facing nowdays if you just push everything everyone and their mama comes up with. Things shoudl fit the maya way of doing things. Im not saying the noise deformer int but hey its easy enough to do with dynamics with MUCH more controll
Somehow many people have a wierd notion that aya is expensive. Maya is dirt cheap, perhaps cvheaper that what future development needs deem worthy. So its better if alias stayed on path to make excelent well documented and tought examples, wich we can buld upposn and let alis themself just concentrate on making the cores core better. wich is what they have been doing by looks of performance boosts lately. And quite frankly they should too, since if the core breaks at ts seams theres no one thet can build uppon that.
Maya 7 effectivly addresses my concerns. This is what I was hoping for in render layers, it is well integrated, and it looks to not be a huge departure from the previous technique. I have sent many emails to alias requesting this feature over the last 6 years, and I feel I finally have been attended to. Thanks! MD
