 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"clipka" <nomail@nomail> wrote:
> However, beware of media in mcpov - you can't use those reliably.
Actually, media works very well as long as you stick with absorption and
emission, as they do not depend on lights. It works great for glass or other
translucent materials, although it's certainly not subsurface scattering.
Overall, I'd say MCPov is nice if you're lazy and want to get all the benefits
of photons, radiosity, etc. without any extra work or artifacts. Somehow it
just feels more natural.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> That overlaying of images intrigues me. It is merging of two or more images
> in a paint program isn't it? What is used in that case? Averaging?
'convert -average *.png result.png' for you Unix/Linux-types. (Upon further
inspection, of course ImageMagick is available for Windows, too.) I'm not sure
how it handles precision for many images, but I've had good luck. I'd also
recommend rendering much larger images than you need since you can just
down-scale later and reduce the noise. 2x2 -> 1x1 = 1/sqrt(4) = 1/2 the noise.
- Ricky
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks guys (nemesis, clipka, triple_r)!
That fully satisfies my curiosity :-)
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
>
> I have no idea which of these approaches would leave you with the least loss. I
> guess (a), but it depends on how Photoshop does things internally. If for
> example it stays in the 8 bit integer domain for its computations, (b) is
> obviously crap; but if it uses floating-point math (or at least 16-bit
> arithmetics) during any "merge layers" operation, but converts back to 8-bit
> after such an operation, you're definitely better off with (b).
>
> In any case, Photoshop can never do as good as POV.
>
err, just for the records, P'shop works well with 16 bit/channel (not
only for temporary computation) since more then 12 years, does most
if its internal calculation in the L*a*b color space (so yes, it uses
fp) and has since CS3 (hmm, around since 2 years I guess) even full
support for HDRI in 32bit/channel floating point format. P'shop even
supports OpenEXR HDR images as written quite nicely by the POV 3.7 - the
format I use most of the time.
Oh, and Photoshop works within a specified color space where POV-Ray not
even knows what a color space is (e.g. I bet POV simply clips negative
RGB components to 0 at some stage).
Anyway I'm not getting payed by Adobe by saying so (in fact I dislike
them for most of their company policy) so I'll shut up for now.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> benefit again as reference for SSS approximation, but also on top-quality
> shots
> when rendering time is not an issue.
With CPUs getting faster and more cores becoming common, we need more of
these "rendering time is not an issue" features for POV. After all POV is
all about quality when speed doesn't matter, let's keep it that way.
IMO path tracing and real per-photon SSS are two great things that should be
added.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <"ive### [at] lilysoft org"> wrote:
> > In any case, Photoshop can never do as good as POV.
Maybe I should have added "for this particular purpose" ;)
> err, just for the records, [... lotsa stuff...]
Never seemed to have gotten that to work / unfortunately I can't afford a
brand-new version / Good to know / ...
> Oh, and Photoshop works within a specified color space where POV-Ray not
> even knows what a color space is (e.g. I bet POV simply clips negative
> RGB components to 0 at some stage).
.... which is irrelevant because POV obviously works within POV's color space ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"triple_r" <nomail@nomail> wrote:
> "Thomas de Groot" <tDOTdegroot@interDOTnlANOTHERDOTnet> wrote:
> > That overlaying of images intrigues me. It is merging of two or more images
> > in a paint program isn't it? What is used in that case? Averaging?
>
> 'convert -average *.png result.png' for you Unix/Linux-types. (Upon further
> inspection, of course ImageMagick is available for Windows, too.) I'm not sure
> how it handles precision for many images, but I've had good luck. I'd also
> recommend rendering much larger images than you need since you can just
> down-scale later and reduce the noise. 2x2 -> 1x1 = 1/sqrt(4) = 1/2 the noise.
>
> - Ricky
Quite right. Here is a rendering of the biscuit advanced scene that comes with
POV-Ray, rendered with MCPov. This is after almost 9 hours on 4 cores (which
ended up running about 46 passes each in that time) at 1920x1200, and then
averaged and scaled by half to 960x600. Each of the 4 full-size images is still
fairly noisy but once they are averaged and scaled down it's not so bad.
The only thing I changed in the scene was removing the light_sources and
replacing them with a HDR probe (yes, the kitchen!) on a large sphere.
I also had to use mc_colour_clip 2.0 in the global settings due to lots of
bright pixels, especially in the back of the biscuit tin where the lights are
being reflected onto the biscuits.
Post a reply to this message
Attachments:
Download 'biscuitmc.jpg' (190 KB)
Preview of image 'biscuitmc.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sooperFoX wrote:
> This is after almost 9 hours on 4 cores (which
> ended up running about 46 passes each in that time) at 1920x1200, and then
> averaged and scaled by half to 960x600. Each of the 4 full-size images is still
> fairly noisy but once they are averaged and scaled down it's not so bad.
>
Err, did you add the mc_sky keyword like...
sphere { 0, 1000
pigment {image_map {hdr "D:\Maps\HDR\kitchen_lat_long" map_type 1}}
finish {ambient 1 diffuse 0}
montecarlo { mc_sky { 100 }}
}
...to your HDRI sphere?
Just curious 'cause I've rendered similar scenes with MCPov within 2
hours on 1 core with acceptable results. But there might be something
special with this one...
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive wrote:
> Err, did you add the mc_sky keyword like...
>
> sphere { 0, 1000
> pigment {image_map {hdr "D:\Maps\HDR\kitchen_lat_long" map_type 1}}
> finish {ambient 1 diffuse 0}
> montecarlo { mc_sky { 100 }}
> }
>
> ...to your HDRI sphere?
>
> Just curious 'cause I've rendered similar scenes with MCPov within 2
> hours on 1 core with acceptable results. But there might be something
> special with this one...
>
> -Ive
Yes, although I used a value of 1000 instead of 100. I figured I might get
better shadows that way, but I haven't performed a comparison yet.
Also, I have "just" a Core2 Quad Q6600 @ 2.4GHz - not the fastest around, and
it's not overclocked or anything.
The render is still going, I am going to leave it on overnight and then I will
try it again with mc_sky { 100 } and see if there is any difference.
What do you use for your finish? I have:
default { finish { diffuse 1 ambient 0 montecarlo { mc_diffuse { 1 2 2 }
mc_use_cosine_distrib } } }
The cosine_distrib is just there for cases where I don't have sky importance
sampling turned on.
Cheers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
sooperFoX wrote:
> What do you use for your finish? I have:
>
> default { finish { diffuse 1 ambient 0 montecarlo { mc_diffuse { 1 2 2 }
> mc_use_cosine_distrib } } }
>
Almost the same:
#default {
finish { ambient 0 diffuse 1 montecarlo {mc_diffuse {1 2 1}} }
}
As a result of my experiments with MCPov I did come to the conclusion
that it works best if runs as many passes as possible (mostly limited by
my own patience) but by using settings that also each pass is as fast as
possible. Finally I end up with usually 500 - 1000 passes.
I usually also use mc_colour_clip 1.0 because (for my own scenes) this
works just fine and I'm also a bit skeptical about the approach of
rendering at higher resolution and downsampling the image. Does this not
just reduce the number of passes you let MCPov do its fine work and so
avoid the stage when it starts to trace rays from minor reflective
materials? Thats the same I do get with the low colour clip value.
If you want/need this effect of reflected light you'll have to be
prepared to be veeeeeery patient anyway.
But for sure this all is only valid for the way I do use MCPov and this
is mostly for scenes that where already designed to be "radiosity only"
and the strenth of MCPov is, it can indeed produce superior results in
less time than traditional POV-Ray radiosity.
As a conclusion: The statement (I've read somewhere) the best thing
about MCPov is, you no longer have to struggle with tweaking some
settings, is only true if you really do not care about rendertimes.
Tweaking MCPov settings (and well chosen portals) can make a huge
difference for the ratio between rendertime/quality.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
