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

SharkD <mik### [at] gmailcom> wrote:
> You might also want to take a look at SVG (Scalable Vector Graphics).
> It's very similar in many ways to POVray SDL.

It *may* be similar in what it's good for - but being XML it's definitely not an
option: Too much of a hassle typing it (or reading it, for that matter).

Post a reply to this message

I'm working on my own little raytracer to play with, and I know some programming
languages, and *yes* povray one.

I've designed a little language, and interpreter (VM) using flex, bison, gcc and
those gnu tools. Most of simple lang is working ok, but I would like an approach
like this:
-------------------------------------

$camera = ::renderer.camera

with( $camera){
 .loc =  <2, 5, -10>
 .lookat = <0>
}

with ( new Lit() ){
 .loc = <0, -10, 0>
 .color = <1.0>
}

//u can create objects and directly assign'em values. Note there is not
//variables, object references or whatever, in some povray-ish manner
with ( new Sphere() ){
 .geom = <0>, 5
 .pigment = <1.0,0.0,0.0>
}

//or took the traditional more programming approach
$obj_sphere = new Sphere()
with( $obj_sphere){
 .geom = <15, 0, 0>, 2
}

//just decided to let this, for animations. Maybe would be ok on a for loop
::renderer.render()
----------------------------------------------
i think it's ok, this is just one of the things i've working right now, and it
has not too hard to do.





"clipka" <nomail@nomail> wrote:
> "MessyBlob" <nomail@nomail> wrote:
> >
> > Doesn't JavaScript have the ability to assign properties to objects as they are
> > being instantiated?, e.g.
> >
> > Sph = new Sphere( {
> >   radius: 1,
> >   position: [0,0,1]
> > } );
>
> A host of languages has this.
>
> The problem is still the scope: However you toss and turn it, you can't just go
> ahead and do some stuff in the new object's scope (or "namespace" or however
> you want to call it) without some added hassle.
>
> The problem is that all mainstream languages do initialization of an object by
> passing some expressions as parameters, with the expressions being evaluated in
> the scope of the calling block. Plus they're evaluated before the object is
> created, so can't have side effects on the object.

Post a reply to this message