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

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

The goal of this discussion, IMO, is not to convince someone that
someone else is right, it's to draw a picture of what can be ahead,
including the pros and the cons of any proposal.

His worries are perfectly licit and likely represent those of many
people.  This should be adressed with enough distanciation.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:

> > 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.
>
> The goal of this discussion, IMO, is not to convince someone that
> someone else is right, it's to draw a picture of what can be ahead,
> including the pros and the cons of any proposal.
>
> His worries are perfectly licit and likely represent those of many
> people.  This should be adressed with enough distanciation.
>
> Fabien.

I don't really see that this kind of support is a key point in POV 4, but I
also don't see how it could be a bad thing. I suspect the people spending
time implementing these libraries in SDL' aren't going to be the same
people writing the core code, or rather they don't have to be.

On the mesh issue, render-time subdivision would be interesting, although
for me textures usually seem to outweigh meshes in storage requirements,
and (again for me) minimising render time is more important than memory
use. Render-time subdivision is nice for the first use case, and I would
hope it wouldn't adversely affect the other. I can't see myself making much
use of more general mesh manipulation capabilities in POV, but I can't see
the negative impact, really. From the description it sounds like they would
be a "there-if-you-need-them" feature.

Other things I wanted to mention:

* There seems to be a lot more talk about the future SDL than any future
rendering capabilities.

* Specifically on programmable shaders, how will we maintain backwards
compatibility to the somewhat bitty and odd features like irid? Built-in
shader "library"?

* Probably been mentioned before, but I can't remember; will POV 4.0
incorporate any code at all from 3.7, or will it be a complete rewrite?

* I love media {}. Most of the jobs it fails at are actually jobs for an
improved shading language, in my view. For many things it's excellent, even
compared to some professional applications, unusually.

Tom

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> His worries are perfectly licit and likely represent those of many
> people.  This should be adressed with enough distanciation.

  His worries may be valid, but his proposed solution is not.

  He has got it completely backwards. The new scripting language is going
to make the core code *simpler*, not more complicated (because tons of
features currently in the core code can be removed from there and moved
to libraries). Also there's nothing in a more powerful scripting language
that will automatically make it harder for the average user to use. In
fact, it could well be the opposite: If well designed, the new scripting
language could be *easier* to use than the current SDL (or at least make
many things a lot easier).

  With a powerful scripting language lots of features of the core code
can be removed from there, making the core code smaller and simpler, and
it will then be easier to add features to the core code which really need
to be there (if they can't be implemented in the scripting language or it
would be too inefficient to do so).

  Also a well-designed scripting language will make it much easier to
offer an easy-to-use interface to the core features. In the current SDL
each time a new feature is added, adding the correspondent SDL construct
is usually a pain, makes the parser more complicated and overall has a lot
of overhead.

-- 
                                                          - Warp

Post a reply to this message

Shay wrote:
> Warp wrote:
>> Shay <Sha### [at] cccc> wrote:
>>> C) Invent and code a new programming language and then code the 
>>> algorithm in that language.
>>
>> Right, because all that is necessary for every single algorithm which
>> will be ever made for POV-Ray.
>>
> 
> Not quite. I suppose one set of commands would take care of a handful of 
> converters. The mesh-handling stuff? Well there's decimation for 
> marching cubes of isosurfaces or CSG. Subdivision? Of what? Who creates 
> mesh models without a mouse (except me)?
> 
I do (sometimes)

Post a reply to this message

nemesis wrote:
> 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!
So do I. "one" did not refer to "SDL", as you are apparently assuming, 
but to "new SDL".

Post a reply to this message

St. wrote:
[snip]

>  As it happens, from a non-programmers point of 
> view, I think this thread has been a frenzy of what everyone *wants*, 


What I get from the thread so far is that:
- syntax of the declarative part (objects, textures, transformations, 
...) should stay the same.
- the control structures with # (#if, #macro, ...) should stay (at least 
for now)
- there should be a new set of control structures. Especially to replace 
the #declare and #macro. This should be closer to a conventional 
programming language
- it should be possible to create new objects with the same syntax as 
current ones (box, sphere, etc.)
- More of the internals should be exposed. The representation of e.g. a 
mesh should be known and modifiable at user level to create a 
subdivision, to convert an isosurface of the fly into a mesh, to write 
new import routines, etc.
- At many points it should be possible to call user functions in stead 
of predefined choices. And those functions should be able to call many 
internal functions. This is needed for new shaders and such.
- binary input and output should be supported from within new style 
functions.

 > and in the end, I think nothing will happen directly resulting from
 > this thread imo.

I expect all of these things to be in POV4.


Anyone dare to answer the question on whether POV4 should be a scene 
description language or a scriptable ray tracer?

Post a reply to this message