Leonardo Bernardini

Forum Replies Created

Viewing 15 posts - 106 through 120 (of 492 total)
  • Posted in:
  • 25th March 2019 at 10:54 am #17367

    For the ones with a similar problem, be sure that no more than 4 clients are trying to connect to the Dispatcher when running in evaluation mode.

    21st March 2019 at 3:21 pm #17340

    On Linux do the following , when you experience the issue , send a soft restart , this should close as many threads as possible. After about 10-15 locate the dispatcher pid and collect the output of gstack .
    Send us the output as well as a complete dispatcher.log trough our ticketing support. Also be sure that you do not have more than 4 hosts racing for connection and that the notificator port is correct either on client and server side

    25th February 2019 at 9:59 am #17254

    Hi Shaun,

    Consider that when the Muster client spawns a render, it may run under different credential than the ones you installed Arnold (Muster runs as a service and if you followed the correct setup guidelines, the Render client service may run under a different account). It is possible you installed Arnold not for everyone but just for your own account, and the environment is not set when started by Muster. Please check the following:

    1) What account is Muster running on, to do it, check the services control panel applet, locate the Renderclient Service, and check its “Logon” tab of its properties

    2) If under a different account just to step 3, otherwise jump to step 4

    3) Log in with this account on your workstation and start Maya , Arnold and try a batch render. Check that it’s working correctly or configure according

    4) Otherwise, double check that Arnold is working good under a command line batch render. To do this, start a job in Muster, then grab the chunks log, and in the beginning, copy the exact command line sent by Muster . Try this command line from a shell and double check the results

    21st January 2019 at 3:15 pm #17189

    the template can be modified adding a new folder selector:

    – ADD AFTER THE FOLLOWING LINE(39)
    aliasFile = MTemplateAPI.MTemplateItemFile(“ALIASFILENAME”,”Scene file”,”Specifies the Alias studio scene file to render”,””,0,1,1,”*.sdl;*.*”)

    the following

    aliasFolder = MTemplateAPI.MTemplateItemFolder(“ALIASPROJECT”,”Project path”,”Specified the project path to start the render from”. “”.0,1,1)

    – ADD AFTER THE FOLLOWING LINE (47)
    self.addSubmissionItem(aliasFile)

    the following

    self.addSubmissionItem(aliasFolder)

    THEN AT LINE 95 CHANGE TO:

    def onGetApplicationStartingFolder(self,job,chunk,clientTemplatePreferences,pathOut):
    pathOut.setString(job.attributeGetString(“ALIASPROJECT”))

    Be sure to select the Alias file or folder from a drive mapping, launching from a direct network location (\\server\\…) may not work…

    18th December 2018 at 11:55 am #17178

    Compare two logs between two machines, also be sure that the render engine is taking 100% cpu while rendering.
    What Maya version and in what configuration are you using ?
    The bottleneck may be somewhere else, depending on your i/o configuration. Try with a simple thousand spheres with raytracing enabled and no textures, and check the results. In such kind of scenario, the i9 must perform better than the i7-6700

    18th December 2018 at 11:40 am #17176

    You just need to expand the column of the cpus usage, when too many bars does not fit into the column , Muster collapsed them into a single average bar.

    The display of one core has no correlation about any kind of rendering delay.

    11th September 2018 at 10:34 am #17138

    Hi andres

    On what muster version you are ?

    Once you enable ldap/ad bindings even the web server let you log in using those credentials as console/mrtool do

    4th September 2018 at 10:09 am #17134

    Yes, indeed you do not need to rebuild mrtool by yourself, it’s part of the standard distribution.
    By the way, I’ll take a look at the SDK compilation because you should be able to build it by yourself and you should not have missing dependancies, thanks for pointing this out.

    Have a great day!

    1st September 2018 at 2:04 pm #17128

    no it is not referencing mental ray, mrtool is the muster command line tool to submit job that the Maya integrated plugin refer to.

    About your issue, it’s clear that you still have an old script referencing around, so please double check that there’s no /Applications/Autodesk/maya2017/MayaMuster9.py and then restart maya.

    Also, to avoid the problems in startup, depending on your muster version (8 or 9), define a MUSTER or MUSTER9 environmental variable in the maya.env (MUSTER9=/Applications/Muster9/Contents for mac) that you find into your home dir/maya/2017/maya.env , then restart maya.
    In that way, the connector should immediately find the Muster installation folder and start correctly

    29th August 2018 at 10:25 am #17124

    Problem was due to a configuration in the end user files, we confirm compatibility with Cryptomatte. Users was using references to local folders instead of network ones.

    27th August 2018 at 10:16 am #17103

    We were not aware of problems using Cryptomatte in batch render mode, we are checking the issue and get back to you as soon as possible.

    23rd August 2018 at 7:53 pm #17101

    Yes I was talking about the render nodes, and I’m 99% sure the problem is with the older versions, we’ll run a test on our own but If you want to update, you must update the clients too.

    About the Maya plugin, the error message is referring to the settings into the Dispatcher tab here:

    https://www.vvertex.com/wiki900/doku.php?id=muster:9.0:applications_plug-ins_connectors:maya#usage

    By default, the plugin reads the contents of the MUSTER9 environmental variable inside your global environment or into the Maya.env file, by the way, from that section, you can configure the path to the Muster installation manually in the first field at the beginning.

    Regards.

    22nd August 2018 at 2:15 pm #17099

    Your Dispatcher crashes as soon as a client connects. Have you updated the renderclients too or they are still at 9.0.2 ? Even we always let older clients to connect and then we report the wrong version, I cannot exclude there’s a bug if an older client tries to connect, we will double check this but could you confirm me that the clients were still at 9.0.2 ? Have you tried to update the clients too ?

    Regards.

    21st August 2018 at 8:30 pm #17097

    Hi Eric,

    Thank you for getting back on this. May I ask you a few more information ?

    First of all, you should have a dispatcher.log file generated where there may be an hint of what’s causing the failure. Also does it crashes immediately on startup or just after a certain amount of time ?
    And as last but not less important, do you launched it only over a previous installation, or you tried also a fresh install of version 9.0.4 and having the same problem ?

    Please also provide the running platform of the Dispatcher, and the database engines you’re using (sqlite / mysql / sqlserver or mongodb).

    Thanks!

    9th August 2018 at 2:00 pm #17092

    HI there,

    Nuke should use all the available cores by default, you can force multiple cores using the “Additional flag”:

    -m #

    where # is the number of threads used by the batch render

Viewing 15 posts - 106 through 120 (of 492 total)