 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think this "discussion" is going nowhere... let's just conclude that
(a) there are obviously different views on the issue of whether a mesh-only
lighting model should be included into a renderer like POV-ray, and
(b) in practice it will most likely not happen any time soon.
To throw in some more pragmatic argument: Although I see some point in Warp's
argumentation, I for one think it is of *much* more benefit to invest time &
energy into improving an existing lighting model, than into adding a new one
that works only with a subset of the geometry supported by POV-ray.
Note that I'm not saying that it wouldn't be worth to put time & energy into new
lighting models *per se* - but that *any* lighting model supporting only a
subset of POV-ray's geometric primitives should have lower priority than *any*
reasonably promising lighting model supporting the whole palette.
And I still consider "Wardian" radiosity promising enough for that matter. I
think there is still room for improvement - at least on the quality side. 3.6
was obviously flawed with implementation issues worth working out.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
news:web.49553f5eb480f7928ac4fcf10@news.povray.org...
> From what I gather from Ward's paper, true radiosity requires the geometry
> to be
> subdivided in - roughly - equally sized patches. This is easy to do with
> mesh
> based geometry, but infeasible with the mathematical representation
> POV-ray
> uses for objects.
Now here's something that has been bothering me for a while. The current
generation of commercial renderers (the Vray/finalRender types, not the
unbiaised types like Maxwell or FryRender) are, as far as I know, evolutions
of POV-Ray-like renderers, i.e. basically raytracers with GI on top.
However, they are extremely fast and are able to produce artifact-free GI
images, typically for design and architectural visualisations where light
calculations must be very accurate, even for complex models. One can throw a
lot at them (area lights of any shape, blurred reflection/refraction, real
focal blur, displacement mapping etc.) and they still perform very well, and
users obtain fast and smooth results. Of course, these renderers are all
mesh-based.
The question is: is using mesh geometry the only way to get this kind of
speed, and is POV-Ray's unique ability to deal with mathematical
representations a limitation here?
G.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Gilles Tran" <gil### [at] gmail com> wrote:
> The question is: is using mesh geometry the only way to get this kind of
> speed, and is POV-Ray's unique ability to deal with mathematical
> representations a limitation here?
Let's see what POV can do when those pesky bugs are out. I bet a lot of scenes
out there have (otherwise) unnecessarily high quality settings just to get rid
of those artifacts.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gilles Tran wrote:
> Now here's something that has been bothering me for a while. The current
> generation of commercial renderers (the Vray/finalRender types, not the
> unbiaised types like Maxwell or FryRender) are, as far as I know,
> evolutions of POV-Ray-like renderers, i.e. basically raytracers with GI
> on top. However, they are extremely fast and are able to produce
> artifact-free GI images, typically for design and architectural
> visualisations where light calculations must be very accurate, even for
> complex models. One can throw a lot at them (area lights of any shape,
> blurred reflection/refraction, real focal blur, displacement mapping
> etc.) and they still perform very well, and users obtain fast and smooth
> results. Of course, these renderers are all mesh-based.
> The question is: is using mesh geometry the only way to get this kind of
> speed, and is POV-Ray's unique ability to deal with mathematical
> representations a limitation here?
It is more a question of research and necessity: If you go through
literature and i.e SIGGRAPH proceedings, you will find that most research
deals with meshes only because implementation is just easy when you have to
deal only with triangles (and all their neat mathematical properties). So
even if better alternatives exist, in many cases meshes are used just
because meshes are quick to implement and "commonly" used...
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
