Existing Render Farm for 3Delight/RIB
This question is a bit of follow-on to Wancow's tutorial on RIB and 3Delight.
For those of us who do not have ready access to a fast render machine and would like to experiment with a render farm, 3Delight claims this is quite doable. However, I have not found any render farms that support 3Delight or RIB, in general. The ones I have contacted only provide direct support the "major" 3D packages (Maya, 3DS, Lightwave, C4D, etc.).
Yes, I have studied the tutorial on Lux-in-the-cloud but that does not apply to 3Delight, as far as I can tell. I have Reality 2.x but I am not interested in investing the time, at the moment. Also, it is clear that Amazon has made many, many changes in the past 1 1/2 years.
No, I have no interest in setting up my own render farm.
Has anyone seen evidence of a Render Farm that does provide direct support for 3Delight/RIB? I don't see evidence of one at the 3Delight forum.
Thanks.
Comments
The main problem is that according to the DAZ license you would be able to upload only items you have made yourself or that are in the public domain, not any DAZ3D items. With the preceding caveat, example 3Delight render farms: http://www.xlrender.com/renderfarm/render/ , http://www.mirage-vfx.com/services/render-farm/?cbg_tz=-60 , http://www.focuzinfotech.com/hpc.htm .There was also an announcement from Qube that they were going to support 3Delight but I don't see it listed on their site: http://pipelinefx.com/
Thanks for the info. In terms of the DAZ license, since nothing is uploaded but a RIB file, why would that apply here? Also, there have been many posts regarding the use of Amazon Cloud for rendering DS scenes using Lux. Why the difference with 3Delight?
As to uploading 'just a RIB'...nope, not quite. The RIB will contain the geometry info...in fact you could edit the RIB, pull out the geo info and dump it to a file and give the extension obj...and presto...instant mesh (not exactly THAT easy...but yeah, it's doable). Also, you need to upload the materials...otherwise you'll render rather 'white' items...that's if you don't include the shaders, because if you do, then you'll get shiny/shadowed/occluded/etc white renders...
Now, as to how it differs...I suppose if it were like the Amazon cloud service that supports Luxrender, where you are actually rendering on a virtual machine through your own account, that is more or less an extension of your own computer/network as opposed to passing it off to a third party to render on their machines, that would be the difference.
Hmm, that's a good question. I asked for clarification about the Reality/Lux tutorial to Richard a couple of years ago and he said he passed it on to DAZ, but I never heard back. If it's tolerated for Lux I don't see why it shouldn't be tolerated for 3Delight.
It's an exercise in futility anyway. If one looks at what is supported for Maya, Lightwave, etc. there are some serious tools provided for the user directly by the Render Farms. It would appear that none of the Render Farms provide any support for DS while some support 3Delight but only for major render efforts. I sent queries to 3 farms asking about support for 3Delight. Only one of them even responded and that was with just a simple "No".
This is probably just another bit of evidence supporting those in the rest of the 3D industry that view DS as a toy for beginners and hobbyists with its' purpose being to sell content (no one questions that it's a serious thing for those making money from content and/or tools for DS).
Is DS a hobbiest's tool? Yeah, it probably is.
Is 3Delight, however?
You tell me... because, yanno... Superman Returns, Harry Potter, Twilight, Knight and Day, District 9, Terminator Salvation, Fantastic Four, XMen Last Stand, The Chronicles of Narnia, they didn't use 3Delight... Nope, not a bit.
Did I say 3Delight was a hobbyist tool? I am fully aware that is considered a serious render engine. As you know, it is supported on both 3DS and Maya platforms. The potential quality of render is one reason that I have decided not to invest more time in Reality 2 and Lux (the others being that Reality requires more effort plus Lux renders very slowly on my machine). Since there is no direct support for DS on these farms, I was referring to evidence of indirect support for 3Delight as this would then be required in order to make something work. I hope other interested parties do some checking, as well.
It is possible that support for 3Delight is baked into the tools that these render farms provide to their customers who are running the major 3D packages. I can't tell but does it really matter? The issue here is DS and possible alternatives to slow render times on our local PCs.
Interesting to hear you say that DS is a hobbyist tool. I guess if one is trying to do any semi-serious or serious work in telling stories this is not the place to look for tools (and don't tell me about Carrara as I see no clear evidence that this tool will get much DAZ support going foward). If for no other reason, render times are going to become a major bottleneck in the process.
The alternatives appear to be low quality renders and/or the purchase of a very expensive render machine.
I also said "Probably" - And I think Poser falls into that same category as well. Of course, both of those are opinions. ;)
DS has self-imposed limitations with 3Delight in order to give it away for FREE. The first and foremost of those is no Network Rendering. Which I understand is why you're looking for a render farm, but there are a lot of issues down that path as you've already begun to see.
If you're doing animation, the best way to work around this is to render to image sequences (this is better anyway) and spread the frames around different machines.
From what I understand the best way to get the most performance out of the FREE 3Delight version is to run it on a Linux box which can boot into command line mode so its not using up any resources on a GUI. Folks in other threads have stated that it renders blazing fast.
To me this seems like the cheapest way to get "faster" renders. since the 3delight pricing models seems to push the cost of a render farm out of the reach of alot of folks
Eh, I have 12 cores for about $3K. I'm 99% sure my 12 cores, even with overhead render faster than 2 cores without.
Here, my opinion of course, but the difference is that Smith Micro sells Poser as part of its' overall strategy to sell software (in addition to content to some extent). As for DAZ (speculation), DS exists to sell Genesis and support the required needs of the PAs producing that content. It would appear to me that Poser is better positioned to integrate with other tools. Is Manga Studio Pro now just a hobbyist tool? Anime Studio Pro?
Would DS now be getting even minimal upgrade support if Smith Micro had decided in 2011 to provide direct support for Genesis in Poser 9 (or if DAZ had decided to stick with Gen 4)? In 2011, Daz had four 1st-party software packages for sale. It now sells one at a very reduced cost and that one hasn't had a major non-beta release in how many months?
Regardless of what DAZ may think, this stuff is not lost on its' user base and the 3D world, in general...
just going by what I've read in other threads. I myself don't see how even a bare bones linux install on a box with duo cores is outperforming a windows machine with 6 to 12 cores.
unless its two physical single core processors running around 3ghz per processor then yeah maybe.. but you'd probably only see a difference on renders with high resolution textures.
I don't have a spare machine to build up and test. (or the space to put one)
just going by what I've read in other threads. I myself don't see how even a bare bones linux install on a box with duo cores is outperforming a windows machine with 6 to 12 cores.
unless its two physical single core processors running around 3ghz per processor then yeah maybe.. but you'd probably only see a difference on renders with high resolution textures.
I don't have a spare machine to build up and test. (or the space to put one)
Depends on how the software was coded and compiled.
When I started using the RIB output method I would render on an Intel iMac with 3GB ram between OS 10.5 and native Windows XP, both stripped down to a zero TSR boot, the mac version was always faster, hands down, same machine, same everything except how the software was coded between the same exact version. OS X is BSD Unix. these were both 32 bit OS's btw.
Depends on how the software was coded and compiled.
When I started using the RIB output method I would render on an Intel iMac with 3GB ram between OS 10.5 and native Windows XP, both stripped down to a zero TSR boot, the mac version was always faster, hands down, same machine, same everything except how the software was coded between the same exact version. OS X is BSD Unix. these were both 32 bit OS's btw.
MAC OS on the proprietary hardware was always faster than a comparable windows box hands down. and windows XP even stripped to a TSR boot used more resouces than OS X,
@artistb3, original poster. Stumbled across this thread, as for 3Delight in a rendering farm, I was one of the first to have such a thing. Had a tv series and realtime 3d/live action rendering with the Panavision 24p cameras when they launched. Worked amazingly well, I remember when we hit our millionth HD frame in the first year of development, big party. I still have the rendering farm up and running.
Render Farms that support 3Delight:
http://www.xlrender.com/renderfarm/render/
http://www.mirage-vfx.com/services/render-farm/?cbg_tz=420
Actually any software that exports RIB format would be supported. One might have to do a little file manipulation, but you should anyway. Never export none changing data every frame, total waste of resources. The true power of RIB format is unsurpassed. Forget about single system rendering, pointless if you really want speed. Find some first gen AppleTVs (use OS X 10.4 or Linux) (we used something else that was easily replaced by the AppleTV), more than enough power and RAM to spit out full HD frames, and once you have several, you can output sequence after sequence in record time. A little work and planning and you have a very modular and flexible pipeline, just grow it over time.
Jasonbelec, you stated in your first post you actually have a render farm and support 3Delight? do you have a website?
Currently no site for that. However if your just looking me up, unless a change has occurred recently I am still in the 3Delight acknowledgements. If your interested in getting something rendered, well that's on a per request discussion.
As soon as I have a project that needs your services, I have you on speed dial :)
Although, come to think of it, I do have one project that might just need your services, however there's a problem. I cannot figure out how to get a background image into 3Delight Stand Alone... I have to render out an 8x10 at 300dpi with two or three layers... but its a little dependent on the background image so the background image colour is consistent on the edges of my alpha channel... I can't figure out how to get that into 3Delight. I can, of course, do it in DS natively, but not in 3Delight... :(
Not sure what you mean precisely. Assuming you use a default shape, a plain (flat surface) and apply a texture, as long as you have a light of some sort you should get a simple RIB on export (you of course only really need a text editor to test this). Does that not render? Or let's start simpler, what can you get to render at this point in time, just to know the process is working?
TIP: for renderfarms, testing, etc.. -- Everyone here knows how to use 'archive' feature of RIBs right? So you can render your scenes without re-exporting everything that doesn't change, really helps with speeding things up, quick changes to anything from lighting, shader, models, animation sequence, and so on.
Basically it's this: render background, set it as backdrop, render what's in front of the background, and set that as a backdrop, then render the foreground... I"ve found that works best when rendering layers. Setting an object with the backdrop as a texture perpendicular to the camera with the proper dimentions is difficult at best. It would have to have ambiance with no light hitting it and no shadows accepted. I'd rather just be able to assign a background image and have it work.
No, I do not have the first clue how to do that.
OK, not efficient, but if your happy then you should stick with it until you get the urge/time to experiment.
So currently you do everything without exporting, right? If I misunderstood, please re-orient me.
If you do export, what are you getting in the RIB?
@adamr001
If you are talking about a single frame, maybe, otherwise, well you would be wrong. This is not a new topic in any way whatsoever. I personally have proven several times that many small machines can decimate any large system even those who believe graphics cards were the answer. It's all in how you handle things and the basic premise one must grasp is that your software package (no matter which one you utilize) is crap. At least for efficiency of output, and specifically when rendering RIB format. Before you get excited, do take into account that Pixar, every VFX studio, ILM, etc., have been using and proving this for a very long time,
In 2001 we tested rendered over 1 million full HD frames in early development partnership with 3Delight on 7 small boxes called BriQs that had 512 MB RAM each, no graphics card, 20GB HDD and wimpy AMD PC-III processor running RedHat Linux handed off from the animator work stations (MacPro's).
And so we're clear, each frame if exported as a whole was 30GB, how long does your 12 core system take to export and render something like that, and then say 100,000 frames like that for the average features final length?
It's all about economies of scale.
I use the 3Delight stand alone a lot. I just can't use it if I'm rendering a layer with a background image :( And that I would dearly love to be able to do.
All I know how to do is render to RIB with collected files and do RenderDL -ID file.rib
By no stretch of the imagination am I an expert. I have never touched RSL, though it would be nice to understand it at least...
But when I send a file to RIB, I get the exact same results in 3Delight stand alone as I do in DS... the advantage for me is on my four core machine I get two cores to do other things while rendering.
Something is off with your 2001 timeline.
Mac Pro wasn't around until 2006, 2001 the Mac Towers were just hitting the 733MHz. mark with the G4 Quicksilver model and having teched over a dozen of those systems the only thing correct about the name was they were silver.
@Jasonbelec: the background referred to by wancow is a feature in DAZ Studio in which, if the user elects to use an image as background and if no ray intersects any geometry then the background picture is rendered for that ray. It's just like having a plane but without the hassle, such as it is, of its orientation, nor any issue with scene to background interaction. So basically there is no geometry for the background image.
I'm old, lots of systems over the decades. Your right and that is what we used at the time. ;).
Thank you. I better understand the issue. This technique has been done for decades, one just has to be properly setup. DAZ has just rolled it in as a useful feature, which like all features discourages learning. I'll have to think of an easy way and probably have a few more questions to reach a reproducible process.
I use the 3Delight stand alone a lot. I just can't use it if I'm rendering a layer with a background image :( And that I would dearly love to be able to do.
All I know how to do is render to RIB with collected files and do RenderDL -ID file.rib
By no stretch of the imagination am I an expert. I have never touched RSL, though it would be nice to understand it at least...
But when I send a file to RIB, I get the exact same results in 3Delight stand alone as I do in DS... the advantage for me is on my four core machine I get two cores to do other things while rendering.
Within the files for 3Delight, do you not have the 'background image shader' or some such named fie?