 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka schrieb:
> hobBIT <bla### [at] gmx de> wrote:
>> Luxrender:
>> + Very realistic results.
>> + Nice blender integration (other commercial suites too).
>> + Imho good developer activity.
>> + Adjust lighting during rendering !!!!
>> + Easy scaling using active network interface, can add render nodes on
>> the fly (which is really needed, see below :-)).
>> - Damn long render times.
>
> I also notice that the image is a lot grainier than the POV-Ray shot; it's not
> hard to tell that Luxrender uses some kind of monte-carlo approach.
As I understand it, rays are shot in a more or less random way. You can
let it render as long as you wish, longer traces give results with less
noise. I stopped my rendering at ~1200 samples/pixel, which normally
should give a really clean image, but some scene elements can drive the
need for higher values, i.e. reflection/refraction and size of light
souces (this is what I understand).
>
> Distributed rendering is a goal POV-Ray is aiming for, too; SMP is just a step
> in that direction, and the architectural changes made for SMP were already
> geared towards that goal of distributed rendering.
>
Nice to hear ! The idea to add render nodes by simply add them during a
render is a really user friendly way, the povray team should adapt it :-)
>
>> POVRay:
>> + Endless possibilities due to the SDL and windows frontend. I like to
>> have full control using text files (I'm a software developer).
>> + Nice control to scale render time (Comment out parts, use flags to
>> scale quality, ...).
>> + Easy way to enhance scene by scripting.
>> + Working on ultra complex scenes even on ultra slow machines, text rules :)
>> - Development seems a bit slow (no critic!, just a bit frustating).
>> - Some issues I can't handle (Can be seen in the POV-render (the second
>> one below)), maybe some POVray pro can tell me how to circumvent them:
>> - Areas with bad anti-alias, sometimes, even with really high AA
>> settings (see edges in the top right area).
>
> That is strange indeed; do you think you can trim down the scene to something
> minimalistic so this effect can be investigated closely?.
I've seen this effect from time to time, areas with no direct lighting
sometimes show aa-free areas, if I see it again, I may post them.
For this scene: After I see normals in this area of , the result seems
to be better now.
>
>> - Areas which have no direct lighting do not show any normal effects
>> (All walls have bumps, but this can be seen behind the plant only).
>
> Did you try "normal on" in the radiosity block? That *should* do it.
Two other users give me that info too, thanks again. I've enabled it,
without a direct success. Additionally I've increased bump_size by a
factor of 4 and I see normals now. But it seems, the render time is
increased by the same factor :-)
>
> What I also see is radiosity artifacts in the corners (blotchy look; it should
> be possible to eliminate them with higher-quality radiosity settings).
I've seen them too, I may increase this value, but this would remove one
of the pro's of povray, short render times :-)
>
> What bothers me most, however, is the curtains, and it actually shows (or
> rather, doesn't show) a feature I'm missing in POV-Ray: Diffuse translucency.
> Shouldn't be *too* hard to integrate.
>
I read the last beta's (31-33) contain subsurface scattering, does this
give results similar to this ? I will try this if I have some more time :-)
>
> Furthermore, I see significant differences in brightness / contrast, but these
> may be due to (a) the curtain thing, and (b) possibly gamma issues.
>
>
I haven't invest that much time to create identical lighting, as both
engines use total different approaches, maybe I will do this, maybe not :-)
hobBIT
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> As for the lighting on the curtains--you could try the double_illuminate
> keyword. I think that will also interact with radiosity properly.
I actually don't think it will give proper results.
double_illuminate will indeed cause *direct* illumination to "seep through" to
the other side, thus replicate the bright streaks on the curtain as seen in the
Luxrender shot, and these will also affect the lighting in the room through
radiosity.
However, *indirect* illumination will *not* "seep through", so we would miss
that beautiful gradient we see on the curtain in the Luxrender shot, which is
presumably caused by diffuse sylight blocked in the lower portions by the
balcony.
Aside from that, it's also a rather inflexible solution, running into trouble as
soon as the material is intended to be only slightly translucent (like, for
instance, the leaf of a tree; I once did that by embedding a double-illuminated
layer between two classic filtering ones, but it's cumbersome regarding
geometry, and responds non-linearly to "tuning").
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hobBIT <bla### [at] gmxde> wrote:
> > I also notice that the image is a lot grainier than the POV-Ray shot; it's not
> > hard to tell that Luxrender uses some kind of monte-carlo approach.
>
> As I understand it, rays are shot in a more or less random way. You can
> let it render as long as you wish, longer traces give results with less
> noise. I stopped my rendering at ~1200 samples/pixel, which normally
> should give a really clean image, but some scene elements can drive the
> need for higher values, i.e. reflection/refraction and size of light
> souces (this is what I understand).
Yes, that's exactly the so-called "monte-carlo integration" approach (which is
also used in MCPov).
> Nice to hear ! The idea to add render nodes by simply add them during a
> render is a really user friendly way, the povray team should adapt it :-)
I'm not sure whether *dynamic* addition of render nodes was part of the initial
plans, but I guess the architecture should be quite well-suited for that, too.
> >> - Areas which have no direct lighting do not show any normal effects
> >> (All walls have bumps, but this can be seen behind the plant only).
> >
> > Did you try "normal on" in the radiosity block? That *should* do it.
>
> Two other users give me that info too, thanks again. I've enabled it,
> without a direct success. Additionally I've increased bump_size by a
> factor of 4 and I see normals now. But it seems, the render time is
> increased by the same factor :-)
That's to be expected, unfortunately. Or, to put it the other way round, not
using "normal on" decreased render times, fortunately ;)
> I read the last beta's (31-33) contain subsurface scattering, does this
> give results similar to this ? I will try this if I have some more time :-)
Yes and no - SSS (or SSLT = Subsurface Light Transport, as it is also called) is
a different beast, designed to give even superior results at even slower render
times ;) It's also primarily intended to model effects seen in solid objects
made from quite tranclucent materials, like a wax candle, instead of thin
sheets of rather opaque materials like fabric (it will actually need a solid
object to work on).
SSLT is also still very, very early experimental stage, and much more complex,
so it'll take a while until it is fully integrated and compatible with all the
other POV-Ray features.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> hobBIT <bla### [at] gmxde> wrote:
> > Is it possible to set it to 0.05, 0.025, or is 0.0 the only alternative
> > ? If so, doesn't this mean all AA rays are traced in any case, as the
> > difference to the neihboring pixels is always too big ?
>
> You can even set it to 0.031415926535897932384626433832795 if you like :P
>
> The main issue is that the AA threshold is specified as an absolute value, so
> for instance when you set AA to 0.1, if one pixel is at 1.0 it will kick in if
> the neighboring pixel differs by 10%, but if one pixel is at 0.1 it will kick
> in only if the neighboring pixel differs by 100%.
>
> Maybe this should be one for the TODO list.
Sounds like a good idea, except you might need an absolute cutoff value at some
point to prevent anti-aliasing that you can't see. I wonder how much different
that approach would look from applying gamma correction before the aa decision?
-Reactor
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> > > Did you try "normal on" in the radiosity block? That *should* do it.
> >
> > Two other users give me that info too, thanks again. I've enabled it,
> > without a direct success. Additionally I've increased bump_size by a
> > factor of 4 and I see normals now. But it seems, the render time is
> > increased by the same factor :-)
Makes me think, there are some drawbacks with how POV-Ray radiosity currently
goes about with normals:
- If the bumps are small compared to radiosity sample density, they tend to be
blurred out.
- The effect may be non-uniform, giving stronger normal effects in corners than
on flat surfaces (due to non-uniformity of sample density).
- There's an implementation problem with radiosity and normals when using
multi-layered textures with different normal pertubations.
- Although theoretically all that normal perturbations do is affect the
weighting of the light coming in from different directions, POV-Ray just
braindeadly takes more samples (to cover different normal angles), shooting new
sample rays for each one, instead of somehow re-using the information already
gathered and just adapting it to the different (fake) surface orientation.
There must be *some* smart way to overcome all these limitations at the same
time.
Something like storing for each radiosity sample not only the resulting
illumination for a perfectly unpertubed normal, but for an additional set of,
say, a dozen standardized pertubed-normal directions, and interpolating among
these when computing the radiosity-based illumination for a particular point
that has a pertubed normal.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Reactor" <rea### [at] hotmailcom> wrote:
> Sounds like a good idea, except you might need an absolute cutoff value at some
> point to prevent anti-aliasing that you can't see. I wonder how much different
> that approach would look from applying gamma correction before the aa decision?
Significantly, because you're simply mixing the stuff the wrong way, giving you
distortions in both brightness and hue, leading to new types of artifacts such
as thin, slightly slanted lines' brightness "pulsing" along their length in the
rythm of the original aliasing effect.
Might be an option though to compare the gamma-corrected values, but then
interpolate the linear ones and gamma-correct the result separately.
As for preventing "anti-aliasing that you can't see", with the introduction of
HDRI output the situation has somewhat changed, because by cranking up the
brightness level in a HDRI viewer you can transpose *any* absolute difference
into the visible range.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kirk Andrews" <kir### [at] tektonartcom> wrote:
> As for the lighting on the curtains--you could try the double_illuminate
> keyword. I think that will also interact with radiosity properly. However, if
> those working on the next version of POV wanted to implement a diffuse
> transparency feature, that would be wonderful indeed!
Something like this?
(Genuine POV-Ray 3.7.0 beta 33, except for a few changes I hacked up in the last
few hours.)
Post a reply to this message
Attachments:
Download 'test.jpg' (26 KB)
Preview of image 'test.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Luxrender:
> + Very realistic results.
> + Nice blender integration (other commercial suites too).
> + Imho good developer activity.
> + Adjust lighting during rendering !!!!
> + Easy scaling using active network interface, can add render nodes on
> the fly (which is really needed, see below :-)).
> - Damn long render times.
>
> POVRay:
> + Endless possibilities due to the SDL and windows frontend. I like to
> have full control using text files (I'm a software developer).
> + Nice control to scale render time (Comment out parts, use flags to
> scale quality, ...).
> + Easy way to enhance scene by scripting.
> + Working on ultra complex scenes even on ultra slow machines, text rules
> :)
> - Development seems a bit slow (no critic!, just a bit frustating).
> - Some issues I can't handle (Can be seen in the POV-render (the second
> one below)), maybe some POVray pro can tell me how to circumvent them:
> - Areas with bad anti-alias, sometimes, even with really high AA
> settings (see edges in the top right area).
> - Areas which have no direct lighting do not show any normal effects
> (All walls have bumps, but this can be seen behind the plant only).
>
> At the end, I like both and I will investigate more time in both engines
> (others too).
Did you look at MCPov? It is a patch for POV that will make it closer to
Luxrender output (ie more physically realistic results for global lighting,
but much longer render times)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> "Kirk Andrews" <kir### [at] tektonartcom> wrote:
> > As for the lighting on the curtains--you could try the double_illuminate
> > keyword. I think that will also interact with radiosity properly. However, if
> > those working on the next version of POV wanted to implement a diffuse
> > transparency feature, that would be wonderful indeed!
>
> Something like this?
>
> (Genuine POV-Ray 3.7.0 beta 33, except for a few changes I hacked up in the last
> few hours.)
YES!!!! I'm ecstatic! So when can we get our hands on that?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
