View Full Version : Why not!
ytsejam
March 15th, 2011, 10:17
Hi all.
The question:
Why not mental images, not write your own Mentalray plugin for maya, like chaos group?
Please don't says me, report it on Autodesk. I know it.
But 3 version of maya and not well integration. I don't talk about standalone version. i know it run well. I want integration, workflow, fast and furiousssssssss mentalray inside maya. All mental ray users, i think, are happy to pay for a great and usefull plugin.
for nearly 10 years i use mental ray. It' s plausible to migrate to vRay? is necessary?
Thanks
rlevene
March 15th, 2011, 14:21
I am not sure it is going to get any better.
Have you tried mental core?
http://www.core-cg.com/
Corey seems to have taken it upon himself to develop a user friendly mental ray integration package.
I am pretty sure this will be the answer you are looking for.
Best,
Rich
ytsejam
March 15th, 2011, 15:01
yes. I'm on mental core beta from the begin. thanks
Remydrh
March 15th, 2011, 19:43
I haven't tried mental core but it might be nice to give it a shot. I certainly looks well thought out. Might be a good model if a plug-in or external support was offered.
I'll see if I can get on the Beta.
steve
March 16th, 2011, 13:29
Hi all,
I would like to comment on the concerns from you guys about the progress of the mental ray integration into Autodesk Maya.
Let me start with a little bit of history.
The original prototype of a mental ray file export plug-in was done at mental images. With the success of Maya the demand for more features of the mental ray scene translation increased, and the whole plug-in quickly evolved into a full integration into Maya. That was developed in a close collaboration with Alias, with the vision to make it the successor of the Maya Software Renderer. This phase drove a lot of feature extensions in both products, Maya and mental ray. It includes, for example:
rendering with mental ray inside Maya with live preview into Render View,
rendering with mental ray using Maya Batch, export to mental ray using Maya Batch,
full support for basically all Maya nodes in mental ray, including legacy functionality primarily intended for the Maya Software Renderer,
complete custom mental ray shader integration pipeline with representation as true Maya nodes,
rendering Maya swatches for native mental ray nodes in the background,
bake textures for OpenGL display of native mental ray nodes in the background,
full IPR integration of mental ray with features far beyond Maya Software IPR
unlimited access to all mental ray features through Maya user interface (GUI and API).
Some years ago Autodesk took over the responsibility of the plug-in development. More important features have been added during that time that are based on the mental ray integration, like color management and the render pass system. On the other hand, new mental ray features like progressive rendering or native IBL did not make it into the GUI and workflows. With the latest move in Maya to provide a clean renderer plug-in API that should cover all of the above use cases, new ways of embedding and exposing renderers are now imaginable.
For the future, I do see new opportunities to bring mental ray for Maya back on track and keep up with latest feature set in the renderer, together with Autodesk. The open source projects make a lot of sense in that attempt, since they are not blocked by the need to support legacy functionality and can show what a modern and fresh integration should look like.
Thank you for all your support, and for using our software.
Best, Steve.
rlevene
March 16th, 2011, 14:09
Hi Steve,
Thank you for taking the time to post a comment on this and really interesting to hear your thoughts about what the future might hold.
For me one of the big issues is having to wait ages for bug fixes to be released. When I look at the release notes of mental ray standalone, I see all these (dot) versions listed with bug fixes yet as a maya/mental ray standalone user/subscription holder, I do not get these fixes until Autodesk decide to release a hotfix/service pack for maya.
Will this be changing?
With the latest move in Maya to provide a clean renderer plug-in API that should cover all of the above use cases, new ways of embedding and exposing renderers are now imaginable.
Will this be something that will give allow users to get mental ray bug fixes quicker?
I will say that one thing that has helped me as a mental ray user recently has been the huge increase of high end users posting on this forum as well as yourself and the other devs, managers, trainers (Bart) etc being more and more vocal.
Many thanks,
Richard
ytsejam
March 16th, 2011, 15:46
thanks Steve for the answer and thanks so much at all MentalIMages staff.
The problems are after ........... ........... i don't talk about the problem for my opinion stupid.
Anyway, much user after a clot of year don't have a unique workflow. Ok two 3 are ok, but a lot of workflow appears.
Not a real support in this way. The problem with much bugs, the problem with assemblies, the problems with not support for the new mentalray features. The problem for(here on 2011) create the lights in the scene. I know this is a problem of The "major" but if this plugin dev from mentalImages i think the problems are solved.
The purpose of this forum is to pass information to know but also to communicate directly with you to fix or to add new features, methods. I am sure that the development of an external plugin (but the mental intenro) brings a breath of fresh air in this battered Mentalray for maya. Because the truth is this. Many of us have studied for a report with regard to the IES in Maya, and we found solutions, then we were right. We are tired and exhausted that it can not know what will happen in the scene after squashing render, you do not know if our channel zdepth come out or not. We are tired of not seeing the zdepth instances painteffects. We are tired of looking at renderings of kids who use vray for two months and although doubts "do the decent render without knowing what they did and why that render it out. Mentalray I do not want to leave, but at what price? liver me rotten to convince my boss that there we can still do to be competitive without the need to use the more famous rendering engine (I will not say his name:)).
Thanks and sorry for my English
Remydrh
March 16th, 2011, 18:18
A new model for integration is certainly something we're all interested in and I'm glad to see more discussion about it. Being in a forum that's visible to developers helps because they can see where we are having trouble and hopefully take that into account.
Another related note would be increased availability of training, feature explanations, and examples. A lot of commercial renderers have been successful in making a larger splash by making themselves more visible in websites, youtube, and training partners.
Getting a better integration is part of the battle, but once that arrives there will be a greater demand to explain features and controls. Hopping in and out of CGTalk is truly cringe worthy seeing the tools and methods employed. To say nothing of the occasional advice that's given. The end result is "it just doesn't work" when in reality they don't understand how to control the renderer. And for now there are limited resources for them to go to.
Until cloning is perfected, there's only one Bart. So more resources for training and improved documentation will help stem the tide of unhappy users. As I've mentioned before, your user base has changed in both their experience and background so it might be wonderful to adjust and be ready.
steve
March 17th, 2011, 15:44
Hi Richard,
Will this be something that will give allow users to get mental ray bug fixes quicker?
I hope that we can address especially this concern by finding a solution that would allow to update the mental ray core component independently of the Maya plug-in binary.
Best, Steve.
rlevene
March 17th, 2011, 16:38
good to hear but concerned that when you say "finding a solution" it means this is not already possible with maya 2012 and that we will have to wait another year or more before this is possible.
but what is another year when people have already been waiting almost 10 years i guess.
many thanks,
richard
steve
March 18th, 2011, 11:04
Hi Rich,
there are two sides to consider, the pure technical aspects how this can be implemented, and the release engineering and business related questions, how feasible a separate update might be.
To be fair, Autodesk -does- release hot fixes and service packs that include bug fixes for mental ray. But yes, a lose dynamic coupling instead of static embedding of mental ray offers possibilities to make this process less involved and more flexible.
Keep in mind, our discussion here does not cover how to address the need for workflow and user interface changes in Maya to expose new features in mental ray. That is another story. Your input in this area of usability is very welcome.
Best, Steve.
rlevene
March 18th, 2011, 15:34
Hey Steve,
I totally understand that things are not straight forward and there are many aspects to consider and I really appreciate you speaking and making people aware of this.
Regarding the userbility and workflow side of things, I think people will be more than happy to give you their feelings about how it can be improved. Take the release of Mental Core for example. Corey is reconfigurating the mental ray integration the way he feels, as an artist, (and artists at the company he works for) is more appropriate and practical for a production pipeline. Making it more artist/user friendly. I think the team that are dealing with the integration at Autodesk can get a clear idea of how people would like the native integration to be from this.
Best,
Rich
ytsejam
March 18th, 2011, 16:09
Yes rich.
For example in viewport see from the environment it an idea request from me to corey. The env in viewport run with ryswitch and it is a good method and workflow in little touch.
royter
March 21st, 2011, 10:36
For the future, I do see new opportunities to bring mental ray for Maya back on track and keep up with latest feature set in the renderer, together with Autodesk.
is there any reasons besides the API issue that makes you say that?
thanks alot steve for all the info, we never had that kind of transparency from autodesk.
Remydrh
March 22nd, 2011, 01:26
is there any reasons besides the API issue that makes you say that?
This could potentially put mental images in a position where what's available in Maya would be more contemporary with what mental ray offers. New features and the like could be updated and used where they are somewhat behind now, hence the "keep up with" comment.
Unless I'm completely missing your question, which is possible.
Javadevil
March 30th, 2011, 03:09
I think this is a great idea, I'd like to see if for 3dsmax as well.
I noticed cinema 4D has a nice plugin thats actively developed and will probably be light years a head of integrated features of any DCC aplication and there last application to the party !!!
You only have to look at how well IRAY is properly integrated and there the first to get Mental ray 3.9.
http://www.m4d.info/index.php
Its one reason why I keep considering VRAY, I do not have to wait for Autodesk to integrate Mental ray features. The string options are nice start, but you have to be able to script or wait for some kind community member to share theres.
With Vray theres point releases being released through out the year and nightly builds.
I could see this might be a problem for Autodesk since the main reasons I upgrade 3dsmax is for Mental ray features and if theres no mental ray features theres no need to upgrade to the latest release of 3dsmax. But then again if there was a separate developer on the Mental ray plugin, autodesk would have more time to work on features that might be worthy of an upgrade.
cheers
Remydrh
April 1st, 2011, 00:39
But then again if there was a separate developer on the Mental ray plugin, autodesk would have more time to work on features that might be worthy of an upgrade.
The problem here is that Autodesk has access to parts of their API that isn't exposed to a third-party developer. This means they have the potential to build a COMPLETE integration solution.
This is why some features are not fully supported by Vray, etc. upon new release, etc.
But given the choice, some is better than none. Just keep in mind that a new translator from scratch will take some time. Vray for Maya had a Beta in Jan 2008 and we're still waiting on a better integration with 2.0 that's more on par with Max. 2+ years later from initial offering and probably 3+ from inception.
So starting over for any package will take awhile (Autodesk owns the translator for Max, Maya, etc)
Javadevil
April 1st, 2011, 03:02
The problem here is that Autodesk has access to parts of their API that isn't exposed to a third-party developer. This means they have the potential to build a COMPLETE integration solution.
This is why some features are not fully supported by Vray, etc. upon new release, etc.
Thats true to a certain extent, though through the years theres been lots of 3dsmax features that haven't been able to render in Mental ray as well.
I understand that autodesk should be able to code a better translator since they can access the core and rewrite things accordingly. But chaosgroup always seem to find ways around it, like the frame buffer.
But given the choice, some is better than none. Just keep in mind that a new translator from scratch will take some time. Vray for Maya had a Beta in Jan 2008 and we're still waiting on a better integration with 2.0 that's more on par with Max. 2+ years later from initial offering and probably 3+ from inception.
So starting over for any package will take awhile (Autodesk owns the translator for Max, Maya, etc)
I'd hope if anything was to happen there would be something worked out with Autodesk so the developer wouldn't have to start from scratch. I think it would be crazy to have autodesk and a 3rd party developer working on two different plugins/integration of the same plugin.
But if that was to happen and the 3rd party integration was better I'd buy it in a flash
ytsejam
April 1st, 2011, 12:27
@Remydrh(The problem here is that Autodesk has access to parts of their API that isn't exposed to a third-party developer)
This speech is not good, since the integration of Mentalray within 3dsmax is better. Leaving aside the option string that have their value, but it seems that users about 3dsmax mental ray not placed to have significant problems that we have and that leads us to use the strings. The speech is more difficult to understand, when in fact a 'company develops a render engine, which fits very well within Maya, without necessarily having all the features given by the Maya API, which Autodesk has.
Maya has been a huge upgrade that moves slowly but considerably well. But this does not bring us any security on real good and even excellent future integration of mental ray in it. Many of the things that make other great render engine is the simple solution of the first problems. No one can leave in a few clicks to make a render in mental ray as he would like, except banging his head a lot. There are too many steps that slow down your workflow. VRay moves toward "one-click result" which then allows us to improve the rendering to a more artistic, but the result is what must have under settings. This does not happen on mental ray for Maya.
ytsejam
April 12th, 2011, 17:36
MR in 2012 (3.9) much slower than 2011 (3.8)?
http://forums.cgsociety.org/showthread.php?f=87&t=971499&page=1&pp=15
Remydrh
April 12th, 2011, 20:09
I've seen this post and the only thing I can think of is Final Gather. That is known to be slower in this version with lots of glossiness.
I cannot replicate his problems inside Maya.
There are so many variations and scenes that are used that it could be anything. It's possible he has a combination that reveals an unknown issue. But without seeing a scene no one can really comment that it's a problem.
ytsejam
April 12th, 2011, 20:35
My scenes are with a lot of glossy. I'm archi Viz.
Sorry i'm not a VFX render artist, and for me is a problem have this.
Ever ever ever i optimized the scenes, my scene have 100.000.000 or 900.000.000 of polytris. I 'm render forest, Home in a forest and swimming pool, satined metal,glossy metal, glass, marble pavement, with a lot of glossy. Is' nt easy optimized ever ever ever.
Thanks
Ever ever ever i optimized the scenes, my scene have 100.000.000 or 900.000.000 of polytris.
if you say you have 100 00000 00 0 0 0 0 00 0 polytris in your scene - you never never never optimized it for anything. I'm wondering what hardware you use - which can handle 900mio polys "in the scene".
In respect to the shaders - how do you use the glossyness? how do you "optimize" it in your rendering? how do you bulid your environments? how do you setup your GI solution? Is your forest all geometry? To ask more provocative way: do you have an attic door in the sceen while rendering a pool view?
there are way how to render that amount of data - and to render that fast enough to keep the profit.
ytsejam
May 27th, 2011, 10:09
o-v
Search on mental images site, the image slide. Search marlas farnsworth. Me and marla have a collaborative\exange data Infos on that work, so i know how i'm optimize the scene. What i doing is what i want to render. Forest yes.
So for clarify, for all that says me something like a newbies i am. i 'm not a newbies.
Thanks
rawalanche
May 27th, 2011, 10:37
@o-v:
I am afraid you are trying to reinvent the wheel here. Some of us already know mental ray quite deep and are past these basics. We know how to optimize glossy surfaces, we know how to build our scenes, we have spent years experimenting with all available MR GI solutions just to find out they are insufficient, and yeah, some of us are trying to push it to the next level, where we found MR is limiting us.
We do not intend to render steampunk robot on the table. The complexity of our scenes is way more complicated.
If you want to push quality of your work to the edge, like Marla Prodan did with his Farnsworth house, you can not afford almost any compromises. So sticking a 2D photo behind a window is not an option.
Powered by vBulletin® Version 4.2.0 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.