Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> The libraries would be written in C++, like the rest. No need for
> proprietary or non-free stuff.

> This would allow POV-Ray to be controlled by something else than
> "official" SDL (in a more open architecture), though the normal user 
> would only see SDL.

  How would the average user then use those libraries from the SDL?

-- 
                                                          - Warp

Post a reply to this message

Bryan Valencia <no### [at] waycom> wrote:
> I should say that a type of this is possible today...

> You could create a POV namespace and begin coding "objects" that exist 
> in a structure and are able to be managed in source code, and stored in 
> your own formats, either in your own library or in a custom "Scene" file.

  That would not give any way of adding new features to POV-Ray, so it's
not a viable solution.

-- 
                                                          - Warp

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> The libraries would be written in C++, like the rest. No need for
>> proprietary or non-free stuff.
> 
>> This would allow POV-Ray to be controlled by something else than
>> "official" SDL (in a more open architecture), though the normal user 
>> would only see SDL.
> 
>   How would the average user then use those libraries from the SDL?

He would not.  I mean : it would be transparent for the end user.
The "official SDL" parser will take that in charge.

where the user types...
  sphere {<0,0,0>,2 pigment {Red}}

...the parser makes the appropriate library calls to put a red sphere in
the scene.


If I understood well the model you are advocating, it's :
layer 0 : core rendering engine
layer 1 : unique SDL, powerful enough to allow users to add complex functionality,
           directly interfaced with layer 0
layer 2 : whatever people creates that makes use of the SDL

(please forgive, and correct if needed, any over-simplification, bad terminology...)

The "library" model would look like this :
layer 0 : core rendering engine
layer 1 : framework of libraries, providing interface to the core engine
layer 2 : official SDL, powerful enough to allow users to add complex functionality,
           parsing manipulates libraries
layer 2 (alternative) : another SDL, or direct control by a modeller, ...
layer 3 : whatever people creates that makes use of the SDL

about the "library" model :
pros :
  - more "open" architecture
  - allows (for competent people) adding complex functionalities with (probably) more
    power (speed) than an end-user SDL would allow, without touching the core engine,
though
  - transparent to the end user

cons :
  - adds another layer
  - risk of multiplying library sets and versions (but there's a similar risk for core
engine)

I think that what you (globally) envision for the SDL is the way to go (making it much
powerful that it currently is).  However there will be a compromise to find between
the
powerfulness (how far it can go) and user-friendliness (readability,
compatibility...),
and I think that having something between the core engine and the SDL would help ajust
the threshold without too much regrets.

Fabien.

Post a reply to this message

I was under the impression that the POV-Team sadly objects
to POV as a library backend and that this is even prohibited
by the distribution license, so the point seems to be moot.

Post a reply to this message

> I was under the impression that the POV-Team sadly objects
> to POV as a library backend and that this is even prohibited
> by the distribution license, so the point seems to be moot.

This was to prevent someone to "hide" POV-Ray and use it as a rendering
engine for their own application.

We are talking (at least, I hope it's clear for everyone) about the
future POV-Ray 4.0 which will have an open-source licence, so
these restrictions will fall.

Fabien.

Post a reply to this message

Bryan Valencia wrote:
> I've been following the "new language SDL" thread for a while, but I 
> don't know if this topic has been covered.
> 
> Having been a fan of Borland, and now a user of Visual Studio, I would 
> like to present the notion of using a language-independent framework, 
> like the .net framework and then document it so well that us users can 
> write our own front-end languages, a la Visual Basic, C#, J#, ASP.NET, etc.
> 
> So there would be the ".POV Framework" and then C#.POV, J#.POV, Visual 
> POV...
> 
> Also, if I want to create a post-processor library, or an animation 
> utility, or a complicated subroutine that can create a random moon for 
> example, then the compiled libraries could work with all the 
> implementations.
> 
> Maybe (and this is a big maybe) we could boil down the SDL to a set of 
> libraries that can be plugged in to Visual Studio, or used with Java or 
> Perl, etc.
> 
> 
> 
> I know this is a lot of work, but it would get the POV team out of the 
> language biz and let them focus on thing like rendering engines and 
> speed optimizations.
> 
> Sorry if this has been brought up previously, but I missed it if it was.
> 
> 

Personally, I like the SDL just the way it is... Simple, mostly 
predictable and easy to use... It has a few areas that could be 
improved, as noted in previous posts, but overall its served the 
community pretty well over the years...

I see no advantage to building "libraries" or porting it to other 
(propriatary) languages and complicating it.

"The more complicated the plumbing, the easier it is to stop it up." to 
quote Mr. Scott of Star Trek fame.

Post a reply to this message

Bryan Valencia nous apporta ses lumieres en ce 2007/10/03 16:50:
> I've been following the "new language SDL" thread for a while, but I 
> don't know if this topic has been covered.
> 
> Having been a fan of Borland, and now a user of Visual Studio, I would 
> like to present the notion of using a language-independent framework, 
> like the .net framework and then document it so well that us users can 
> write our own front-end languages, a la Visual Basic, C#, J#, ASP.NET, etc.
> 
> So there would be the ".POV Framework" and then C#.POV, J#.POV, Visual 
> POV...
> 
> Also, if I want to create a post-processor library, or an animation 
> utility, or a complicated subroutine that can create a random moon for 
> example, then the compiled libraries could work with all the 
> implementations.
> 
> Maybe (and this is a big maybe) we could boil down the SDL to a set of 
> libraries that can be plugged in to Visual Studio, or used with Java or 
> Perl, etc.
> 
> 
> 
> I know this is a lot of work, but it would get the POV team out of the 
> language biz and let them focus on thing like rendering engines and 
> speed optimizations.
> 
> Sorry if this has been brought up previously, but I missed it if it was.
> 
> 
You must make sure that the new, revamped SDL remain compatible with the actual 
SDL, and remain capable to render existing scenes. Some deprecated and obsolete 
"features" can be droped as were athmosphere and some others, but only you have 
some good justification for doing so.
This compatibility must be maintained due to the huge library of premade 
objects, textures, materials and various utilities distributed as .INC flies.
You also want to be able to render images from other peoples who may still be 
using the 3.x version when you use the 4.x, and them to render yours.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you keep a blacklist of people who 
ask questions about 3DFX products.
Alex McLeod a.k.a. Giant Robot Messiah

Post a reply to this message

On Wed, 03 Oct 2007 21:09:59 -0700, Darren New wrote:

> Mono is pretty
> good.

It has its good points and its bad points; I run openSUSE 10.2 here, and 
I can tell you that the ZMD stuff is painfully slow, and Beagle is 
horribly broken; both will bury the processor on my laptop.

For high-performance work like POVRay requires, I don't think it'd be the 
right solution.

Jim

Post a reply to this message

Alain a écrit :

> You must make sure that the new, revamped SDL remain compatible with the 
> actual SDL, and remain capable to render existing scenes.

That will be a big issue.

Personally, I think that, while it might be possible to keep a good
amount of compatibility, 100% backwards compatibility shouldn't block
POV-Ray's evolution.  Some things will have to be broken, for the best.

I think (but might be wrong) that writing some kind of converter, to take
care of what's been broken, should be preferred instead of making an half-baked
SDL for the sake of compatibility.

Compromises...

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >   How would the average user then use those libraries from the SDL?

> He would not.  I mean : it would be transparent for the end user.
> The "official SDL" parser will take that in charge.

  So what you are suggesting is that you can change the behavior of
existing features but you can't add new features?

  That would be rather useless.

-- 
                                                          - Warp

Post a reply to this message