 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I wonder what povray lacks compared to vray. when I look at the renders produced
by vray I get the feeling they are very much up to date and modern looking.
In comparison povray has some awesome images produced so far but at times they
look somehow outdated. I hope you understand what I mean. Is it me or the vray
images are the same as povray quality but just uses better setups(environments,
etc, god knows what else)
I am a raging povray fanboy(45 yrs old though), I wanna see it rule the
raytracing scene, oh gosh.
This question has been bugging me for a year or two, I had to ask it, sorry if
I offended anyone by any remark, my intentions are clear by the fanboy comment.
I really want to know what people's take on this is, since most of them (you
know who you are) are far more knowledgeable than me.
So the question is how do you compare povray to vray in/on any scale you choose?
I will appreciate any answer. Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 13.12.2010 21:42, schrieb optima:
> So the question is how do you compare povray to vray in/on any scale you choose?
I don't compare it at all. One is a freeware open source renderer with
built-in modelling language, the other is a commercial proprietary
render engine available as a "plug-in" to commercial modelling tools.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-12-13 15:42, optima a écrit :
> Hi,
>
> I wonder what povray lacks compared to vray. when I look at the renders produced
> by vray I get the feeling they are very much up to date and modern looking.
>
> In comparison povray has some awesome images produced so far but at times they
> look somehow outdated. I hope you understand what I mean. Is it me or the vray
> images are the same as povray quality but just uses better setups(environments,
> etc, god knows what else)
>
> I am a raging povray fanboy(45 yrs old though), I wanna see it rule the
> raytracing scene, oh gosh.
>
> This question has been bugging me for a year or two, I had to ask it, sorry if
> I offended anyone by any remark, my intentions are clear by the fanboy comment.
> I really want to know what people's take on this is, since most of them (you
> know who you are) are far more knowledgeable than me.
>
> So the question is how do you compare povray to vray in/on any scale you choose?
>
> I will appreciate any answer. Thank you.
>
>
You want to compare the offering of two totaly different groups of artists.
POV-Ray users are mostly hobyists using a great free tool.
vray seems to be a comercial addon for other comercial renderers, and
thus, mostly used by professional artists using it for a living.
It is thus unrealistic to compare the end products.
Alain
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2010-12-13 15:47, Alain wrote:
> You want to compare the offering of two totaly different groups of artists.
> POV-Ray users are mostly hobyists using a great free tool.
>
> vray seems to be a comercial addon for other comercial renderers, and
> thus, mostly used by professional artists using it for a living.
>
> It is thus unrealistic to compare the end products.
I, for one, disagree that it's unrealistic to compare the end products.
Yes, there are differences, but they are measurable. Optima is
asking, it seems to me, if given an identical scene and light setup,
what are the differences between POV-Ray and vray? What features are
present in typically-seen vray renders that are perhaps absent in
POV-Ray renders?
The exact same question is valid to ask one's self as a hobbyist artist
using traditional media vs the works of professional illustrator who
also uses traditional media: 'what do they do that the I don't, so that
I can improve my own skills?'
--
Tim Cook
http://empyrean.freesitespace.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2010-12-13 15:42, optima wrote:
> So the question is how do you compare povray to vray in/on any scale you choose?
Well, after looking at the feature list for vray and sample renders, a
few obvious things stand out:
1) vray has a bigger library of good looking textures, where the stock
povray textures are, well, lacking. It seems that most good artists here
create their own or use what others post on the newsgroups or websites.
This leads to more ability to make custom looks in povray, but at the
expense of a considerable amount of time and requires that you have some
expertise yourself.
2) vray has GPU acceleration. I know the official stance here is that
povray needs to work with double instead of float, but nowadays CUDA
allows for that (at reduced speed) and really, there probably are places
in the scene where floats would work fine.
3) I'd assume vray has more efficient "SDL parsing" or their version of
it, because they mention reusable things for animations and the like.
POV-Ray speed can be increased considerably by unrolling loops, that
should tell you something (besides that it's an interpreted language).
The whole bit with opening an included file every time you call
something inside it also is a negative for pov in the speed department,
but allows for more powerful macros.
4) vray advertises motion blur, bokeh on DoF, ... All things that _can_
be done with povray but require someone to write macros.
Overall, I'd say that their main strength is the stock selection of
materials and textures and the like, with a boost from (advertised)
real-time rendering by using GPUs.
POV-Ray's strength in comparison is the lack of "hacks" to speed things
up such as ambient occlusion, instead focusing on providing an
"accurate" image for what you want. It may be slower, but it's more
physically realistic if you get your parameters correct.
If one wants to say the adage "you get what you pay for", well, I'm
getting a heck of a better cost/results ratio from povray than I would
get from vray! If I were doing professional work I'd probably be using
one of the commercial packages for the reason that I'd be paying someone
else to spend the time to make the materials and tracer so I would only
have to spend time on the modeling itself, but I'm not.
That's really what it boils down to, what's the value of your time? I
would posit that given enough experience and time a good artist could
get an image from povray that would look as if not more realistic than
one from vray, but it might take quite a while.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.12.2010 00:08, schrieb CShake:
> 2) vray has GPU acceleration. I know the official stance here is that
> povray needs to work with double instead of float, but nowadays CUDA
> allows for that (at reduced speed) and really, there probably are places
> in the scene where floats would work fine.
That /used/ to be the official stance, when double precision floating
point arithmetics wasn't available in GPUs.
While this is a non-issue nowadays, there are other remaining issues
that make GPU use problematic (most notably the inavailability of
recursions) as well as of low benefit (most notably the fact that GPUs
are most efficient on bulk data that undergoes the same
transformations). Avoiding those issues is possible, but in the case of
POV-Ray would require a complete redesign of its internal architecture.
> 4) vray advertises motion blur, bokeh on DoF, ... All things that _can_
> be done with povray but require someone to write macros.
In the case of bokeh, macros are no longer needed (with version 3.7 that
is) ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2010-12-13 19:31, clipka wrote:
> Am 14.12.2010 00:08, schrieb CShake:
>
>> 2) vray has GPU acceleration. I know the official stance here is that
>> povray needs to work with double instead of float, but nowadays CUDA
>> allows for that (at reduced speed) and really, there probably are places
>> in the scene where floats would work fine.
>
> That /used/ to be the official stance, when double precision floating
> point arithmetics wasn't available in GPUs.
>
> While this is a non-issue nowadays, there are other remaining issues
> that make GPU use problematic (most notably the inavailability of
> recursions) as well as of low benefit (most notably the fact that GPUs
> are most efficient on bulk data that undergoes the same
> transformations). Avoiding those issues is possible, but in the case of
> POV-Ray would require a complete redesign of its internal architecture.
Ah, didn't know for sure. Is that because of the function based
primitives that POV uses compared to entirely triangle meshes in most
other packages?
>
>> 4) vray advertises motion blur, bokeh on DoF, ... All things that _can_
>> be done with povray but require someone to write macros.
>
> In the case of bokeh, macros are no longer needed (with version 3.7 that
> is) ;-)
Neat, hadn't seen that. And now that I check the changelog, thanks to
you for implementing it. :)
As for my comment above about the render being more realistic or
accurate, I should qualify that by saying that POV seems to be the most
physically accurate tracer that works on rgb internally instead of
wavelength response.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
CShake <cshake+pov### [at] gmail com> wrote:
>
> That's really what it boils down to, what's the value of your time? I
> would posit that given enough experience and time a good artist could
> get an image from povray that would look as if not more realistic than
> one from vray, but it might take quite a while.
Thanks for the answers. To make what I mean more clear by differences I include
the path to my gallery
http://www.optimadekor.com/galeri/mutfak_program_optima.htm
the first 4 pics are done with radiosity values like
#declare rad_quality= 1;
#declare rad_bounces= 2;
#declare rad_brightness= 0.8;
global_settings {adc_bailout 0.003922
assumed_gamma 1.0
irid_wavelength <0.247059,0.176471,0.137255>
max_trace_level 10
radiosity {
pretrace_start 0.05
pretrace_end 0.005
count rad_quality*rad_quality
nearest_count 10+rad_quality
error_bound 0.5/rad_quality
recursion_limit rad_bounces
brightness rad_brightness}}
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>}
the remaining pics after first 4 dont use radiosity. SDL files for all pics
produced automatically by C# code.
This is the best I got from Povray, Of course POV is capable of doing better.
So, as C Shake states, is it my lack of good textures, lack of better radiosity
or lighting settings? Or am I just trying to play catchup with vray hopelessly?
the quality of some POV images I've seen so far are second to none. So I know
there is hope.
thank you for everything :D
optima
To C Shake
> one from vray, but it might take quite a while.
Whay do you mean by quite a while?
to get the good textures
to gain the experience
to render the image
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1) vray has a bigger library of good looking textures, where the stock
> povray textures are, well, lacking. It seems that most good artists here
> create their own or use what others post on the newsgroups or websites.
> This leads to more ability to make custom looks in povray, but at the
> expense of a considerable amount of time and requires that you have some
> expertise yourself.
This is the main reason, plus realistic lighting/environment setups
ready-made. It's all too easy with POV to create unrealistic looking
scenes purely because of bad textures and lighting.
Fundamentally I don't think there is anything POV is lacking to prevent
you creating very realistic scenes similar to other commercial renderers.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 14.12.2010 10:42, schrieb optima:
> Thanks for the answers. To make what I mean more clear by differences I include
> the path to my gallery
> http://www.optimadekor.com/galeri/mutfak_program_optima.htm
Image #1 appears overly bright to me; the ceiling appears to have an
"ambient" term (or, in case it was rendered with an up-to-date 3.7 beta,
an "emission" term); same with the fruit.
Geometry looks fairly sophisticated, with beveled edges and stuff
(though the geometry of the lower shelf in the corner seems incomplete,
see the shadow), and radiosty settings seem fairly good.
You might try improving on the diffuse reflections. Focal blur might be
a good idea for that, because it can do a fairly good antialiasing.
#2 has the same problems with the ceiling as #1; wall tiles texture
could be improved (not enough bump, maybe too much ambient), floor tiles
look much better. Doors texture shows that you're already using
sophisticated texturing features, but I think the scale is wrong, and
the bump mapping maybe a bit too strong. Metal surfaces appear somewhat
too bright, maybe too much diffuse.
#3 ceiling is much better, but shows that you need better radiosity
settings. Wall tiles seem to use ambient once again. Glass doors might
look more convincing with stronger reflection (try "reflection 0.0 1.0
fresnel" and "ior 1.5"). The lower door of the fridge appear "decal-ish"
somehow.
#4 appears to use ambient on the ceiling again, and maybe also on the
walls. The doors look too flat for some reason I cannot identify;
something about the reflection doesn't seem quite right. The glass doors
look like they could use more reflection again (see above). The pot on
the very top shelf on the right is the only convincing metal I've seen
in your shots so far (and is very good at that), so have a closer look
at that one.
I don't think we need to discuss #5 and following - you just can't get
convincing results without radiosity (or, to use the more general term,
"global illumination"; radiosity is just one out of various algorithms
to compute that).
So all in all: Yes, there's still room for improvement in your images
with POV-Ray.
In general, many of your textures appear to be using ambient; this is ok
for preview renders without radiosity, but it is an absolute no-go for
realistic radiosity renders; if you're using radiosity, make sure you
also use "ambient_light 0" to disable the ambient in all textures (or,
alternatively, use an up-to-date 3.7 beta and make sure you have a
"#version 3.7" statement in your scene).
You also seem to have problems getting metal textures to look right;
maybe this has to do with ambient as well, but there may be other
reasons. Look at the pot I mentioned, because its metal texture looks
really good. Unfortunately, POV-Ray is currently rather poor for
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. (My personal favorite approach is to use a single-layer
texture with a very small-scaled normals bump, and use high
anti-aliasing using AA or focal blur. Other people prefer a
multi-layered approach, which does not require anti-aliasing but gets
very costly for rays reflected multiple times.)
Speaking of reflection: When you're working with mirrors, make sure to
model a complete room so that the mirror doesn't just reflect a uniform
background. You can mark the corresponding geometry as "no_image" if it
would otherwise obstruct the camera.
Speaking of mirrors: The second-to-last image (non-radiosity) suffers
from the reflected wall being brighter than the non-reflected wall,
which is obviously physical nonsense. Photons may help in such cases.
And finally, you may also want to look at your glass textures; I'm not
exactly sure how they will look best, but I'd recommend trying
"reflection 0.0 1.0 fresnel" and an IOR fitting for window glass
(something roughly around 1.5). Also make sure that the glass has no (or
very little) diffuse.
Occasionally you may be struggling to achieve some particularly vivid
colors. In such cases, dare to set some color components to /negative/
values. While counterintuitive at first, such values /can/ make sense
physically.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoocom> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-12-14 04:42, optima a écrit :
> 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:
> Le 2010-12-14 04:42, optima a écrit :
>
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2010-12-15 04:36, optima a écrit :
> Alain<aze### [at] qwertyorg> wrote:
>> Le 2010-12-14 04:42, optima a écrit :
>>
>
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
