andrel <a_l### [at] hotmailcom> wrote:
> My suggestion for a 'new' language would be to have an as simple as 
> possible language (without loops and control structures)

  Bad idea. The new language should be more powerful, not less.

  For example, I envision that with the new language you could, for example,
create a function which opens and parses a JPEG2000 file and returns an
image map from it. Or that you could create render-time code with it (like
shaders and such) as well as post-processing code (which could very well
benefit from things like loops and control structures).

  The current user-defined functions are a step towards this goal (after
all, they can be evaluated at render-time, and you can even create loops
with them).

-- 
                                                          - Warp

Post a reply to this message

andrel wrote:
> My suggestion for a 'new' language would be to have an as simple
> as possible language (without loops and control structures) that
> is easy to parse for a machine but not necessarily for a human.
> Plus an easy way to integrate that with a front end, one of those
> should be a pov 3.6 style language. Or perhaps as the only front
> end, because if everybody can make his own language we may not be
> able to share our sources.

This would COMPLETELY DESTROY the way this community works. The language 
*must* be human-friendly.

===> Machine friendly scenario:
An advanced user would bypass the 3.6-like front end and create his own 
front-end which produces non-human-friendly code. The 3.6-like front-end 
would only be used by beginners.

A beginner asks, "How do I create an oriented area-light?"
The advanced user (ignorant of 3.6-like front-end) replies:
<start non-friendly code>5d$#34gs#$%3gf3$%$#</end>

===> Human friendly scenario:
An advanced user may write his own front-end, but that front end would 
communicate with the renderer in a human-friendly language. Users of all 
levels would be familiar with this human-friendly language.

A beginner asks, "How do I create an oriented area-light?"
The advanced user replies:
light_source { .....

  -Shay

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
>
> My suggestion for a 'new' language would be to have an as simple as
> possible language (without loops and control structures) that is easy to
> parse for a machine but not necessarily for a human. Plus an easy way to
> integrate that with a front end, one of those should be a pov 3.6 style
> language. Or perhaps as the only front end, because if everybody can
> make his own language we may not be able to share our sources.


I've used povray in the office to do some image processing of a sort that
was not available in any commercial software I know of.  I hand-coded the
routine in SDL.  I've also taken great joy in coding projects for fun like
flocking algorithms and a car race with AI drivers.   Need loops for that.


As to Chris' statement about the future license.  First of all, I say thanks
for all you have done-- I understand you're trying to avoid legal problems
associated with code contributed from folks who are no longer active on the
team.

But I'm surprised that you appeared to be more worried about OSI than GPL3.
Right now, some linux distros turn their nose at the current license, and I
thought you were already OSI-approved. Now I'd respect your choice either
way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
as "acceptance," wouldn't GPL3 suffice?
thanks.

Post a reply to this message

in news:46E### [at] hotmailcom andrel wrote:

> My suggestion for a 'new' language would be to have an as simple as 
> possible language (without loops and control structures) that is easy
> to parse for a machine but not necessarily for a human.

The one doesn't exclude the other imo. You could have a language that is 
easy for humans, preferably even easier than the current SDL. You can 
write in this language from any other language, as I do with Python and 
you with matlab. Now give this new, or even the current SDL the ability to 
rewrite itself, by unrolling all loops and structures (kinda parsing) and 
you have your machine version.

Eventhough we're talking about a raytracer, where every bit of speed is 
still essential, I'm happy with offering some of this speed to a human 
readable language.

Ingo

Post a reply to this message

Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> My suggestion for a 'new' language would be to have an as simple as 
>> possible language (without loops and control structures)
> 
>   Bad idea. The new language should be more powerful, not less.
> 
A small misunderstanding, I guess. What I proposed was to have a well 
defined low level language (think RISC) and on top of that a very user 
friendly one that directly communicates to the backbone.
That would separate the POV design into two more or less disjunct 
concerns. One with a focus on low level features and one with a focus on 
a user friendly interface. It is my experience that the set of people 
that are able to solve difficult mathematical problems and are able to 
implement those (provable) bugfree and understand the subtleties of 
language design is almost empty.
>   For example, I envision that with the new language you could, for example,
> create a function which opens and parses a JPEG2000 file and returns an
> image map from it. Or that you could create render-time code with it (like
> shaders and such) as well as post-processing code (which could very well
> benefit from things like loops and control structures).
> 
>   The current user-defined functions are a step towards this goal (after
> all, they can be evaluated at render-time, and you can even create loops
> with them).
>

Post a reply to this message

andrel wrote:
> A small misunderstanding, I guess. What I proposed was to have a well 
> defined low level language (think RISC) and on top of that a very user 
> friendly one that directly communicates to the backbone.

Perhaps something like a well-defined byte-code interpreter is what you
mean? With calls that allow access to all of the ABI?

I'd already raised the issue that I felt that a byte-coded (or JIT'd) back-
end to any SDL was necessary for speed. If this was exposed and formally
documented then, firstly, more or less any language could be used with it
(assuming someone wants to write the translator), and secondly, portability
is at least vaguely possible by providing a reverse-compiler that outputs
some form of 'standard' SDL (whatever we end up calling 'standard' is up to
question of course).

This wouldn't be ideal for portability as you'd lose comments and the code
may be unreadable (especially if the front-end optimized it), but it's
possible it's better than nothing.

Note I am not necessarily advocating doing this: I am merely pointing out
that it is possible.

-- Chris

Post a reply to this message

gregjohn wrote:
> But I'm surprised that you appeared to be more worried about OSI than GPL3.

Where do you get that from?

> way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
> as "acceptance," wouldn't GPL3 suffice?

IIRC this is exactly what I said.

-- Chris

Post a reply to this message

Chris Cason wrote:
> Warp wrote:
> 
>>  Does this mean that 4.0 will *not* have any kind of revised SDL language?
> 
> 
> I have to be realistic here and take the approach that attempting to write a
> new SDL prior to releasing the tree for folks to work on would not be
> practical. On the other hand, the existing parser has to be replaced since it
> is fairly cumbersome and hard to maintain.

How hard would it be to separate the parser and the renderer as much as 
possible, and thereby allow for both a parser based on the current SDL, 
and another parser based on an entirely different SDL (as well as a 
rendering engine that is not primarily a ray-tracer)?

Regards,
John

Post a reply to this message

gregjohn wrote:
> But I'm surprised that you appeared to be more worried about OSI than GPL3.
> Right now, some linux distros turn their nose at the current license, and I
> thought you were already OSI-approved. Now I'd respect your choice either
> way, but wondering why you'd strive for OSI if GPL3 were in the bag. As far
> as "acceptance," wouldn't GPL3 suffice?
> thanks.

OSI is a non-profit institution that owns the phrase "Open Source". If 
they "like" your license, then you can call your program Open Source. 
The current POV license does not meet the OSI's criteria to be called 
Open Source.

GPLv3 has not yet received the OSI's approval as an Open Source license, 
but it's pretty much a given that it will. The first two versions of the 
GPL, along with the BSD license (and possibly the MIT license), were 
what pretty much defined Open Source in the first place.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you start wishing you were 
actually in that futuristic mandelbrotian landscape you just rendered.
     -- fish-head

Post a reply to this message

Shay <Sha### [at] cccc> wrote:
> andrel wrote:
> > My suggestion for a 'new' language would be to have an as simple
> > as possible language (without loops and control structures) that
> > is easy to parse for a machine but not necessarily for a human.
> > Plus an easy way to integrate that with a front end, one of those
> > should be a pov 3.6 style language. Or perhaps as the only front
> > end, because if everybody can make his own language we may not be
> > able to share our sources.
>
> This would COMPLETELY DESTROY the way this community works. The language
> *must* be human-friendly.

I second that.  So far, I've not seen any other renderer out there with such
friendly and easy-going DSL like povray's SDL.  I hate the XML or structured
ones with no loops or conditionals.

I like Warp's proposal for Lua as the embedded language.  The language has
many strong points going for it, including being free software (MIT
license), easy integration to C/C++ code, simple, friendly syntax, powerful
and flexible constructs, and offers a very lightweight and fast interpreter.
 It even features the infamous tail call optimization from functional
languages!  Seems to have learned a lot from past Scheme, Tcl and Forth
experiments...

and last but not least, it was developed here in Brazil... :)

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> By the way, I have been reading the stuff Pixar has at
> http://graphics.pixar.com

wow!  wonderful collection of papers!  thanks for the link!

Post a reply to this message

My 2 cents...

I think that, prior to discussions about which approach should be
taken, we should create a dozen (or so) of typical simple scenes
which would include most typical SDL features (one with a loop, one
with a macro, one with textures, one with 'trace', etc...).

Each envisioned language and/or paradigm should be tested 'against'
these scenes, with sample would-be code.  This would allow, IMO,
better evaluation upon criterias such as features, powerfulness,
expandability, readability, user-friendliness, ease of implementation, etc...

Fabien.

Post a reply to this message

Shay a écrit :

> This would COMPLETELY DESTROY the way this community works. The language 
> *must* be human-friendly.

I second that.  In these days of point-and-click systems, people are already
frightened enough at the idea of *typing* something to get an image.  If
the language becomes human-unfriendly, the future of POV-Ray is, at best,
to become some other Blender-compliant rendering engine...

Fabien.

Post a reply to this message

Fa3ien wrote:
> My 2 cents...
> 
> I think that, prior to discussions about which approach should be
> taken, we should create a dozen (or so) of typical simple scenes
> which would include most typical SDL features (one with a loop, one
> with a macro, one with textures, one with 'trace', etc...).
> 
> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code.  This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of implementation,
> etc...

Very good idea!!!

	Thorsten

Post a reply to this message

David Buck schrieb:
> 
> I'm going to make a radical proposal for you to think over.
> 
> As POVRay's SDL has evolved over the years, it's become more and more 
> like a programming language.  I think it's worth considering pushing it 
> into a real programming language.
> 
> These days, I do most of my work in Smalltalk.  It's one of the simplest 
> yet most powerful programming languages around.
> [...]

The question of the general concept of a new SDL or extension of the 
existing one has already been discussed quite a lot (some of it in 
private) - although there has not been anything definite on the matter 
yet some important issues have crystallized that stand against your 
suggestion.

Anyone agrees that the current SDL lacks important features for coding 
more complex functionality and the current design significantly limits 
performance of SDL code interpretation.  Both together make it difficult 
to extend POV-Ray's features using the SDL.

Another problem of the current language is that the different levels of 
the language are difficult to understand for the beginner - the use of 
loops and macros in user defined functions being a good example.

But the most important thing is it needs to be straight away to do 
simple scenes using it.  Languages like Smalltalk appeal to the ones who 
know them because they are very consistent on the whole.  The price for 
this however is that even for the most simple tasks you need to 
understand most of the language's advanced concepts and this makes it 
fairly unsuited as a SDL.

In short:  Simple tasks like a reflective sphere over checkered plane 
need to be straight away to implement and to read - without knowing 
about language concepts.  Like in the current SDL version of such a 
simple scene the purpose of every token should be intuitively 
understandable.  More complex features of the language would need to be 
optional additions to this.

-- Christoph

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Warp wrote:
> > andrel <a_l### [at] hotmailcom> wrote:
> >> My suggestion for a 'new' language would be to have an as simple as 
> >> possible language (without loops and control structures)
> > 
> >   Bad idea. The new language should be more powerful, not less.
> > 
> A small misunderstanding, I guess. What I proposed was to have a well 
> defined low level language (think RISC)

  A RISC without loops and control structures? I still think it's a bad idea.

-- 
                                                          - Warp

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
>  It even features the infamous tail call optimization from functional
> languages!

  I believe the word "infamous" has a negative connotation to it. Was that
really what you wanted to express?-)

-- 
                                                          - Warp

Post a reply to this message

John VanSickle <evi### [at] hotmailcom> wrote:
> How hard would it be to separate the parser and the renderer as much as 
> possible, and thereby allow for both a parser based on the current SDL, 
> and another parser based on an entirely different SDL (as well as a 
> rendering engine that is not primarily a ray-tracer)?

  I'm not 100% sure that separating the parser from the renderer even
further is actually the right thing to do.

  It may sound rational because it would allow changing the parser easily.

  However, that's where the advantages end. The disadvantage is, however,
that it would limit the usability of the language *during rendering* even
more than the current SDL (which at least has user-defined functions which
can be evaluated during render-time).

  A separate "shader" language and a "post-processing" language would be
needed for enhanced functionality. That's already three separate languages
in one. Is that really what we want? Or do we want one language which can
be used for everything?

-- 
                                                          - Warp

Post a reply to this message

On Wed, 12 Sep 2007 07:27:16 -0400, Warp wrote:

>> A small misunderstanding, I guess. What I proposed was to have a well
>> defined low level language (think RISC)
> 
>   A RISC without loops and control structures?

IIRC (and I probably don't), unrolling loops (in particular) is an 
optimization; but at a low level, I don't necessarily see that as a bad 
idea myself.  But the high-level language does need these structures.

Jim

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> nemesis <nam### [at] gmailcom> wrote:
> >  It even features the infamous tail call optimization from functional
> > languages!
>
>   I believe the word "infamous" has a negative connotation to it. Was that
> really what you wanted to express?-)
>
> --
>                                                           - Warp

that was my half-assed attempt at a joke at replacing the term "famous". :P

obviously, tail call optimization is a very Good Thing!

Post a reply to this message

Jim Henderson <nos### [at] nospamcom> wrote:
> IIRC (and I probably don't), unrolling loops (in particular) is an 
> optimization;

  So how do you unroll a loop which depends eg. on the color of a pixel,
determined at rendertime?

-- 
                                                          - Warp

Post a reply to this message

in news:46e7797a$1@news.povray.org Fa3ien wrote:

> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code.  This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of
> implementation, etc... 
> 

I like that.

somewhat related, here is a link to something somebody did in Python to 
creat POV-Ray scenes. http://arrowtheory.com/software/python/pypov/
I did simmilar things myself and immediatly missed a built in vector <>.

ingo

Post a reply to this message

in news:Xns99A9CF023F162seed7@news.povray.org ingo wrote:

> somewhat related, here is a link to something somebody did in Python to 
> creat POV-Ray scenes. http://arrowtheory.com/software/python/pypov/
> 

I should not this was written for Python users, so it uses things not 
ovious for POV-Ray users like list comprehention. There is non need to use 
it that way.

ingo

Post a reply to this message

Jim Henderson wrote:
> On Wed, 12 Sep 2007 07:27:16 -0400, Warp wrote:
> 
>>> A small misunderstanding, I guess. What I proposed was to have a well
>>> defined low level language (think RISC)
>>   A RISC without loops and control structures?
> 
> IIRC (and I probably don't), unrolling loops (in particular) is an 
> optimization; but at a low level, I don't necessarily see that as a bad 
> idea myself.  But the high-level language does need these structures.
> 
That was indeed my suggestion. Add sophisticated control structures to a 
high level language and while executing that, fill a pipeline with 
objects and other necessary descriptions of the scene.

For what I mostly do that would be enough and I could even imagine that 
I would write my matlab programs in such a way that I could directly 
fill the pipeline. But I have never used complex textures, so I am not 
in a position to judge if you really need a full blown programing 
language to define those. Nor if that would be incompatible with such a 
pipeline.

Post a reply to this message

On Wed, 12 Sep 2007 13:38:41 -0400, Warp wrote:

> Jim Henderson <nos### [at] nospamcom> wrote:
>> IIRC (and I probably don't), unrolling loops (in particular) is an
>> optimization;
> 
>   So how do you unroll a loop which depends eg. on the color of a pixel,
> determined at rendertime?

I presume that would be done when the SDL is parsed and the colour was 
determined.  Just at a guess - I don't claim any expertise.

I think what andrel was getting at was not that users should code in 
tokenized form, but instead was suggesting a way that the developers 
might use the tokenized/bytecode generated from the parser.

Jim

Post a reply to this message

Warp wrote:
> Jim Henderson <nos### [at] nospamcom> wrote:
>> IIRC (and I probably don't), unrolling loops (in particular) is an 
>> optimization;
> 
>   So how do you unroll a loop which depends eg. on the color of a pixel,
> determined at rendertime?
> 
Interesting concept.
Trying to think of a situation where the presence of objects can only be 
determined during a render...
Failing...
I think that would imply that the order of evaluation would be relevant, 
which would make parallel rendering impossible.
Perhaps not a good example. But feel free to come up with another. I 
think such examples are vital in determining how intertwined the 
language has to be.

Perhaps one case could be that you want to create a marble bas relief by 
creating a displacement map from another scene.
Can I donate this one to Fabien's list?

Post a reply to this message

Le 12.09.2007 21:12, andrel nous fit lire :
> Warp wrote:
>> Jim Henderson <nos### [at] nospamcom> wrote:
>>> IIRC (and I probably don't), unrolling loops (in particular) is an
>>> optimization;
>>
>>   So how do you unroll a loop which depends eg. on the color of a pixel,
>> determined at rendertime?
>>
> Interesting concept.
> Trying to think of a situation where the presence of objects can only be
> determined during a render...
> Failing...

Have a look at trace function... In still parsing time, already
performing some rendering, usually to place some additional objects.

> I think that would imply that the order of evaluation would be relevant,
> which would make parallel rendering impossible.

There is parse time, and then render time.
But particule system just want to mix them...
And radiosity is another hell.

Of course, once parsed, a full scene could be output just as a
serialisation of all the objects in the scene.

But if you have some parameters for your scene, instead of accessing
only these parameters, you have to make each possible scenes...
Let's say you have a macro to generate a cubic cristal of spheres.
The parameter is the number of sphere per side of the cube. Just
three nested loops, one parameter.

Unroll them... and now what if you want a cube of 4 instead of a
cube of 3 ? A cube of 6 ?

-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Warp wrote:
>   However, that's where the advantages end. The disadvantage is, however,
> that it would limit the usability of the language *during rendering* even
> more than the current SDL (which at least has user-defined functions which
> can be evaluated during render-time).

I don't see why this sort of thing can't be implemented via callbacks or 
objects (we are using C++, so why not take advantage of it?).

Maybe I can say it more clearly this way: We could use some sort of 
event-driven architecture where the rendering engine fires off events to 
the script interpreter and gets instructions that way.

I would expect it would be possible to do something like this in a way 
that's almost invisible to the scripting language itself.

OTOH, I would expect a performance penalty for something like this, but 
I would also expect it to be fairly minor. Correct me if I'm wrong.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you spend more time 
"tweaking" a texture than modelling the rest of the scene.
     -- Twyst

Post a reply to this message

BTW, what I would really like is to see a half-dozen different prototype 
new SDLs appear as working prototypes that people can play with. After 
people have kicked the tires on them for a few months, at some point by 
consensus/vote/royal decree/Voice of God/whatever one of them would be 
"blessed" as the new official SDL.

It's a bit messy, but strikes me as *much* better than some 
design-by-committee monster.

Anyway, that's why I'd really like to get some decent separation between 
the parser and renderer code, within reason.

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you know a lot more about 
basic anatomy and proportions than the average person with a degree in 
fine arts.
     -- Quietly Watching

Post a reply to this message

On Wed, 12 Sep 2007 15:44:29 -0700, William Tracy wrote:

> OTOH, I would expect a performance penalty for something like this, but
> I would also expect it to be fairly minor. Correct me if I'm wrong.

Well, from a performance computing standpoint, remember that "minor" 
times a million/billion/trillion suddenly becomes something other than 
"minor". ;-)

Jim

Post a reply to this message

On Wed, 12 Sep 2007 15:51:55 -0700, William Tracy wrote:

> Anyway, that's why I'd really like to get some decent separation between
> the parser and renderer code, within reason.

That would certainly make writing import tools easier - the parser could 
essentially *be* the import tool (ISTR that that's what's often said 
about import/conversion tools - that you'd have to reimplement a 
significant portion of POV to get it working properly).  Something like 
Blender (which is also GPL - since we're talking POV under GPLv3 in 4.0) 
would really benefit from that.

Jim

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> Trying to think of a situation where the presence of objects can only be 
> determined during a render...

  Creating objects is not the only use for loops.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> andrel <a_l### [at] hotmailcom> wrote:
>> Trying to think of a situation where the presence of objects can only be 
>> determined during a render...
> 
>   Creating objects is not the only use for loops.
> 
I might be aware of that, but my question is: under what kind of 
circumstances would you need a user defined loop *after* you have fully 
specified the scene? I can't think of any, but I don't have much 
experience with shaders and complex textures.

Post a reply to this message

andrel <a_l### [at] hotmailcom> wrote:
> I might be aware of that, but my question is: under what kind of 
> circumstances would you need a user defined loop *after* you have fully 
> specified the scene? I can't think of any, but I don't have much 
> experience with shaders and complex textures.

  Loop over a series of pixels and calculate their average?

-- 
                                                          - Warp

Post a reply to this message

andrel a écrit :
> Interesting concept.
> Trying to think of a situation where the presence of objects can only be 
> determined during a render...
> Failing...

"trace" seems to me the most obvious example of "bi-directionality" between
the rendering engine and the scripting language.

(yeah, it's not during a render, it's during parsing, but it relies on data
  (result of an intersection computation) which should be given by the rendering
  engine)

Of course, that kind of feature could be extended to new possibilities, such
as the one evoked.

That's why, IMO, POV-Ray should been seen as a "rendering system", instead of
a "rendering engine fed by a script".

This doesn't mean the rendering engine and scripting system can't be separated
at code level (being able to develop other complete or partial scripting languages
would be great), but whatever interfacing system (bytecode, etc..) takes place
MUST be able to manage that kind of bi-directonality.

Fabien.

Post a reply to this message

Chris Cason a écrit :
> John VanSickle wrote:
>> By the way, I have been reading the stuff Pixar has at 
>> http://graphics.pixar.com , and some of it suggests improvements in the 
>> way that POV-Ray handles various kinds of anti-aliasing.  How open will 
>> the project be to changes of this nature?
> 
> Once the port is done and we have something stable, I'm entirely open to
> playing with new ideas. We may have a 'stable' and 'testing' tree for
> playing around with new ideas (with binaries released from each; probably
> the testing tree would get a nightly automatic build or something).

Why not start some "laboratory" groups right now ?  I mean, public groups,
where people could freely discuss many thing related to the future of POV-Ray,
in a constructive manner.

For example, there could be groups like :
"implementation of core engine"
"re-implementation of existing features"
"SDL evolution"
"C++ school" (where knowlegeable programmers would supervise motivated, but less
knowledgeable ones
  working as "little hands")
"texturing system"
"sample images re-write"
"documentation revision"
"feature requests" (where people could simply put ideas of new features or changes)
"documented feature request" (where people could say "hey, this could be added to
POV-Ray
  and there's a White Paper / GPL code availiable here / already done in
SuperPOV++0.7b
  and the guy who made it would be OK to help ...")

All this would form some kind of "knowledge base" and a helping community which would
be ready at appropriate time.

Fabien.

Post a reply to this message

Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> Why not start some "laboratory" groups right now ?

  That would be an interesting thing to try. If for nothing else, then to
see if it would work. (It's not like it would cost anyone anything, and it
can always be cancelled if it results that it's a bad idea.)

-- 
                                                          - Warp

Post a reply to this message

Fa3ien wrote:
> "C++ school" (where knowlegeable programmers would supervise motivated, 
> but less knowledgeable ones

Just curious, as someone who has never really looked at the POV code 
(yeah, I should really find this out myself): Is POV all C++ by now, or 
is there any actual C code left?

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

You know you've been raytracing too long when you post an idea to a news 
group about starting an Internet movie project using PovRay.
     -- Ken Tyler

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> > Why not start some "laboratory" groups right now ?
>
>   That would be an interesting thing to try. If for nothing else, then to
> see if it would work. (It's not like it would cost anyone anything, and it
> can always be cancelled if it results that it's a bad idea.)
>
> --
>                                                           - Warp

I'm all for getting my hands dirty! :)

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> Just curious, as someone who has never really looked at the POV code 
> (yeah, I should really find this out myself): Is POV all C++ by now, or 
> is there any actual C code left?

  How do you define that something is C and not C++?

  If what you mean is "is there still something left which is from the
old C code and which would have a much better C++ equivalent", then
I suppose there is.

-- 
                                                          - Warp

Post a reply to this message

Fa3ien wrote:
> andrel a écrit :
>> Interesting concept.
>> Trying to think of a situation where the presence of objects can only
>> be determined during a render...
>> Failing...
> 
> "trace" seems to me the most obvious example of "bi-directionality"
> between the rendering engine and the scripting language.
> 
> (yeah, it's not during a render, it's during parsing, but it relies on
> data (result of an intersection computation) which should be given by the
>  rendering engine)

Correct.

> Of course, that kind of feature could be extended to new possibilities, 
> such as the one evoked.
> 
> That's why, IMO, POV-Ray should been seen as a "rendering system", 
> instead of a "rendering engine fed by a script".

Exactly, though doing so on all levels is tricks with the current
implementation. I.e. that is why (isosurface) functions cannot access
declared arrays dynamically at render-time.

> This doesn't mean the rendering engine and scripting system can't be 
> separated at code level (being able to develop other complete or partial
> scripting languages would be great), but whatever interfacing system
> (bytecode, etc..) takes place MUST be able to manage that kind of
> bi-directonality.>

The solution to the parse vs render time limits would be to make all
features of a scene object replaceable by the user from within the language
- i.e. even replace the intersection algorithm or the transformation
computations. That would also put POV on-par with Renderman.

	Thorsten

Post a reply to this message

Le 14.09.2007 17:13, William Tracy nous fit lire :
> Fa3ien wrote:
>> "C++ school" (where knowlegeable programmers would supervise
>> motivated, but less knowledgeable ones
> 
> Just curious, as someone who has never really looked at the POV code
> (yeah, I should really find this out myself): Is POV all C++ by now, or
> is there any actual C code left?
> 
Have a look for yourself when source available.
In 3.6, it's just C in C++ disguise.
No clean object classes, No metaclasses, no hierarchies.


-- 
The superior man understands what is right;
the inferior man understands what will sell.
-- Confucius

Post a reply to this message

Le Forgeron <jgr### [at] freefr> wrote:
> Have a look for yourself when source available.
> In 3.6, it's just C in C++ disguise.
> No clean object classes, No metaclasses, no hierarchies.

  3.7 might not be perfectly-designed C++ because it still drags so
much code from 3.6, but much better.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Le Forgeron <jgr### [at] freefr> wrote:
>> Have a look for yourself when source available.
>> In 3.6, it's just C in C++ disguise.
>> No clean object classes, No metaclasses, no hierarchies.
> 
>   3.7 might not be perfectly-designed C++ because it still drags so
> much code from 3.6, but much better.

:-)

Yeah, I was curious if there were any actual .c files left. It sounds 
like there isn't, but there's some code in the dark corners that only 
halfway made it through the transition...

-- 
William Tracy
afi### [at] gmailcom wtr### [at] calpolyedu

"Jérôme M. Berger" <jeb### [at] freefr> wrote:
 > >  - Type 0 are tesselated dynamically during render time and the
 > > tesselation results are discarded immediately once the intersections
 > > are found. In particular, I noticed that POV accessed the u_order
 > > and v_order variables and repetitively called the DeCasteljau
 > > subdivision functions during intersection computations...

I see.

     -- Warp

Post a reply to this message

Thorsten Froehlich wrote:
> The solution to the parse vs render time limits would be to make all
> features of a scene object replaceable by the user from within the language
> - i.e. even replace the intersection algorithm or the transformation
> computations. That would also put POV on-par with Renderman.

That would be rather neat.

Post a reply to this message

Fa3ien wrote:
> I think that, prior to discussions about which approach should be
> taken, we should create a dozen (or so) of typical simple scenes
> which would include most typical SDL features (one with a loop, one
> with a macro, one with textures, one with 'trace', etc...).
> 
> Each envisioned language and/or paradigm should be tested 'against'
> these scenes, with sample would-be code.  This would allow, IMO,
> better evaluation upon criterias such as features, powerfulness,
> expandability, readability, user-friendliness, ease of implementation, etc...

I concur with the others - excellent idea.

-- Chris

Post a reply to this message

Christoph Hormann wrote:
> In short:  Simple tasks like a reflective sphere over checkered plane 
> need to be straight away to implement and to read - without knowing 
> about language concepts.  Like in the current SDL version of such a 
> simple scene the purpose of every token should be intuitively 
> understandable.  More complex features of the language would need to be 
> optional additions to this.

Putting this another way: POV-Ray's SDL grew from a simple means of
providing an object description to something that had many of the
traditional language constructs, while still retaining the ability to
define a scene in terms of objects with no 'programming' as such. This is a
Good Thing since it allows non-programmers to work with it and may have
been a significant factor in POV's acceptance.

Thus, I suspect it is desirable that any new 'official' SDL have the same
ability.

-- Chris

Post a reply to this message

Fa3ien wrote:
> Why not start some "laboratory" groups right now ?  I mean, public groups,
> where people could freely discuss many thing related to the future of POV-Ray,
> in a constructive manner.

I'm not opposed to this.

-- Chris

Post a reply to this message

William Tracy wrote:
> Yeah, I was curious if there were any actual .c files left. It sounds 
> like there isn't, but there's some code in the dark corners that only 
> halfway made it through the transition...

Even 3.6 has no .c files ... but 3.7 is much much (much) more object-
oriented. This was in part necessary due to the requirement to eliminate
(almost) all globals, as well as the fact that it's just easier to manage a
large codebase with you're dealing with encapsulated functionality.

-- Chris

Post a reply to this message

Chris Cason wrote:

> 
> Putting this another way: POV-Ray's SDL grew from a simple means of
> providing an object description to something that had many of the
> traditional language constructs, while still retaining the ability to
> define a scene in terms of objects with no 'programming' as such. This is
> a Good Thing since it allows non-programmers to work with it and may have
> been a significant factor in POV's acceptance.
> 
> Thus, I suspect it is desirable that any new 'official' SDL have the same
> ability.
> 
> -- Chris

Not even desirable, but, at least in my case, mandatory.
I know very little math and have no clue whatsoever about stuff like
isosurfaces and such, and absolutely no desire to learn a "real"[*]
programming language. What I do have however is a very good "internal eye"
which helps me see how I can create CSG-objects out of the primaries, box,
cylinder and sphere. With these limited resources I still manage to create
scenes with 100.000+ parts in it. I posted a mainboard render in 2005.


As an afterthought, while you guys are in the process of creating a new
language, please get rid of the "#" in front of some of the keywords. 
-- 
Ger

[*] With a real programming language I mean something that would resemble
C(++) or Object Pascal or ......

Post a reply to this message