 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel <a_l### [at] hotmail com> wrote:
> Yes but still not fast enough to me, unless I missed some.
With level 0 or 1 you don't even get basic shading, just the shapes of
objects in your scene. Couple that with a small resolution and enough CPU
and you get almost real-time-like rendering speed, even for complex scenes.
It'll get better if the SDL doesn't have to be reparsed each frame...
> I don't use the beta ;) .
I'm not saying that kind of visualization is planned, but it'd surely be
cool...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I started this thread by submitting some practical fragments of code, in
order to help thinking, with the corresponding syntax, and in order to make
things be formally expressed.
I already proposed something for higher level control structures (classes,
scenes, principles for relationship between class definition and POV-like
contructor syntax).
As I did not get any real feedback about that, do you consider I should
proceed to express POV4 syntax basics? It is too early to propose more
advanced features/syntax now, but I think we have enough material to go one
step further.
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> POV-Ray allows you to do that, not as a side-effect of the SDL, but
> precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
> already many nice and free pure renderers out there).
(Somewhat unrelated to your post specifically, ie. I'm not directly
replying to *you*, but I thought I post this somewhere, and this could
be a good place.)
I think some people are having a slight misconception about this whole
discussion. What they seem to see is some people talking about how to
create a "new" SDL which is more of a programming language, and they are
expressing their concern that this new SDL might not be so accessible to
non-programmers than the current SDL.
I think this is the complete opposite: It's *because* the new SDL
*must* be accessible to non-programmers why there's so much discussion.
If accessibility to non-programmers would not be a concern, then this
whole thing would be a lot easier: Just embed some LUA or AngelScript
into POV-Ray as its native scripting language, perhaps with some
enhancements and a library of auxiliary functions, and there you are.
However, precisely because some kind of "backwards compatibility" must
be preserved (in both syntax, as far as is possible, and ease-of-use)
that this is being discussed.
Thus all you who are worrying about the "new SDL" being some cryptic
high-end programming language only a few can understand, you have got
it completely wrong: Keeping the current ease-of-use and, as far as
possible, the same syntax, is a *major* concern in the designing of
the new SDL. You don't have to express your concern about this.
(Of course a different issue is whether there's enough manpower and
expertise to actually develop and implement such a language.)
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> POV-Ray allows you to do that, not as a side-effect of the SDL, but
>> precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
>> already many nice and free pure renderers out there).
>
> Thus all you who are worrying about the "new SDL" being some cryptic
> high-end programming language only a few can understand, you have got
> it completely wrong: Keeping the current ease-of-use and, as far as
> possible, the same syntax, is a *major* concern in the designing of
> the new SDL. You don't have to express your concern about this.
>
> (Of course a different issue is whether there's enough manpower and
> expertise to actually develop and implement such a language.)
>
When I have a few minutes here and there, I'm working on a technique
which retains the current SDL (with the possible exception of macros as
they currently exist) but makes it user-expandable. The POV SDL syntax
doesn't need to be the huge complex thing that it appears to be. For
example, consider the following snippet of SDL:
camera {
location <-5, 10, -15>
direction <0, 0, 2.25>
right x*1.33
look_at <0,0,0>
}
sky_sphere {
pigment {
gradient y
color_map {
[0, 1 color Gray50 color Gray80]
}
}
}
The parts of the syntax would include things like 1.33, <-5, 10, -15>,
{} and []. The rest of the identifiers name methods written in either
the SDL itself or a high level programming language.
The semantics would be something like:
camera
- call the camera method to:
- create an instance of a camera
- add it to the scene
{
- push it on the stack
location
- call the location method to:
- expect a vector parameter to follow
- apply to the top of stack (the camera)
}
- pop the stack
sky_sphere
- call the sky_sphere method to:
- create a sky_sphere
- add it to the scene
{
- push it on the stack
pigment
- call the pigment method to:
- create a new pigment
- apply it to the sky sphere
{
- push the pigment on the stack
etc...
The words like camera, location, pigment, and so forth are no longer
part of the syntax - they are methods that are called by the parser. To
add new functionality, you can add new methods which can be written in
either SDL or the high level programming language.
It seems to me like the whole SDL grammar can be modelled this way which
would give backwards compatibility as well as expandability.
Thoughts?
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck nous apporta ses lumieres en ce 2007/10/09 07:39:
> Warp wrote:
>> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>>> POV-Ray allows you to do that, not as a side-effect of the SDL, but
>>> precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
>>> already many nice and free pure renderers out there).
>>
>> Thus all you who are worrying about the "new SDL" being some cryptic
>> high-end programming language only a few can understand, you have got
>> it completely wrong: Keeping the current ease-of-use and, as far as
>> possible, the same syntax, is a *major* concern in the designing of
>> the new SDL. You don't have to express your concern about this.
>>
>> (Of course a different issue is whether there's enough manpower and
>> expertise to actually develop and implement such a language.)
>>
>
> When I have a few minutes here and there, I'm working on a technique
> which retains the current SDL (with the possible exception of macros as
> they currently exist) but makes it user-expandable. The POV SDL syntax
> doesn't need to be the huge complex thing that it appears to be. For
> example, consider the following snippet of SDL:
>
> camera {
> location <-5, 10, -15>
> direction <0, 0, 2.25>
> right x*1.33
> look_at <0,0,0>
> }
>
> sky_sphere {
> pigment {
> gradient y
> color_map {
> [0, 1 color Gray50 color Gray80]
> }
> }
> }
>
> The parts of the syntax would include things like 1.33, <-5, 10, -15>,
> {} and []. The rest of the identifiers name methods written in either
> the SDL itself or a high level programming language.
>
> The semantics would be something like:
>
> camera
> - call the camera method to:
> - create an instance of a camera
> - add it to the scene
> {
> - push it on the stack
>
> location
> - call the location method to:
> - expect a vector parameter to follow
> - apply to the top of stack (the camera)
>
> }
> - pop the stack
>
>
> sky_sphere
> - call the sky_sphere method to:
> - create a sky_sphere
> - add it to the scene
> {
> - push it on the stack
>
> pigment
> - call the pigment method to:
> - create a new pigment
> - apply it to the sky sphere
> {
> - push the pigment on the stack
>
> etc...
>
> The words like camera, location, pigment, and so forth are no longer
> part of the syntax - they are methods that are called by the parser. To
> add new functionality, you can add new methods which can be written in
> either SDL or the high level programming language.
>
> It seems to me like the whole SDL grammar can be modelled this way which
> would give backwards compatibility as well as expandability.
>
>
> Thoughts?
>
> David Buck
As long as it's transparent to the user. That is, the user don't see it unless
he want to.
--
Alain
-------------------------------------------------
Never frown, even when you are sad, because you never know who is falling in
love with your smile.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck <dav### [at] simberoncom> wrote:
> Warp wrote:
> > Fa3ien <fab### [at] yourshoesskynetbe> wrote:
> >> POV-Ray allows you to do that, not as a side-effect of the SDL, but
> >> precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
> >> already many nice and free pure renderers out there).
> >
> > Thus all you who are worrying about the "new SDL" being some cryptic
> > high-end programming language only a few can understand, you have got
> > it completely wrong: Keeping the current ease-of-use and, as far as
> > possible, the same syntax, is a *major* concern in the designing of
> > the new SDL. You don't have to express your concern about this.
> >
> > (Of course a different issue is whether there's enough manpower and
> > expertise to actually develop and implement such a language.)
> >
>
> When I have a few minutes here and there, I'm working on a technique
> which retains the current SDL (with the possible exception of macros as
> they currently exist) but makes it user-expandable. The POV SDL syntax
> doesn't need to be the huge complex thing that it appears to be. For
> example, consider the following snippet of SDL:
>
> camera {
> location <-5, 10, -15>
> direction <0, 0, 2.25>
> right x*1.33
> look_at <0,0,0>
> }
>
> sky_sphere {
> pigment {
> gradient y
> color_map {
> [0, 1 color Gray50 color Gray80]
> }
> }
> }
>
> The parts of the syntax would include things like 1.33, <-5, 10, -15>,
> {} and []. The rest of the identifiers name methods written in either
> the SDL itself or a high level programming language.
>
> The semantics would be something like:
>
> camera
> - call the camera method to:
> - create an instance of a camera
> - add it to the scene
> {
> - push it on the stack
>
> location
> - call the location method to:
> - expect a vector parameter to follow
> - apply to the top of stack (the camera)
>
> }
> - pop the stack
>
>
> sky_sphere
> - call the sky_sphere method to:
> - create a sky_sphere
> - add it to the scene
> {
> - push it on the stack
>
> pigment
> - call the pigment method to:
> - create a new pigment
> - apply it to the sky sphere
> {
> - push the pigment on the stack
>
> etc...
>
> The words like camera, location, pigment, and so forth are no longer
> part of the syntax - they are methods that are called by the parser. To
> add new functionality, you can add new methods which can be written in
> either SDL or the high level programming language.
>
> It seems to me like the whole SDL grammar can be modelled this way which
> would give backwards compatibility as well as expandability.
>
>
> Thoughts?
>
> David Buck
Hello David. Glad to see you.
I am not a compiler writer, but, correct me if I am on the wrong way (it's
sooo long ago), my memory reminds me that this is what happens naturally
when you write syntax-directed parser for LL(1) grammars. What you propose
seems to me like an uniformization of the grammar by means of something
like
block
{
property_name <value>
another_block {.... } // cannot be any block. Must be a compatible block
like 'pigment' in objects
<method_name> <parameter_list> // e.g. scale/rotate/translate
}
The stack you mention is simply the call-stack of the parser (let me have a
look at my compiler courses, poor me :o().
Bruno
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Only thing lacking, I guess, would be allowing the mouse to
> manipulate that render window by zooming in/out and rotating freely.
> Wouldn't that be a cool application for the real-time rendering in povray
> 3.7? :)
>
And I'd like not only mouse support, but also 3D mouse support:
http://www.3dconnexion.com/3dmouse/spacenavigator.php
There is a SDK...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck wrote:
> Warp wrote:
>> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>>> POV-Ray allows you to do that, not as a side-effect of the SDL, but
>>> precisely BY DESIGN. Drop that, and you kill POV-Ray (there are
>>> already many nice and free pure renderers out there).
>>
>> Thus all you who are worrying about the "new SDL" being some cryptic
>> high-end programming language only a few can understand, you have got
>> it completely wrong: Keeping the current ease-of-use and, as far as
>> possible, the same syntax, is a *major* concern in the designing of
>> the new SDL. You don't have to express your concern about this.
>>
>> (Of course a different issue is whether there's enough manpower and
>> expertise to actually develop and implement such a language.)
>>
>
> When I have a few minutes here and there, I'm working on a technique
> which retains the current SDL (with the possible exception of macros as
> they currently exist) but makes it user-expandable. The POV SDL syntax
> doesn't need to be the huge complex thing that it appears to be. For
> example, consider the following snippet of SDL:
>
> camera {
> location <-5, 10, -15>
> direction <0, 0, 2.25>
> right x*1.33
> look_at <0,0,0>
> }
>
> sky_sphere {
> pigment {
> gradient y
> color_map {
> [0, 1 color Gray50 color Gray80]
> }
> }
> }
>
> The parts of the syntax would include things like 1.33, <-5, 10, -15>,
> {} and []. The rest of the identifiers name methods written in either
> the SDL itself or a high level programming language.
>
> The semantics would be something like:
>
> camera
> - call the camera method to:
> - create an instance of a camera
> - add it to the scene
> {
> - push it on the stack
>
> location
> - call the location method to:
> - expect a vector parameter to follow
> - apply to the top of stack (the camera)
>
> }
> - pop the stack
>
>
> sky_sphere
> - call the sky_sphere method to:
> - create a sky_sphere
> - add it to the scene
> {
> - push it on the stack
>
> pigment
> - call the pigment method to:
> - create a new pigment
> - apply it to the sky sphere
> {
> - push the pigment on the stack
>
> etc...
>
> The words like camera, location, pigment, and so forth are no longer
> part of the syntax - they are methods that are called by the parser. To
> add new functionality, you can add new methods which can be written in
> either SDL or the high level programming language.
>
> It seems to me like the whole SDL grammar can be modelled this way which
> would give backwards compatibility as well as expandability.
>
>
> Thoughts?
Yes something like that. Not sure about the need for a stack here.
And I would suggest not to include the camera *in* the scene but have a
scene description and an output device, that may or may not be a camera,
that gets the scene as input.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> Yes something like that. Not sure about the need for a stack here.
> And I would suggest not to include the camera *in* the scene but have a
> scene description and an output device, that may or may not be a camera,
> that gets the scene as input.
I was trying to match the existing POV syntax. If you want to separate
the camera from the scene description, it would be trivial to do with
this approach.
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Bruno Cabasson wrote:
> Hello David. Glad to see you.
>
> I am not a compiler writer, but, correct me if I am on the wrong way (it's
> sooo long ago), my memory reminds me that this is what happens naturally
> when you write syntax-directed parser for LL(1) grammars.
This does indeed implement an LL grammar but the semantics don't happen
completely naturally. There's a little bit of magic under the covers.
My point, I suppose, is to say "stay away from a large formal grammar -
model it with a simple grammar supported by an extendable mechanism"
> What you propose
> seems to me like an uniformization of the grammar by means of something
> like
>
> block
> {
> property_name <value>
> another_block {.... } // cannot be any block. Must be a compatible block
> like 'pigment' in objects
> <method_name> <parameter_list> // e.g. scale/rotate/translate
> }
>
> The stack you mention is simply the call-stack of the parser (let me have a
> look at my compiler courses, poor me :o().
>
> Bruno
Yes, the stack is similar to a call-stack used by an LL parser. The
stack is needed to know which object to sent the messages to. Since you
can have {} braces within other {} braces, you need a stack to manage
the nesting.
David Buck
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
