> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
>   So in your opinion, because many people use something else than
> meshes,
> we should not offer those who do use exclusively meshes for their
> scenes
> any additional tools?

Look at it another way.

If there were a feature that made boxes look a *lot* better by
performing lighting calculations differently, would you advocate it?
Remember, because the lighting is different, it probably won't be
possible to mix boxes using the new method with other geometry; that is,
you'll have to use *only* boxes to get the result.

Would you advocate the addition of such a feature?

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

On 27-Dec-08 21:24, Chambers wrote:
>> -----Original Message-----
>> From: Warp [mailto:war### [at] tagpovrayorg]
>>   So in your opinion, because many people use something else than
>> meshes,
>> we should not offer those who do use exclusively meshes for their
>> scenes
>> any additional tools?
> 
> Look at it another way.
> 
> If there were a feature that made boxes look a *lot* better by
> performing lighting calculations differently, would you advocate it?
> Remember, because the lighting is different, it probably won't be
> possible to mix boxes using the new method with other geometry; that is,
> you'll have to use *only* boxes to get the result.
> 
> Would you advocate the addition of such a feature?
> 
It's the wrong example, and you know it.
It is a difficult decision in this version of POV. Currently there are 
two important aspects of POV. One is the SDL and the other is the 
rendering engine. And they are coupled. If they weren't you could take 
the SDL and add another lighting method to derive another JustNotPOV 
with restrictions. Probably one can run it as a branch and expect that 
one day someone solves how to get the same result for algorithmically 
defined objects. Clipka would be fully justified to create that branch, 
but he doesn't want to. Branching off is not a decision to take lightly, 
and I am glad that he wants to add to the main stem.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> It is a difficult decision in this version of POV. Currently there are
> two important aspects of POV. One is the SDL and the other is the
> rendering engine. And they are coupled.

Well, not precisely:

It's the *geometry model* and the lighting model which are tighly coupled.

The SDL is coupled with the two, but that's something irrelevant in this
context. The SDL could be adjusted accordingly.

Post a reply to this message

On 27-Dec-08 22:13, clipka wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> It is a difficult decision in this version of POV. Currently there are
>> two important aspects of POV. One is the SDL and the other is the
>> rendering engine. And they are coupled.
> 
> Well, not precisely:
> 
> It's the *geometry model* and the lighting model which are tighly coupled.
> 
> The SDL is coupled with the two, but that's something irrelevant in this
> context. The SDL could be adjusted accordingly.

The SDL is only relevant in the sense that if you would allow a version 
of POV with only triangles, effectively stripping all other primitives, 
it would not really be POV anymore. The reason why I called it coupled 
is that they are both in the same package and one does not exist without 
the other. That is of course quite different from being logically 
coupled in the source.
BTW I applaud it that you have found time to look at the source in an 
attempt to improve it. I wish I had time for that.

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> Look at it another way.

> If there were a feature that made boxes look a *lot* better by
> performing lighting calculations differently, would you advocate it?

  That comparison is very poor.

  Triangle meshes are by far the most common rendering primitive in
computer graphics. Basically all renderers and modellers support them,
and in fact there are lots and lots of renderers and modellers which
don't support anything else. Even when they do support something else,
eg. NURBS, they tend to be primitives which are very easily tesselable.

  If you search for models out there, they will invariably be in triangle
mesh format. Search for entire scenes out there which you can render, and
they will invariably be in triangle mesh format (or easily conversible to
one). Basically you can create entire scenes with triangle meshes, and most
people do. In other words almost anything can be (and is) done with meshes.

  A box is in no way so versatile all on its own. You can't use boxes only
in order to seriously create any scene.

  It makes a lot of sense to add enhancing features which work on meshes
only, for the exact reason that meshes are so versatile and common.

  And it's not like there would be no precedent. For example, even though
UV-mapping cannot be applied to all POV-Ray primitives, that didn't stop
people from implementing it in POV-Ray.

-- 
                                                          - Warp

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> The SDL is only relevant in the sense that if you would allow a version
> of POV with only triangles, effectively stripping all other primitives,
> it would not really be POV anymore.

Well, some of the statements describing primitives could be modified to instead
create mesh representations of them.

Anyway, you're right in that POV-ray wouldn't be POV-ray anymore if it were
stripped down to meshes - at least if I'm asked.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   It makes a lot of sense to add enhancing features which work on meshes
> only, for the exact reason that meshes are so versatile and common.
>
>   And it's not like there would be no precedent. For example, even though
> UV-mapping cannot be applied to all POV-Ray primitives, that didn't stop
> people from implementing it in POV-Ray.

It's a big difference whether you (a) add some feature that will enhance
usability of meshes and don't reduce the usability of others, or (b) introduce
a lighting model that cannot be used unless your scene is meshes only.

There's no problem adding a UV-map to some mesh in any existing scene.

There *would* be a problem adding a better but meshes-only lighting model to an
existing scene.

Post a reply to this message

> -----Original Message-----
> From: Warp [mailto:war### [at] tagpovrayorg]
> Posted At: Saturday, December 27, 2008 2:24 PM
> Posted To: povray.beta-test
> Conversation: Radiosity: status & SMP idea
> Subject: Re: Radiosity: status & SMP idea
> 
> Chambers <ben### [at] pacificwebguycom> wrote:
> > Look at it another way.
> 
> > If there were a feature that made boxes look a *lot* better by
> > performing lighting calculations differently, would you advocate it?
> 
>   That comparison is very poor.

I don't think so.  You're talking about a new lighting model, something
that drastically effects the final image.  If such a lighting model is
usable with only one type of primitive, then any scenes wishing to use
it will be forced to use only that primitive.

In other words, I would be forced to use only meshes if I want the new
lighting model.

>   If you search for models out there, they will invariably be in
> triangle mesh format.

When made by other programs, that is.

Search for items made in POV, and triangle meshes are rather uncommon.

>   A box is in no way so versatile all on its own. You can't use boxes
> only in order to seriously create any scene.

Sure you could, if the tools were written to generate boxes instead of
triangles.  It wouldn't even be that much harder.

Most people modeling don't actually work with triangles; it's just the
tool breaks down what the user does into triangles, and then works with
those.  The same effect *could* be achieved with boxes.

>   It makes a lot of sense to add enhancing features which work on
> meshes only, for the exact reason that meshes are so versatile and
common.

Fine, I agree that meshes are common... in other modelers.

>   And it's not like there would be no precedent. For example, even
> though UV-mapping cannot be applied to all POV-Ray primitives, that
didn't
> stop people from implementing it in POV-Ray.

That's because if I use UV-mapping, I'm not prohibited from using a
sphere right next to the mesh.  If the lighting model is different for
the two objects, however, I would be (unless I were trying to achieve a
discrepancy between the two).

If it were something as trivial as UV mapping, I'd say go for it.  But
for something as *global* as the lighting model, I think it needs to
apply to all POV primitives for it to be workable.

...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

clipka <nomail@nomail> wrote:
> It's a big difference whether you (a) add some feature that will enhance
> usability of meshes and don't reduce the usability of others, or (b) introduce
> a lighting model that cannot be used unless your scene is meshes only.

  What do you mean "cannot be used"? Of course it can be used even if your
scene contains something else than meshes. It's just that the radiosity
lighting is limited to appear on the meshes. The other primitive will have
to do with regular lighting.

-- 
                                                          - Warp

Post a reply to this message

Chambers <ben### [at] pacificwebguycom> wrote:
> I don't think so.  You're talking about a new lighting model, something
> that drastically effects the final image.

  You mean UV-mapping doesn't drastically effect the final image?

>  If such a lighting model is
> usable with only one type of primitive, then any scenes wishing to use
> it will be forced to use only that primitive.

  What do you mean "forced to use only that primitive"? What would force
them to do so? I don't see any reason why other primitives couldn't be
used as well. It's just that the radiosity will not be calculated for the
other primitives, but I see no reason why they cannot be used. It's simply
that the other primitives will have to be illuminated by conventional means.

  And besides, so what if the radiosity only affects meshes? As I said,
creating entire scenes with meshes is completely normal, and in most
renderers the *only* thing they support. If you download free objects or
entire scenes out there, made with some modeller, guess which format they
use.

> In other words, I would be forced to use only meshes if I want the new
> lighting model.

  1) Who forces you?

  2) So what? You could say the same about UV-mapping. Does that bother you?

> >   If you search for models out there, they will invariably be in
> > triangle mesh format.

> When made by other programs, that is.

> Search for items made in POV, and triangle meshes are rather uncommon.

  Guess how many objects/scenes out there can you find which are made
in other programs, compared to how many of them will be made with POV-Ray.

> >   A box is in no way so versatile all on its own. You can't use boxes
> > only in order to seriously create any scene.

> Sure you could, if the tools were written to generate boxes instead of
> triangles.  It wouldn't even be that much harder.

  Now you are nitpicking, and you know it.

> >   And it's not like there would be no precedent. For example, even
> > though UV-mapping cannot be applied to all POV-Ray primitives, that
> didn't
> > stop people from implementing it in POV-Ray.

> That's because if I use UV-mapping, I'm not prohibited from using a
> sphere right next to the mesh.

  And what exactly what prohibit you from using a sphere right next to
the mesh if radiosity was used?

> If it were something as trivial as UV mapping, I'd say go for it.  But
> for something as *global* as the lighting model, I think it needs to
> apply to all POV primitives for it to be workable.

  So because radiosity can only be applied to meshes, we must not offer
this tool to anyone who could find it useful.

  I'm sorry, but that's just stupid.

-- 
                                                          - Warp

Post a reply to this message