POV-Ray : Newsgroups : povray.binaries.images : POVRay / Luxrender Server Time
5 Nov 2024 09:22:43 EST (-0500)
  POVRay / Luxrender (Message 1 to 10 of 19)  
Goto Latest 10 Messages Next 9 Messages >>>
From: hobBIT
Subject: POVRay / Luxrender
Date: 27 Jul 2009 15:12:13
Message: <4a6dfc0d@news.povray.org>
Hi all,

below a scene I started some days ago inspired by the portal doc of 
luxrender (luxrender.net), a really nice GPL render engine. While 
waiting for the result calculated by luxrender, I planned to port it to 
POVRay and compare the result, see yourself.

Here my 2 cents to the differences:

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

Some values:
Luxrender image: The scene was rendered 8 hours on an Athlon 3800 X2, 
both cores, I've then added 2 Athlon 4850 dual core plus one Sempron 
3000, so it renders 6 additional hours on 7 cores (my complete home 
network).

POVRay image: 2.5 hours on the Athlon 3800 X2, both cores (3.7 beta 33).

Please leave some comments :-)

hobBIT


Post a reply to this message


Attachments:
Download 'luxroom_comp.jpg' (688 KB)

Preview of image 'luxroom_comp.jpg'
luxroom_comp.jpg


 

From: Reactor
Subject: Re: POVRay / Luxrender
Date: 27 Jul 2009 15:35:00
Message: <web.4a6e00e67ae82ffcdef9a2950@news.povray.org>
hobBIT <bla### [at] gmxde> wrote:
> Hi all,
>
> below a scene I started some days ago inspired by the portal doc of
> luxrender (luxrender.net), a really nice GPL render engine. While
> waiting for the result calculated by luxrender, I planned to port it to
> POVRay and compare the result, see yourself.
>
..
..
..
> POVRay:
>    - Areas with bad anti-alias, sometimes, even with really high AA
> settings (see edges in the top right area).

What were the anti-aliasing settings?  Also, are you aware of an odd (but
documented) interaction between anti-aliasing and gamma correction?
Specifically, gamma correction is applied after anti-aliasing, which means that
your settings may have told it not to use aa further (based on the threshold
value), but gamma correction placed it out of the threshold.


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

By default, normals are ignored in radiosity.  To take them into account, place
"normal on" in your radiosity block.

>
> Please leave some comments :-)
>
> hobBIT


It seems to me that luxrender was described a while back as allowing you to
define the emission pattern of a light source.  I saw the IES example image on
the wiki, but I am having trouble tracking down how a user might make their own
IES files.  I would definitely be interested, though.  I am curious as to how it
compares to mcpov

-Reactor


Post a reply to this message

From: Christian Froeschlin
Subject: Re: POVRay / Luxrender
Date: 27 Jul 2009 15:35:20
Message: <4a6e0178@news.povray.org>
> below a scene I started some days ago 

Nice scene! Although you should have replaced the luxrender
picture by a povray logo in the second version ;)

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

By default, radiosity ignores normals (see 2.3.7.4). You can add
"normal on" in the radiosity block, but it might be slow. Using fill
lights may be an alternative.


Post a reply to this message

From: hobBIT
Subject: Re: POVRay / Luxrender
Date: 27 Jul 2009 16:27:47
Message: <4a6e0dc3$1@news.povray.org>
Reactor schrieb:
> hobBIT <bla### [at] gmxde> wrote:
>> Hi all,
>>
>> below a scene I started some days ago inspired by the portal doc of
>> luxrender (luxrender.net), a really nice GPL render engine. While
>> waiting for the result calculated by luxrender, I planned to port it to
>> POVRay and compare the result, see yourself.
>>
> ..
> ..
> ..
>> POVRay:
>>    - Areas with bad anti-alias, sometimes, even with really high AA
>> settings (see edges in the top right area).
> 
> What were the anti-aliasing settings?  Also, are you aware of an odd (but
> documented) interaction between anti-aliasing and gamma correction?
> Specifically, gamma correction is applied after anti-aliasing, which means that
> your settings may have told it not to use aa further (based on the threshold
> value), but gamma correction placed it out of the threshold.

[1280x1024, AA 0.1, Smpl=2, Jitter+]
Width=1280
Height=1024
Quality=11
Antialias=On
Antialias_Threshold=0.1
Sampling_Method=2
Jitter=On

...

No I havn't heared that before. I've removed the assumed_gamma directive 
and rerendered the area, but the artifacts are still there. Will try to 
find detailed information about the things you've mentioned.


> 
> 
>>    - 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).
> 
> By default, normals are ignored in radiosity.  To take them into account, place
> "normal on" in your radiosity block.

Thanks, I will try this !

> 
>> Please leave some comments :-)
>>
>> hobBIT
> 
> 
> It seems to me that luxrender was described a while back as allowing you to
> define the emission pattern of a light source.  I saw the IES example image on
> the wiki, but I am having trouble tracking down how a user might make their own
> IES files.  I would definitely be interested, though.  I am curious as to how it
> compares to mcpov

Using IES data in renders is a bit above my knowledge, but I often read 
thing about this. I should invest more details in technical background 
related things :-)

> 
> -Reactor
> 
> 

hobBIT


Post a reply to this message

From: hobBIT
Subject: Re: POVRay / Luxrender
Date: 27 Jul 2009 16:35:42
Message: <4a6e0f9e$1@news.povray.org>
Christian Froeschlin schrieb:
>> below a scene I started some days ago 
> 
> Nice scene! Although you should have replaced the luxrender
> picture by a povray logo in the second version ;)

Thanks, I thought about this, but I've tried to use mainly the same 
colors for comparision. I may do this in the 'release' version :-)

> 
>>   - 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).
> 
> By default, radiosity ignores normals (see 2.3.7.4). You can add
> "normal on" in the radiosity block, but it might be slow. Using fill
> lights may be an alternative.

Thanks, I will try it.
Using fill lights is something that I don't like. I will setup scenes 
like they occure in reality, independent of the rendering time :-)
BTW: Are there any plans or side projects that allow rendering in 
networks for single scenes ?

hobBIT


Post a reply to this message

From: clipka
Subject: Re: POVRay / Luxrender
Date: 27 Jul 2009 18:30:01
Message: <web.4a6e29bb7ae82ffc842b7b550@news.povray.org>
hobBIT <bla### [at] gmxde> 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.

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.


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

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

What I also see is radiosity artifacts in the corners (blotchy look; it should
be possible to eliminate them with higher-quality radiosity settings).

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.


Furthermore, I see significant differences in brightness / contrast, but these
may be due to (a) the curtain thing, and (b) possibly gamma issues.


Post a reply to this message

From: Cousin Ricky
Subject: Re: POVRay / Luxrender
Date: 27 Jul 2009 18:40:01
Message: <web.4a6e2bf97ae82ffc78641e0c0@news.povray.org>
hobBIT <bla### [at] gmxde> wrote:
>
> [1280x1024, AA 0.1, Smpl=2, Jitter+]
> Width=1280
> Height=1024
> Quality=11
> Antialias=On
> Antialias_Threshold=0.1
> Sampling_Method=2
> Jitter=On

Lower the Antialias_Threshold.  For dark areas, 0.1 may not be low enough.


Post a reply to this message

From: hobBIT
Subject: Re: POVRay / Luxrender
Date: 28 Jul 2009 13:18:15
Message: <4a6f32d7@news.povray.org>
Cousin Ricky schrieb:
> hobBIT <bla### [at] gmxde> wrote:
>> [1280x1024, AA 0.1, Smpl=2, Jitter+]
>> Width=1280
>> Height=1024
>> Quality=11
>> Antialias=On
>> Antialias_Threshold=0.1
>> Sampling_Method=2
>> Jitter=On
> 
> Lower the Antialias_Threshold.  For dark areas, 0.1 may not be low enough.
> 
> 

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 ?

hobBIT


Post a reply to this message

From: Kirk Andrews
Subject: Re: POVRay / Luxrender
Date: 28 Jul 2009 13:45:01
Message: <web.4a6f38be7ae82ffcaf99e1340@news.povray.org>
> 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 ?
>
> hobBIT

Yes, amounts less than 0.1 are permissible, and yes, 0.0 means every pixel is AA
traced.

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!


Post a reply to this message

From: clipka
Subject: Re: POVRay / Luxrender
Date: 28 Jul 2009 13:55:00
Message: <web.4a6f3b457ae82ffcdcf616650@news.povray.org>
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.


Post a reply to this message

Goto Latest 10 Messages Next 9 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.