 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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:
>> Thorsten Froehlich 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] free fr | 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
|
|
| |
| |
|
|
|
|
| |
|
|
