Hi,
I have a littlie future request / suggestion.
Problem :
If I want to i.e. center object I have to do soemthing like :

#declare obj = union { .....  }
object { obj translate (max_extent(obj)-min_extent(obj))/2 }

So it would be useful to declare keyword 'this' :

object { obj translate (max_extent(this)-min_extent(this))/2 }

so 'this' is currently declared object, like :

union {
  // 'this' is now an empty object
  sphere { 0 1 } // 'this' is now an sphere
  sphere { 0 5 } // 'this' is now an union of two spheres
  box { 0, 1
     // 'this' placed here - is only a box
  }
  // 'this' placed here - is union of 2 spheres an a box
}


-- 

Post a reply to this message

On 24 Jun 2002 02:03:22 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Hi,

Hi

> I have a littlie future request / suggestion.
> Problem :
> If I want to i.e. center object I have to do soemthing like :
>
> #declare obj = union { .....  }
> object { obj translate (max_extent(obj)-min_extent(obj))/2 }
>
> So it would be useful to declare keyword 'this' :

Isn't it also clear, fast and easy when you
just use Center_Object macro from 3.5 ?

ABX

Post a reply to this message

news:3ohdhus3ekhv13ts5fcmsvvps47330gqll@4ax.com: 

>> #declare obj = union { .....  }
>> object { obj translate (max_extent(obj)-min_extent(obj))/2 }
>> So it would be useful to declare keyword 'this' :
> Isn't it also clear, fast and easy when you
> just use Center_Object macro from 3.5 ?

ups, I gues i didnt notice it :)

but 'this' can be probably useful for other things, and It is probably easy 
to implement

-- 

Post a reply to this message

> > > #declare obj = union { .....  }
> > > object { obj translate (max_extent(obj)-min_extent(obj))/2 }
> > > So it would be useful to declare keyword 'this' :
> > Isn't it also clear, fast and easy when you
> > just use Center_Object macro from 3.5 ?
>
> ups, I gues i didnt notice it :)
>
> but 'this' can be probably useful for other things, and It is probably easy 
> to implement

Perhaps but even such simple thing like etents can be optimized when
calculated after object modifiers parsing. Using it inside object modifiers
could be hard before '}'. Moreover AFAIK extents are only properity available
for script.

BTW: it is always nice to meet fellow from Poland :-)

ABX

Post a reply to this message

Personally, I'd prefer "self"... ;-)
I don't think this would work, not with the current object syntax anyway.
If it is available at any point in the object block, then it would have to
be available at times when the object doesn't completely exist yet. There
would be an "invisible line" somewhere where the "self" identifier would
appear, you couldn't do this:

sphere {min_extent(self), 1}

And I'm not sure how CSG objects would handle it in between adding
objects, or meshes while adding triangles. Something like this might work
though:

object {
    sphere {...}
    "self" or "this" is defined in this level, but not in the shape
specification block itself, making sure there is a complete shape to
refer to.
}

Or if the shape parameters used a different syntax or always had default
values...it would be pretty much necessary for my idea of changing the
POV-Ray language into a prototype-based object oriented language.


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

> Moreover AFAIK extents are only properity available for script.

  You forget inside().

  (And perhaps also trace() could be in some way thought as a property of
the object...)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <pan### [at] maccom> , Christopher James
Huff <chr### [at] maccom>  wrote:

> I don't think this would work, not with the current object syntax anyway.
> If it is available at any point in the object block, then it would have to
> be available at times when the object doesn't completely exist yet.

While it would not only not work practically when implemented as a
parse-time variable, it is also not necessary if implemented as a
render-time variable - the scope and object are always known and
well-defined without ambiguity at that time!

    Thorsten

Post a reply to this message

On Mon, 24 Jun 2002 13:15:46 -0500, Thorsten Froehlich wrote:

> While it would not only not work practically when implemented as a
> parse-time variable, it is also not necessary if implemented as a
> render-time variable - the scope and object are always known and
> well-defined without ambiguity at that time!

Actually, I think it might work fine if everything has a default value
and is considered to exist at the opening { brace.
If that were so, this:
sphere {min_extent(self), 1}
would center the sphere on the min_extent of the default sphere. I don't
know what it would do for meshes or CSG though, and it might not give a
perfectly obvious result all the time...

I'm not sure what you are trying to say about implementing it as a
render-time variable...most of the uses I can think of for it are at
parse time.


-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: <chr### [at] tagpovrayorg>
WWW: http://homepage.mac.com/chrishuff/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote in 
news:pan### [at] maccom:

>> While it would not only not work practically when implemented as a
>> parse-time variable, it is also not necessary if implemented as a
>> render-time variable - the scope and object are always known and
>> well-defined without ambiguity at that time!
> Actually, I think it might work fine if everything has a default value
> and is considered to exist at the opening { brace.

> If that were so, this:
> sphere {min_extent(self), 1}
> would center the sphere on the min_extent of the default sphere. I don't
> know what it would do for meshes or CSG though, and it might not give a
> perfectly obvious result all the time...

I think that is rather easy to implement - even more - I could implement it 
my self - as pre-procesor, and I think that same algorithm will work for
new parser :

1. if You fond keyword 'this' in expresion 'zzz(this)' then 
1a. parse '#declare this_obj = xxx { yyy }' where xxx is type, and yyy are 
object modificers and parameters of object in with keyword 'this' was found
1b. change 'qqq zzz(this)' to 'object {this_obj qqq zzz(this_obj)'
and continue parsing
  qqq zzz(this) - this is last sentens, that was not completly paresed 
(because) 'this' was found while parsing it. 
  i.e.  translate <1,2,3> will be translated fully, and it would be part of
  yyy in  example above, and entrie
  translate min_extent(this) is qqq/xxx

  It should work, ie.:
union { sphere{1,2} sphere{0,1} translate min_extent(this) }
  would become
#declare this_obj = union { sphere{1,2} sphere{0,1} }
object { this_obj translate min_extent(this_obj) }

btw - Name 'this' or 'self' - maybe use both - for users that like C++ and 
thoes who like Pascal/Deplhi ;)





-- 

Post a reply to this message

On 24 Jun 2002 12:00:28 -0400, Warp <war### [at] tagpovrayorg> wrote:
> W?odzimierz ABX Skiba <abx### [at] babilonorg> wrote:
> > Moreover AFAIK extents are only properity available for script.
>
> You forget inside().

I consider inside() more as method. The same way eval_* for pigments and
patterns.

ABX

Post a reply to this message