SharkD <mik### [at] gmailcom> wrote:
> clipka wrote:
> > Hmm... at first glance I thought it could do the desired thing - but it can't.
> > How, for instance, would the following translate?
> >
> > sphere { <x,y,z>, r
> >     translate <a,b,c>
> >     pigment { ... }
> >     translate <d,e,f>
> > }
> >
> > Filing both translate statements as "translate" in the hash map would overwrite
> > the first of them. Just combining the two would fail to properly affect the
> > pigment.
>
> True, but in this case maybe it's better to force the user to substitute
> a better solution? I.e.:
>
>  scene.objects.MySphere.translation += <d,e,f>

Yuck!

You really want to script scenes using statements like

scene.objects.MySphere.material.finish.pigment[2].pattern.translation +=
<a,b,c>?

Not me!

Also note that below the hood, again with the sphere example in mind, this is
not just about changing the "translation" property of a geometric object - it
also must act on the "translation" properties of any patterns associated with
it at that very moment (e.g. pigment patterns).


> While having XML *and* a scripting language might be yucky, I think that
> using separate conventions for content and behavior is a *good idea*.
> And, hash arrays are good in this regard.

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.

Also note that functions must be part of the content (to allow for modelling
isosurfaces, function patterns and such), while at the same time they may come
in handy as part of the scripting, too. And as soon as you're using trace(),
you mix the two anyway.

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.

Therefore, I strongly advocate a single language to drive both form and
behavior, because in a lot of POV-Ray scenes behavior will be used to
auto-generate content.

It's a different thing when the intention is to script a scene for an animation.
However, in that case, nothing stops you as the user from separating content and
behavior by using include file mechanisms.

Post a reply to this message