> Can we use it in IMP?

Sure, why not? For me it's all about the "old issue":
credit where credit is due. :-)

Come to think about it, I see why this particle-
system might be better suited than a I/O one:
there's no dependancy on earlier frames. It has
a pretty high parsing load, but I've found that
for animations where no object-interaction is
required, the system is sufficient and especially
suited for distributed rendering...

It IS a little complicated to handle, but I plan
on creating a little Insert-Menu for it, to ease
the usage, and rename variables to more
intuitive names...

And it isn't finished yet, so that may take some
time...

But we POVers are patient, aren't we? ;-)

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights

>
> >
> > Anyways, I'm pretty happy to have it back, though
> > I don't plan to go on with the development. I've begun
> > completing the code and erasing the redundant
> > parts, and hope to have a stable and running version
> > before I leave for my vacation...
> >
>
> Can we use it in IMP?
>
>
> -- 
> Tom
> _________________________________
> The Internet Movie Project
> http://www.imp.org/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message

"Tim Nikias v2.0" <tim### [at] gmxde> wrote in news:3f1b8c2e$1
@news.povray.org:

>> Can we use it in IMP?
> 
> Sure, why not? For me it's all about the "old issue":
> credit where credit is due. :-)
> 

I will be happy to oblige.


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

>
> I will be happy to oblige.

Fine with me! Gee, after Rune put his Particle System
online I thought mine was never going to be needed
for *anything*. And now I'll be famous! :-)

Today IMP, tomorrow the world! ;-)

I'll post a note on povray.general when the system
is finished and when it will be released.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights


>
> >> Can we use it in IMP?
> >
> > Sure, why not? For me it's all about the "old issue":
> > credit where credit is due. :-)
> >
>
> I will be happy to oblige.
>
>
> -- 
> Tom
> _________________________________
> The Internet Movie Project
> http://www.imp.org/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message

Tim Nikias v2.0 wrote:
> Come to think about it, I see why this particle-
> system might be better suited than a I/O one:
> there's no dependancy on earlier frames.

Um, I just want to put in a small note here that my system is not
dependent on earlier frames either. Of course it still has to
"calculate* the simulation from the beginning, in the first frame of the
series of rendered frames, but that's also the case in Non-I/O particle
systems, where the simulation is calculated from the beginning in
*every* frame, and not just the first one.

So in short: You can render any sub-series of frames in an animation,
and the system will automatically make sure that the final animation
when the sub-series are combined, will be smooth and seamless. It is the
same trickery that makes my system support cyclic animation, which is
also not normally supported in I/O particle systems.

Now, Tim's system might still be better suited for the project. (There
are probably numerous arguments both for and against.) All I wanted with
this post was to clear a possible misunderstandings about my I/O
particle system.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

You're right about that.

There's also the precision thingy we've talked about
months ago, remember? That my non I/O calculates
an impact with the boundary box, while your I/O
one approximates it with trace() calls. I doubt that
the precision of your system is so much a drawback
though.

But one thing I've noticed and that is probably fitting to
mention here:
I've noticed that the interpolation in between frames
doesn't yield smooth flying curves, but rather straight
connections. Is that still an issue? I'm not sure how that
could be solved anyways, I haven't given much thought
to it. Maybe I'm even wrong, since that was a looong
time ago.
One solution is of course to calculate more frames, but
is there an alternative to that?

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights

> > Come to think about it, I see why this particle-
> > system might be better suited than a I/O one:
> > there's no dependancy on earlier frames.
>
> Um, I just want to put in a small note here that my system is not
> dependent on earlier frames either. Of course it still has to
> "calculate* the simulation from the beginning, in the first frame of the
> series of rendered frames, but that's also the case in Non-I/O particle
> systems, where the simulation is calculated from the beginning in
> *every* frame, and not just the first one.
>
> So in short: You can render any sub-series of frames in an animation,
> and the system will automatically make sure that the final animation
> when the sub-series are combined, will be smooth and seamless. It is the
> same trickery that makes my system support cyclic animation, which is
> also not normally supported in I/O particle systems.
>
> Now, Tim's system might still be better suited for the project. (There
> are probably numerous arguments both for and against.) All I wanted with
> this post was to clear a possible misunderstandings about my I/O
> particle system.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com (updated Oct 19)
> POV-Ray Ring: http://webring.povray.co.uk
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message

Tim Nikias v2.0 wrote:
> There's also the precision thingy we've talked about
> months ago, remember? That my non I/O calculates
> an impact with the boundary box, while your I/O
> one approximates it with trace() calls. I doubt that
> the precision of your system is so much a drawback
> though.

Yes, this is the price to pay for having support for collision detection
with more than a simple bounding box or a plane... In most cases it's
not really a problem though.

> But one thing I've noticed and that is probably
> fitting to mention here:
> I've noticed that the interpolation in between
> frames doesn't yield smooth flying curves, but
> rather straight connections.

Are you talking about your system here or mine? I'm also not sure what
you're trying to say. You can't see the particles in between frames
anyway, so what do you mean by in between frame interpolation?

Anyway, in my system the precision of the flying curves are not
dependent on the framerate at all. It is dependent on the calculation
step rate, which is independent from the framerate. If you specify a
calculation step rate which is lower than the framerate, then (linear)
interpolation is used, but I've never been able to actually spot this
with my eye except in extreme cases where a way too low calculation step
rate was used.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

> Are you talking about your system here or mine? I'm also not sure what
> you're trying to say. You can't see the particles in between frames
> anyway, so what do you mean by in between frame interpolation?
>
> Anyway, in my system the precision of the flying curves are not
> dependent on the framerate at all. It is dependent on the calculation
> step rate, which is independent from the framerate. If you specify a
> calculation step rate which is lower than the framerate, then (linear)
> interpolation is used, but I've never been able to actually spot this
> with my eye except in extreme cases where a way too low calculation step
> rate was used.

Yeah, I was talking about that very last bit of way too few calculations
steps. I mixed "framerate" and "calculation steps" in my original post,
my mistake.

Aside of that, I think both our systems would be suited for the IMP,
but you mentioned something about mine being better suited. I have
been thinking about that, and in that regard, I don't think that there
are more reasons for mine than for yours, especially since yours
handles more collision detection possibilities...

BTW, can you call macro on certain events, e.g. when a particle hits
a wall? I've been rendering an animation where my particles bounce
around in a Cornell-Box (the one from my Radiosity Experiments) and
interact with a water-surface (achieved with, what else, my LSSM),
and it looks pretty nice so far. :-)
(even though particles shouldn't bounce off a water surface as if it
was made of stone ;-)

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights

> > There's also the precision thingy we've talked about
> > months ago, remember? That my non I/O calculates
> > an impact with the boundary box, while your I/O
> > one approximates it with trace() calls. I doubt that
> > the precision of your system is so much a drawback
> > though.
>
> Yes, this is the price to pay for having support for collision detection
> with more than a simple bounding box or a plane... In most cases it's
> not really a problem though.
>
> > But one thing I've noticed and that is probably
> > fitting to mention here:
> > I've noticed that the interpolation in between
> > frames doesn't yield smooth flying curves, but
> > rather straight connections.
>
> Are you talking about your system here or mine? I'm also not sure what
> you're trying to say. You can't see the particles in between frames
> anyway, so what do you mean by in between frame interpolation?
>
> Anyway, in my system the precision of the flying curves are not
> dependent on the framerate at all. It is dependent on the calculation
> step rate, which is independent from the framerate. If you specify a
> calculation step rate which is lower than the framerate, then (linear)
> interpolation is used, but I've never been able to actually spot this
> with my eye except in extreme cases where a way too low calculation step
> rate was used.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com (updated Oct 19)
> POV-Ray Ring: http://webring.povray.co.uk
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message

"Rune" <run### [at] runevisioncom> wrote in news:3f1ba59a@news.povray.org:


> 
> Now, Tim's system might still be better suited for the project. (There
> are probably numerous arguments both for and against.) All I wanted with
> this post was to clear a possible misunderstandings about my I/O
> particle system.
> 

Actually I figured that your system would be used at some point as well.  
Just like people will use jpatch and Wings3D for modelling. It is nice to 
have a choice of particle systems.  I just wanted to know if Tim's system 
would be available with an "openish" license so that we can use it.

-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message

> Actually I figured that your system would be used at some point as well.
> Just like people will use jpatch and Wings3D for modelling. It is nice to
> have a choice of particle systems.  I just wanted to know if Tim's system
> would be available with an "openish" license so that we can use it.

Well, my system and Rune's aren't really comparable, they're
completely different in abilities, handling and "up-to-date" coding.

I've begun working on my system about 3 years ago, that was
in Povray3.1g times, and have loaded more and more scripts
onto the same underlying principles. It has a wide range of possible
additions, since I've spread usage of User-Defined macros all
over the place, but it is basically limited to a simple task:
Randomly position "something" in a given area and move it about,
regardless of other "somethings" or other objects.

Still, lots of macros may vary the above in so many different ways
that it might have some benefits. But I haven't looked into the latest
version of Rune's particle system and I'm pretty unsure what is
possible "ad hoc", e.g. without modifications of his core-code.


-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights

>
>
> >
> > Now, Tim's system might still be better suited for the project. (There
> > are probably numerous arguments both for and against.) All I wanted with
> > this post was to clear a possible misunderstandings about my I/O
> > particle system.
> >
>
> Actually I figured that your system would be used at some point as well.
> Just like people will use jpatch and Wings3D for modelling. It is nice to
> have a choice of particle systems.  I just wanted to know if Tim's system
> would be available with an "openish" license so that we can use it.
>
> -- 
> Tom
> _________________________________
> The Internet Movie Project
> http://www.imp.org/


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003

Post a reply to this message

Tim Nikias v2.0 wrote:
> Yeah, I was talking about that very last bit
> of way too few calculations steps. I mixed
> "framerate" and "calculation steps" in my
> original post, my mistake.

No problem. But as I said, I don't really think that the linear
interpolation is a problem.

> Aside of that, I think both our systems would
> be suited for the IMP, but you mentioned
> something about mine being better suited.

No, I said that yours *might* be better suited, sort of to make clear
that I didn't make the post to indicate that my own system would be
better, but just to point out the fact about independancy on previous
frames.

Which system is really better suited is not a discussion I feel like
taking part in right now.

> BTW, can you call macro on certain events, e.g.
> when a particle hits a wall?

No, I haven't implemented support for that, though I think it would be
easy to add. (The wall hit that is. I don't know which other events you
have in mind.) I probably could do it if there was a great demand for
it, but in general I see my particle system as a project of the past.

> I've been rendering an animation where my
> particles bounce around in a Cornell-Box
> (the one from my Radiosity Experiments) and
> interact with a water-surface (achieved with,
> what else, my LSSM), and it looks pretty nice
> so far. :-)

Neat. :)

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message