 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.12.2010 11:37, schrieb scott:
> Fundamentally I don't think there is anything POV is lacking to prevent
> you creating very realistic scenes similar to other commercial renderers.
Blurred reflections can make a huge difference. Yes, you can achieve
those in POV-Ray, too, but the respective approaches are rather
non-elegant, and either comparatively costly regarding rendering time or
tend to yield grainy results.
Also maybe making specular highlights "fresnel-aware" might help make
things look more convincing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
thank you clipka, I'll try to learn from all you said
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Fundamentally I don't think there is anything POV is lacking to prevent
>> you creating very realistic scenes similar to other commercial renderers.
>
> Blurred reflections can make a huge difference. Yes, you can achieve
> those in POV-Ray, too, but the respective approaches are rather
> non-elegant, and either comparatively costly regarding rendering time or
> tend to yield grainy results.
>
> Also maybe making specular highlights "fresnel-aware" might help make
> things look more convincing.
I vote for incorporating MCPov in the official POV :-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.12.2010 14:13, schrieb scott:
> I vote for incorporating MCPov in the official POV :-)
I vote for waiting for the 3.7.0 release proper (which is soon to come,
this time for real), which will again allow to create patched versions
at last. I guess we'll see at least one stochastical rendering patch
soon after ;-)
Christoph
(treating his fingers with anti-itch salve until then)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2010-12-14 06:17, clipka wrote:
> modelling dull metal: You really need blurred reflection to make that
> look convincing, the "diffuse" term is an insufficient substitute. At
> present, that means you'll need to use some micro- or macronormals
> approach.
It's strange that the impression that I get from references to using
micronormals for blurred reflections is that it is somehow a
less-than-ideal solution. Isn't that how blurred reflections are
created in reality, though? (Well, at least as far as texture normals
represent a surface feature...) The faster, corner-cutting methods used
by other renderers are what's cheating. ;)
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.12.2010 23:28, schrieb Tim Cook:
> On 2010-12-14 06:17, clipka wrote:
>> modelling dull metal: You really need blurred reflection to make that
>> look convincing, the "diffuse" term is an insufficient substitute. At
>> present, that means you'll need to use some micro- or macronormals
>> approach.
>
> It's strange that the impression that I get from references to using
> micronormals for blurred reflections is that it is somehow a
> less-than-ideal solution. Isn't that how blurred reflections are created
> in reality, though? (Well, at least as far as texture normals represent
> a surface feature...) The faster, corner-cutting methods used by other
> renderers are what's cheating. ;)
It is non-ideal for various reasons:
- The classic approach to micro- and macronormals in POV-Ray is to use
an average texture_map with a great number of textures (it is even
discussed in that context how to circumvent the 256-entries-per-map
limit), each with its unique normal pertubation, so that POV-Ray will
fork the ray N-fold in slightly different directions. The problem here
being that if such reflected rays are reflected again, you get NxN rays,
and so forth. See your render times skyrocket in scenes with a /high/
percentage of reflecting surfaces.
- An alternative approach is to use a single texture with an extremely
fine pertubation, and use extremely high-quality anti-aliasing to cause
a bunch of rays to be shot. The problem here is that you get an N-fold
fork of the ray right at the camera, so you will have to do even your
intersection test with the very first object N-fold. Say hello to
unnecessarily high render times in scenes with a /low/ percentage of
reflecting surface.
The ideal solution would be to fork the ray no sooner than it hits a
blurrily-reflecting surface, and prevent forking on subsequent
reflections. There would be no cheating in this approach.
Hell, yes, there /is/ a possibility to do this with current versions of
POV-Ray, but do you /really/ want to duplicate all your reflective
objects, one with micronormals and "no_reflection", one without
micronormals and "no_image"? Ease of use is something different.
- In an ideal world, the amount of blurriness would directly correlate
to the roughness used for specular reflections. This is difficult to
achieve with the current tools available.
- Built-in blurred reflections would allow for some performance
improvements, such as stopping to fork rays as soon as you're confident
that additional forks will not give you any substantially new
information (similar to what's done in focal blur).
There may be even more reasons why built-in blurred reflection would be
better, but I guess the above is reason enough.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"optima" <jes### [at] yahoo com> wrote:
> I am a raging povray fanboy(45 yrs old though)
I'd say most raging povray fanboys are indeed by now fanoldfarts... ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> and just one light
> light_source{
> 0, rgb 3
> area_light 20*x,20*z,4,4 jitter adaptive 1 orient circular
> fade_distance 100
> fade_power 2
> translate<-198.2784,250,405.9303>}
>
You can improve that area_light.
As it is, when you use antialiasing, you have a high likelyhood that
each subsamples be different, pushing the subsampling to it's limit.
I think that it's beter to use a high density array instead:
area_light 20*x,20*z,65,65 jitter adaptive 1 orient circular
You can even use larger values, like: 129,129 or 257,257
Optimum values follow the powers of two incremented by one making them
odd. This is due to the way the adaptive algorythm works. It adaptively
splits the interval between samples by 2 up to the minimal length set by
the setting.
Here, the jitter introduce a small noise that is probably under the
antialiasing threshold. The densest the array, the smaller the
differences an finer the noise.
Also, there are times when using more than one light is advisable.
Other points:
Do you use the metalic textures from metals.inc? Those have a LOT of
ambient! They are not suitable for any radiosity scene. They used
ambient as a cludge to look acceptable in mostly empty scene with mostly
nothing to reflect.
I suspect that something similar may also affect the various glass
textures from glass.inc and glass_old.inc.
In your radiosity block, you can easily get values that fall oustide the
supported or acceptable or sane range.
With rad_quality = 1; you only get one radiosity sample. NOT a sane
value! This will result in extremely splotchy render, that can change
radicaly by moving the camera by a very small amount.
Even rad_quality = 5; gives only 25 samples, whitch is usualy to little,
especialy with an error_bound 0.5/5 (0.1)
rad_quality = 10; gives 100 samples, error_bound 0.05 nearest_count 20
(the largest possible value)
Such a setting can realy cause some artefacts. Not quite enough samples
for the error_bound, and the averaging of up to 20 samples is probably
not enough to compensate.
To get enough samples for the quality 10 setting, you'd probably need
rad_quality = 20; for 400 samples, but error_bound 0.025 and
nearest_count 30 (out of range, silently reduced to 20).
Unless you use version 3.7 beta 40, rad_quality = 40; is the largest you
can use. samples 1600 (maximum value) error_bound 0.0125 nearest_count 20.
I agree with clipka analysis.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <aze### [at] qwertyorg> wrote:
>
Hi,
I will try your suggestions (Alain), very valuable advice.
I use v3.6.1, is it worth to switch to 3.7 because it has multiprocessor
support and may render upto 30-40% faster in multicore computers?
yes, I have problem with metals specially with rad on.
http://www.kitchendesigned.com/tmp/rad_hood.jpg
the code
pigment {color rgbf <200,200,200>/255}
finish {phong 1 ambient 0 reflection 0.5}}
Do you suggest that I use metal and glass inc instead of the rgb I use
currently?
And what about the effect of the said inc files with rad on and off?
> I agree with clipka analysis.
I agree with anything he says too :D
thank you very much
optima
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Alain<aze### [at] qwertyorg> wrote:
>>
>
> Hi,
> I will try your suggestions (Alain), very valuable advice.
> I use v3.6.1, is it worth to switch to 3.7 because it has multiprocessor
> support and may render upto 30-40% faster in multicore computers?
>
> yes, I have problem with metals specially with rad on.
> http://www.kitchendesigned.com/tmp/rad_hood.jpg
>
> the code
> pigment {color rgbf<200,200,200>/255}
> finish {phong 1 ambient 0 reflection 0.5}}
>
> Do you suggest that I use metal and glass inc instead of the rgb I use
> currently?
> And what about the effect of the said inc files with rad on and off?
>
>> I agree with clipka analysis.
> I agree with anything he says too :D
>
> thank you very much
> optima
>
>
>
I don't suggest that you use metal.inc and glass.inc. They tend to have
extra ambient that don't work with radiosity.
The default phong_size is normaly to broad for metals. Use a relatively
large value, like 200 or more.
Maybe using specular highlight could give you a beter result. Use a
small roughness value, usualy less than 0.01.
Don't forget the metallic keyword.
For the glass, you should use reflection{Min_Reflection Max_Reflection
fresnel} and add conserve_energy to your finish.
Don't forget to set an ior. Using some dispersion can greatly improve
your glass materials, even glass panes.
I think that you should update to 3.7 for many reasons:
Multiprocessor support.
HDR support.
Beter focal blur and antialiasing.
Octree bounding giving faster renders.
Back-side illumination and sub surface light transport.
area_illumination for area_light.
Distinct ambient and emission settings.
And many other improvements.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
