POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
13 Jul 2025 15:33:51 EDT (-0400)
  Re: New SDL for POVRay  
From: Bruno Cabasson
Date: 6 Oct 2007 18:55:00
Message: <web.4708112ce7dc742890965fe80@news.povray.org>
Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:

> > Nicolas Alvarez <nic### [at] gmailisthebestcom> wrote:
> >
> >> Also, how would you handle this?
> >> sphere {
> >>     <1,2,3>, 0.5
> >>     translate <12,35,61>
> >>     texture { some_complex_texture }
> >>     translate y*2
> >> }
> >> The first translate doesn't affect the texture, the second does.
> >>
> >
> > Just like POV does (correct me if I am wrong): when translate is encountered
> > it translates the whole object. At the time of first translate, no texture
> > is specified yet (=null, I suppose). At the time of the second the sphere's
> > 'texture' field is non-null, thus transformed with the object. The final
> > state is that de texture has been translated twice.
> >
> > In new SDL, it would be the same: the translate() method (or whatever it
> > will be) of an object (or its derived) will apply on whatever there is
> > inside the current object. You could have also written
> >
> >  sphere {
> >      <1,2,3>, 0.5
> >      translate <12,35,61>
> >      texture { some_complex_texture translate 100*x}
> >      translate y*2
> >  }
> >
> > with 3 translations for the texture.
> >
> > Bruno
> >
> >
> You missed my point (because I didn't make it so clear :P). How would
> you handle that *and* allow syntax like this?
>
> sphere.translate[0]="<5,0,0>"
>
> I think it's a bad idea to allow changing individual transformation
> statements after the object has been created.

Maybe it's me who did not understand well ;o)

However, my vision of things is that the MyObjectType { } block could be a
notational/convenience shortcut, as close to current syntax as possible (at
least obeing the same notational principles), for a 'constructor' in the
sense of 'creating a new object of a specific king with specific
characteristics you valuate'.

What we could decided right now by people here, is: would it be possible to
change charateristics of an object AFTER its creation, displacing it,
changing its texture, or performing specific operations (some basic
mesh-editng ...?)?

We caould have something like:

YES --> Form 1:
my_stool = Stool
{
    <stool class properties, that were not defaulted in class definition>
    < or overridden properties>
}
..../...
my_stool.to_mesh();
my_stool.some_mesh_editing_feature();
my_stool.smooth(); // It's a mesh now

NO --> Form 2:
my_stool = Stool
{
    <stool class properties, that were not defaulted in class definition>
    < or overridden properties>
    to_mesh();

    // It's a mesh now, so, it inhertits mesh methods
    some_mesh_editing_feature();
    smooth();
}

The second form would allow method calls within the creation block, and the
syntax would be more likely not to allow any further modification outside
this block(= after creation). Thinking of that while typing these lines, I
prefer Form 2.

Remark: a new syntax (or whatsoever) cannot be mature at first try. We will
have to make several rounds before the new syntax is considered as
'usable'. My experience is that nothing is really OK before version 3.
Version 1 is a first attempt to have 'all together', version 2 often
implies changes in the approach and many modifications corrections making
the system 'work', version 3 is the one that makes 'all together' AND
'working' AND 'quite fine'.

Bruno


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.