"clipka" <nomail@nomail> wrote:
> Plus, I think it would be nice to have a feature as in JavaScript or Lua to take
> a string and interpret it as a piece of code.

I very nearly suggested the same myself when thinking about post-constructor
code, but decided to keep the proposition uncomplicated :o)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> > "clipka" <nomail@nomail> wrote:
> > > But even then I must say that I'd actually not like the syntax -
> > > for POV needs, it would mean an unreasonably large number of
> > > braces-inside-parentheses "({ ... })" where only one type of
> > > brackets would suffice; and a host of "new" statements which -
> > > as proven by current SDL - shouldn't really be necessary.
> > > Not to speak of all the colons (":").
> >
> > There's always the option of inserting a pre-processor into the pipeline,
>
> I guess I'm overusing the word in this thread, but: Yuck!
>
> That one would have to parse the language anyway, wouldn't it? I mean, as long
> as we intend it to increase conciseness instead of adding just more overhead.
>
> Plus, I think it would be nice to have a feature as in JavaScript or Lua to take
> a string and interpret it as a piece of code. A preprocessor wouldn't be able to
> catch that, and people would (righteously) complain why some language constructs
> don't work in that case.

While again not talking that seriously, Lisp macros are known to do just that:
create parsers for new languages with relatively ease.  For instance:

(define-syntax pigment
    (syntax-rules (color-map checker bozo granite marble)
      ((pigment "skel" str)
       (string-append "pigment {" str
                      "}\n"))
      ((pigment checker (x1 y1 z1) (x2 y2 z2))
       (pigment "skel"
         (let ((ns number->string))
           (string-append "checker rgb <" (ns x1)","(ns y1)","(ns z1)
                          "> rgb <" (ns x2)","(ns y2)","(ns z2)">"))))
      ((pigment checker c1 c2)
       (pigment "skel" (let ((ss symbol->string))
                         (string-append "checker color " (ss (quote c1)) " color
" (ss (quote c2))))))
      ((pigment color-map c1 c2 ...)
       (pigment "skel" (string-append "  color_map {\n" #\newline
                                      "  }\n")))))

This should be sufficient to generate a few well-known pattern of use:

> (display (pigment checker black white))
pigment {checker color black color white}
> (display (pigment checker (1 0 0) (0 0 1)))
pigment {checker rgb <1,0,0> rgb <0,0,1>}

Unfortunately, I'm out of time right now... :P

Post a reply to this message

clipka wrote:
> Yuck!
> 
> You really want to script scenes using statements like
> 
> scene.objects.MySphere.material.finish.pigment[2].pattern.translation +=
> <a,b,c>?
> 
> Not me!

This is fairly typical when interacting with the DOM in for instance 
JavaScript. Note that you can create variables that refer to entire 
branches in the tree and refer to them later using these variables. So 
you don't have to type out the entire address if you reference an item 
more than once.

i.e.

var MyPigment = scene.objects.MySphere.material.finish.pigment[2]

MyPigment.pattern.translation += <a,b,c>


> Can you give an example about how this separation would look like?
> 
> I guess I'm not getting the picture you're aiming at right now.

Basically what I mean is that the entire scene should be contained 
within a single DOM, and that one should be able to express it in 
shorthand notation.

i.e.

var MyObject =
{
	radius : 1,
	translation : [0,0,1]
}

is shorthand notation for:

var MyObject = new Object();
MyObject.radius = 1;
MyObject.translation = [0,0,1]


> The result of a strict separation can be seen for instance in various
> JavaScript-based dynamic HTML pages: Where content and behavior mix, web
> designers are forced to either include the behaviour with the content
> (JavaScript elements inside the HTML page), or pull some of the content into
> the behavior (separate JavaScript files generating HTML code "on the fly"). The
> result is an ugly hodgepodge of two entirely different languages.

In recent browsers at least, designers aren't "forced" to insert 
JavaScript inside HTML. In fact it's highly discouraged, and is more of 
a sign that the designer doesn't know how to work with proper DOM methods.

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> > Can you give an example about how this separation would look like?
> >
> > I guess I'm not getting the picture you're aiming at right now.
>
> Basically what I mean is that the entire scene should be contained
> within a single DOM, and that one should be able to express it in
> shorthand notation.
>
> i.e.
>
> var MyObject =
> {
>  radius : 1,
>  translation : [0,0,1]
> }
>
> is shorthand notation for:
>
> var MyObject = new Object();
> MyObject.radius = 1;
> MyObject.translation = [0,0,1]

So where exactly is there now a "separation"? I only see two different syntaxes
expressing the very same thing.

And I'm still waiting for someone to show me a language that provides a useful
shorthand notation for:

var MyObject = new Object();
MyObject.radius = 1;
MyObject.translation.append([0,0,1]);
MyObject.add(new Texture(...));
MyObject.translation.append([0,2,0]);

Post a reply to this message

clipka wrote:
> I just checked this, to find that what the construct will actually do is:
> 
> temp = new Object();
> temp.radius = 1;
> temp.position= [0,0,1];
> Sph = new Sphere(temp);
> 
> This also matches what the ISO ECMAScript specification implies.
> 
> So at the point e.g. the "position" property is set, it will still use the
> standard getter/setter mechanism of the basic Object type.
> 
> Furthermore, it will not act on the Sphere object at all - it will just create
> yet another object that will be passed as one single parameter to the Sphere
> object.

Could you explain what the Sphere object is doing?

-Mike

Post a reply to this message

clipka wrote:
> So where exactly is there now a "separation"? I only see two different syntaxes
> expressing the very same thing.

What I was trying to say is that objects in the scene tree should just 
have parameters (i.e. data) and no methods. Modifications to the tree 
would be done using methods/functions with global scope.

I think this would be "cleaner", but would be more like procedural 
programming and not like OO programming. I personally think that OO 
programming is too bulky, in that there are loads of "junk" items 
attached to each object and taking up memory that you are likely never 
to use.

> And I'm still waiting for someone to show me a language that provides a useful
> shorthand notation for:
> 
> var MyObject = new Object();
> MyObject.radius = 1;
> MyObject.translation.append([0,0,1]);
> MyObject.add(new Texture(...));
> MyObject.translation.append([0,2,0]);

AFAIK, what you are trying to do doesn't make "sense" according to a 
scripting language. I.e. the scripting language doesn't know that you 
want the latter translation to occur "after" the texture has been added. 
  It doesn't remember/behave differently based on the sequence of your 
commands. Further, this is something I would gladly see scrapped in any 
future SDL.

-Mike

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> > temp = new Object();
> > temp.radius = 1;
> > temp.position= [0,0,1];
> > Sph = new Sphere(temp);
> >
> > This also matches what the ISO ECMAScript specification implies.
> >
> > So at the point e.g. the "position" property is set, it will still use the
> > standard getter/setter mechanism of the basic Object type.
> >
> > Furthermore, it will not act on the Sphere object at all - it will just create
> > yet another object that will be passed as one single parameter to the Sphere
> > object.
>
> Could you explain what the Sphere object is doing?

Um... it's... representing a sphere, maybe?!

Sorry, I have no idea what you're heading for. I just translated that JavaScript
construct

    Sph = new Sphere({ radius:1, position:[0,0,1] });

to a form making it clearer what is really happening there, regarding scope and
such issues.

Post a reply to this message

SharkD <mik### [at] gmailcom> wrote:
> What I was trying to say is that objects in the scene tree should just
> have parameters (i.e. data) and no methods. Modifications to the tree
> would be done using methods/functions with global scope.
>
> I think this would be "cleaner", but would be more like procedural
> programming and not like OO programming. I personally think that OO
> programming is too bulky, in that there are loads of "junk" items
> attached to each object and taking up memory that you are likely never
> to use.

It does, on the other hand, clutter global space with "junk" that you're only
using in some particular context.

It also clutters up those global methods/functions with loads of exceptional
rules for how to deal with things. For instance, "translate(mySphere,v)" will
have to do some things different than "translate(myTexture,v)".

> > var MyObject = new Object();
> > MyObject.radius = 1;
> > MyObject.translation.append([0,0,1]);
> > MyObject.add(new Texture(...));
> > MyObject.translation.append([0,2,0]);
>
> AFAIK, what you are trying to do doesn't make "sense" according to a
> scripting language. I.e. the scripting language doesn't know that you
> want the latter translation to occur "after" the texture has been added.

Well, it's a *scripting* language after all, isn't it? Not a declarative one. So
things should happen sequentially.

>   It doesn't remember/behave differently based on the sequence of your
> commands. Further, this is something I would gladly see scrapped in any
> future SDL.

I *strongly* object!

Translation may be a weak example because it is easy to handle, but other
transformations may make my point stronger. Suppose for example that I want to
model a simple wooden ring: I may want the geometry to be a distorted torus;
but of course I do not want to distort the texture along with it, so what I do
in 3.x SDL is transform the geometry first, *then* apply the texture. Easy as
eating pancakes.

If a transformation would always affect the texture of the object, there would
be no way to do this - no easy one at least; I would have to apply an inverse
transformation to the texture to achieve the same, which is far from handy.

If on the other hand a transformation would never affect texture, then I would
have a hard time pushing that ring around the scene *together* with the texture
- which is the natural thing to do with finished objects.

There are even simpler cases when I would want to apply transformations
sequentialy: For instance, in some cases I want to *first* rotate an object
about the Z axis, *then* about the X axis, and *then* about the Y axis: The
math involved here is far from trivial; and in case I want to add a translation
step in between, it would get even uglier.

No, the sequential operation of transformations is a blessing, not a curse. If
you don't like it, feel free to leave it aside and always apply just one single
transformation to the assembled object. But other users will definitely want it.

Post a reply to this message

"clipka" <nomail@nomail> schreef in bericht 
news:web.49e29a91e7a64ad8d037e2230@news.povray.org...
>
> And I'm still waiting for someone to show me a language that provides a 
> useful
> shorthand notation for:
>
> var MyObject = new Object();
> MyObject.radius = 1;
> MyObject.translation.append([0,0,1]);
> MyObject.add(new Texture(...));
> MyObject.translation.append([0,2,0]);
>

What about something like this:

@type FunnySphere = sphere{
    pos  <1.56, 2.34, 1.67> = @FirstTrans
    rad  3.245
    scale  <2.03, 0.02, 4.58>
    trans  <1.00,  0.0, 2.00>
    trans  <0.0  ,  4.5,  0.0 > = @SecTrans;
    tex {........
            trans (FirstTrans + SecTrans)
          }
    }

I'm using the @ as shorthand for #local or #declare.
The difference lies in

@SecTrans= <0.0  ,  4.5,  0.0 >;

meaning: declare it for later use, so don't use it at this moment and

<0.0  ,  4.5,  0.0 > = @SecTrans;

meaning: use it now, but declare it for later use as well.
I think that the scope of FirstTrans and SecTrans should be inside this 
type-declaration only.

Because it may be possible with POV4 to create a new kind of object, the 
word "type" indicates the creation of some kind of new object. Maybe we 
don't need "@type", but I like it for its clarity.

Jaap Frank

Post a reply to this message

You might also want to take a look at SVG (Scalable Vector Graphics). 
It's very similar in many ways to POVray SDL.

-Mike

Post a reply to this message