Folks:

  There's a fairly full featured physics library called "ODE" that I've been
looking at; it would offer anything we'd need for a particle system, but as
it's C/C++ type of a thing it would require processing before POV-Ray
parsing (sort of like how Morray does it).

  I have also gotten the SDK for a system called "HyperMatter"
(http://www.hypermatter.com) that does more than rigid bodies - you can also
do 'flexible' objects.  Some of their demo's look pretty cool.  They seem
open to the idea of a shareware plugin type of a thing.
 (I think they are redoing their homepage, this is the new one).  See
(DivX):
http://homepage.ntlworld.com/hypermatter/avi/dice_divx.avi
or
http://homepage.ntlworld.com/hypermatter/avi/mstrap_divx.avi


  If I built something like this, it would have to be a preprocessing type
of a thing.  My feeling is that due to CSG complexities, you'd have to
designate some objects as BBox's or somehow declare to my preprocessor what
physical attributes an object has, i.e.

box { <-0.8, -1.2, -1.2> <0.8, 1.2, 1.2> }
 /*Physics: weight 1.3 rigid velocity(1,0,.4) */ }

(best, as you can just do a regular POV-Ray run on the file and it'll pass)

or
#include "physics.inc" //defines physics macro's)
box { <-0.8, -1.2, -1.2> <0.8, 1.2, 1.2> }
 mass(1.0) elasticity(0.4) }

or something.

There's quite a lot of complex keywords / properties that would have to be
programmed in, constraints, physical properties, and you'd have to define
what actual objects compose seperate physical objects.  I'm tring to get a
general feeling for how people would like to use such a package before I
think about what the actual syntax would look like.

Thoughts?

                  == John ==

p.s.  Don't look at the "Naturally" clip, you'll be mesmerized.

Post a reply to this message

I think the idea is great, as long as you actually make it possible
to:
1. not leave POV-Ray during setup
2. the programm works on several platforms

Making it open-source kind a thing would also be neat, as some
guys might come up with quicker and better solutions (that just
happens all over the place).

But, thinking about dynamics, I'd guess you'd have a hard time memorising
all objects in scene. So, you'd probably have to put at least some option
to tell which objects to memorise and which not.

Aside of that, I guess you're probably in a fair amount of trouble, as physics
is sometimes more mind-boggling than you normally expect. ;)

Tim

Post a reply to this message

Oh, I know about physics, I've was involved in the game industry for a
while, and spoke at CGDC a few times on 3D toolkits.  The big advantage of
working with these toolkits though is that a lot of the hard work is done.

In particular, ODE looks pretty good.  Hypermatter is compelling due to the
possibility of having 'squishy blobs' but I'm not sure if it's pure C++, I
think at this point it's a Windows or Mac DLL.

Given the flavor if POV-Ray (from it's early CompuServer roots) is so cross
platform, that makes ODE a much better choice.

However, I got to thinking about it - if I make it a pre-processor, I'd have
to run it more or less like Moray.  Heck, maybe it should be a Moray plug in
by itself.

By 'run like Moray' I mean you'd bring up this app, load your (modified)
POV-Ray scene, then let it generate sucessive POV-Ray files for rendering.
The thing I don't like about that is it would have to read full POV-Ray
macro's and parse clock statements to be really usefull. At first, I was
thinking it would just displace some geometry, but complex anim's include
expressions that would have to be parsed by this tool.

I don't really want to make it part of the Pov-Ray source code, but given
the above paragraph, that might be much easier.

                  == John ==

"Tim Nikias" <Tim### [at] gmxde> wrote in message
news:3C15F086.F166E187@gmx.de...
>
> I think the idea is great, as long as you actually make it possible
> to:
> 1. not leave POV-Ray during setup
> 2. the programm works on several platforms
>
> Making it open-source kind a thing would also be neat, as some
> guys might come up with quicker and better solutions (that just
> happens all over the place).
>
> But, thinking about dynamics, I'd guess you'd have a hard time memorising
> all objects in scene. So, you'd probably have to put at least some option
> to tell which objects to memorise and which not.
>
> Aside of that, I guess you're probably in a fair amount of trouble, as
physics
> is sometimes more mind-boggling than you normally expect. ;)
>
> Tim
>

Post a reply to this message

In your first post you mentioned something about placing inclusions or
comment-like instruction for the programm into the POV-File.

What's so wrong with that?
Another thing is that I don't like the idea of having dozens of files
floating around my PC to create one animation.

I don't know how to actually create something useful that will work
fine with POV-Ray. But if the procedure would be as follows, it might
just be something a lot of people using POV-Ray would agree to:

1. Write your POV-Script, add comments including physical
    properties.
2. Run the programm and load the POV-File into it. Let it calculate
    everything required to do the animation of the physical stuff and
    write it into Include-file, useable by POV
3. Add Include-File into original POV-Script and let POV do the
    trace.

That's something I like and would most probably jump to. If you're in to
create an external editor for the physics, that'd be fine too. But I mostly
like programms that don't require more than the basics.
If you'd use Moray, things would depend on
Version of Moray
Version of POV-Ray
Version of Physical-Plug-In
Platform for Moray, POV-Ray

Creating something thats purely based on POV-Ray is way better, I think.
But perhaps that's just my personal oppinion.

Tim

Post a reply to this message

I think actually my program would have to output each frame of the
animation, but steps 1,2,3 is basically what I was thinking of.  It would
'drive' POV, or for non Windows platforms, it would run a shell command to
do the render.

Hmmm ... although, at first I thought it couldn't just output a .inc file
and then you'd do the render from POV-Ray, as each frame would be pretty
different, I guess it could just calculate the x,y,z locations and rotations
and output those with a big 'if clock==' switch statement in the .inc file.
I was more thinking it would update the positions and write the file out
directly.

i.e.

box { ... translate <...> mass( 1.0 ) initvelocity( xxx) }
would turn into
box { ... translate <...> translate <...> rotate <...> }
or
box { ... translate <...> rotate <...> }

However, the .inc result could be something like
box { ... translate <resultX[cindex], resultY[cindex],resultZ[cindex],
    rotate <...> }

Do you like the idea of comments or new keywords?

I like the general idea if you don't run the pov script through my program,
it would still render, so a #include file that makes 'mass' into a no
operation would be a good idea.

== John ==

"Tim Nikias" <Tim### [at] gmxde> wrote in message
news:3C1### [at] gmxde...
> In your first post you mentioned something about placing inclusions or
> comment-like instruction for the programm into the POV-File.
>
> What's so wrong with that?
> Another thing is that I don't like the idea of having dozens of files
> floating around my PC to create one animation.
>
> I don't know how to actually create something useful that will work
> fine with POV-Ray. But if the procedure would be as follows, it might
> just be something a lot of people using POV-Ray would agree to:
>
> 1. Write your POV-Script, add comments including physical
>     properties.
> 2. Run the programm and load the POV-File into it. Let it calculate
>     everything required to do the animation of the physical stuff and
>     write it into Include-file, useable by POV
> 3. Add Include-File into original POV-Script and let POV do the
>     trace.
>
> That's something I like and would most probably jump to. If you're in to
> create an external editor for the physics, that'd be fine too. But I
mostly
> like programms that don't require more than the basics.
> If you'd use Moray, things would depend on
> Version of Moray
> Version of POV-Ray
> Version of Physical-Plug-In
> Platform for Moray, POV-Ray
>
> Creating something thats purely based on POV-Ray is way better, I think.
> But perhaps that's just my personal oppinion.
>
> Tim
>

Post a reply to this message

I'd rather go with the comments. They can still be function-style, and
since you have to read the POV-Script this way or another, I'd think
it doesn't matter that much which way you choose. But using comments
would be easier to handle, no #include-files to tamper with...

Tim

Post a reply to this message

Oh,  I thought the comments were messier .. I mean, with the #include file
you'd enter
mass( 1.0)
with the comments it would be
/* mass (1.0) */

Hmm ... maybe I could do BOTH, and have it be an option switch?

Parsing inside comments actually causes problems, what if you are trying to
comment out a mass statement, i.e.

/* this works */
/* mass(1.0) */
/* but let's comment this out */
/* mass (2.0) */
Which one is a real comment?

I realize that the comments were my idea <G>.

Surprised it's just you and me talking about this ...

                  == John ==

"Tim Nikias" <Tim### [at] gmxde> wrote in message
news:3C17DA22.6AAA1898@gmx.de...
> I'd rather go with the comments. They can still be function-style, and
> since you have to read the POV-Script this way or another, I'd think
> it doesn't matter that much which way you choose. But using comments
> would be easier to handle, no #include-files to tamper with...
>
> Tim
>

Post a reply to this message

I had a thought:

/** mass(1.0) */
/* mass(2.0) */

Mass 2.0 would be the comment, 1.0 would be the 'real' declaration.  This
would be easy to parse.

In addition, I couild just scan the whole file and look for /**'s and this
would mean my first version would not have to be a completly general POV-Ray
macro processor/parser.

However, I think longer term it would be nice to do this:

#declare mymass = 2.0;

/**mass(mymass)*/
/**mass(mymass * 2.0)*/
or even
/**mass( x* 2.0)*/
but the last would be just weird; essential for starting velocity and other
constraints however.  So I think I need to parse the whole file.

                  == John ==

"John D. Gwinner" <jgw### [at] dazsicom> wrote in message
news:3c17f6d0$1@news.povray.org...
> Oh,  I thought the comments were messier .. I mean, with the #include file
> you'd enter
> mass( 1.0)
> with the comments it would be
> /* mass (1.0) */
>
> Hmm ... maybe I could do BOTH, and have it be an option switch?
>
> Parsing inside comments actually causes problems, what if you are trying
to
> comment out a mass statement, i.e.
>
> /* this works */
> /* mass(1.0) */
> /* but let's comment this out */
> /* mass (2.0) */
> Which one is a real comment?
>
> I realize that the comments were my idea <G>.
>
> Surprised it's just you and me talking about this ...
>
>                   == John ==
>
> "Tim Nikias" <Tim### [at] gmxde> wrote in message
> news:3C17DA22.6AAA1898@gmx.de...
> > I'd rather go with the comments. They can still be function-style, and
> > since you have to read the POV-Script this way or another, I'd think
> > it doesn't matter that much which way you choose. But using comments
> > would be easier to handle, no #include-files to tamper with...
> >
> > Tim
> >
>
>

Post a reply to this message

When commenting my files, I often use different "types" of comment

//  this is a general comment

//@---new section---

//@@---new sub-section---

//@@@---new sub-sub-section---

//#  instructions (how to use macro, etc)

//_  this comment applies to all lines from here...

//^  ...to here

//!  this is really important!

//$  this tells me I haven't finished this portion of code yet.

//?  this piece of code does strange things, but I don't know why!

Perhaps you could use something like this? Let's use "//:x" as a comment
tag for some program denoted "x". Eg, a particle system could read
"//:P" tags, so...

//:P  mass(1.0)

-- 
signature{
  "Grey Knight"
  contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://enphilistor.users4.50megs.com/" }
}

Post a reply to this message

s1631001 <s16### [at] namtarqubacuk> wrote:
: //$  this tells me I haven't finished this portion of code yet.

  Time is money? ;)

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

Post a reply to this message