3Delight Discussion

Comments

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."

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).

And I agree with you in the fact that these things "can" be done. The context of the discussion was "in production." Whether we like it or not, one of the criteria for determining the "worth" of a technology is how it either "advances the art" or "improves the utility" of the processes. In production, current, emphasis on current, unbiased renderers do neither. For the tinkerer, or for those wanting to look at the new methodologies, they are great. For those trying to get things done, not so much. Keep in mind that in a production environment that it isn't just the "ease of setting physical light" that matters, it is matching the current lighting in a scene that matters. In the case where one is adding SFX to a scene with live action, unbiased rendering, so far, has proven to be less than useful. Currently, this is the lion's share of CG work that gets done.

There are limitations of the current generation of unbiased renderers that make simulating specific types of effects either impractical, or impossible (for the software.) The base tech is sound, the implementations are immature. As I stated, this will change. In the case of production pipelines, the question will be whether the "best" of the unbiased work will be folded into Renderman thus leaving the pure unbiased rendering packages languishing. So far, that has been the case with other rendering tech.

You've used different light intensities, angles, and colors. Actually, I prefer the 3DL version, the light looks more appropriate for the shadows. And the plastic on the radio looks more like the "powder pink" used in those types of items.

In the 3DL version, you didn't change your lighting model in Studio from "Plastic" to "Skin" for your girls. This is no different from not setting the material in Reality. It also looks like your "shading rate" is set too high. This is what is causing the noise in the metal post. It looks like your rate is set at 1 or higher. Try setting the rate to 0.2 or so.

It's just a lack of knowledge or effort in setting the base settings for 3DL in this case. For this scene, the amount of effort for 3DL vs Lux would be a wash. The settings for the Studio Materials vs Reality Settings for Lux would pretty much be a 1:1 for this one. The lack of discernible shadows in your Lux render really distracts from the image as a whole.

You've used different light intensities, angles, and colors. Actually, I prefer the 3DL version, the light looks more appropriate for the shadows. And the plastic on the radio looks more like the "powder pink" used in those types of items.

In the 3DL version, you didn't change your lighting model in Studio from "Plastic" to "Skin" for your girls. This is no different from not setting the material in Reality. It also looks like your "shading rate" is set too high. This is what is causing the noise in the metal post. It looks like your rate is set at 1 or higher. Try setting the rate to 0.2 or so.

It's just a lack of knowledge or effort in setting the base settings for 3DL in this case. For this scene, the amount of effort for 3DL vs Lux would be a wash. The settings for the Studio Materials vs Reality Settings for Lux would pretty much be a 1:1 for this one. The lack of discernible shadows in your Lux render really distracts from the image as a whole.

Kendall

See now your assuming things & why we dont ASS U ME! My shading rate has been set 0.2 I learned that a long time ago. Even my fans / clients like the Lux version is better. Perhaps it is based on my skill who knows anyhoo this is a 3delight thread so get back to it later...

You've used different light intensities, angles, and colors. Actually, I prefer the 3DL version, the light looks more appropriate for the shadows. And the plastic on the radio looks more like the "powder pink" used in those types of items.

In the 3DL version, you didn't change your lighting model in Studio from "Plastic" to "Skin" for your girls. This is no different from not setting the material in Reality. It also looks like your "shading rate" is set too high. This is what is causing the noise in the metal post. It looks like your rate is set at 1 or higher. Try setting the rate to 0.2 or so.

It's just a lack of knowledge or effort in setting the base settings for 3DL in this case. For this scene, the amount of effort for 3DL vs Lux would be a wash. The settings for the Studio Materials vs Reality Settings for Lux would pretty much be a 1:1 for this one. The lack of discernible shadows in your Lux render really distracts from the image as a whole.

Kendall

See now your assuming things & why we dont ASS U ME! My shading rate has been set 0.2 I learned that a long time ago. Even my fans / clients like the Lux version is better. Perhaps it is based on my skill who knows anyhoo this is a 3delight thread so get back to it later...

No, I didn't assume. I said it looks like the effect from a high shading rate (see above). Completely different. To illustrate my point (and to show that I didn't assume) look at the excerpt from your 3DL render included below. You have a metallic "pole" here with a level of reflectivity. Going by the amount of light reflected to the camera from the pole, the reflectivity is high enough that the wood grain/color from the table should be visible in the lower portion of the back side of the pole (angle of incidence). Instead, what is reflected is noise generated by a lack of detail provided to the rendering engine. The most common reason for this effect is a high shading rate -- where the pixel incidence is too sparse for the reflection to be added to the mix. Another reason would be because the number of reflections is too low, but in this case, there is enough bounces available for the grain->pole. Now, let's look at the base flange. Again, we see that there is light reflection, yet there is no indication of the excess light shining on the pole in the flange. This is another effect that could be caused by a shading rate issue. However, this could also be caused by a bounce rate of 1 on the rays, or the use of shadow mapped light instead of raytraced light. But in order for me to have made a call on this WOULD have been for me to assume what type of setting you had on your light. That I was not willing to do.

As you can see, I did not *assume* anything. In fact, I brought up BOTH of your renders onto my screens side-by-side and compared them in detail.

What your clients think is the important thing. You asked for a comparison, so I compared. The scenes were so different that comparison could only be done in the most minimalist manner. I provided my subjective preference based on certain specific qualities of the renders, which I laid out in the original. All of which were technical in nature. I did not consider "composition."

In any case I like others have mentioned prefer what Lux does thank you.. I dont care if the hair on a nut is not at the right angle or does not have the 0000.0 follicle refection at the tip.

And that is perfectly fine. Lux is a perfectly fine render engine, for what it does. I don't think anyone has said otherwise.

Kendall

Maybe if I tweaked more the materials like I got used to doing in Reality who knows I guess I will find out when a future client chooses my lower priced option. I will try to change the people's setting to skin that seems like good advice. I am generally just a render out of the box and adjust when needed type of guy but it suits my purpose for what i use the hobby for... Thanks again for the PM but it sounds like its not just a matter of exporting the files and rendering so I will use the internal engine if and when I need to render 3Delight. I ran a quick one of this current lux scene yesterday wit one UE pre set light http://fav.me/d5g7ht1 one thing I did see an improvement on was less blotchiness without the need to exceed the occlusion samples limits to get rid of them lie before.

Too much detail I just go with what works thanks like I said its your thread your a 3Delight guy I get it. Viva la difference!

No, I am not a "3Delight" guy. I will use what is needed to get the job done. I own and use Maya/MentalRay, Maya/3Delight, MessiahStudio, Carrara, DS/3Delight, DS/Lux, Bryce, Poser/Firefly(Tempest), PoV, LuxRender, BlenderCycles, Vue, and several others.

It just so happens that here, in the DAZ forums, the rendering choices are: 3Delight and Lux. Soon Octane will be an option when the plugin is finished and Octane leaves beta. So in the DAZ forums, I discuss what is germane. It would be inappropriate to discuss MentalRay or Messiah here. Since the vast majority of DS users use the built-in 3Delight, most of the discussions use that as the point of reference.

I will be happy to discuss LuxRender in LuxRender threads. I have been a fan of LuxRender long before it was useful in DS, back when all it could eat was text files.

Too much detail I just go with what works thanks like I said its your thread your a 3Delight guy I get it. Viva la difference!

No, I am not a "3Delight" guy. I will use what is needed to get the job done. I own and use Maya/MentalRay, Maya/3Delight, MessiahStudio, Carrara, DS/3Delight, DS/Lux, Bryce, Poser/Firefly(Tempest), PoV, LuxRender, BlenderCycles, Vue, and several others.

It just so happens that here, in the DAZ forums, the rendering choices are: 3Delight and Lux. Soon Octane will be an option when the plugin is finished and Octane leaves beta. So in the DAZ forums, I discuss what is germane. It would be inappropriate to discuss MentalRay or Messiah here. Since the vast majority of DS users use the built-in 3Delight, most of the discussions use that as the point of reference.

I will be happy to discuss LuxRender in LuxRender threads. I have been a fan of LuxRender long before it was useful in DS, back when all it could eat was text files.

Kendall

As I mentioned above it is a 3Delight thread and it has been very useful Octane looks promising but I have an ATI card I have many renders that I was pleased with as well using 3 Delight my personal evolution has been png layers together fake all post work in PS then to LDP2 full rendering then UE and now Reality

In any case I like others have mentioned prefer what Lux does thank you.. I dont care if the hair on a nut is not at the right angle or does not have the 0000.0 follicle refection at the tip.

And that is perfectly fine. Lux is a perfectly fine render engine, for what it does. I don't think anyone has said otherwise.

Kendall

Maybe if I tweaked more the materials like I got used to doing in Reality who knows I guess I will find out when a future client chooses my lower priced option. I will try to change the people's setting to skin that seems like good advice. I am generally just a render out of the box and adjust when needed type of guy but it suits my purpose for what i use the hobby for... Thanks again for the PM but it sounds like its not just a matter of exporting the files and rendering so I will use the internal engine if and when I need to render 3Delight. I ran a quick one of this current lux scene yesterday wit one UE pre set light http://fav.me/d5g7ht1 one thing I did see an improvement on was less blotchiness without the need to exceed the occlusion samples limits to get rid of them lie before.

Working with the materials is always a good thing to do regardless. Of course, you'll want to use those materials optimised for the render engine being targeted. Paolo's Reality does a good job of converting base settings to Lux, but the conversion is nowhere near as good as using materials optimized for Lux.

Similarly, many models used in DS have materials that are set for Poser/Firefly and not DS/3Delight. Using models "out of the box" is likely to get you a render that is of poor quality simply because the model was not set up correctly. Almost every model will load into DS with the lighting model set to "Plastic" and with Textures/Bump/Displacement set to Firefly's limited settings. In order to get access to the real power of DS, one has to scrap the extremely limited Poser settings and load in a more expanded surface set. Whether that is UserSurface(2), (E)HSS, or some custom expanded set. Once one is loaded the material settings really open up. The options abound, and many look at the number of options and their eyes glaze over. The abilities of DS haven't even been scratched. The whole world of Renderman shaders is out there.

As examples, look at the SFX in the Harry Potter movies, X-Men Movies, Superman Returns, District9, Twilight Eclipse, the Hulk Movie, Fantastic4, Narnia. DS has access to all of that ability through 3DL. Either internally, or through the standalone.

Put it this way this took approx 3 hours in Lux http://fav.me/d5g8b2a and would take just over 15 minutes with 1 UE pre light... Of course the outcome will be different but the UE does not look all that bad either I just grew some patience LOL

The sparks are post worked thats a Shemar Moore face genned character I created ...

Working with the materials is always a good thing to do regardless. Of course, you'll want to use those materials optimised for the render engine being targeted. Paolo's Reality does a good job of converting base settings to Lux, but the conversion is nowhere near as good as using materials optimized for Lux.

Similarly, many models used in DS have materials that are set for Poser/Firefly and not DS/3Delight. Using models "out of the box" is likely to get you a render that is of poor quality simply because the model was not set up correctly. Almost every model will load into DS with the lighting model set to "Plastic" and with Textures/Bump/Displacement set to Firefly's limited settings. In order to get access to the real power of DS, one has to scrap the extremely limited Poser settings and load in a more expanded surface set. Whether that is UserSurface(2), (E)HSS, or some custom expanded set. Once one is loaded the material settings really open up. The options abound, and many look at the number of options and their eyes glaze over. The abilities of DS haven't even been scratched. The whole world of Renderman shaders is out there.

This is a great point. I've only done some limited testing but I swear the convert to UberSurface2 preset alone is the closest thing I've come to a "make better" button in DAZ for a lot of things if the prop didn't come with DAZ-specific MATs. I've done some side by side tests and it just seems to make things look more real, even without tweaking anything else from the canned settings it took. Even that small bit of "tweaking" goes a pretty far way, then combine that with moving any bump map into the displacement channel instead and playing with those settings a bit and you can really start to make things pop. I've not really had the chance to dig any further than that but I've been very happy with what that's done for me.

Well, no pic to post...but render completed in 3 hr 12 mins...dirty rotten kids...closed Studio before I could save the render. I was guessing about 3 hrs, based on other stuff I've done.

In my general experience, on my machine, 4.x is about twice as fast as 3A and the stand alone is usually at least twice as fast as 4.x, if not much more than that.

File->Save Last Render

Kendall

I happened to have the temp folder open, looking for an orphan shadowmap that was eating up 90+ MBs of space and noticed that the Render folder was empty and the pic was nowhere to be found, so I didn't even bother to reopen studio. So it does seem like 4.5.0.137 actually does empty the temp file when closed.

I read the time from the log...render completed in 3 hrs 12 mins and whatever seconds, in whatever format it actually says it in...

I've gotten awfully paranoid on drive space lately, because something I did the other day caused the .xsessions error log to shoot up to almost 6 GB in size. Yeah, I was able to track down the offending file in a console log in and remove it...the the GUI started working again. So I've been going around getting rid of all the junk files that seem to accumulate over time (like that 90 MB shadowmap dated from March...)

Well, no pic to post...but render completed in 3 hr 12 mins...dirty rotten kids...closed Studio before I could save the render. I was guessing about 3 hrs, based on other stuff I've done.

In my general experience, on my machine, 4.x is about twice as fast as 3A and the stand alone is usually at least twice as fast as 4.x, if not much more than that.

File->Save Last Render

Kendall

I happened to have the temp folder open, looking for an orphan shadowmap that was eating up 90+ MBs of space and noticed that the Render folder was empty and the pic was nowhere to be found, so I didn't even bother to reopen studio. So it does seem like 4.5.0.137 actually does empty the temp file when closed.

I read the time from the log...render completed in 3 hrs 12 mins and whatever seconds, in whatever format it actually says it in...

I've gotten awfully paranoid on drive space lately, because something I did the other day caused the .xsessions error log to shoot up to almost 6 GB in size. Yeah, I was able to track down the offending file in a console log in and remove it...the the GUI started working again. So I've been going around getting rid of all the junk files that seem to accumulate over time (like that 90 MB shadowmap dated from March...)

It's a good idea to watch the Shader storage areas as well. I've had the internal calls to tdlmake go crazy and use HUGE amounts of disk space. Truthfully though, I've pretty much stopped using the internal rendering as I have a 1 command setup for converting the RIBs and I just use the standalone. It also allows me to continue to play while the render chugs.

If you've got the tmp cleaner daemon running in cron, you might want to consider linking the Studio4/temp area to /tmp and allowing the daemon to clean up anything left behind.

Working with the materials is always a good thing to do regardless. Of course, you'll want to use those materials optimised for the render engine being targeted. Paolo's Reality does a good job of converting base settings to Lux, but the conversion is nowhere near as good as using materials optimized for Lux.

Similarly, many models used in DS have materials that are set for Poser/Firefly and not DS/3Delight. Using models "out of the box" is likely to get you a render that is of poor quality simply because the model was not set up correctly. Almost every model will load into DS with the lighting model set to "Plastic" and with Textures/Bump/Displacement set to Firefly's limited settings. In order to get access to the real power of DS, one has to scrap the extremely limited Poser settings and load in a more expanded surface set. Whether that is UserSurface(2), (E)HSS, or some custom expanded set. Once one is loaded the material settings really open up. The options abound, and many look at the number of options and their eyes glaze over. The abilities of DS haven't even been scratched. The whole world of Renderman shaders is out there.

This is a great point. I've only done some limited testing but I swear the convert to UberSurface2 preset alone is the closest thing I've come to a "make better" button in DAZ for a lot of things if the prop didn't come with DAZ-specific MATs. I've done some side by side tests and it just seems to make things look more real, even without tweaking anything else from the canned settings it took. Even that small bit of "tweaking" goes a pretty far way, then combine that with moving any bump map into the displacement channel instead and playing with those settings a bit and you can really start to make things pop. I've not really had the chance to dig any further than that but I've been very happy with what that's done for me.

The skin setting in that render was a heavily tweaked default material, no Uber. I didn't want Uber anything in it...because in 3A, in my experience anything Uber goes even slower. I believe the 7 hrs is solely due to the heavy transmapping and raytraced shadows. That is one setting that stayed the same for all three 3Delight renders. I want to run a render with everything Uber converted.

I had the skin settings tweaked for Lux, but DS pulled one of it's "I'm having a tantrum and won't save anything" fits when I tried to export it, so I didn't bother to go back and redo them...I should, because I know that will improve the render immensely. The other thing that was annoying was the tiling on the lace wrap. It took me several tries to get it right, because it wasn't converting correctly. I don't use Reality, but rather LuxrenderDS (which is only good in DS3A and doesn't even support some of the latest features of Lux...it's basically stuck at the 0.9 feature set), so I'm not sure if Reality would have gotten it right in one shot or not.

But over all, the latest version of Studio and the stand alone 3Delight make a perfect team. On Linux there is a very definite speed advantage (2x or more) to using it. Even the Uber items are converting/recompiling now and more of the 3Delight feature set has been made accessible in Studio, so manually recompiling shaders or hand editing RIBs to get them to run correctly is pretty much a thing of the past. The key factor is to make sure you always use the RIB inside the _collected folder that's generated when you save to RIB with the collect feature enabled.

Its actually kind of funny when Reality 1st came out my attempt to use it was a total failure. Add 18 more months of 3deeing and I can now can use it. I am not taking anything away from 3Dlight its been very good to me and have produced many nice renders with it as well

Some trek ships 3Dlight http://fav.me/d4gnlkm Lux http://fav.me/d50d4ql I understand all about long render times some of my early Lux renders took several days then i got wise with lighting and practice and cut it down to hours for the most part..

I also "cheat" by using PS to get rid of some of that "noise" Lux tends to leave behind that would probably take a week to clear up....Kind of like when 3Dlight keeps spinning endlessly at the last leaf of strand of hair...

Edit forgot to mention when i tried using Uber surface the surface would all turn solid grey and when I attempted to apply HSS to skin it would make the character look like a chimo victim (No offense to anyone who may be suffering from cancer :(

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, this is where the "collect & localize" checkbox is indeed normally located when using 3Delight, but in the "scripted 3Delight" option with the point-based AO script, they seem to have forgotten to put it there. Should be dead easy to fix this by editing those scripts ...if this particular feature isn't broken, of course. I have yet to check if the DzQuat class has been fixed for DS4 scripting, for instance...

In my general experience, on my machine, 4.x is about twice as fast as 3A and the stand alone is usually at least twice as fast as 4.x, if not much more than that.

Same here. I was totally blown away with the speed of 10.x standalone. For dual core machines, it is THE way to go.

I believe the 7 hrs is solely due to the heavy transmapping and raytraced shadows.

Might very well be. If I remember correctly, raytracing performance has been significantly improved for the 10.x 3Delight versions as compared to the 9.x ones.

I once did a simple test with transmapped hair in DS3A: a mid-quality UE, a distant light, and a lone fully dressed figure using UberSurface materials for everything, with SSS turned on for skin (it was before we discovered the right scale and shading rate, but SSS never added that much overhead for me outside of using GI, even with HQ shading rates) and AO turned off for transmapped hair. Render time was about 10 minutes with a DSM and 1 h 27 mins with the only change being shadow set to raytraced. Not even mentioning the fact that from the artistic POV I like the look DSM tend to give much better... I'd attach the images but they're on another computer right now, sorry.

I haven't yet had a chance to try GI (the photon mapping method) in DS4.5. Has anyone?

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, this is where the "collect & localize" checkbox is indeed normally located when using 3Delight, but in the "scripted 3Delight" option with the point-based AO script, they seem to have forgotten to put it there. Should be dead easy to fix this by editing those scripts ...if this particular feature isn't broken, of course. I have yet to check if the DzQuat class has been fixed for DS4 scripting, for instance...

Well looky there, you are indeed correct! I hadn't noticed that it was missing there. But then again, I don't use the scripted mode much. It could be that the scripting engine needs the files in specific places in order to do its job.

In my general experience, on my machine, 4.x is about twice as fast as 3A and the stand alone is usually at least twice as fast as 4.x, if not much more than that.

Same here. I was totally blown away with the speed of 10.x standalone. For dual core machines, it is THE way to go.

I believe the 7 hrs is solely due to the heavy transmapping and raytraced shadows.

Might very well be. If I remember correctly, raytracing performance has been significantly improved for the 10.x 3Delight versions as compared to the 9.x ones.

I once did a simple test with transmapped hair in DS3A: a mid-quality UE, a distant light, and a lone fully dressed figure using UberSurface materials for everything, with SSS turned on for skin (it was before we discovered the right scale and shading rate, but SSS never added that much overhead for me outside of using GI, even with HQ shading rates) and AO turned off for transmapped hair. Render time was about 10 minutes with a DSM and 1 h 27 mins with the only change being shadow set to raytraced. Not even mentioning the fact that from the artistic POV I like the look DSM tend to give much better... I'd attach the images but they're on another computer right now, sorry.

I haven't yet had a chance to try GI (the photon mapping method) in DS4.5. Has anyone?

The raytracing engine in 3DL was improved drastically in the 10. series. There was an issue where starting up had huge overhead. That overhead has been completely removed and the raytracer can now start pretty much immediately. Also, the speed of the tracer itself was improved. According to reports, it should now be faster to use the raytracer than the shadow maps. I have not personally tested this as I don't normally use shadow maps to start with. Now, on to your question... I haven't tried the GI mode in 4.5 yet. I guess I should.

@mjc1016 : could you post the specs of your pc and what you used as a graphic card and also what's really in the scene and you render settings and resolution please? It's difficult to have a real idea with just your pictures

The latest 3DL is indeed very quick and It never needed more than 1 hour since the engine update. Even tried some scene with raytraced reflexions, volumetrics, SSS and other things. By the way, did you notice the UE GI and indirect light now work better?

Btw I'm on windows and the standalone with 2 cores is slower than the internal with 4 cores.

Well looky there, you are indeed correct! I hadn't noticed that it was missing there. But then again, I don't use the scripted mode much. It could be that the scripting engine needs the files in specific places in order to do its job.

Could be, but judging from the scripts, I'm not sure this is the case. The scripts simply implement two passes needed to generate the point cloud first and then render. The only hindrance I can think of might be the standard "collect and localise" subroutine in DS not being configured to recognise the .ptc as one of the files that would need to be collected... but to test this I need the docs.

The raytracing engine in 3DL was improved drastically in the 10. series. There was an issue where starting up had huge overhead. That overhead has been completely removed and the raytracer can now start pretty much immediately. Also, the speed of the tracer itself was improved. According to reports, it should now be faster to use the raytracer than the shadow maps. I have not personally tested this as I don't normally use shadow maps to start with. Now, on to your question... I haven't tried the GI mode in 4.5 yet. I guess I should.

If only we could convince DNA to get on the GPU assisted wagon.

Thanks for the info! I should transfer that scene into 4.5 and see how it fares. I generally don't like raytraced shadows because they require a softness percentage to look more natural, and those softness calculations used to be a real performance hog as well, but if that has been dealt with by chance, I might consider using them more often - especially for larger scenes like landscapes, where DSMs can get unwieldy with higher sample rates and a lot of detail in the scene.

...I wonder if blurred raytraced reflections are now faster. So many things to test, so little time...

As for GPU assisted rendering... I guess they will take advantage of this, in due time. From what I've heard, and correct me if I'm wrong, GPU acceleration is not that widely used in film industry yet, and isn't 3Delight primarily geared at movie studios?