>   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

Shay <Sha### [at] cccc> wrote:
> Best example I've seen yet, and a very compelling, but I'm not sold. 

  Ok, clearly there's no way to convince you, so we can stop trying.
You have expressed your opinion at it has become clear. Case closed.

-- 
                                                          - 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.
> 
Not necessarily forever ;)

Post a reply to this message

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

Who wants to obfuscate the SDL ?  I believe (and hope I'm right)
that its both possible to have a simple SDL, accessible
even to beginners, and to have new extended programming possibilities.
(and 90% backward compatibility, too).  That should be
verified by producing theorical SDL code for simple situations.

> 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).

As I already said, it's all a matter of compromise.  POV-Ray's SDL
won't be a "full featured" OO language like C++ or such.  I imagine*
there would be :
  - no pointers
  - only a few data types (we don't need an "integer" type, for example)
  - no polymorphism or other advanced brainf***ing technique
  - ... ?

(* : Warp, don't jump on this, it's only some vague speculations)

> "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."

POV-Ray's current SDL is already a programming language.  There are
loops, conditional, and functional macros.  What is needed is mainly to 
enhance these, for speed (macros are currently darn slow) and
flexibility.  And some object-orientedness won't harm.

> 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. 

90% of my scenes (well, when I did scenes) were done in SDL.
95% of my meshes were done by an external app (of course), but
there's much more than meshes in a POV-Ray scene.  If CSG could be
instanciated, and if we had more programming power (and speed) within
SDL, we could make images of unprecedented complexity, images that 
couldn't be done with any other app, while not requiring extreme skills.

If you look at Gilles Tran's images, you will see that, except for
pre-made people, cars, and such, everything is done in 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.

Non-users, don't read this, please :-)

Fabien.

Post a reply to this message

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

Who wants to obfuscate the SDL ?  I believe (and hope I'm right)
that its both possible to have a simple SDL, accessible
even to beginners, and to have new extended programming possibilities.
(and 90% backward compatibility, too).  That should be
verified by producing theorical SDL code for simple situations.

> 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).

As I already said, it's all a matter of compromise.  POV-Ray's SDL
won't be a "full featured" OO language like C++ or such.  I imagine*
there would be :
  - no pointers
  - only a few data types (we don't need an "integer" type, for example)
  - no polymorphism or other advanced brainf***ing technique
  - ... ?

(* : Warp, don't jump on this, it's only some vague speculations)

> "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."

POV-Ray's current SDL is already a programming language.  There are
loops, conditional, and functional macros.  What is needed is mainly to 
enhance these, for speed (macros are currently darn slow) and
flexibility.  And some object-orientedness won't harm.

Before POV 3.0, POV-Ray was pure scripting.  You had to use an
external proggy to create a spiral.  Imagine that !  When 3.0
and its programming features, though somewhat simplistic, arrived,
a new world opened, just have a look at the images produced before
and after.  When 3.1 introduced macros, another new world opened, 3.1
have been the pinnacle.  Let's open new worlds again !  Let's go higher !

> 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. 

90% of my scenes (well, when I did scenes) were done in SDL.
95% of my meshes were done by an external app (of course), but
there's much more than meshes in a POV-Ray scene.  If CSG could be
instanciated, and if we had more programming power (and speed) within
SDL, we could make images of unprecedented complexity, images that 
couldn't be done with any other app, while not requiring extreme skills.

If you look at Gilles Tran's images, you will see that, except for
pre-made people, cars, and such, everything is done in 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.

Non-users, don't read this, please :-)

Fabien.

Post a reply to this message