Reality 4.1 Review

I’ve written, rewritten, performed delicate surgery, and ultimately torn up this review a number of times now. I don’t want to be the negative reviewer guy, but what it comes down to is that I’m just not very impressed with Reality 4. Sure, we have some nice features introduced since Reality 2, such as procedural textures, and SSS, but I’m just not sold (more on that later). There are many happy Reality users out there, but then there are the others like me, skeptical, on the fence, indifferent. So, I’m not saying Reality is bad, just that it’s not my beverage of choice.

Metropolis CPU 20 mins

Metropolis CPU 20 mins

Before moving on I should point out now that I’m writing this review for the DAZ Studio (Windows 7) version using a i7 4770 and two GTX 780ti cards (not AMD cards). For most GPU renders I stuck with using the 780 in the secondary slot as using the first or both resulted in slow system response. All renders in this review are raw from Reality for the purposes of test (sorry, no pretty ones here).

LuxRender Speed Increases

Given my outlook of Reality I was still quite excited by the news of Reality 4.1 and all the talk of speed. Speed increases are a huge selling point for me when it comes to LuxRender, and in this regard Reality 4.1 is a solid point release. 4.1 gives access to some of the latest advances of LuxRender 1.5, which is great. We see some nice acceleration on many recent CPUs, and we get a greatly updated OpenCL based engine, which is now well on the way to containing all the features of CPU LuxRender.

CPU Extra Boost 19 min A close examination of shows the stark differences between bidirectional and standard path tracing.

CPU Extra Boost 19 min
A close examination shows the stark differences between bidirectional and standard path tracing.

There are a number of caveats with these speed increases. First: CPU and GPU “boost” modes only support Path “mono-directional” renderer (depending on the type of scene being rendered this may or may not be an issue). Boost seems to be one of Paolo’s own “homebrew” tweaks to Lux render settings. Two: There are slight (and sometimes not so slight) render difference between OpenCL and standard CPU modes. I’ve noticed this with glossytranslucent materials, particularly when coupled with the homogenous volume for SSS. More importantly, there are issues with geometry artefacts at lower levels of subdivision. These issues appear to be particularly noticeable on models that heavily rely on subd methods for controlling shape, such as the Genesis figures (fixed as of 4.1.1).

Reality 4: A Mix of Good and Bad

Reality was my introduction to physically based rendering, which completely spoiled me for biased options. Even the pretty Monte Carlo GI in LightWave felt like slumming it afterwards. What spoiled my interest in Reality, as a bridge to LuxRender, was Luxus. Luxus is a huge ‘effing mess in its implementation (in to DAZ Studio’s user interface), but it has a number of points that, in my mind, and to a good number of others users, makes it superior. Probably the most significant of these points is that it exposes the controls for just about every feature of LuxRender.

CPU left, OpenCL right. Both metropolis. Again we see that CPU is still king in terms of quality.

CPU left, OpenCL right. Both metropolis, and both with identical material settings. We see that CPU is still king in terms of quality.

Luxus beat Reality (3, Poser) to the punch when it came to offering options for subsurface scattering, and with all the extra render and material features I could forgive that Luxus was spread all over the place with huge ugly lists of options (some of which even the hardest core of the hardcore would rarely touch). It’s a raw, barebones sort of plugin, but it makes up for it in power. I had hoped that Luxus would shake up the Reality trajectory, but every release of Reality has been an evolution of the earlier product (which, depending on perspective is either good or less good). Maybe Luxus didn’t hurt Reality, maybe Paolo (Mr Reality) never saw the endless blog and forum posts that pointed out the power aspects of Luxus. Maybe these “elite users” aren’t a big enough porting of Reality users. Whatever the reason, Paolo is happy to tell us how we should be using LuxRender.

Reality on Right, Luxus on left. Both are flawed renders but Luxus gives many more options when setting up glossy translucent materials. Texture control maps are great for subtle tweaks.

Reality on Right, Luxus on left. Both are flawed renders but Luxus gives many more options when setting up glossy translucent materials. Texture control maps are great for subtle tweaks.

I love that Luxus lets us tweak render settings, access multiple subsets of rendering engines. I love that it gives us sensible access to the basics such as glossy translucent surfaces and volumes. Yes, I know Reality has these surfaces and volumes, but even then Reality gives us the “light version”. Why, in this wondrous modern day and age, or we not given the option to input textures in to our absorption and scattering slots? Why is Reality lingo inconsistent with LuxRender lingo? Why does it require google to learn how to setup a glossy translucent surface specifically for Reality? The manual is obscenely vague on this process.

One would assume the glossy trans would be sitting right next to glossy and matt materials, but nuh-uh. We unlock this obscure material via volumes. Why? And why is there a separate tab for volumes in the first place? Yes, I guess it might make it easier to share volumes between different surfaces, but what about good old copy past? After all, we are probably going to have to tweak those volume settings from one model or character set to the next.

OpenCL having a fit on left. CPU doing weird stuff on right. Presumably the patchy areas in the CPU image is working to clear noise.

OpenCL having a fit on left. CPU doing weird stuff on right. Presumably the patchy areas in the CPU image is working to clear noise (noise aware).

Reality has gone a good distance on squashing some strange idiosyncrasies and quirks, but these seem to be rooted in Paolo’s design process and ideas about how things should be, both in terms of design and how users should relate to LuxRender

To cut through it all, and paraphrase so many posts I’ve seen on the subject, Reality is great for novices and those that just want to get on with the business of rendering. If Reality were a book it would be “LuxRender for Dummies”. This is certainly not a bad thing. Many of the render settings are superfluous for many users, as are texture control maps, but for hardcore render geeks and artists that really want to push their work to the next level, it is limited. There, that’s it! Reality is limited.

Final Thoughts: Reality 4/4.1 and LuxRender

Reality’s Good Points
  • Reality is great for new users, and those that want to render without having to worry about a huge list of engine configurations.
  • It supports a good chunk of what LuxRender has to offer
  • It is relatively easy to work with (though with some frustrating quirks)
  • Some love the Reality GUI
  • Speed increases
  • Procedural goodies
Reality’s Bad Points
  • The first point on the list isn’t about the program so much, but this seems rather big to me. On the Reality “Details” page there is one mention of LuxRender, and it’s all the way down the bottom of the page. This seems to be a systematic tactic taken on other pages on Preta3D.

“Reality is a rendering solution that extends DAZ Studio and Poser providing the most advanced Physics-Based Rendering system in the market.”

Is it just me, or are we correctly attributing the awesome rendering power here? Let’s give Paolo the benefit of the doubt and say he’s concerned making too much out of the external render engine (which Preta3D has little to do with) will unnecessarily scare people away. Something like that?

  • Reality hides many of LuxRender’s rendering and material features (more so the former). Some of these would be very beneficial to intermediate and advanced users.
  • Reasonable manual
  • Reality GUI – though considerably improved since Reality 2 (first version I used)
  • Convoluted glossy translucent and volume setup
  • Would love to see more of the procedural options available for use in the diffuse channels (as opposed to being strictly for displacement).
  • Manual has some serious limitations and oversites
  • Reality lingo is not always consistent with LuxRender spec
  • Does not include the LuxRender environment camera (why?)
On LuxRender Speed Increases

Metropolis CPU is still by far the sharpest tool in the LuxRender arsenal. Comparing OpenCL, accelerated, and “Extra Boost” render side-by-side with CPU renders will often be as day is to night. Sometimes speed just isn’t worth it. OpenCL just isn’t there yet, but we are so close!

If you have a reasonable NVIDIA card LuxRender might not be the best option, certainly not in all situations. See the next post for a head-to=head LuxRender vs Iray.

On Luxus vs Reality

For the sake of final balance it is necessary to make a notes on Luxus in its current state.

  • Has not been updated in quite some time. As a result it doesn’t support all LuxRender’s latest features, though it does include text boxes to input code.
  • Its incorporation into DAZ Studio makes an art of mess.
  • Poor documentation.
  • Bug where Luxus somehow fails to export materials. A very frustrating bug.
  • Exports scenes to a temp folder (that wipes on closing DAZ Studio). However, this can be changed.
  • No environment camera (why?).

In short, I would love to see this plugin updated and tidied up. In its current state Reality is the better plugin for most users. You can pickup Reality 4 for DAZ Studio and Poser from most DAZ/Poser community brokerages including DAZ and directly from Pret-a-3D.

6 thoughts on “Reality 4.1 Review

  1. Jim, thanks for this review. I bought Reality 2/2.5 about 2 years ago when I started seriously taking up 3D art as a hobby ( I had dabbled with PP 2010 prior) and made the choice to move from 3Delight to a non biased render engine. I had tried Luxus but found that I couldn’t do anything at all with it. This was due no doubt to my being a rank beginner (currently a rank novice :)). Unlike Jim, I kind of liked the Reality 2.5 GUI as I had ready access to what I wanted, and hesitated moving to 4.x after hearing horror stories about the GUI. I purchased it recently but have yet to load it or for that matter DS 4.8. To be honest, I have no clue as to the advanced features Jim mentions and Reality hides/makes access to difficult (maybe one day). I definitely agree that the manual for 4.x and for that matter Reality 2.x releases is mediocre at best with major omissions/ lack of clarity. This really surprised me given that Paolo has worked in the software bizz for quite some time and manuals are the life blood of an engineer. I definitely agree that there is a bit too much Reality self promotion and luxrender sidelining (it is after all the render engine) that goes on but I guess Paolo has to make a living. In short, as I progress, I would hope that Reality keeps pace and not become a hindrance. Sorry for being so long winded.

    • Hi Tom,

      Don’t fear the new GUI. I find it superior to 2.5 in so many ways. Being able to keep it open to drop back into DAZ to use the material selector and make other small tweaks saves a lot of time. Paolo’s “multi-edit” function is very handy for bulk editing materials too. These were two of my biggest (though not only) headaches with R2. There are actually a lot of good features packed into Reality 4x. Setting up LuxRender with Luxus sort of looks like the pre-prep for launching a space shuttle, but there are a number of very handy tweaks you just don’t get with Reality. In a lot of cases most of the Luxus configuration could be left at default. A lot of them were only active for certain sub sets of LuxRender (completely superfluous to most users all of the time). I don’t really consider myself an advanced user, certainly not an advanced artist. I just like to tinker with things. Usually nothing explodes, so I guess I’m not doing it completely wrong.

      I too hope that Reality gets better and stronger as LuxCore continues to develop. LuxRender 2 will be a game changer for the DAZ/Poser ecosystem, but only as long as there is a robust bridge.

      Happy renderings,

      Jim

  2. I don’t have either Reality or Luxus, but I have seen screenshots and tutorials… and I must say that it’s a shame that Tofusan never updated his DS3 LuxRender exporter to the DS4+ SDK. It still works!

    Re:unidirectional vs bidirectional path-tracing. Bidir is “the” way to sample good caustics efficiently. Unidirectional PT requires way too many samples for a clean resolution… for instance, Arnold is the industry leader unidirectional path tracer, and see what the devs say about caustics there:

    https://support.solidangle.com/display/AFMUG/Caustics

    Yup, as it turns out, they use path pruning by default. Which minimises noise/fireflies, but how exactly “unbiased” this is, that is another question =)

    If I get it right, that’s the same with Iray: you need to explicitly enable “caustic sampler” (at least in the DS frontend).

    As I personally don’t mind photon mapping for caustics, I find it great that 3Delight allows for combining path-tracing (which is currently unidirectional as well) and photon mapping – there is no ray pruning by default, though, so it’s up to you not to forget to exclude the caustic-generating objects from GI (cuz fireflies can be rather harsh). There are hints at the 3DL forums that bidir transport is coming, but when exactly, it’s not known yet.

    • Yeah, I’ve found that bidirectional[standard path tracing] rarely produces good caustics. I also find that for a lot of renders I do, bidirectional [unidirectional] just isn’t up to the sort of things I want to render. So that means beings stuck with the beautiful but glacial metropolis. I haven’t used photon mapping much – a few renders. I find it can be very time consuming when configuring photon counts (through trial and error).

      Ah, interesting. I suspected that Iray’s “Architectural Sampler” had something to do with bidirectional sampling. Was just reading some Iray documentation for 3DS Max users. Turns out this is Iray’s implementation of Metropolis. Suspicion confirmed! I’m guessing that the caustic and architectural sampler are both separate but compatible tweaks the Metropolis algorithm.

Leave a Reply to Jim Willey Cancel reply

Your email address will not be published. Required fields are marked *