Warp wrote:
>   I'm not sure I have any reason to, but what I fear is that once the
> developement of POV-Ray becomes completely open, if it so happens that
> nobody takes the role of strong leader ("dictator") or nobody is accepted
> as such, what will happen is that there will be too many cooks spoiling
> the broth and no general agreement is ever reached over which kind of
> scripting language should be adopted and implemented. Even if an attempt

Well, it is my hope that whatever is released as 'official' by povray.org
will be accepted as official.

I do accept (and it has been my concern for many years, hence e.g. the
requirements for '.unofficial' in non-standard SDL's) that without a
standard for the language, it will diverge into various incompatible
derivatives. Hence, I may well want to take the stance that anything that
uses the 'POV-Ray' name has to comply with certain requirements regarding
the language. Not sure exactly what these would be, it's something we can
work out later.

>   3) I would say the most likely scenario: Someone will embed an existing
> scripting language (such as LUA) as an *alternative* to the existing SDL.

I have had a look at a few embeddable languages, such as AngelCode (see
http://www.angelcode.com/angelscript/) but haven't come to any solid
conclusion yet.

I will comment however that it's probable that we would want to take an
existing library and modify it (if necessary) to suit, rather than writing
something entirely new. I would expect that whatever language we use, it
would require some modification, since expressing POV vectors and so forth
would become too cumbersome otherwise.

>   The main reason for the need for a new scripting language is that the
> current SDL is very limited (and slow). There are things which are simply
> impossible to do. Thus making a prototype of a more flexible and powerful
> language which is then simply converted into existing SDL would not be
> possible.

I think it's important that any new SDL be at least P-coded, if not fully
JIT'd on platforms that support it. The latter would be handy in particular
for user-defined shaders. And also note that as a GPL'd program, we can use
portions of the GCC suite as needed.

-- Chris

Post a reply to this message

John VanSickle wrote:
> What help with re-licensing do you need from those of us who have made 
> code contributions?

If we can clearly identify your contribution, and it is stand-alone, then
an assignment form stating it's released under the GPL3 would be needed.

Apart from that, help in re-coding the existing code would be great ;]

-- Chris

Post a reply to this message

Woody wrote:
> I did C++ coding in college, only about 4 years ago. I still remember most
> of the concepts related to OOP i.e. pointers datatypes stacks ques
> struct/typedef, althought my syntax may have gotten a bit rusty. I use
> mostly VBA now for work. I don't know if this counts as reasonable, but if
> it does, let me know what I can do to help.

That's fine. As long as you can read the existing code and use the same C++
concepts as it uses in re-implementing it, then you're right.

I'll post an example of some code in a new thread shortly.

-- Chris

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Larry Hudson wrote:
> Jérôme M. Berger wrote:
>> Thorsten Froehlich wrote:
>>
>>> Jérôme M. Berger wrote:
>>>
>>>> Because of this, they have a
>>>> syntax that is *very* easy to parse for a computer (as an example,
>>>> the XML grammar fits in about 200 lines, whereas the C grammar takes
>>>> over 400 lines (and that's *without* the preprocessor!)
>>>
>>> No XML is better discussion (not sure if that is your argument or not),
>>> please, those lead nowhere. XML being easy to parse is not an
>>> argument for
>>> anybody who knows something about (programming) language theory - the
>>> complexity of a grammar* isn't defined by the name of the language
>>> after all ;-)
>>>
>>
>>     I don't understand your answer so I can't really answer to it, but
>> I'll try to clarify my post:
>> ...
> I also found Thorsten's opening sentence confusing, but I was finally
> able to parse it as meaning:
>      No "XML is better" discussion, please...
> 
	Thanks for the translation ;) Then I can answer Thorsten: No, that
wasn't my argument. I firmly believe that XML would be a poor choice
given the goals pursued by POVRay. As I explained, XML was designed
to be an exchange format between different softwares. As such, it is
intended to be generated by a computer program, not hand-typed. This
is quite incompatible with the idea that POVray scenes are primarily
written by hand.

	XML has its uses, but replacing the POV SDL most emphatically is
*not* one of them.

		Jerome
- --
+------------------------- Jerome M. BERGER ---------------------+
|    mailto:jeb### [at] freefr      | ICQ:    238062172            |
|    http://jeberger.free.fr/     | Jabber: jeb### [at] jabberfr   |
+---------------------------------+------------------------------+
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFG5Ym2d0kWM4JG3k8RAoMbAJ4uiJyqloRfW8XK/Q6RYujbrG6Z+QCfcZ1v
z5Y1l4iHGh+ZDix1dzDWT4g=
=3Fwk
-----END PGP SIGNATURE-----

Post a reply to this message

Chris Cason wrote:
> John VanSickle wrote:
> 
>>What help with re-licensing do you need from those of us who have made 
>>code contributions?
> 
> 
> If we can clearly identify your contribution, and it is stand-alone, then
> an assignment form stating it's released under the GPL3 would be needed.
> 
> Apart from that, help in re-coding the existing code would be great ;]

No problem, as long as I can find the time.

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?

Regards,
John

Post a reply to this message

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

-- Chris

Post a reply to this message

Chris Cason wrote:
> I have had a look at a few embeddable languages, such as AngelCode (see
> http://www.angelcode.com/angelscript/) but haven't come to any solid
> conclusion yet.

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.  Building a Smalltalk 
compiler/interpreter is not terribly hard (I've done it before) and if 
you wish, there are commercial systems (and freeware systems) which you 
can already use.  The commercial system have "free for non-commercial" 
licenses.

A few years ago, I built a simple little raytracer in Smalltalk to see 
what it would be like.  Here's what the scene description code looks 
like in this system (The code below is extracted directly from that 
reaytracer and it renders an actual image.):

"This method renders a scene and displays it in a window"
view
	self show: self renderImage


"This method renders the image"
renderImage
	^(self camera)
		imageSize: 640 , 480;
		render: self scene

"Here is the definition of the camera"
camera
	^(Camera new)
		location: 0 , 2 , -10;
		direction: 0 , 0 , 1;
		up: 0 , 1 , 0;
		right: 1.333 , 0 , 0


"And here is the scene"
scene
	^(Scene new)
		lightSource: self lightSource;
		shape: self floor;
		shape: self sphere1;
		shape: self sphere2

"The definition of the light source"
lightSource
	^(LightSource new)
		location: 10 , 20 , -20;
		color: Vector white

"Here's the floor"
floor
	^(Plane new)
		normal: 0 , 1 , 0;
		offset: 1;
		texture: self floorTexture

"We need the floorTexture"
floorTexture
	^(TextureWithFinish new)
		pigment: self checkerBoardPigment;
		finish: self reflectingFloorFinish

"And the checkerBoardPigment"
checkerBoardPigment
	^(CheckerBoardPigment new)
		center: 0 , 0.1 , 0;
		color1: Vector green;
		color2: Vector white;
		squareSize: 1

"The reflectingFloorFinish makes it reflect"
reflectingFloorFinish
	^(CompoundFinish new)
		finish: self floorFinish;
		finish: self fullReflectionFinish



I'll leave it at that for now.

By doing this, you can make libraries of textures, shapes, finishes, 
light sources, etc. which can be reused.  The definition of an entire 
scene could exist in one class and could re-use common textures, shapes, 
etc.  You have the full power of Smalltalk to build the shapes including 
loops, conditions, random numbers, importing data from files, writing 
out files, etc.  You also have the full power of the development 
environment when running including inspecting your scenes and debugging 
the rendering.

I know this is coming from left field, but it's good to think about some 
radical ideas every once in a while to really inspire innovation.

Discussion is welcome.

David Buck

Post a reply to this message

David Buck wrote:
> Chris Cason wrote:
>> I have had a look at a few embeddable languages, such as AngelCode (see
>> http://www.angelcode.com/angelscript/) but haven't come to any solid
>> conclusion yet.
> 
> 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.  Building a Smalltalk 
> compiler/interpreter is not terribly hard (I've done it before) and if 
> you wish, there are commercial systems (and freeware systems) which you 
> can already use.  The commercial system have "free for non-commercial" 
> licenses.
> 
> A few years ago, I built a simple little raytracer in Smalltalk to see 
> what it would be like.  Here's what the scene description code looks 
> like in this system (The code below is extracted directly from that 
> reaytracer and it renders an actual image.):
> 
> "This method renders a scene and displays it in a window"
> view
>     self show: self renderImage
> 

[snip rest of smalltalk code]

> 
> I'll leave it at that for now.
> 
> By doing this, you can make libraries of textures, shapes, finishes, 
> light sources, etc. which can be reused.  The definition of an entire 
> scene could exist in one class and could re-use common textures, shapes, 
> etc.  You have the full power of Smalltalk to build the shapes including 
> loops, conditions, random numbers, importing data from files, writing 
> out files, etc.  You also have the full power of the development 
> environment when running including inspecting your scenes and debugging 
> the rendering.
> 
> I know this is coming from left field, but it's good to think about some 
> radical ideas every once in a while to really inspire innovation.
> 
> Discussion is welcome.
> 
Is there any reason why your smalltalk could not automagically output 
SDL and renderImage be implemented as a system call to POV?
Because that is basically the way I use it in matlab, and want to 
continue to do so in POV 4.0

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.

Post a reply to this message

andrel wrote:
> David Buck wrote:
>> Chris Cason wrote:
>>> I have had a look at a few embeddable languages, such as AngelCode (see
>>> http://www.angelcode.com/angelscript/) but haven't come to any solid
>>> conclusion yet.
>>
>> 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.
>>
> Is there any reason why your smalltalk could not automagically output 
> SDL and renderImage be implemented as a system call to POV?
> Because that is basically the way I use it in matlab, and want to 
> continue to do so in POV 4.0
> 
> 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.
> 

There's no reason why we couldn't do that.  The advantage we get from 
the Smalltalk side, though, is being able to procedurally define new 
shaders right within the SDL.  With this scheme, if I wanted a variation 
of Marble, I could code it in Smalltalk and have it called as needed 
from the renderer.  With the existing structure of POVRay, you'd have to 
modify the C source and enhance the SDL accordingly in order to create a 
new shader - way too much work.

David Buck

Post a reply to this message

David Buck <dav### [at] simberoncom> wrote:
> These days, I do most of my work in Smalltalk.  It's one of the simplest 
> yet most powerful programming languages around.  Building a Smalltalk 
> compiler/interpreter is not terribly hard (I've done it before) and if 
> you wish, there are commercial systems (and freeware systems) which you 
> can already use.

  While a new SDL should definitely have strong tools for abstraction
(object-orientedness being one good choice for this), it should still
retain the simple procedural approach of the current SDL. Procedural
programming is the easiest to learn quickly.

  As I see it, there are two possibilities:

1) Design a scripting language fine-tuned from the ground up for use
with POV-Ray.

2) If an existing language is used instead, it makes no sense to have to
write a parser for it, but it would be a much better idea to use an
existing parser (and bytecode interpreter VM) which has been specifically
designed to be integrated in C++ programs (such as lua or angelscript).

  As I see it, it makes little sense to use an existing language which
has not been designed for POV-Ray and which has not been designed for
integration with C++. It will simply cause more problems than it's worth.
If the language lacks an easily-approachable procedural programming paradigm,
all the worse. (With this I don't mean that the language should not have
OOP support.)

> The commercial system have "free for non-commercial" 
> licenses.

  Yet I believe POV-Ray 4.0 is still planned to be free to use even for
commercial purposes.

-- 
                                                          - Warp

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)

  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