This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Hackney Effects Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
------------------------------------------------------------This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Hackney Effects Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
------------------------------------------------------------This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Hackney Effects Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
------------------------------------------------------------Here is the explanation for the modified `Emit Branches` compound:
I moved the `set data` node to outside of `Add point` node on creation. This is because whenever there is a `Add point` node, the custom attribute stored in points may be reset. This was the case with `self.__strandTree_NumBranchesPerIteration`, which was reset to 0. It caused division by 0 in `Even Distribution Grow` node and thus the whole compound does not work. To work around this, we need to set the custom attributes in per Object context, instead, so that those attributes will not reset when there is another `Add point` node.
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Hans Adrian (Intern)
Sent: Monday, April 14, 2014 4:26 PM
To: soft...@listproc.autodesk.com
Subject: RE: strand tree and xsi2014
Hi,
Attached is modified Emit Branches compound which would work with the preset basic tree and other basic use. It has not been tested exhaustively, though.
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Cristobal Infante
Sent: Thursday, April 10, 2014 6:08 PM
To: soft...@listproc.autodesk.com
Subject: Re: strand tree and xsi2014
Support your local plugin maker!,
from what he is commenting on his video he is not getting enough support from the softimage community:
On 10 April 2014 11:03, Andi Farhall <hac...@outlook.com> wrote:
yeah the 3d quakers stuff looks good.... certainly worth the pennies they're charging. The ice tutorial stuff looks interesting too..
cheers,
A>
...........................................................................
This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Hackney Effects Ltd.
If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone.
Please contact the sender if you believe you have received this email in error.
------------------------------------------------------------
Date: Wed, 9 Apr 2014 20:19:01 -0300
Subject: Re: strand tree and xsi2014
From: xsim...@gmail.com
|
Hi Angus,
I never touched the MR standalone route in depth, because of two things:
1. It needs extra standalone- licenses. And therefore will cost probably more than a few RR licences (I don't know if there are educational versions for MR standalone, however)
2. The export takes a decent amount of time and disk storage, depending on the scenes complexity (one file per frame and in general not very comfortable nor even idiot save ;). And students are lazy people right? Making every fuckup possible with sending their scenes).
Regarding the five batch render licences that comes with every Softimage seat and the ability to use also satellite rendering within the farm (the bugs with satellite rendering were fixed by mental images several versions back), seems to me as a smarter route than using standalone MR. Getting satellite rendering to work with Royalrender is not supported out of the box but doable. I had a talk with Holger Schoenberger a while ago when I set up a farm using satellite rendering. http://www.binaryalchemy.de/forum/viewtopic.php?t=2291 That was more about security issues and to have it fully automated inside the production pipeline. But maybe useful.
As mentioned, I have not really any experiences in using standalone MR in production because I dropped it to the reasons stated above.
sven
The standalone is much more efficient than when run from a 3D application. This does translate to noticeable performance differences. Each 3D app exposes a different subset of mental ray’s capabilities – there are some useful features for job control that aren’t available from the GUI, for example. Your ability to render will be constrained by the number of 3D licenses you have available and installed. Render licenses usually cost significantly less than 3D licenses which should allow you to expand your render capabilities to keep your user workstations free and uncluttered – which is valuable at the end of each course when students are rushing to get their projects done. If you’re worried about students pushing the wrong buttons to screw things up, you can make a simple scripted GUI to launch the standalone with the desired flags, or use something like royal render which his very cost effective.
With regards to #2, the same translation happens whether you use the standalone or the GUI. When you run the render from the GUI, it competes for memory and resources with the 3D application. Less of an issue now that everything is running 64 bit raising the ceiling on your resources, but the problem is still there if your computers are not well equipped. You’ll likely want to dump logs to track what the renderer is doing to track jobs and troubleshoot when things go wrong. If you render from the GUI that means that information is only available in the softimage script log (or Maya). If softimage crashes or is restarted, you’ve lost your logs. The process of logging in softimage takes longer compared to writing directly to STDOUT from a shell using the standalone, and can direct output to a centralized location so all your applications feed the same pool of logs which can be inspected/managed by the renderfarm manager.
Rendering from the GUI may be less hassle to activate, but it will render slower, be more difficult to troubleshoot when things go wrong, and be constrained by the number of workstations you have available.
Matt
From: softimag...@listproc.autodesk.com [mailto:softimag...@listproc.autodesk.com] On Behalf Of Sven Constable
Sent: Monday, April 14, 2014 1:15 PM
To: soft...@listproc.autodesk.com
Subject: RE: Mental Ray Standalone
Hi Angus,
You're right, but I think these advantages of using standalone-MR are very low or not existent in a educational environment. I wouldn't expect student to change MI2 files to get access to MR features that are not exposed in the GUI of their 3D-application. And that applies to Softimage as well as maya or 3dsmax. I was not talking about rendering from the GUI versus standalone but rendering xsi-scenes via batch with royalrender (or any other manager) instead of rendering pure MI2 files.
Yours sincerely, Siew Yi Liang