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.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
You can get a real wiz bang system for under $500, easily.
Cheaper still if you buy a bare bones box, the parts separately and put it together yourself.
I have three words for you about where to shop: tigerdirect, tigerdirect, and tigerdirect.
tigerdirect=screw-job. You'll spend more money sending back defective goods and mis-shipped parts than you'll save. With tigerdirect it is caveat emptor to the max.
Kendall
tigerdirect=screw-job. You'll spend more money sending back defective goods and mis-shipped parts than you'll save. With tigerdirect it is caveat emptor to the max.
Kendall
Really? I've yet to have a problem with them, and I've been dealing with them for years.
I've had dealings with at least 2 dozen folks over the years that have had very bad dealings with TD. I've personally had one order messed up royally by them (for well over two thousand dollars), but after some "persuasion" they made good. I've had a couple messed up slightly, but the cost to "fix" the problem was more than the amount lost.
There are some times that I will chance a purchase from TD, but it is only with extreme caution. I will not recommend them to any of my
clients, as TD's failure will reflect on me.
EDIT: But this thread isn't about TD, but about 3DL. :-)
Kendall
Really? I've yet to have a problem with them, and I've been dealing with them for years.
Hey man, I ain't calling you a lair, I've just never had any problems with them personally.
But yeah, we're getting OT. Back on topic, I've got nothing but good things to say about using the Standalone version. I've been playing with it ever since mid day yesterday. I've been trying light set ups that take an obscene amount of time when rendered in-studio, and to my delight they render at a very quick pace in standalone, like Lightdome Pro.
I'm not insinuating that you are. :-) Folks will have a lot of different experiences with any vendor. I happen to deal with a large number of people in IT on a regular basis, and am more likely to run into more people who have had problems than most. I just wanted to pass along a precautionary heads-up for those who may find TD's prices tempting, but who may also be ill equipped to deal with the extra costs sometimes associated with buying from TD.
Kendall
The key to doing that in Lux is to light your scene as if you were lighting it for a movie. Now that said, if you're absolutely doing things that won't work physically (like say, a vampire scene and need the vampire to not cast a reflection) then you really can't use a physical unbiased renderer.
...well, if I could get 4.5 to behave while setting up a scene. I can use the latest 3Delight Standalone as it should be able to interpret the shaders correctly. Tried it with a scene set up in 3Advanced only to get a tonne of TDLMake errors and a lovely render of the .obj file.
As my current system is only a DuoCore, not losing any "performance" with the free licence.
The key to doing that in Lux is to light your scene as if you were lighting it for a movie. Now that said, if you're absolutely doing things that won't work physically (like say, a vampire scene and need the vampire to not cast a reflection) then you really can't use a physical unbiased renderer.
Where unbiased renderers fall down is anywhere where full daylight/moonlight isn't available or wanted. Go outside in the countryside (where there's no light pollution) on a night with a new moon (or before the moon has risen). One will see exactly ... nothing. (I live in such a place.) Unbiased renderers will give one exactly that in a nighttime scene: nothing. And they would be right. However, try recording a scene that way... disembodied voices anyone? Watch any movie scene set at night away from "neon". The train yard, the cemetery, the warehouse, the abandoned boiler room, the slum alleyway. Where is all of that light coming from naturally? Nowhere. In real life, physically, there would be little to no light, but in the movie scene we can see clearly. This is where the unbiased renderers fail; they're supposed to. Adding lights really doesn't help, as they act like light would, which is exactly what one doesn't want.
Similarly, many times lights are added even outdoors in full daylight. The sun projects shadows that play h*ll with cameras, so flood lights will be used to soften the shadows, or even remove them. Again, an unbiased renderer will give one physically correct light, but not the light needed for the purpose.
In this case, it's using the right tool for the job. Unbiased renderers are great when striving for photos, not so much for situations where the lighting, by its very nature, is contrived.
Don't get me wrong. I like Lux, I've liked it since its inception. I'm interested in Octane, once it is a bit more capable. I've written radiosity renderers in the past, as well as raytracers and scanline renderers, and other not so well known types. They each have their place. For the moment, unbiased rendering is limited to photo-realism. However 90%+ of all production rendering is not "real light" and therefore is in the realm of biased renderers.
Kendall
...this is why I still like using LDP2, SLP as well as making up my own light sets. Lighting in and of itself is a very powerful medium. and biased rendering brings out what I feel is a more "expressive" quality.
I'm not even totally won over by IDL except when using CG models with photo based backdrops/settings (which is one of it's better strong points).
This rendered in about a half a minute, using 3Delight standalone, using the lighting set that came with the scenery. The only post work done was a day-to-night shift in the color. I had D|S and Chrome running to boot.
Kendall
Where unbiased renderers fall down is anywhere where full daylight/moonlight isn't available or wanted. Go outside in the countryside (where there's no light pollution) on a night with a new moon (or before the moon has risen). One will see exactly ... nothing. (I live in such a place.) Unbiased renderers will give one exactly that in a nighttime scene: nothing. And they would be right. However, try recording a scene that way... disembodied voices anyone? Watch any movie scene set at night away from "neon". The train yard, the cemetery, the warehouse, the abandoned boiler room, the slum alleyway. Where is all of that light coming from naturally? Nowhere. In real life, physically, there would be little to no light, but in the movie scene we can see clearly. This is where the unbiased renderers fail; they're supposed to. Adding lights really doesn't help, as they act like light would, which is exactly what one doesn't want.
Similarly, many times lights are added even outdoors in full daylight. The sun projects shadows that play h*ll with cameras, so flood lights will be used to soften the shadows, or even remove them. Again, an unbiased renderer will give one physically correct light, but not the light needed for the purpose.
In this case, it's using the right tool for the job. Unbiased renderers are great when striving for photos, not so much for situations where the lighting, by its very nature, is contrived.
Don't get me wrong. I like Lux, I've liked it since its inception. I'm interested in Octane, once it is a bit more capable. I've written radiosity renderers in the past, as well as raytracers and scanline renderers, and other not so well known types. They each have their place. For the moment, unbiased rendering is limited to photo-realism. However 90%+ of all production rendering is not "real light" and therefore is in the realm of biased renderers.
Kendall
Hmmmm .... OK, I'm not trying to pick a fight or derail the discussion (which is quite interesting), but I fail to see the logic here, or possibly my logic is completely flawed. Maybe you could help me understand your view point a bit better.
As I understand it, by definition, unbiased render engines use real light physical poperties (or real light physics) to "light" the scene. On a film/studio set, real lights are used to light the scene. So, by definition, if one had all the proper information regarding lighting and set/studio environment, would that not produce the exact same lighting as was found in the studio/set (assuming that the software had the proper tools to reproduce the lighting like softboxes, reflective umbrellas, etc.)?
A biased renderer uses light simulation "cheats" (for lack of an easier term), such as ambient occlusion, to provide rapid sampling/simulation of the effects of real light physics without encountering the overhead of actually performing the calculations for every mm of surface/light interaction required by an unbiased renderer. The beauty and utility of a biased render engine is the dramatic increases in rendering speed while using predictable approximations of lighting effects. The downside to biased render engines is that it can often be quite difficult to achieve equivalent lighting effects compared to unbiased render engines (caustics for example).
It's my understanding that where unbiased render engines fall down in the production environment is not their inability to faithfully reproduce studio/set lighting. They "fail" in the production environment due to their inability to produce images quickly. The additional calculation times required for the ray-tracing of lighting based on real light physics would easily push production times from hours/days to months to render 5-10 minutes of film. At least that is my understanding and logic.
So, in your example above, where does the lighting come from for the filming of a night time scene? From lights, the moon, etc., unless they are using infrared cameras (and that would just look weird, unless that was the desired effect). Wouldn't an unbiased renderer with the same lighting/environment, and camera/film setup achieve the same lighting as the nighttime scene of the set/studio? Take a visible spectrum camera outside when there is no moon, cloudy with no stars, and no ambient light from artificial lighting (like in/near a city), and you'll get the exact same thing as your example above with any renderer or visible light spectrum camera (doesn't matter if it's a biased or unbiased renderer). Regardless of medium, no visible spectrum "light" in the scene means black render or black photo/film/image.
Speed is indeed one reason for the methodologies used, but the ability to simulate the myriad techniques used in "lighting" is the main reason for the "cheats" as you call them. To the contrary, most biased renderers are fully capable of "physical light simulation." Those methodologies are rarely used because they have a deleterious effect on what is being attempted -- the replication of "contrived" lighting.
So, in your example above, where does the lighting come from for the filming of a night time scene? From lights, the moon, etc., unless they are using infrared cameras (and that would just look weird, unless that was the desired effect). Wouldn't an unbiased renderer with the same lighting/environment, and camera/film setup achieve the same lighting as the nighttime scene of the set/studio? Take a visible spectrum camera outside when there is no moon, cloudy with no stars, and no ambient light from artificial lighting (like in/near a city), and you'll get the exact same thing as your example above with any renderer or visible light spectrum camera (doesn't matter if it's a biased or unbiased renderer). Regardless of medium, no visible spectrum "light" in the scene means black render or black photo/film/image.
OK, my question was rhetorical as I presumed the reader probably knew the answer. In nighttime scenes, "blue" lighting is used to increase the recordable luminosity without increasing the ambience, and hence illuminating everything. If you'll look closely at those "nighttime" scenes you'll see the "blue." It is not wholly dissimilar to "black" light which will only increase the luminosity of specific elements. This is the reason one can see details in a "dark" area without getting the "nightvision" effect. It is these types of effects that current unbiased renderers don't handle.
Good questions. As I stated above, it is not that unbiased rendering *cannot* do these effects, it is that the current unbiased renderers *don't* handle these effects. I'm sure that in due time this will change. Also, your statements about product generation time... while previously quite true, are no longer germane. With the right hardware, unbiased rendering can match, and in some cases, exceed the speed of biased rendering.
At the moment we have a distinction between biased and unbiased rendering only because the attention is on two products that only do only one part of the rendering equation. Once, or if, Lux and Octane, can handle "contrived" lighting then the distinction will disappear. It is the same with GPU rendering, it is special only because of it is lacking in a subset of the tools. There is nothing inherently special about the tech that precludes its use in any one place.
Kendall
EDIT: I think it may be appropriate at this point to recommend to the interested reader the 2nd edition of "[digital] Lighting & Rendering" by Jeremy Birn. While it does not cover the absolute latest tech, it does give great insight into why specific rendering technologies are better than others for specific tasks. Since it is only around 400 pages or so in length, it isn't an overly hard read.
OK, my question was rhetorical as I presumed the reader probably knew the answer. In nighttime scenes, "blue" lighting is used to increase the recordable luminosity without increasing the ambience, and hence illuminating everything. If you'll look closely at those "nighttime" scenes you'll see the "blue." It is not wholly dissimilar to "black" light which will only increase the luminosity of specific elements. This is the reason one can see details in a "dark" area without getting the "nightvision" effect. It is these types of effects that current unbiased renderers don't handle.
Good questions. As I stated above, it is not that unbiased rendering *cannot* do these effects, it is that the current unbiased renderers *don't* handle these effects. I'm sure that in due time this will change. Also, your statements about product generation time... while previously quite true, are no longer germane. With the right hardware, unbiased rendering can match, and in some cases, exceed the speed of biased rendering.
At the moment we have a distinction between biased and unbiased rendering only because the attention is on two products that only do only one part of the rendering equation. Once, or if, Lux and Octane, can handle "contrived" lighting then the distinction will disappear. It is the same with GPU rendering, it is special only because of it is lacking in a subset of the tools. There is nothing inherently special about the tech that precludes its use in any one place.
Kendall
EDIT: I think it may be appropriate at this point to recommend to the interested reader the 2nd edition of "[digital] Lighting & Rendering" by Jeremy Birn. While it does not cover the absolute latest tech, it does give great insight into why specific rendering technologies are better than others for specific tasks. Since it is only around 400 pages or so in length, it isn't an overly hard read.
Thanks for the clarifications! Now back into lurk and learn mode.
vrba79
When you say the standalone are you using the fee or paid version? I am also a Lux user after 7 months I am pretty well versed at using it and love the results it gives me, but this has me curious since i give 2 tier pricing for commissions using UE lighting... How does one send a render to it?
This is untrue, I've rendered a night scene in Lux by using a NASA space map as my IBL solution and I placed a large mesh light a reasonable distance away as my "moon" light set to a very high colour temperature, leaving the film response set to daylight white balance to achieve the blue look you're describing. It can be done. I'd attach the image but it's on my other computer.
Again, this is not the case, you can still "contrive" light in a physically based renderer. You do it the same way a film set does it. See Preta3d's site for an example of this. Yes, the tutorial is mostly about reducing noise but it also demonstrates how to do contrived lighting properly.
Free version, I have a dual core processor, so that is all I need.
As for how-to, you need to render to a .rib file. I also tick that "collect resources" box.
Go to where it saved the .rib, double click the .rib and 3Delight renders it, if it doesn't happen automatically, you can have windows associate .rib files to "renderdl.exe" wherever you installed 3Delight.
Free version, I have a dual core processor, so that is all I need.
As for how-to, you need to render to a .rib file. I also tick that "collect resources" box.
Go to where it saved the .rib, double click the .rib and 3Delight renders it, if it doesn't happen automatically, you can have windows associate .rib files to "renderdl.exe" wherever you installed 3Delight.
Thanks but I just read that it will be slower for someone who had a quad core like me I have a year old i7 8G quad core machine which is why Lux is working for me overall but like I mentioned offering 3Dlight for clients who may not be as concerned with the type of render a lower price option
Thanks but I just read that it will be slower for someone who had a quad core like me I have a year old i7 8G quad core machine which is why Lux is working for me overall but like I mentioned offering 3Dlight for clients who may not be as concerned with the type of render a lower price option
Sorry that it's not going to work out for you, for me this is like sliced bread.
Thanks but I just read that it will be slower for someone who had a quad core like me I have a year old i7 8G quad core machine which is why Lux is working for me overall but like I mentioned offering 3Dlight for clients who may not be as concerned with the type of render a lower price option
Sorry that it's not going to work out for you, for me this is like sliced bread.
its cool overall my Luxrenders come out better I have shown my clients the comparison dine with both and 90% of the time they pony up for Luxrenders
Not necessarily true...while yes, the stand alone-free version, is locked to two cores, just the fact that it isn't running in the context of Studio could speed the process up, immensely. Sometimes even enough that a dual core rendering with the stand alone could actually beat a quad rendering in Studio (especially if it's the Linux version of the stand alone running from a console log in...I'd love to have 3 identical machines to do a timing test...all three use the same scene file...1st machine Windows/Studio, 2nd Windows/stand alone and 3rd Linux/stand alone...I bet the Linux machine beats them all, by a huge margin).
And while Luxrender is great, it's still slower, no matter what...until full GPU rendering is working correctly, it will continue to be slower. I've been getting pretty decent results and decent times using the SPPM rendering mode. I heavily tweaked the settings for it and saved them to a 'dummy' lxs file so I just copy and paste those settings into any scene I'm rendering. For most things I can get decent results in about an hour on my aging dual core machine. But, some of the same scenes, dumped to a RIB and rendered in the stand alone 3Delight render in under 15 mins. (Yeah, the 'look' is entirely different, but usually both look pretty good.)
I just ran a 3delight of the same type of scene I am rendering in lux (here is an example of the scene its my crossover of Fringe & Land of the giants story) http://fav.me/d5avfrb 3Delight was going to take 15 to 20 mins as oppose to the few hours something like this takes but I have learned not to mind it plus Lux rendering does not bog down my machine like 3Delight. I often queue render. I download the standalone 64 bit file and have it stored in any case so when you choose to render where is it one chooses to export the RIB file? I am guessing I just then need to get the 3Dlight app to read the RIB file like exporting only with Reality which I do with heavy scenes.
OK guys, anyone played with the point-based AO script that comes with the 4.5 release? I love it, but I wish there were an option to "collect and localise" while rendering to RIB. Otherwise it looks like DS has to be open at the same time (since it erases its temp .tdl files on closing, and the RIB references them) which sort of negates the benefit of using the standalone on my system (I only have 2 GB RAM, and please don't tell me to upgrade - unfortunately I'm not a pro artist and there's a lot of things going on in real life that won't give me the luxury of spending time shopping for a new laptop, optimising the new OS, reinstalling my programs etc)
In short, could anyone please point me to the page in the DS4 script documentation that would allow me to put that "collect and localise" box there myself?
You could always copy the files and then manually edit the RIB...it's a simple text file.
And whenever I've 'collected and localized' I've gotten everything (but then again, I haven't done the point based AO)
Please read the 3rd sentence of my post that you quoted as well as the 2nd to last paragraph. You will see that all of the points of your rebuttal falls well within those statements.
I'll restate the 3rd sentence of the 1st paragraph and stop there: "In short, any renderer (with enough effort) can replicate the results of any other, barring deliberate design limitations."
Kendall
Again, this is not the case, you can still "contrive" light in a physically based renderer. You do it the same way a film set does it. See http://preta3d.com/Kill the render noise form your Lux scenes/ for an example of this. Yes, the tutorial is mostly about reducing noise but it also demonstrates how to do contrived lighting properly.
The "Collect and Localize" check box is in render settings tab in the advanced area. It is grayed out until you activate "Render to RIB"
The files are collected into the "scene_collected" directory. You will need to edit the .RIB in a text editor that can handle over a million lines of code. Look for a reference to "brickyard" in a path. Redirect that path to the location of the collection directory and you're good to go.
OOPS! You may also need to look for a reference to "Studio4\temp" (this path can vary dependent on your preferences, but this is the default) and redirect that to the same place. It will depend on the specific shader whether there will be the "temp" reference or not. It may not always exist in the RIB. The same with the "brickyard" and "old_brickyard" references.
Kendall
stonemason won me over with the use of UE2 and one directional light for daytime scenes. I've mainly used LDP2 in majority of cases before I switched to UE2, and it's very fine for what it does. But it doesn't produce AO like UE2 does. I know it's 'faking' light, but it's part of what I do. ;-)
LOL thats cool Norse as far as using Lux and the time it takes my thought became who am I hurrying for? Producing my 500 plus stories will prolly take over 6 months rather then 2 1/2 but they will be lots purdier. Most of my fan base could not care less if I png layers together or produce nice lux renders its just my preference. I dont tweak maps and stuff. I always been a set the scene apply lights adjust some materials when needed and render type dude... I have already cranked out approx 600 plus renders since late feb..
stonemason won me over with the use of UE2 and one directional light for daytime scenes. I've mainly used LDP2 in majority of cases before I switched to UE2, and it's very fine for what it does. But it doesn't produce AO like UE2 does. I know it's 'faking' light, but it's part of what I do. ;-)
...having worked with oils for much of my artistic life, I tend to prefer the quality LDP gives my scenes compared to UE.
Again, I also often build my own lighting effects from scratch as I worked in theatrical lighting. " A lot of what I did involved "faking it" for the desired effect.
...basically it is familiar territory for me.
Hi Kendall, wasn't trying to start a flame war or anything, I completely agree that a lot of it comes down to what you're familiar with and the skills that you bring to the render. I'd dabbled in 3-d in the late 90s and then spent the time since then pursuing photography so my understanding of lighting comes from the photo world. For me, using Lux feels a lot more natural because I can setup the lights the way I'd expect to light it for a photo shoot and get results that I'd expect to see. For me, I can get to the lighting results I'd like to see a lot more quickly than doing it in 3Delight but that's a matter of where my experience lies. And note, I'm talking about scene setup time, not render times here.
That said, there's been a few times where either for the look, resources available, or some other factor I've used 3Delight instead. I remember one time where I was trying to use IBL for a scene and just couldn't get the lighting to look like what I wanted. In that case, switching to the LDP2 based lighting that was included with the scene prop I was using produced results I was happier with. But, when I'm setting up my own lighting in 3Delight I find that I often run smack up against the limitations of the renderer and all of the "fakes" that I have to do to make things look real (like recreating bounce off of the floor/walls). I'll admit that I've not had much of a chance to really dig into UE2 and it seems like some of its options, like GI, address some of this.
The only thing I was trying to achieve in my posts was to clear up some apparent misconceptions in your posts. You'd mentioned that physically based renderers can't do cinematic lighting because there's usually more lighting in movies. My response was that's not true, you simply have to light the scene the same way as you'd light a movie. I think this is fairly obvious given how physically based renderers work. You can't expect it to produce results that require additional lighting in real life without using similar additional lighting. That's not a limitation, that's a feature (arguably the main feature).