Trouble with Enhanced Remote Control (ERC) when network rendering
cyborgty_074ff6c243
Posts: 132
Is Enhanced Remote Control (ERC) suppose to work with network rendering? I have an object with the ERC modifier applied and the results only look fine when rendering locally. I copied the ERC* files from my primary workstation's carrara extensions path to the extensions path of the network render nodes. Could it be a licensing issue on the rendering nodes? if yes, how do I resolve? Any help would be appreciated.
Post edited by cyborgty_074ff6c243 on
Daz 3D is part of 
Connect
DAZ Productions, Inc.
224 S 200 W, Suite #250
Salt Lake City, UT 84101
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
It should just work. What sort of behavior are you seeing?
I have an animation with a ponytail attached to a ball character and when rendered over the network, the tail doesn't move or stays in the rest/initial position (except for maybe the frames rendered by the local system).
I copied these files to the render nodes. Are these the only ones needed?
ERCModifier.dat
ERCModifier.mcx
ERCModifier.txt
ERCTweener.dat
ERCTweener.mcx
ERCTweener.txt
Attached is a animated gif of local machine render (where the tail moves) followed by the network render.
Yes, those are the only files. And no, that's certainly not right. I'll take a look... it used to work on 8.1, so that's disappointing.
It appears that Carrara no longer plays every frame at the rendernodes. Many effects depend on state that "came before" the current frame, and so the modifiers and behaviors need to be walked through from frame zero forward, even if the node is only rendering a later frame.
That means that none of the delay-related operations are going to work on a network render. I'm not sure how to fix this.
Fenric,
Thanks for looking into the problem. I know its common to have host application changes that cause problems for plug-ins. Since I recently considered spending time to get familiar with ERC, its too bad I encountered this problem with a resolution that is elusive. :down:
It is possible to work around this issue without needing any code changes:
1. Get the scene to its "production" state.
2. Save your original scene off somewhere - you're about to ruin it.
3. Rewind the sequencer to the first frame of your animation (presumably frame 0)
4. Make sure that "play every frame" is enabled (don't let the preview player skip frames)
5. No Looping!
6. In the ERC modifier, choose "Manage Keyframes"
7. Play the preview animation.
8. Immediately delete the ERC modifier
9. Save the scene - only saved scenes will render with network rendering.
This will bake the animation into keyframes, which will happily work across the network render. It's not ideal, but at least you can keep moving forward.
Can we get this in a ReadMe somewhere?
Or do we have a community rolodex of workarounds where these things are saved?
Good idea.
http://fenric.com/wordpress/product-help-and-tips/carrara-enhanced-remote-control/
Due to SPAM, all of my pages are set to "full moderation", so you won't see anything you post until I review and approve it.
Oh. Okay. This might be an acceptable workaround. I will test this later today. :-)
Actually, this is a bit disappointing, Fenric (not due to anything you did!)
It would seem this "change" in C8.5 is not an enhancement. Actually, I can't imagine someone made the decision to modify how node rendering works without posting something somewhere about it, and thus, I'd call it for what it is - a defect.
Should this be reported? I GOL'ed (groaned-out-loud) reading through the work around steps. And I can't imagine doing any significant animations without farming it out....
BTW, thank you so much for looking into this and providing a solution (band-aide though it is...).
Yes, I suppose this should be reported.
Frankly, this is going to limit what you can do in the Python script plugin. And I had wondered why Physics always seemed to calculate the entire timeline instead of figuring out things as it went - that's the only thing I could come up with: basically automate the keyframe-generation workaround to pre calculate the entire timeline.
It's a brilliant maneuver.
On a tangential note, I noted C8.5 no longer converts Physics calculations into keyframes. (I used to do this in C8.1.) I need to report this as well. I'll submit this today.
Just as an aside, my understanding is that they changed it for efficiency when rendering an animation with render nodes. With the old way, every render node did the scene set-up for every frame. Render 100 frames on 4 render nodes, then the scene set-up gets run 400 times. In the new way, the scene set-up is only run 100 times, and each frame is handled by one of the nodes. This is apparently a side-effect, and one I'll have to watch for in my own plugin. Too bad there's no checkbox to use the old render behavior. I think your plugin can still request "SetTime()" to step through the animation calculations.
I've also seen bug reports in the past about some shaders and volumetrics not "lining up" where the render tiles meet due to differences between 32/64 bit or Windows/Mac. The new node behavior would eliminate that problem, as well.
Interesting to hear there is now a solution.