 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> In the last animation there were actually a huge amount of particle falling
> through the surface of the heightfield but it was not visible because of the
> camera view from above.
>
> 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.
I wonder why they fall through at all, a simple test whether the particle
is inside the heightfield object should help.
>
> 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. 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 also improved the heightfield, changed the camera view, textures and so
> on.
It looks really good, the water seems - a bit like particles of course :-)
What i especially like is the first part when the water reaches the
heightfield and bounces back. To me it seems it works best on the steeper
parts where the water is mostly falling rather than flowing.
>
> 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 looks ok here.
>
> The animation took 5.5 hours to render on a 1000 GHz machine. I turned
> statistics off, but as far as I could see more than half of the time were
> spend parsing (the particle system is not particularly fast).
>
1000 GHz - wow! ;-)
Can you save the data generated so things are faster in a second run?
BTW, when will you show us some code for these?
Christoph
--
Christoph Hormann <chr### [at] gmx de>
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 wonder why they fall through at all, a simple test
> whether the particle is inside the heightfield object
> should help.
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.
> It looks really good, the water seems - a bit like particles of course :-)
Not enough blobby I think...
> What i especially like is the first part when the water
> reaches the heightfield and bounces back. To me it seems
> it works best on the steeper parts where the water is mostly
> falling rather than flowing.
Maybe. Is it because the water looks too "wild" on the flat parts?
> 1000 GHz - wow! ;-)
Err... Whoops!
> 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.
> BTW, when will you show us some code for these?
When my particle system including documentation and everything is finished.
I expect it to be released sometime this decade.
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:
>
> 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
|
|
| |
| |
|
|
|
|
| |
|
|
