 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW, it's the first time I see Warp defending polygon meshes, rather than his
preferred perfectly mathematical primitives, parametric and iso surfaces. And
he get scorned for it. Poor unlucky fellow... :P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp nous illumina en ce 2008-12-28 13:37 -->
> Nicolas Alvarez <nic### [at] gmail com> wrote:
>> The image will look horrible if each object is rendered with different
>> lighting.
>
> If you want the sphere to have the same lighting as the mesh, then use
> a mesh instead of a sphere.
>
> It's not like this would be the only primitive-specific feature in POV-Ray.
> Not being able to implement some feature for all primitives has never stopped
> anyone from implementing them for specific primitives anyways.
>
Whatever lighting model is used, it ABSOLUTELY MUST apply to any element of any
scene. It just can't apply to only one kind of object. Any POV-Ray scene can
contain simple primitives, isosurfaces and meshes. Any lighting model that don't
work with any one of those just can't be used at all.
--
Alain
-------------------------------------------------
You know you've been raytracing too long when your ophthalmologist examines you
for complaints of eye strain and blurred vision and asks you why the words Pov,
#declare, #include, sphere, translate, rotate, texture, and pigment are
permanently burned into your retina.
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chambers <ben### [at] pacificwebguycom> wrote:
> > If you want the sphere to have the same lighting as the mesh, then
> > use
> > a mesh instead of a sphere.
> Warp, that statement makes my point.
Which I disagree with. *My* point is that a lighting model which applies
only to meshes can be useful given how common mesh-based scenes are
(especially when importing from other modellers/renderers to POV-Ray).
The counter-argument seems to be that since the algorithm can only be
applied to meshes, it should not be provided *at all* (even though providing
it wouldn't hurt anyone). I find this reasoning incomprehensible. In the
exact same way you could argue that UV-mapping should not be provided
because it cannot be applied to all primitives. It makes the exact same
amount of sense.
If you don't like UV-mapping because it cannot be applied to everything
then the solution is rather simple: Don't use UV-mapping. Likewise if you
don't like radiosity because it can only be applied to meshes, the same
solution applies: Don't use it. Nobody gets hurt.
However, depriving people who *could* find it useful from the tool
doesn't make sense.
> I think we're operating under different assumptions here. I'm under the
> impression that a scene would look best when the entire scene uses the
> same lighting model.
Have you ever heard of light groups?
The entire scene being lighted in the exact same way is in no way a
prerequisite. On the contrary, sometimes you even *want* some parts not
being illuminated in the same way as the others. That's why light groups
were introduced in the first place.
Not that this has anything to do with radiosity+meshes. I just wanted
to point out that your argument that a lighting model *must* apply to all
possible primitives or else it's useless does not necessarily hold true.
> You're saying that different parts of the scene can use different
> lighting models.
Of course they can. I don't see the problem. Light groups already provide
a way of achieving that.
> While technically you are correct, the results do *not* look good.
Then don't use the proposed radiosity (assuming it was actually
implemented). It's that simple.
> Now, if you're *trying* to make a scene that looks fake and horrible,
> then by all means go ahead. Most of us here don't want that.
Another alternative is to make the entire scene with triangle meshes
and have superb, fast and viewpoint-independent global illumination.
You want to deprive people from having that?
> And as far as triangle meshes go, I think it would be a good thing for
> POV to support them (it currently doesn't, you know, unless you run it
> through a converter anyway)
I think you are trying to say something else than what you wrote there,
but I'm not sure what.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> BTW, it's the first time I see Warp defending polygon meshes, rather than his
> preferred perfectly mathematical primitives, parametric and iso surfaces. And
> he get scorned for it. Poor unlucky fellow... :P
Well, it's one thing to appreciate the work put into a scene made of
varied POV-Ray primitives, and another thing to admit the reality of the
computer graphics world: That 99.9% of scenes out there are made of
triangle meshes (or of easily tesselable primitives), and that most
rendering algorithms have been optimized for them.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> Whatever lighting model is used, it ABSOLUTELY MUST apply to any element of any
> scene.
Says who? That's like saying that whatever texturing elements are used,
they ABSOLUTELY MUST apply to any element of any scene. Clearly UV-mapping
doesn't do this, yet nobody is complaining.
I see no problem in triangle meshes supporting lightmaps, and these
lightmaps being pre-calculated using the algorithm called "radiosity".
(In fact, lightmaps are not very far from UV-mapping. It's just an
additional layer on top of the texture layer.)
> It just can't apply to only one kind of object. Any POV-Ray scene can
> contain simple primitives, isosurfaces and meshes. Any lighting model that don't
> work with any one of those just can't be used at all.
And why, exactly? I see no technical, ideological nor philosophical
problem with it.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote:
> > And as far as triangle meshes go, I think it would be a good thing for
> > POV to support them (it currently doesn't, you know, unless you run it
> > through a converter anyway)
>
> I think you are trying to say something else than what you wrote there,
> but I'm not sure what.
I guess he was talking about .obj format files or something similar.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmailcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
