How difficult would it be to allow SDL access to predeclared objects?  Ie,
you'd use something like this:

#declare obj = firstObject;

// obj is now a reference to the first declared object

#declare loc = obj.location;
#declare pig = obj.texture.pigment;
#declare med = obj.interior.media;
#declare shine = obj.texture.finish.specular;

// The above would be access to the referenced variables.

#declare obj = nextObject;

// And continue with the rest

I'm not interested in changing the objects already declared, just in getting
information about them.  I don't see that there would be any technical
difficulties, and it would be hugely advantageous for particle simulations,
among other things.

Any thoughts?

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message

On Mon, 22 Mar 2004 10:04:40 -0800, "Chambers" <bdc### [at] yahoocom> wrote:
> How difficult would it be to allow SDL access to predeclared objects?

Not difficoult at all if you encapsulate input data and object in one
structure and operate on it.
http://news.povray.org/povray.advanced-users/thread/%3C6lpkut0vdh0h6gljr7u2v4mip6olddkmel%404ax.com%3E/

ABX

Post a reply to this message

In article <405f2a3f$1@news.povray.org> , "Chambers" 
<bdc### [at] yahoocom> wrote:

> How difficult would it be to allow SDL access to predeclared objects?  Ie,
> you'd use something like this:

Using the syntax you suggest, or any snytax for that matter: Impossible for
a practical implementation.  It would require duplicating most of the parser
code, and even then not every keyword is actually stored, so you could still
not access everything.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:uqau509fp9s1aq67kkr6buhg3amup6lc0h@4ax.com...
> On Mon, 22 Mar 2004 10:04:40 -0800, "Chambers" <bdc### [at] yahoocom>
wrote:
> > How difficult would it be to allow SDL access to predeclared objects?
>
> Not difficoult at all if you encapsulate input data and object in one
> structure and operate on it.
>
http://news.povray.org/povray.advanced-users/thread/%3C6lpkut0vdh0h6gljr7u2v4mip6olddkmel%404ax.com%3E/

Hmm, I've used a similar method, but this again requires that you declare
your objects in #declare 's and then operate on those.

Say we have the following:

sphere {0,1 pigment {color red 1} }

#declare struct=array[3];
#declare struct[0]=sphere{y*2,1 pigment {color blue 1} }
#declare struct[1]=finish {reflection 1};
#declare struct[2]=sphere{x*2,1 pigment {color green 1} }

(I know it's a crude example, but let's keep things simple :)

OK, now in the struct we have two spheres and a finish because we declared
them.  Fine, we can access those.  For the purposes of the example, let's
say I'm doing collision detection (though this would be useful for much more
than that).  I can check against the blue and green spheres as parts of the
struct.  However, how can I check for collision against the red sphere?  In
fact, how do I know there aren't other objects in the scene that aren't part
of the struct?  I'd like a method for POV-Ray to let me *see* them (but not
necessarily change them) and their internal data.

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message

In article <405f2a3f$1@news.povray.org>,
 "Chambers" <bdc### [at] yahoocom> wrote:

> How difficult would it be to allow SDL access to predeclared objects?  Ie,
> you'd use something like this:
> 
> #declare obj = firstObject;
> 
> // obj is now a reference to the first declared object
> 
> #declare loc = obj.location;

obj has a location? What's the location of an infinite plane? Or a julia 
fractal?


> #declare pig = obj.texture.pigment;
> #declare med = obj.interior.media;

Which media? You can have more than one.


> #declare shine = obj.texture.finish.specular;

And which texture? What if the object has layered textures?


> I'm not interested in changing the objects already declared, just in getting
> information about them.  I don't see that there would be any technical
> difficulties, and it would be hugely advantageous for particle simulations,
> among other things.

It would require writing a lot of special code for each object type, and 
as already mentioned, the specified object parameters may no longer 
exist in the same form, and some things can exist in multiple forms. You 
could parse objects into an intermediate structure to avoid that 
problem, and make it a structure of the script language to allow both 
reading as in your examples and modification. This would be the best 
way, but would be a large amount of work. It would be useful in other 
ways though, if one were able to define custom structures. It wouldn't 
need to be a full fledged object oriented system, but that would really 
help.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-6795B5.07440523032004@news.povray.org...
> In article <405f2a3f$1@news.povray.org>,
>  "Chambers" <bdc### [at] yahoocom> wrote:
>
> > How difficult would it be to allow SDL access to predeclared objects?
Ie,
> > you'd use something like this:
> >
> > #declare obj = firstObject;
> >
> > // obj is now a reference to the first declared object
> >
> > #declare loc = obj.location;
>
> obj has a location? What's the location of an infinite plane? Or a julia
> fractal?

The location of all objects is <0,0,0> until acted on by translations /
rotations.  The final location is the sum of these transformations.

> > #declare pig = obj.texture.pigment;
> > #declare med = obj.interior.media;
>
> Which media? You can have more than one.

True.  Multiple textures / medias aren't something I tend to go for,
though - I prefer a nice ordered hierarchy.  Of course, that doesn't mean it
isn't possible, and any solution would need to account for that.

> > I'm not interested in changing the objects already declared, just in
getting
> > information about them.  I don't see that there would be any technical
> > difficulties, and it would be hugely advantageous for particle
simulations,
> > among other things.
>
> It would require writing a lot of special code for each object type, and
> as already mentioned, the specified object parameters may no longer
> exist in the same form, and some things can exist in multiple forms. You


But don't all objects share certain parameters, such as texture, location,
etc?

> could parse objects into an intermediate structure to avoid that
> problem, and make it a structure of the script language to allow both
> reading as in your examples and modification. This would be the best
> way, but would be a large amount of work. It would be useful in other
> ways though, if one were able to define custom structures. It wouldn't
> need to be a full fledged object oriented system, but that would really
> help.

Structures would be useful in and of themselves, but that's another topic.

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message

> The location of all objects is <0,0,0> until acted on by translations /
> rotations.  The final location is the sum of these transformations.

sphere { y*10,1 } is located at the origin? Well Real Life (tm) is not 
logical, either, so why not :)

About your particle system: You have to keep in mind that there may be 
objects in the scene which have nothing to do with your system. To 
seperate them from the ones your system interacts with you need a flag 
for each object... Not really a nice and clean solution.

Normally I use something like this in such cases:

#declare System_Environment = object { SomeObject }

Or use an array of such environments if you want to give each 
environment specific properties (in a particle system, that might be 
things like friction, damping, etc.).

This method has another advantage: The objects your system works with 
don't have to be part of the scene. That might sound strange, but 
sometimes it's a handy thing to have.

Don't get me wrong, I'd love to see a syntax like the one you described 
(and I'd like write-access, too *g*). But in most cases you can use a 
pretty clean workaround.


HTH,
Florian

Post a reply to this message

"Florian Brucker" <tor### [at] torfboldcom> wrote in message
news:4061fb80@news.povray.org...
> > The location of all objects is <0,0,0> until acted on by translations /
> > rotations.  The final location is the sum of these transformations.
>
> sphere { y*10,1 } is located at the origin? Well Real Life (tm) is not
> logical, either, so why not :)

Well, OK, that would start located at <0,10,0> - but that's because you
define the center of it there!

> About your particle system:

I'm not writing one.  That was just one example of what it would be useful
for.

> Don't get me wrong, I'd love to see a syntax like the one you described
> (and I'd like write-access, too *g*). But in most cases you can use a
> pretty clean workaround.

Well, write access might be nice, but I thought asking for less would
increase the probability of implementation :)

OK, so even if we don't do the whole POV syntax, would it be possible just
to get object positions like this?

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message

"Chambers" <bdc### [at] yahoocom> wrote in message
news:40620208$1@news.povray.org...
> OK, so even if we don't do the whole POV syntax, would it be possible just
> to get object positions like this?

OK, I figured it out by looking at objects other than spheres.  Sorry 'bout
that, everyone.

-- 
...Chambers
http://www.geocities.com/bdchambers79

Post a reply to this message

In article <40620208$1@news.povray.org>,
 "Chambers" <bdc### [at] yahoocom> wrote:

> > sphere { y*10,1 } is located at the origin? Well Real Life (tm) is not
> > logical, either, so why not :)
> 
> Well, OK, that would start located at <0,10,0> - but that's because you
> define the center of it there!

What about cone {y*2, 0, y*5, 2}? Where's its center? y*3.5? y*4? It 
certainly isn't < 0, 0, 0>.

Or for a more extreme example:

union {
    sphere {-x*5, 5}
    cylinder {-x*1, x*10, 0.05}
}

There's obviously far more of the object on the -x side than on the +x 
side, but it extends an equal distance in both directions. Center of 
mass/volume? Center of extents?


> OK, so even if we don't do the whole POV syntax, would it be possible just
> to get object positions like this?

No, because there is no single vector that can represent the position of 
an arbitrary object. You couldn't even get the transformations without 
some additional work, because some objects apply the transformations at 
parse time. For example, translating a sphere will move the center point 
instead of adding a transformation matrix which would have to be 
evaluated during tracing.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message