adventures in GI

Everyone knows that global illumination is very much “in”. Or, to be more precise, “photorealism” is “in”, and so is everything that helps the artist achieve it, preferably as fast and easily as possible. Hence the success of unbiased renderers like Octane or LuxRender; hence the widespread belief that Poser’s Firefly render engine is “better” than 3Delight, this what-a-quirky-name renderer available in DAZ Studio by default… however, regarding the latter notion, nothing could be further from the truth.

The truth is: Firefly is tightly integrated within its scene setup software; this software (Poser) was conceived as a character-oriented solution from the get-go. Poser is a commercial program (i.e. the user generally pays for it, unless s/he gets it in some promotional event), so it’s totally understandable that usability – in the sense of the closest approximation of the mythical “make art” button – is the developers’ primary concern.

Not the case with DAZ Studio (which, to avoid confusion, should be called DS for short – as it commonly was when dinosaurs like me first downloaded DS version 2 how many years ago? – and not “DAZ” because DAZ is the company that makes it) – however groundbreaking the technical ideas currently implemented in DS may be, it’s still not much of a means of generating income for its developers; content is.

Moreover – 3Delight is not developed by DAZ3D. It’s a child of a completely separate team called DNA Research, and actually it’s a pro grade renderer used in movies and stuff like that. It’s capable of much more than Poser’s Firefly (which, as far as I have heard from experienced Poser users, still faces problems with rendering something as relatively simple as refraction).

There lies the heart of the problem: 3Delight’s capabilities are fairly overwhelming for a general hobbyist user, particularly a newcomer. How many DS artists do you know who write their own RSL shaders – and DS-specific scripts to augment those shaders? I bet not too many.

And yet, this is the only way for a DS user to truly harness the amazing power of 3Delight.

Of course, it’s possible to rely upon others – capable new shaders appear every now and then (and I don’t mean shader mixer networks; the whole shader mixer thing is both a blessing and a curse, and a topic for another rant some day), and some people even take time to figure out how to use the “scripted renderer” for something interesting, but – the DNA Research team, not unlike the DAZ3D team, tend to put actual development before writing documentation. A lot of tantalisingly attractive things are only mentioned on their forums, and not everyone is going to bother with scouring those for info.

So what I did was to take everything in my own hands. I’ve been pushing the limits of the DS/3Delight combo for years, and I’ve learnt a lot along the way. The whole affair seemed unbelievably complex and downright scary at first, but hey, if I could understand these things, everyone else should be able to.

I’ve targeted various ways of using subsurface scattering in the UberSurface family of shaders in my “treatise” – which I truly hope more people would download (for free!) and work through, because the techniques described there are robust and totally allow DS renders to compete with Poser’s coveted “waxy look”. But subsurface scattering is just one type of global illumination. And I bet not many people actually knew that. Yes, SSS is a sort of GI. Let that sink in for a minute…

However, most people think “bounce light” when they hear “GI”. Put a few light-sources in your scene so that they would correspond to “real world” lighting, and let the GI shader do the rest. This was generally thought of as being clunky and slow in 3Delight as compared to the newer iterations of Firefly with its shiny nifty “irradiance caching” feature.

This is not the case.

First of all, if Firefly were using brute force raytracing, like “the” environment light shader for DS, the UberEnvironment2, does, it wouldn’t probably be much faster. The whole trick is that irradiance cache.

Then, the DS devs, in one of their generous moments, did develop a “render script” that makes great use of point clouds – which are a longstanding workhorse of biased renderers, able to noticeably speed up GI calculations. The script has a misleading name “point-based occlusion” (and it’s also not _that_ user-friendly, what with the completely unwarranted “simple occlusion light” that is on by default but needs to be off for any serious render – it’s a direct sibling of the dreaded DS “headlamp” that is a yet another source for the “Firefly is better” misunderstanding – no, not Firefly but the “default” light set that Poser loads, while the “headlamp” does not even cast shadows…). As it turns out, paired with UE2, this script can do whatever UE2 itself can do – including bounce light – but much faster.

Point-clouds aren’t the end-all, still. They’re tricky to set up properly; moreover, I still haven’t figured out what should be changed about the built-in DS setup so that the point cloud generation would “see” surfaces with the diffuse channel turned off. And besides, they won’t compute any bounces past 1 – simply because that’s the way they work.

One bounce is but a crude approximation, all in all. The minimum value should be 2 – okay, that’s the way I see it after many tests. For some, one may be enough. Not for me…

So I decided to look into what the new 3Delight “raytrace” hider can do. For those who don’t know what “hider” means, well, it’s like a sub-engine within a rendering engine. 3Delight started out as a REYES engine, picking up raytracing capabilities along the way, but a few years ago the DNA folks implemented a dedicated pure raytracer as a separate hider. At first it was not taken seriously and only used for solving specific problems, but lately it’s been redesigned fairly thoroughly, and it boasts serious speed improvements – costly raytracing operations like GI (oh yeah, ambient occlusion is also considered a type of GI…), especially when they involve transparent surfaces, can be a dozen or more times faster.

There is a built-in way to access the new hider through the DS interface – the “progressive” mode employs it. However, I don’t care much for progressive rendering, if only because it forces the “box” filter that I am not that fond of. So I made a “render script” to get the “real deal”, dug through docs, forums and examples, wrote some simple GI shaders, tested, tested again… The “raytrace” hider does speed up brute force raytracing significantly, but it’s still not “the” fastest way to get GI.

I was one of the first folks on the DS forums to publicly experiment with shader mixer-based photon mapping for GI, but I wasn’t ever 100% satisfied with it. It was too unpredictable for my tastes. So I experimented with render scripts further, developed a fairly robust photon-mapping-for-GI solution, but was not _that_ impressed, either.

I felt there had to be more. I was looking at papers, thinking about implementing that irradiance caching algorithm myself – even though I am not sure I could ever pull it off. That’s a bit too “pro” for my coder skills. I was also looking at physically plausible shading, just because it’s interesting, and, well, the way of the future. And it led me to finding out that 3Delight has diffuse ray caching implemented already! But it’s not mentioned anywhere apart from one (1) forum post =)

Fun stuff. I render almost exclusively with GI cache and in the raytracer now. With “crazy” trace depths. I had to rewrite my SSS shader to work most optimally within the new framework, and I’m loving it.

I also discovered that 3Delight does treat non-shaded colours as emissive – something I never thought it did. These are no match for proper area lights since they cannot do specular lighting, but still, fairly useful (those objects with glow shaders can now light their surroundings up quite nicely). The funniest thing… this particular feature has been there all along, for years. It’s just that nobody ever really bothered with GI in DS3.


2 thoughts on “adventures in GI

    1. Hello Jack. I have no information about you and your 3D experience so I’m not sure what exactly you mean by “GI render settings”. I use the so-called “scripted renderer” in DAZ Studio to pass my preferred RiOptions and default RiAttributes and a system of completely custom RSL shaders with heavily customized rendertime scripts to manipulate per-surface attributes. Do you want information about how I set up all of it to work in tandem, or do you simply want to know the sample values I use in my GI shader?

Comment here

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s