network rendering not working with latest Tyflow
#1
Hi Tyson,

Max won't launch a network render node when using the latest Tyflow (v.1.0121)

When I revert to the previous build, the problem disappears.

I'm attaching the Backburner log and a screen shot.

Max 2018, Vray Next ( problem occurs no what the render engine), I'm sure it's a Tyflow thing.

thanks

John butler    
  Reply
#2
Thanks John, I think I may know what's causing the issue....hopefully I can push a fix soon.
  Reply
#3
Still having the same net render problem with the latest build.

Max 2018, Vray Next, Win 10.


Attached Files Thumbnail(s)
   
  Reply
#4
Hmm, thought this might be cleared up with the other network rendering error I fixed. Guess not.

Is this happening in all scenes? Or are you trying to render terrain?

If the latter, try disabling all Terrain Display operators before rendering and see if that fixes the issue. If not, if you could send me the problem file that would be great...
  Reply
#5
(02-25-2023, 01:26 PM)tyFlow Wrote: Still having the same problem, with and without terrain. Just did a reset to MAx to fix another problem, but this one still persists.
I'll attach two sample scenes

thanks

John Butler


Attached Files
.zip   Tyflow_netrender_errors.zip (Size: 1.89 MB / Downloads: 59)
  Reply
#6
Hmm, they netrender fine here.

Could you turn on forced file logging in tyFlow on one of the problem machines and send me the log? Info about turning that on is here:

https://docs.tyflow.com/feedback/bugs

If it comes down to it, I may send you a debug build with even more logging so I can determine precisely which script is triggering the error, assuming the forced log doesn't give a hint...
  Reply
#7
Hi Tyson,

Here is the log and related scene.

thanks

jb

Log file plus scene.

thanks

jb

logfile


Attached Files
.max   tyflowtest_crashtest.max (Size: 716 KB / Downloads: 55)
.txt   tyFlowlog.txt (Size: 23.66 KB / Downloads: 44)
  Reply
#8
Hmm yea I'm kind of at a loss here...

Your log shows the tyFlow sim completing without issue, prior to render completion. And the error says it's related to an ExecuteMAXScriptScript exception - but the only time tyFlow calls that function of the API in your scene is before simulation starts, and every time tyFlow calls that function it also specifies a conditional argument telling max to ignore any exceptions which may occur....so it shouldn't even be possible for tyFlow to generate an exception related to that function call.

Are you sure you don't have another script or plugin which is generating the error? I can render the scenes you've sent from the command line without issue, and nobody else has reported any similar issues.....the error doesn't seem related to tyFlow at this point...I could be wrong of course, but I can't figure out how or where tyFlow could be causing this issue.

The only other thing I can think of, is that tyFlow generates some macroscripts when Max starts to expose certain tyFlow properties to MAXScript...it's possible that those macroscripts are being evaluated after the simulation completes (therefore the log doesn't show the exception occurring) and that your machine is configured in a way that results in an error when they evaluate....but that macroscript-generating function has been unchanged within tyFlow for at least a year, and you mentioned only recent versions of tyFlow have the crashing issue, so I don't think that can be it.

Maybe some other script or plugin you have installed is conflicting with new tyFlow classes introduced in recent versions, and so when the other script/plugin evaluates, the naming conflict generates an error. That's my best guess but I honestly have no idea.

One thing I could do is see about writing a dummy plugin that hooks Max's ExecuteMAXScriptScript function and prints a log of anything sent to it...running that on your machine would tell us exactly which script is the troublemaker. Let me know if you're up for trying that.
  Reply
#9
Thanks for trying anyway. Sorry about the work this has caused.

It does sound like a rogue script in my system. since the previous build worked fine, I thought it was a Tyflow thing, but that's clearly not the case.

I'd like to try the dummy plugin thing, when you can manage it. My 2018 installation has probably accumulated a lot of trash over the years, but I was always worried that Autodesk wold not reauthorize it if I reinstalled. My perpetual license is 2018, and they said they would not authorize anything over 3 years old.

i may have to risk it, though.
  Reply
#10
Hi John, I know it's been a while but the latest build of tyFlow (v1.018) has some MAXScript hooking functions implemented, in order to help track down this issue you're having.

On the problem machine, create the following empty file:

Code:
c:\hookScripts.tyf

When tyFlow finds that file during startup, it will hook Max's script execution function and dump all scripts that Max tries to execute to this file:

Code:
c:\tyFlowHookedScripts.log

You can also create this file:

Code:
c:\hookScriptsNoExceptions.tyf

When that file is also present, tyFlow will force all executed scripts to run with exceptions turned off.

Hopefully a combination of those hooks can help us to a) track down which script is causing the issue at rendertime, and potentially b) prevent it from throwing an exception.
  Reply
#11
    Thanks, Tyson.

I tried all this, but no logfile seems to be generated. This is all supposed to be in the root of the c: drive, I take it.

I'll post a screenshot.
My max 2018 is not onĀ  my C drive, it's on another drive altogether.
  Reply
#12
Can you open Max normally on that machine and see if a log is generated?

If no log is generated even if Max is opened normally, then there's an issue on the machine preventing the log from being created. Possible cause: your UAC settings are preventing Max from creating the file on C:\. Try running Max as Administrator and see if the file pops up. Or you can try creating the file manually (C:\tyFlowHookedScripts.log) and see if Max is at least able to fill the file once it's created.
  Reply
#13
Good news:

A had another user report this exact issue...and after some further debugging with them I believe I've tracked down the root cause and it'll be fixed in the next build (v1.024). It only happens during network rendering using v1.012 and above, and only when using Max 2019 or below, which is why it was tough to track down and why nobody else reported it.
  Reply


Forum Jump: