> Agreed, but this scripting support must be accessible to draw and keep 
> users.

I second that.  Simple things (and moderately complex things) that we do
now with POV 3.6 must remain simple to do in any future development.

However, provided the above, being able to do more complex things, or
doing it with more flexibility, on top of that, is a necessary evolution.

Fabien.

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> Adding clutter (and almost 
> certainly new bugs) to the interface for the purpose of overlapping the 
> capabilities of existing, non-renderer tools will not.

  For some reason you have this obsessive fixation about "if it can be
done with third-party tools, it should not be added to POV-Ray".

  Well, you know what? 3D images can be rendered with third-party programs.
Thus, by your logic, rendering support is not necessary in POV-Ray because
you can do it with other programs.

  So what if you can calculate subdivision of meshes with third-party tools.
Can you guess how many of these tools I have in my computer? Moreover, can
you guess how many of these tools are not available at all for my OS?

  Besides, even if I had a subdivision-capable program available for my OS,
it would still be clumsy to use. I would have to create or convert the mesh
to a format supported by that program, then I would have to perform the
subdivision, then I would have to export or convert the result to a POV-Ray
mesh, and then I would have to write the SDL file to read that mesh.
  Naturally this becomes more complicated if the original mesh was created
with POV-Ray itself (for example I have an include file which creates a
mesh in the shape of a surface of revolution, given the outline spline).

  It would be really, really handy if I could perform the subdivision in
POV-Ray itself. No conversions, no saving, no temporary files, no nothing.
Just one command and there you are: I have the subdivided mesh.

  Why you think enhancing POV-Ray in a way that allows creating this kind
of functionality is a bad thing goes beyond my comprehension.

-- 
                                                          - Warp

Post a reply to this message

St. <dot### [at] dotcom> wrote:
>   Couldn't we just call Moray 'Pov-Ray', and work with that?

  No, because Moray is windows-only.

-- 
                                                          - Warp

Post a reply to this message

> St. <dot### [at] dotcom> wrote:
>>   Couldn't we just call Moray 'Pov-Ray', and work with that?
> 
>   No, because Moray is windows-only.

I think he's joking...

Fabien.

Post a reply to this message

>   So what if you can calculate subdivision of meshes with third-party tools.
> Can you guess how many of these tools I have in my computer? Moreover, can
> you guess how many of these tools are not available at all for my OS?

Good example.  Imagine you have a mesh which requires subdivision, and are
making an animation.  If POV-Ray performs the subdivision, various instances
of the mesh could be subdivised at different levels, according the distance
from the camera (thus optimizing memory requirements and rendering time).
It wouldn't be easy to get that with an external tool.

Advanced features such as displacement mapping would also benefit from an
integrated model (well, the list is long).

Of course, there are features that would be better handled externally,
but, before saying "it shouldn't be within POV-Ray", first answer the
question : "won't it be faster or more flexible if done within POV-Ray ?".

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Good example.  Imagine you have a mesh which requires subdivision, and are
> making an animation.  If POV-Ray performs the subdivision, various instances
> of the mesh could be subdivised at different levels, according the distance
> from the camera (thus optimizing memory requirements and rendering time).
> It wouldn't be easy to get that with an external tool.

  Also: Being able to subdivide using POV-script allows more flexibility.

  For example, suppose you want to subdivide the mesh only at parts which
are outside of a given object, but not in parts which are inside. Or you
want to subdivide only at places where the mesh is green.
  Those kinds of things would be simply *impossible* with a third-party
tool.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > Good example.  Imagine you have a mesh which requires subdivision, and are
> > making an animation.  If POV-Ray performs the subdivision, various instances
> > of the mesh could be subdivised at different levels, according the distance
> > from the camera (thus optimizing memory requirements and rendering time).
> > It wouldn't be easy to get that with an external tool.
>
>   Also: Being able to subdivide using POV-script allows more flexibility.
>
>   For example, suppose you want to subdivide the mesh only at parts which
> are outside of a given object, but not in parts which are inside. Or you
> want to subdivide only at places where the mesh is green.
>   Those kinds of things would be simply *impossible* with a third-party
> tool.
>
> --
>                                                           - Warp

Can we imagine a fragment of code like this:

my_mesh = mesh { ... } // or: pov.primitive.Mesh.read("body.msh");
my_mesh.nose.subdivide(...);
my_mesh.nose.smooth(...);


Bruno

Post a reply to this message

"Fa3ien" <fab### [at] yourshoesskynetbe> wrote in message 
news:47050742$1@news.povray.org...

>> St. <dot### [at] dotcom> wrote:
>>>   Couldn't we just call Moray 'Pov-Ray', and work with that?
>>
>>   No, because Moray is windows-only.
>
> I think he's joking...

     No, I wasn't, I didn't know that. I have it, but don't use it. Anyway, 
why can't it be ported then?

      ~Steve~


>
> Fabien.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> As you might have noticed, not everybody is convinced we should have one (SDL).

hello?!  Drop povray's SDL and povray is just among many rendering engines.
I believe to be the crown jewel of povray!

We should have one and only povray SDL and it should have easy syntax and
semantics, should be mostly declarative interspeced with a few useful
control flow commands and should be modular.  If someone wishes to program
in another language which suits his needs best, do it and create a program
in said language which compiles his scene or library to povray SDL, just
like today.

I think if povray loses its SDL, it'd lose its identity.  If it shipped just
with some sort of bytecode VM for which lots of languages could compile to,
it'd still lose its identity.

Povray needs its SDL, period.

Post a reply to this message

Fa3ien wrote:
> 
> Imagine you have a mesh which requires subdivision, and are
> making an animation.  If POV-Ray performs the subdivision,
> various instances of the mesh could be subdivised at different
> levels, according the distance from the camera

Best example I've seen yet, and a very compelling, but I'm not sold. 
This simplification would require more than just distance to the camera, 
angle of incidence would also have to be considered. The system would 
need to be fairly complex to produce a decent result, and characters, 
landscape, and teapots would all require different rules. One person 
might someday do this if the SDL were extended enough.

But how many people are we excluding by obfuscating the SDL?

When much of the code in p.text.s-f looks like this:
MacroName (*Param1, %Param2%$, ....)
new users will not be willing to commit to learning POV's (among free 
renderers) "Killer App" (scripting interface).

"Scripting" may mean something different to programmers. but it means 
something particular to me - something distinct from "Programming." I 
think POV is best served by a "Scripting Interface."

I've said several times that if it's necessary for shaders, it needs to 
be included. Modeling *will* be done 99% with outside apps, no matter 
what is included in the SDL. A lot lost for very little gained IMO. If a 
non-user read this thread, he might conclude that there are scores of 
people hand-coding complex scenes in POV or MEL[1], just champing at the 
bit waiting for the ability to make even more complex scenes this way - 
this is NOT the case.

  -Shay

[1] Maya scripting interface

Post a reply to this message