Hi all!

As mentioned in "Being Lucky" on off-topic, I've
found an old CD with my lost Particle-System. The
last three months of its updates have been lost
in the System Crash, and I actually believed that it
had been gone for good, as the backup CD had
been broken...

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...

Anyways, this one was just a quick test if everything
was working and if the data wasn't corrupted somehow.
Some might recognize it, but don't panic, I'm not
planning on resubmitting all those older animations again.
Instead, I'll be doing some complete new ones.

But this one is for old times sake. :-)

Regards,
Tim

PS: I'm working on an animation where particles and
LSSM interact, well, at least particles cause waves,
doesn't work vice versa with non-I/O (that old issue
again... ;-)

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



---
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

Attachments:
Download 'sphere_trail.mpg' (257 KB)

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

> 
> 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/

Post a reply to this message

> 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