 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] simberon com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
