Rune wrote:
> 
> I don't use that. I use trace only. The reason is that to find out whether a
> particle is inside an object or not is of no use if one doesn't know where
> to move it to and how to align them. I could however remove such particles
> so they don't get in the way.

Just removing them is of course the most simple way, but i'm quite sure
there are other options although i don't know about your code and
therefore can't say for sure.

If you always use 'trace' i wonder why the can fall through at all, does
trace not work correctly?

> 
> Not enough blobby I think...
> 
> [...]
> 
> Maybe. Is it because the water looks too "wild" on the flat parts?

I suppose using more and samller particles would be good, but that would
of course be much slower.

> 
> > Can you save the data generated so things are faster in a second run?
> 
> No. I considered it, but it would require another layer of complexity, and
> the data arrays would become huge.

That would not be much of a problem, of course it could be smaller and
easier to program when not implemented in Pov-SDL, but i really think that
would be very useful.

> 
> When my particle system including documentation and everything is finished.
> I expect it to be released sometime this decade.
> 

Looking forward to it...

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Nice. Very very nice. I think you're right about the blobbyness, the last one
looked a bit more like water, but this is still awesome. Now give us the source,
please!!!!

> I thought a lot about the problem and analyzed possible causes in my head,
> then came up with a better flowing algorithm. Luckily it worked! Now only
> about 0.3% of the particles fall through the surface.

Just pretend that the ground is slightly porous ;)

--
Tek
http://www.evilsuperbrain.com

Post a reply to this message

"Tek" wrote:
> Nice. Very very nice.

Thank you very very much!

> I think you're right about the blobbyness, the last one
> looked a bit more like water, but this is still awesome.

Awesome is not quite good enough. Realistic is better...

> Now give us the source, please!!!!

No, you'll have to wait. Bwahahar!!!

> Just pretend that the ground is slightly porous ;)

Yeah...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

"Christoph Hormann" wrote:
> If you always use 'trace' i wonder why the can fall
> through at all, does trace not work correctly?

It's not that simple. With the old model the problem was the following:

When a ray segment detects a surface:

      V
     /
----/-----
   V

The ray is roated so it is parallel to the surface:

<--------<
----------

But with curved surfaces the rotation may cause the ray segment to intersect
with the surface in another point:

 \
<-\------<
   `------

Therefore the collision detection algorith keeps looping untill there's no
collision.

It can also happen that the rotation causes the ray to intersect with a
surface but from the inside and out:

        /
<------/-<


The algorithm ignores that because it will not cause the ray to fall through
the surface.

However, in some cases the rotation causes the ray to intersect a surface at
two points:

 \      /
<-\----/-<


The algorithm only checks for the first intersection, and if the first
intersection is from the inside and out, it will be ignored, and the
algorithm thinks there's no problem. I then improved the algorithm to check
for the most relevant intersection and it seems to work for the large
majority of cases, but as you can see the whole concept is a bit
complicated, so it's very difficult to make a perfect algorithm...

> I suppose using more and samller particles would be good,
> but that would of course be much slower.

For every animation I have made there have been more and smaller particles,
but it just never seems to be enough...

> That would not be much of a problem, of course it could be
> smaller and easier to program when not implemented in Pov-SDL,
> but i really think that would be very useful.

The problem is that a whole new interface would have to be developed that
would allow the user to "save" and "load" data. It would be more complicated
for the user and much more complicated for me.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

> I thought a lot about the problem and analyzed possible causes in my head,
> then came up with a better flowing algorithm. Luckily it worked! Now only
> about 0.3% of the particles fall through the surface.

That's not good enough! We don't want ANY particles to fall through! Go back
to the drawingboard! NOW! ;) You'll figure it out. Why don't you ask at
p.a-u? Maybe someone there can shed some light on the subject. I would be
cool if we could do an external version of this, and feed the data back to
POV. Collision detection would be the tough part, though. :\

> This animation does not have any more particles than the last (about 2000
> particles), but this time I've used 6 blob elements for each particle, one
> big and 5 small surrounding it.

Clever... :)

> However, while the last animation was too
> blobby, this one is perhaps not quite blobby enough. I think I should have
> used slightly larger particles. It may also be caused by the fact that I
> didn't use pseudo motion blur this time, so I tried to compensate by using
> real motion blur using an external program.

I was going to ask after watching it, if you used motion blur. Looks cool.
Pseudo and real motion blur are better together, I think.

> I also improved the heightfield, changed the
> camera view, textures and so on.

I approve of this new look.

> I'm wondering if the animation is too slow? I tried to compile it a double
> speed and it looked equally nice, but I decided to use the slow version
> because I'm going for the look of a large-scale simulation.

It's a good speed to show off the effect. Too slow for RL, though.

Post a reply to this message

"Tony[B]" wrote:
> We don't want ANY particles to fall through! Go back
> to the drawingboard! NOW! ;)

Ok then. It'll probably not delay the release more than a few months anyway.

> You'll figure it out. Why don't you ask at p.a-u?

Dunno. I figured that if anybody else here had been working on flowing
algorithms I would have heard about it, or they would have contacted me. But
sure, I'll try.

> I would be cool if we could do an external version of this,
> and feed the data back to POV. Collision detection would be
> the tough part, though. :\

Replace the word "tough" with "impossible" and it'd be correct...

The real solution would be to do a patch, but I won't be able to do that in
any near future.

> > I didn't use pseudo motion blur this time, so I tried to
> > compensate by using real motion blur using an external program.
>
> I was going to ask after watching it, if you used motion blur.
> Looks cool.

Thanks, but I think myself that it's a bit too much.

> Pseudo and real motion blur are better together, I think.

To scale the blob elements longer in the direction of movement AND use
external motion blur? Hmm...

> > I also improved the heightfield, changed the
> > camera view, textures and so on.
>
> I approve of this new look.

Phew! :)

> It's a good speed to show off the effect. Too slow for RL, though.

I'll speed it up next time.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> [...]
> The algorithm only checks for the first intersection, and if the first
> intersection is from the inside and out, it will be ignored, and the
> algorithm thinks there's no problem. I then improved the algorithm to check
> for the most relevant intersection and it seems to work for the large
> majority of cases, but as you can see the whole concept is a bit
> complicated, so it's very difficult to make a perfect algorithm...
> 

I understand the problem, but it only occurs, if you already start below
the surface, so i wonder how this happens (since originally everything is
above and there should be no way to get below)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> I understand the problem, but it only occurs, if you
> already start below the surface, so i wonder how this
> happens (since originally everything is above and
> there should be no way to get below)

Not exactly correct.

The old algorithm worked like this:

The particle motion is calculated using an OldLocation and a NewLocation for
the particle. The collision detection algorithm traces a ray between these
two points:

\        V  /
 \      /  /
  \    /  /

     /
    V

Then both the OldLocation and the NewLocation are rotated around the
collision point:

\           /
 \         /
  \       /


In order to avoid errors the ray is moved a tiny bit along the normal vector
of the surface:

\           /
 \         /
<-\---o---/-<


The new algorithm works the same way except that if the algorithm loop is
run more than once, then for each loop the ray is traced not from the
OldLocation but from the collision point from the loop before. That works
fairly well, but not perfect.

Perhaps one reason for the occasional errors could be that a ray
accidentally hits exactly between two triangles of the heightfield?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> 
> [...]
> 
> The new algorithm works the same way except that if the algorithm loop is
> run more than once, then for each loop the ray is traced not from the
> OldLocation but from the collision point from the loop before. That works
> fairly well, but not perfect.
> 
> Perhaps one reason for the occasional errors could be that a ray
> accidentally hits exactly between two triangles of the heightfield?

I must admit that your method seems rather strange, but without knowing
the 'surrounding' parts of the algorithm, i can't say much.  Maybe try
moving upwards rather than in direction of the normal vector, this should
be save for heightfields.  Furthermore an additional 'trace()' from
'OldLocation' to 'OldLocation_rotated' could avoid this "getting below the
surface"

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" wrote:
> I must admit that your method seems rather strange

Maybe, maybe! How would I know, never having seen any material on the
subject I could compare it to? If anybody has a nice flowing algorithm that
is not "strange" I would be very interested in hearing about it!

How would you have expected the flowing algorithm to work?

> Maybe try moving upwards rather than in direction of
> the normal vector, this should be save for heightfields.

Sorry, I'm going for a 100% generic solution so I won't make any HF specific
workarounds. But I don't think that's where the problem is anyway.

> Furthermore an additional 'trace()' from 'OldLocation' to
> 'OldLocation_rotated' could avoid this "getting below the surface"

The OldLocation_rotated is irrelevant using my improved algorithm, as the
trace ray is not shot from there.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated May 10)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message