 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm afraid my "objects" don't work quite that way. I use them like this:
--- code ---
// Parametric variable form
//#version unofficial MegaPov 0.7;
#declare uMin = 0; // Minimum u value
#declare uMax = radians(90); // Maximum u value
#declare uNum = 41; // Number of points in u direction
#declare uWrap = 0; // u wraps around if != 0
#declare uSeed = 8266; // Random number seed for u parameter
#declare vMin = 0; // Minimum v value
#declare vMax = radians(356); // Maximum v value
#declare vNum = 90; // Number of points in v direction
#declare vWrap = 1; // v wraps around if != 0
#declare vSeed = 1425; // Random number seed for v parameter
#declare IsRnd = false; // True if random number used
#declare IsUV = false; // True if object is to be UV-mapped
#declare Smooth = 0; // Smooth flag
#declare Detail = "Partial"
/* Detail values
Verbose = Line by line details
Partial = Operations only
Other = Filename only
*/
/* For all macro functions
i = Current value of u parameter
j = Current value of v parameter
p = Current value of u variance (0...1)
q = Current value of v variance (0...1)
vc= Current 3D point
*/
// Optional functions
// point function
#macro pnt(i, j, p, q)
#local r0 = 1.1;
#local r1 = exp(cos(j));
#local yp = r0*sin(i);
#local xp = cos(i)*cos(j)*r1-exp(yp-0.35);
#local zp = cos(i)*sin(j)*r1*.1;
<xp, yp, zp>
#end
--- end code ---
To alter a property I simply use #declare or MegaPov's #set. I use the
contained macros in the traditional POV-Ray fashion. Like I mentionned
earlier, this trick is used to simplify macro calls and make variable macros
and functions available to them. It's not classic C++ classes by a long
shot and it wasn't intended to be.
"Tek" <tek### [at] evilsuperbrain com> wrote in message
news:4029c7e1$1@news.povray.org...
> Maybe I'm misunderstanding you, but how does having each object as an
include
> file help? Or do you mean have each class as an include file?
>
> BTW, did you see the technique I posted in p.b.s-f? That sounds pretty
similar
> to what you're suggesting. It solves the problem of indirect function
> invocation, but but I still haven't found a nice way of defining
> structures/classes. Can your system do this?
>
> Basically I want to be able to do things like this:
>
> myMoveableObject = new Monkey; //Monkey is a class
> ...
> myMoveableObject.move(deltaTime);
> ...
> if ( myMoveableObject.position == invalid ) delete myMoveableObject;
>
> --
> Tek
> www.evilsuperbrain.com
>
>
> "David Wallace" <dar### [at] earthlinknet> wrote in message
> news:402907a4@news.povray.org...
> >
> > "Tek" <tek### [at] evilsuperbraincom> wrote in message
> > news:4025787d@news.povray.org...
> > > I've decided to have a go at creating a fairly complex scene file
based on
> > lots
> > > of autonomous entities with simple ai and physics. So, I've been
figuring
> > out
> > > tricks for writing pov scene code in an object-oriented manner.
> > >
> > > i.e. there basically needs to be some way of defining classes (I won't
do
> > > inheritance), with member variables and functions. And some system of
> > creating
> > > and destroying these on the fly. Oh, and persistent variables.
> > >
> > > Now, I think I've actually figured out a pretty decent way to do all
this,
> > just
> > > using the SDL. I'm happy to give details but I don't want to clog up
this
> > > message with all that info.
> > >
> > > But anyway, the reason I'm posting: I was just wondering has anyone
done
> > this
> > > before? Either within the SDL, or as a modification to pov to support
> > simple
> > > data structures and function callbacks?
> > >
> > > Oh, and do you think it should be oriented or orientated? ;)
> > >
> > > --
> > > Tek
> > > www.evilsuperbrain.com
> > >
> > >
> > My principal "object" is the #include file. Each object definition,
> > including macros, variables, etc. can be placed in this file.
> >
> > If you want a macro to use the object, just use the filename as a string
> > parameter:
> >
> > #macro ObUser(iFile, oFile)
> > #include iFile
> > #open oFile
> > ...
> > #write oFile, Data
> > ...
> > #close oFile
> > #end
> >
> > I use this tactic frequently. Macros that would otherwise use a large
> > number of parameters are greatly simplified by this method. Macros,
> > functions, and primitives that might not otherwise be available as macro
> > parameters can be provided for this way.
> >
> > #include files also carry one extra benefit: you can add descriptive
> > comments and variable names that make code reading easier
> >
> > Try it some time.
> >
> >
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, I think I see what you mean. Yeah, that's a nice solution to a different
problem. I don't think it can quite handle the ludicrous complexity I'm trying
to achieve :)
--
Tek
www.evilsuperbrain.com
"David Wallace" <dar### [at] earthlinknet> wrote in message
news:402bc112@news.povray.org...
> I'm afraid my "objects" don't work quite that way. I use them like this:
> --- code ---
> // Parametric variable form
> //#version unofficial MegaPov 0.7;
>
> #declare uMin = 0; // Minimum u value
> #declare uMax = radians(90); // Maximum u value
> #declare uNum = 41; // Number of points in u direction
> #declare uWrap = 0; // u wraps around if != 0
> #declare uSeed = 8266; // Random number seed for u parameter
>
> #declare vMin = 0; // Minimum v value
> #declare vMax = radians(356); // Maximum v value
> #declare vNum = 90; // Number of points in v direction
> #declare vWrap = 1; // v wraps around if != 0
> #declare vSeed = 1425; // Random number seed for v parameter
>
> #declare IsRnd = false; // True if random number used
> #declare IsUV = false; // True if object is to be UV-mapped
>
> #declare Smooth = 0; // Smooth flag
>
> #declare Detail = "Partial"
> /* Detail values
> Verbose = Line by line details
> Partial = Operations only
> Other = Filename only
> */
>
> /* For all macro functions
> i = Current value of u parameter
> j = Current value of v parameter
> p = Current value of u variance (0...1)
> q = Current value of v variance (0...1)
> vc= Current 3D point
> */
>
> // Optional functions
>
> // point function
> #macro pnt(i, j, p, q)
> #local r0 = 1.1;
> #local r1 = exp(cos(j));
>
> #local yp = r0*sin(i);
> #local xp = cos(i)*cos(j)*r1-exp(yp-0.35);
> #local zp = cos(i)*sin(j)*r1*.1;
>
> <xp, yp, zp>
> #end
> --- end code ---
> To alter a property I simply use #declare or MegaPov's #set. I use the
> contained macros in the traditional POV-Ray fashion. Like I mentionned
> earlier, this trick is used to simplify macro calls and make variable macros
> and functions available to them. It's not classic C++ classes by a long
> shot and it wasn't intended to be.
>
> "Tek" <tek### [at] evilsuperbraincom> wrote in message
> news:4029c7e1$1@news.povray.org...
> > Maybe I'm misunderstanding you, but how does having each object as an
> include
> > file help? Or do you mean have each class as an include file?
> >
> > BTW, did you see the technique I posted in p.b.s-f? That sounds pretty
> similar
> > to what you're suggesting. It solves the problem of indirect function
> > invocation, but but I still haven't found a nice way of defining
> > structures/classes. Can your system do this?
> >
> > Basically I want to be able to do things like this:
> >
> > myMoveableObject = new Monkey; //Monkey is a class
> > ...
> > myMoveableObject.move(deltaTime);
> > ...
> > if ( myMoveableObject.position == invalid ) delete myMoveableObject;
> >
> > --
> > Tek
> > www.evilsuperbrain.com
> >
> >
> > "David Wallace" <dar### [at] earthlinknet> wrote in message
> > news:402907a4@news.povray.org...
> > >
> > > "Tek" <tek### [at] evilsuperbraincom> wrote in message
> > > news:4025787d@news.povray.org...
> > > > I've decided to have a go at creating a fairly complex scene file
> based on
> > > lots
> > > > of autonomous entities with simple ai and physics. So, I've been
> figuring
> > > out
> > > > tricks for writing pov scene code in an object-oriented manner.
> > > >
> > > > i.e. there basically needs to be some way of defining classes (I won't
> do
> > > > inheritance), with member variables and functions. And some system of
> > > creating
> > > > and destroying these on the fly. Oh, and persistent variables.
> > > >
> > > > Now, I think I've actually figured out a pretty decent way to do all
> this,
> > > just
> > > > using the SDL. I'm happy to give details but I don't want to clog up
> this
> > > > message with all that info.
> > > >
> > > > But anyway, the reason I'm posting: I was just wondering has anyone
> done
> > > this
> > > > before? Either within the SDL, or as a modification to pov to support
> > > simple
> > > > data structures and function callbacks?
> > > >
> > > > Oh, and do you think it should be oriented or orientated? ;)
> > > >
> > > > --
> > > > Tek
> > > > www.evilsuperbrain.com
> > > >
> > > >
> > > My principal "object" is the #include file. Each object definition,
> > > including macros, variables, etc. can be placed in this file.
> > >
> > > If you want a macro to use the object, just use the filename as a string
> > > parameter:
> > >
> > > #macro ObUser(iFile, oFile)
> > > #include iFile
> > > #open oFile
> > > ...
> > > #write oFile, Data
> > > ...
> > > #close oFile
> > > #end
> > >
> > > I use this tactic frequently. Macros that would otherwise use a large
> > > number of parameters are greatly simplified by this method. Macros,
> > > functions, and primitives that might not otherwise be available as macro
> > > parameters can be provided for this way.
> > >
> > > #include files also carry one extra benefit: you can add descriptive
> > > comments and variable names that make code reading easier
> > >
> > > Try it some time.
> > >
> > >
> > >
> >
> >
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tek wrote:
> Oh, I think I see what you mean. Yeah, that's a nice solution to a different
> problem. I don't think it can quite handle the ludicrous complexity I'm trying
> to achieve :)
>
IMHO this comes down to 'pov ain't oo' - I don't think anyone denies
that oo capabilities in pov wouldn't be at the very least interesting,
but that's not the issue....
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <4032b303$1@news.povray.org>,
Tom Melly <pov### [at] tomandlucouk> wrote:
> IMHO this comes down to 'pov ain't oo' - I don't think anyone denies
> that oo capabilities in pov wouldn't be at the very least interesting,
> but that's not the issue....
Wha...? You're saying you don't think OO capabilities would be useful,
or even interesting? And that you don't think anyone thinks it would be
interesting? It's sure spawned a lot of discussion for something so
utterly uninteresting...
--
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-60ACCD.21030117022004@news.povray.org...
> In article <4032b303$1@news.povray.org>,
> Tom Melly <pov### [at] tomandlucouk> wrote:
>
> > IMHO this comes down to 'pov ain't oo' - I don't think anyone denies
> > that oo capabilities in pov wouldn't be at the very least interesting,
> > but that's not the issue....
>
> Wha...? You're saying you don't think OO capabilities would be useful,
> or even interesting? And that you don't think anyone thinks it would be
> interesting? It's sure spawned a lot of discussion for something so
> utterly uninteresting...
After you parse the double-negative, he's actually saying the opposite --
that everybody would find it, at very least, interesting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> After you parse the double-negative, he's actually saying the opposite --
> that everybody would find it, at very least, interesting.
Not me. It would add another layer of complexity that I don't want to have
to bother to learn. OO is for programming not a scene description language.
If I wanted to learn programming I would do that rather than using POV-Ray.
--
Mr. Flameproof
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ken" <tyl### [at] pacbellnet> wrote in message
news:4032CB5A.9277B9BA@pacbell.net...
>
> Dan P wrote:
>
> > After you parse the double-negative, he's actually saying the
opposite --
> > that everybody would find it, at very least, interesting.
>
> Not me. It would add another layer of complexity that I don't want to have
> to bother to learn. OO is for programming not a scene description
language.
> If I wanted to learn programming I would do that rather than using
POV-Ray.
I whole-heartedly disagree. OO would enable POV-Ray to evolve beyond a scene
description language. Also, OO would make POV-ray /easier/ to learn because
Object-Orientation is just that: a way to describe abstract "objects", which
is what makes /up/ a scene. The thing is, POV-Ray isn't for people who
aren't programming-minded. I'm not discounting other pieces of software like
3DSMax or anything, but for programming-minded individuals, the graphical
user-interface gets in the way of achieving our true intentions. There are
many alternatives to POV-Ray for non-programming types, but few (if any -- I
don't know of any others, anyway) alternatives to POV-Ray/MegaPov.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Twaddle!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 17 Feb 2004 18:18:02 -0800, Ken <tyl### [at] pacbellnet> wrote:
>
>
>Dan P wrote:
>
>> After you parse the double-negative, he's actually saying the opposite --
>> that everybody would find it, at very least, interesting.
>
>Not me. It would add another layer of complexity that I don't want to have
>to bother to learn. OO is for programming not a scene description language.
>If I wanted to learn programming I would do that rather than using POV-Ray.
(Also at the risk that I'm again number one of your list)
If you use POV-Ray and write the scenes yourself (without a modeler)
there is no difference to 'programming'.
POV-Ray is just an interpreter to translate SDL to a binary image.
SDL is rather close to a subset of C, I always wonder whether the
deviations are unfortunate coincidences.
At least inheritance (of textures, objects, ...) is an OO feature of
POV-Ray's SDL.
--
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Now you're nit picking. Povray is as much like programming as it is, but OO
would make it more like programming. Stop pretending you didn't know what he
meant!
--
Tek
www.evilsuperbrain.com
"Andreas Kaiser" <aka### [at] nurfuerspamde> wrote in message
news:rhp5301kh5ji7gtjk9tvljodi9cpi80hge@4ax.com...
> On Tue, 17 Feb 2004 18:18:02 -0800, Ken <tyl### [at] pacbellnet> wrote:
>
> >
> >
> >Dan P wrote:
> >
> >> After you parse the double-negative, he's actually saying the opposite --
> >> that everybody would find it, at very least, interesting.
> >
> >Not me. It would add another layer of complexity that I don't want to have
> >to bother to learn. OO is for programming not a scene description language.
> >If I wanted to learn programming I would do that rather than using POV-Ray.
>
> (Also at the risk that I'm again number one of your list)
> If you use POV-Ray and write the scenes yourself (without a modeler)
> there is no difference to 'programming'.
> POV-Ray is just an interpreter to translate SDL to a binary image.
> SDL is rather close to a subset of C, I always wonder whether the
> deviations are unfortunate coincidences.
> At least inheritance (of textures, objects, ...) is an OO feature of
> POV-Ray's SDL.
>
> --
> Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
