PDA

View Full Version : Network Rendering: Dreamlight Constellation vs. Butterfly (head to head)



cyclopse
01-15-2017, 05:10 PM
So, I've been using Constellation for a few months now. I've always been looking at the nodes and saying to myself, "wow... there's like 30 seconds there where it's literally not doing anything." The reason? it's just a screamernet interface. But is Butterfly any different?

Uh... hell yes it is!

I'm not sure if Butterfly is still using the LWSN.exe file to execute renders, or exactly what's going on under the hood (yet); But I can tell you that there is virtually no delay between frames. I can also tell you that rather than using a text file on the host computer to transfer messages, there is an actual node app that sends messages back and forth every few seconds (including how much memory is being used on the nodes in real time).

What does this mean?

On a 7484 frame render (testing some mocap on some sticks parented to each FBX bone) that Butterfly uses ~30s per frame (I also have some fiberFX/bullet mohawk hair to test the mocap to see if the movement is too severe, as well as a human head to test the mocap face). On the same scene, Constellation is about 1:15 per frame.. 30s of which is just screamernet saying, "yep I'm done, waiting". THAT'S A HUGE DIFFERENCE!!!

Not only that, but if I set up an after effects scene to process the image files into a movie, I can set that in the queue after any LW camera angles, and BLAMO! It processes AEX directly after the LW is done (or Nuke, or whatever you like... Butterfly has a lot of different render types).

Then there's updates. Constellation hasn't been updated in over a year! Butterfly... much more up to date on their development.

And finally... there's the setup. With dreamlight, every time you add a new plugin, you'd better remember to add that plugin on every node. With Butterfly, you only update the master computer (it uses the plugins and config files from the master computer). So ease of setup is crazy.

Final verdict: Not even close. Butterfly kicks buttinsky!

What do you guys think? Have you used both?

Otterman
01-16-2017, 03:40 AM
Hum I'm guessing you get what you pay for. I've used one old version of Dreamlight in the past. It was very basic but rock steady not to mention cheap. My understanding it is written by one guy who frequents these forums and has always been very hands on with advice so I think its a solution that smaller companies or individuals should entertain. That said I have no experience with Butterfly although I have heard good things about it. I imagine its a lot more robust but a more expensive render farm management solution than Dreamlights offerings. Me personally, at work we are set up to use Qube. Believe me when I say it is the most complex, flakey and expensive software I have ever used. Avoid!!

cyclopse
01-16-2017, 04:04 AM
Hum I'm guessing you get what you pay for. I've used one old version of Dreamlight in the past. It was very basic but rock steady not to mention cheap. My understanding it is written by one guy who frequents these forums and has always been very hands on with advice so I think its a solution that smaller companies or individuals should entertain. That said I have no experience with Butterfly although I have heard good things about it. I imagine its a lot more robust but a more expensive render farm management solution than Dreamlights offerings. Me personally, at work we are set up to use Qube. Believe me when I say it is the most complex, flakey and expensive software I have ever used. Avoid!!

Yeah... Qube is a turd. We used it on some science visualization stuff for planetariums at a company I was at a while back. Once you get it running... it's great... for one scene. But setup a new scene with different objects and shaders and it goes all crazy.

Correct... Dreamlight is a bit less than 1/2 the price of Butterfly (for 10 nodes of dreamlight vs 8 nodes of b-fly). But man, (like qube says it can) you can render anything with it... pretty damned easily. I'm gonna shut up now. Starting to sound like I work for them or something...

Otterman
01-16-2017, 04:15 AM
Ha no it's ok. I would of gone the Butterfly route if they had offered a mac solution at the time I chose Qube. Qube was kinda mis sold it to me and it's something I have to live with for the time being. My understanding that Butterfly is now available to us mac users. Is this correct?

tcoursey
01-16-2017, 07:00 AM
We've used Butterfly for nearly 15+ years. It's solid, great support by Paul and works everytime. He keeps it up date and we have always been pleased! Glad you found it, hope you can support him and his work.

3D Kiwi
01-17-2017, 11:29 PM
It sounds like it is loading your scene after each frame. Butterfly is probably using some kind of task or group setting, see if there is a way to increase or even use tasks in dreamlight

kopperdrake
01-18-2017, 03:33 AM
I'm afraid I also use Butterfly. I used to use Amleto, but found Butterfly so much easier to set up and keep set up that I haven't gone back to anything else.

Spinland
01-18-2017, 04:36 AM
I switched to Dreamlight from Smedge because the latter was flakey and prone to irritating dropouts, not to mention more difficult to manage. I've never used Butterfly but in my experience with Dreamlight each node only loads the scene at the start of a job. I like the file flag approach because it's robust and my local network isn't necessarily so.

Not sure why the OP is seeing such a disparity in render times but maybe Mike will see this thread and comment. In my testing I got render times nearly bang on as fast as I would on each node rendering locally. Not arguing what the OP is seeing, I'm sure that's happening, I just don't understand why.

Scazzino
01-18-2017, 11:23 AM
Hi Guys,

DreamLight Constellation was primarily developed as a replacement for the built-in network render panel in LightWave 3D for the Mac in small studios where a simple drag-and-drop interface was most useful (actually for my use in my own Mac studio). There were no third-party controllers left that ran on the Mac when I wrote Constellation. It runs full speed on the Mac and you shouldn't see any difference in speed between controllers on the Mac. If you're on Windows however that won't be the case.

DreamLight Constellation also runs cross-platform on both Mac and Windows and remaps paths on the fly for Mac/Win. However there's a problem we kept running into with Windows nodes running LWSN that would often read a duplicate bogus command from the SMB network cache. In such cases they would report "Ignoring duplicate command" to the terminal but not report anything back to the controller. So there was no easy way to recover from this which meant Windows LWSN nodes would just drop out of the network over time. This also happens when using the built-in Network Render panel. The workaround I used for simplicity on this initial version was to add a 30 second delay between LWSN commands if any Windows nodes are detected in your setup. This 30 second delay got rid of the problem of LWSN reading bogus duplicate commands from the SMB network cache. In future versions I'd expose that setting to the user to tweak or disable this setting. It also may only be needed in mixed Mac/Win networks and if so I can disable it on Win/Win networks in a future version.

So if you're rendering primarily on Windows and are rendering frames that only take a minute or so then yes, that 30 second delay that Constellation uses will slow down your renders. If you're rendering frames that take long to render then the delay wouldn't be as noticeable. If you're Mac only, there is no delay and it should be the same speed as any other controller. That Windows 30 second delay workaround is noted on the Constellation page but I thought I'd explain it further here for anyone that missed that.

Thanks,
-MikeS

Scazzino
01-18-2017, 11:40 AM
Here's the original note on the Constellation page about the delay.

"[NOTE: If a Windows node gets stuck just reinitialize it and it should resync. There’s currently a 30 second delay when Windows nodes are activated to compensate for the SMB networking cache sending repeat commands to the LWSN nodes.]"

I've reworded it to be clearer that the delay is between all LWSN commands where the original note could have been misinterpreted as only occuring when first activated.

[NOTE: There’s currently a 30 second delay between all LWSN commands when any Windows nodes are detected to compensate for a problem where LWSN reads duplicate commands from the SMB networking cache. If a Windows node gets stuck just reinitialize it and it should resync.]

Hope that's clearer!

Scazzino
01-18-2017, 12:10 PM
One other note about setup. Constellation uses the LW config file to read the plugin directory. The tutorials walk you through setting it up by installing directly on all nodes because that's sometimes the most robust rather than running all the nodes across the network, so that only the job/ack files are read/written over the network (along with the rendered frames of course). Sometimes I've had trouble running too many nodes over the network rather than each running locally on each render node. So that's the way the tutorials are structured. But, you should be able to set it up to run LWSN over the network and read the config files (and thus the plugin directory) over the network as well. Just like the built-in network controller. It should basically run just like the built-in controller but allow drag-and-drop configuration, scene queue reordering, Mac/Win path remapping, individual scene/node starting/pausing, etc.

So for a small Mac studio I'd recommend Constellation (which is why I wrote it for my own Mac studio).

For a small Mac/Win studio that's mostly Mac but has a few Win render nodes and renders frames that take a while to render so the 30 second delay on windows isn't a problem I'd still recommend Constellation for the price.

For a larger primarily Windows studio that renders lots of quick frames, one of the other Windows centric controllers would render faster without that 30 second delay.

Hope that helps!

Scazzino
01-18-2017, 12:21 PM
BTW: I'm curious for those running Windows only and/or Win/Mac networks with another controller. Do you ever notice LWSN nodes reporting "Ignoring duplicate command" and then just hanging? If so what does the controller do?

Spinland
01-18-2017, 12:24 PM
Interesting, thanks for the insights, Mike. I can vouch that the lone Windows machine in my studio sometimes hangs and has to be kicked in the keister to get it back online. Fortunately it's really only around to run MOCAP stuff so I don't rely on it much.

One great way I've found to share common files (like configs and plugins) across all my nodes is to install them into a DropBox folder and point everything there. Give it a few minutes to sync up after any additions or changes and voila. I did have some issues with the commands folder being there: as I noted above sometimes my local network gets dodgy and I was missing ack reads so nodes were getting borked. I have all that stuff on a NAS now that gets automounted by new nodes as I add them to the farm. Still a shared folder but more quickly in sync than DropBox. My farm is no great shakes size-wise but with some good file structure management it's not hard at all to keep all the nodes in sync. Not sure how Windows would handle stuff like that since it doesn't follow the *nix industry standard for file systems. In MacOS I just use the command line tools to move and symlink stuff wherever I want it.

Spinland
01-18-2017, 12:27 PM
BTW: I'm curios for those running Windows only and/or Win/Mac networks with another controller. Do you ever notice LWSN nodes reporting "Ignoring duplicate command" and then just hanging? If so what does the controller do?

Well, when the token Win10 box hangs the controller just shows it holding at the last status it reported. If I restart the node it picks up at the next frame the controller gives it and I have to remember to re-render that frame after the fact. It's often better just to leave that box out of the render unless I really need the extra boost in time. Gotta weigh risk and reward. If there were good MOCAP tools for MacOS I'd donate the silly thing to charity.

Scazzino
01-18-2017, 12:35 PM
Interesting, thanks for the insights, Mike. I can vouch that the lone Windows machine in my studio sometimes hangs and has to be kicked in the keister to get it back online. Fortunately it's really only around to run MOCAP stuff so I don't rely on it much.

One great way I've found to share common files (like configs and plugins) across all my nodes is to install them into a DropBox folder and point everything there. Give it a few minutes to sync up after any additions or changes and voila. I did have some issues with the commands folder being there: as I noted above sometimes my local network gets dodgy and I was missing ack reads so nodes were getting borked. I have all that stuff on a NAS now that gets automounted by new nodes as I add them to the farm. Still a shared folder but more quickly in sync than DropBox. My farm is no great shakes size-wise but with some good file structure management it's not hard at all to keep all the nodes in sync. Not sure how Windows would handle stuff like that since it doesn't follow the *nix industry standard for file systems. In MacOS I just use the command line tools to move and symlink stuff wherever I want it.

Thanks! I'm glad it's working well for you!

Yes, I've even set it up using Dropbox to render across the Internet between local and remote nodes. As long as all the computers can access the job/ack files and the content folder then they can render, anywhere in the world. It's not the fastest method, so doesn't work well for frames that render fast, but if the frames are taking a long time to render each frame, then the extra time to handle the remote networking doesn't cause much trouble vs. the extra horsepower you can add with the remote nodes.

Here's a tutorial where I showed how to render across the Internet using Dropbox. Any such filesharing system should work similarly.

http://dreamlight.com/blog/mastering-lightwave-3d-screamernet-lwsn/internet-rendering-with-lightwave-3d-screamernet-lwsn/

vonpietro
01-20-2017, 12:37 AM
what about this one -- http://www.lightspeedrender.com/

also
butterfly wants 379 for 16 nodes - is a node a cpu - what if i have 4 dual xeons hex cores compiters. is that 4 nodes or 8 nodes or 24? (is it based on cores or cpus?)

Danner
01-20-2017, 03:57 AM
Usually for rendering applications a node is a PC regardless of CPUs or cores.

kopperdrake
01-20-2017, 04:06 AM
From their FAQ:

Q: Is each Processor in a Multi-Core system considered a Render Node?

A: Yes it could, but, you could configure the rendernodes to use all CPU’s or a single CPU/Core in a multiprocessor system.
So you are not locked into using a rendernode per CPU/Core – you can configure them depending on the type or render system you will be using.

_____________

I can confirm that my dual processor machine on the network here is only running as one rendernode.

Greenlaw
01-20-2017, 01:51 PM
Kopperdrake already explained but, yeah, it depends. You can configure it for each PC or per Core if you wish...it's up to you. On some multicore systems, if you have plenty of RAM on a computer, it can make sense to run more nodes on a single system.

In my case, I don't have a ton of RAM in each multi-core PC, and I assign one BNR node per PC because my renders seem to go faster that way--that is, all cores can concentrate on getting one frame done faster, rather than splitting up the resources on one computer to render multiple frames more slowly. Of course, if my scenes were lighter, then it might make sense to run more nodes per box.

Several years ago, I didn't understand that and I wound up purchasing way more BNR node licenses than I have ever been able to use in my home studio. Fortunately, Paul has never charged me extra to upgrade all those extra nodes I don't use. (Maybe someday I'll be able to afford a farm big enough to make it worthwhile. Someday...) :p

jwiede
01-20-2017, 01:54 PM
Usually for rendering applications a node is a PC regardless of CPUs or cores.

There are currently CPU limits in Win10Pro (https://answers.microsoft.com/en-us/windows/forum/windows_10/windows-10-versions-cpu-limits/905c24ad-ad54-4122-b730-b9e7519c823f?auth=1) (only 2 physical CPUs, but up 256 cores per CPU), which represent the practical "single node" limits for BNR and similar render node systems. Running more render nodes than the number of actual cores (not threads) present is probably unwise, but can be done, IIRC.

I'm a long-time BNR customer, have a spare 16c/32t system sitting here that I fire up occasionally for rendering, as well as my main 12c/24t MacPro5,1, and I find BNR very flexible about allowed render node configurations (and highly efficient once up and running). I'm looking at upgrading my DLI SNUB licenses to Constellation when I have more time, in order to do some of my own compare/contrast testing.

Chrusion
01-25-2017, 02:58 PM
You cannot run multiple instances of BFN node and configure each one to use a select number of cpu/cores. Also, you can't run multiple instances of bnetservice, which manages the execution of a single BFN node only. So, even though you can limit a node to a desired number of cpu/cores, only ONE node can run on one PC at a time, thus each computer is one node.

BTW, has anyone been able to get BFN service to run properly in Win 7? For me, it gives an "error 87: the parameter is incorrect" error when starting the service. Paul hasn't been able to figure it out. It gives the same error on my home system (not IT managed) and at work (IT managed).

jwiede
01-25-2017, 07:16 PM
You cannot run multiple instances of BFN node and configure each one to use a select number of cpu/cores. Also, you can't run multiple instances of bnetservice, which manages the execution of a single BFN node only. So, even though you can limit a node to a desired number of cpu/cores, only ONE node can run on one PC at a time, thus each computer is one node.

Hmm, I could swear I had this working at one point, though thinking back, I vaguely recall I had to mess around with network interface assignments, etc. to get it working. I'm pretty sure I wasn't using virtualization (machine-scoped virtualization, anyway), either.

Is that a recently-added (BNR5 or BNR6) restriction by any chance?

I'll have to ask Paul and see if he recalls the discussion. I recall it was when I had spare "big" machines as BNR nodes while working at AMD (we had a bunch of machines with lots of cores sitting around doing nothing in our team), but that's almost ten years ago so don't recall precise configuration.

Chrusion
01-26-2017, 11:05 AM
I'm pretty sure it's always been this way, at least since 4.0. After launching a node, double-clicking on the shortcut icon results in "ButterflyNet Client is already running..."

Spinland
01-26-2017, 03:25 PM
FWIW the Smedge controller software provides a butt load (that's a real measurement, Google it) of CPU-vs-node options. I just did not like how fiddly it was to keep running on my network. If you want granularity down to having one frame per potential thread, even hyperthreads, it'll give you that. It's also compatible with the other apps out there such as Maya and Max.

For my part I am loving Constellation and have no interest in changing (again). I have a six-machine render farm of mixed Mac and PC boxen and it Just Works(tm). I personally can't ask for more than that.

Scazzino
02-15-2017, 12:18 PM
For my part I am loving Constellation and have no interest in changing (again). I have a six-machine render farm of mixed Mac and PC boxen and it Just Works(tm). I personally can't ask for more than that.

Thanks Spinland!

Just some background info. The reason it's been a long time without updates for DreamLight Constellation (http://dreamlight.com/shop/dreamlight-constellation-lightwave-3d-network-render-controller/) is because LiveCode (the IDE that I used to make it cross-platform rather than using XCode which is Mac only) has changed their licensing scheme and it is no longer cost effective for me to make updates using that IDE. So, I've been in the process of a full re-write from the ground up in Electron (http://electron.atom.io/)/React (https://facebook.github.io/react/) for the next update.

So, other than removing the Windows speed issue (mentioned in the OP) by making the 30 second Windows network cache delay editable by the user (and limited to the windows nodes rather than the entire farm), what other issues/features would be desired for me to consider in the next update?

Here's an initial screenshot of 2.0.0 currently in development in Electron/React. (A few items I'm already adding are full window resizing and additional information for rendering scenes such as elapsed time, average time, estimated remaining time and ETA, not yet in this screenshot.)

BTW: In Constellation you can configure each computer to run as many render nodes as you like up to the license #. Just limit the threads each uses in the config file (http://dreamlight.com/blog/mastering-lightwave-3d-screamernet-lwsn/managing-lightwave-3d-screamernet-lwsn-config-files/#Multithreading).

calilifestyle
02-15-2017, 01:17 PM
Better windows docs. I had trouble following the links.

Scazzino
02-15-2017, 01:32 PM
Better windows docs. I had trouble following the links.

That's an easy one. Was there a specific sticking point that gave you trouble?

Scazzino
04-13-2017, 09:42 AM
I'm preparing to package and release an initial beta version of DreamLight Constellation 2.0 shortly. It's a complete rewrite in Electron/React. I've added more robustness when dealing with the Windows SMB cache issues (LWSN reporting 'ignoring duplicate command' errors). I've also exposed the ScreamerNet Throttle setting to the user in the preferences which allows you to tune it to your own network's performance. This removes the hard-coded 30 second delay on Windows that was causing Windows scene renders to take longer than Mac scene renders. I've also implemented a few new features such as reporting avg frame render times, estimated time remaining, estimated completion time and sending system notifications when a scene finishes rendering.

Any registered users who wish to participate in the beta (Mac and/or Windows) please let me know (http://dreamlight.com/contact/) and I'll add you to the list for when the first beta is ready shortly. BTW: Now that it's based on Electron/React rather than LiveCode I'll be able to push out patches/updates whenever needed. Any NEW purchases of Constellation from this point on will get a free upgrade to 2.0 when it's released.

Scazzino
04-18-2017, 03:49 PM
OK gang, we're in beta, with an impending release (that addresses the Windows delay from OP), and a pre-release sale!

In celebration of DreamLight’s 30’th anniversary we’re pleased to announce that our newly upgraded DreamLight Constellation 2 network render controller has entered final beta testing for an impending version 2.0 release. All DreamLight Constellation version 1 registered users are eligible to participate in the beta test.

For a limited time only, any new purchases of DreamLight Constellation version 1 licenses will automatically be eligible for a free upgrade to version 2.0 when released. All pre-release sales lock in the current prices and allow you to purchase version 2.0 licenses at the current version 1.0 prices.

http://dreamlight.com/dreamlight-constellation-2-0-upgrade-announcement/

An excerpt from the announcement that specifically addresses the point about the Windows delay from the OP.

"We’ve revamped our ScreamerNet LWSN communication stack to add more robustness to LightWave 3D cross-platform network rendering. This is particularly useful to help circumvent the typical SMB network cache issues that often derail Windows renders where LWSN reports “ignoring duplicate command” errors. In such cases LWSN is not reading a duplicate command from the network controller. It’s re-reading the previous command from the SMB network cache. In DreamLight Constellation version 1 we had implemented a 30 second delay between LWSN commands to allow the SMB cache to clear between commands for Windows render nodes. This had a negative performance impact on Windows network rendering that was most noticeable when rendering scenes where frames only took a minute or so each. The more robust LWSN communications handling in version 2.0 allows most such errors to automatically correct themselves. We’ve also made the ScreamerNet Throttle setting user adjustable in the preferences panel for further network tuning."

And here's a screenshot of the new preferences panel with the new user adjustable ScreamerNet Throttle setting to allow fine tuning of your network. Thanks for all the feedback!

http://dreamlight.com/wp/wp-content/uploads/DLI_Constellation-Screens-MacPrefs-FullWin_17A.png

Scazzino
05-06-2017, 02:07 PM
OK, DreamLight Constellation 2.0.1 was just posted live for download today (http://dreamlight.com/shop/dreamlight-constellation-lightwave-3d-network-render-controller/). Official announcement will follow on Monday but downloads are already up and ready. This version implements the user adjustable ScreamerNet Throttle to allow optimization of your network. This brings the Windows version on parity with the Mac version as far as communication/render speed. So the biggest issue in the OP (the 30 second delay between LWSN commands) should be addressed by this update. Feel free to download and give it a spin. I'd be interested in any feedback!