Yes, I know Reality has these surfaces and volumes, but even then Reality gives us the “light version”. I love that it gives us sensible access to the basics such as glossy translucent surfaces and volumes. I love that Luxus lets us tweak render settings, access multiple subsets of rendering engines. Texture control maps are great for subtle tweaks. Both are flawed renders but Luxus gives many more options when setting up glossy translucent materials. Whatever the reason, Paolo is happy to tell us how we should be using LuxRender. Maybe these “elite users” aren’t a big enough porting of Reality users. 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. 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). It’s a raw, barebones sort of plugin, but it makes up for it in power. 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). We see that CPU is still king in terms of quality. Both metropolis, and both with identical material settings. Probably the most significant of these points is that it exposes the controls for just about every feature of LuxRender.ĬPU left, OpenCL right. 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. What spoiled my interest in Reality, as a bridge to LuxRender, was Luxus. Even the pretty Monte Carlo GI in LightWave felt like slumming it afterwards.
POSER DEBUT ON WINDOWS 7 KEYGEN
Reality was my introduction to physically based rendering, which completely spoiled me for biased options. 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). More importantly, there are issues with geometry artefacts at lower levels of subdivision. I’ve noticed this with glossytranslucent materials, particularly when coupled with the homogenous volume for SSS. Two: There are slight (and sometimes not so slight) render difference between OpenCL and standard CPU modes.
Boost seems to be one of Paolo’s own “homebrew” tweaks to Lux render settings.
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). There are a number of caveats with these speed increases. A close examination shows the stark differences between bidirectional and standard path tracing.
0 kommentar(er)
