POV-Ray : Newsgroups : povray.general : Status of Moray? : Re: New SDL for POVRay Server Time
2 Jul 2025 06:04:36 EDT (-0400)
  Re: New SDL for POVRay  
From: Darren New
Date: 14 Oct 2007 13:38:43
Message: <47125423@news.povray.org>
Patrick Elliott wrote:
> the issue isn't semantic, its associative. 

I'm not sure what your level of experience with programming is, but such 
things stop being problematic after a while.

 > Objects don't "usually", when they track some internal set
> of data, rely on purely external sources for storing it, simply because 
> that disassociates the data from the object that uses it.

Not if it's indexed by the object.

> ginger.copytransforms(fred)
> vs.
> ginger.applytrandforms(arbitrary_table)

Of course when you name one of them "fred" and the other 
"arbitrary_table", it's confusing. Don't do that.


I'm suggesting
   walking_transforms[ginger] = walking_transforms[fred].

Or even
   walking_transforms[ginger] = feminize(walking_transforms[fred])
or
   running_transforms[ginger] = walking_transforms[fred]

Then, eventually, you say
   ginger.apply(running_transforms[ginger])
   fred.apply(walking_transforms[fred])

If you have a set of global transforms (that always apply), you can
   extern function
     feminize(array of transforms) returns array of transforms;
   global_transforms[fred] = (....)
   global_transforms[ginger] = (....)
   frame_transforms[fred] = (clock*....)
   frame_transforms[ginger] = feminize(frame_transforms[fred])
   frame_transforms[freds_arm] = (rotate clock*y)
   ginger = object(...)
   fred = object(...)
   freds_arm = object(....)
   foreach object {ginger fred ...) {
     object.apply_transform(global_transforms[object])
     object.apply_transform(frame_transforms[object])
     object.render
   }
   freds_arm.apply_transform(global_transforms[fred])
   freds_arm.apply_transform(frame_transforms[fred])
   freds_arm.apply_transform(frame_transforms[freds_arm])


Maybe you should supply a similar bit of pseudo code showing a similar 
scene and show why your mechanism is more clear.

> The first one though is "associatively" clearer, even if its 
> semantically the same.

Except it only associates to the object. It doesn't "associate" what the 
*transform* is, only what object it applies to. Perhaps it's only clear 
to you.

Plus, if in your code, you have
   ginger.apply(walking_transforms[robot])
   fred.apply(walking_transforms[robot])
I think that's more clear than saying
   ginger.transforms = fred.transforms
because now you know they're both using the same
transforms and you know those transforms are
treating them both as robots.

 > And, even if you wanted to do that, there hasn't
> exactly been a discussion on how you a) structure such a table, 

It's structured the same way you'd structure yours, except it's a 
user-created object instead of a unique property defined by the 
renderer. This also has the advantage that you can (for example) pass it 
to user-defined functions without having to create an object just to 
carry it around.

> or b) get one out of, or into, an POVRay object that has subobjects. 

The same way you would.

> when you first did some_object(<location>,size(s)) Hardly helpful, if 
> you are trying to avoid having to redundantly store "every" change 
> needed to get from there to the final result.

I think if you want to argue that your syntax is superior to my syntax, 
while my syntax is more orthogonal and more flexible yet has similar 
semantics,

-- 
   Darren New / San Diego, CA, USA (PST)
     Remember the good old days, when we
     used to complain about cryptography
     being export-restricted?


Post a reply to this message

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