 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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 /
\ / /
\ / /
`--o--´
/
V
Then both the OldLocation and the NewLocation are rotated around the
collision point:
\ /
\ /
\ /
<--`--o--´--<
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The real solution would be to do a patch, but I won't be able to do that
in
> any near future.
I would suggest a separate app that outputted pov among other formats -
share the wealth and all that :)
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
my other half suggest i shout AWSOME ROLEX as it looks so good :))
--
Rick
Kitty5 WebDesign - http://Kitty5.com
Hi-Impact database driven web site design & e-commerce
TEL : +44 (01625) 266358 - FAX : +44 (01625) 611913 - ICQ : 15776037
POV-Ray News & Resources - http://Povray.co.uk
PGP Public Key
http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=0x231E1CEA
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hey, looking great!
I like the look of the heightfield this time around...it seems more real.
My one gripe is that in the beginning of the movie, in the upper stream,
when the little "bowl" fills up, it looks like the water has the consistancy
of gel (moving slowly). Perhaps it's because of this being the slow motion
version?
-Ian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" wrote:
> my other half suggest i shout AWSOME ROLEX as it looks so good :))
Oh no! The word looses it's meaning when it's used too often!
AWSOME ROLEX is for 100% photorealistic renderings only. :)
But thank you anyway! ;)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rick [Kitty5]" wrote:
> > The real solution would be to do a patch, but I won't be
> > able to do that in any near future.
>
> I would suggest a separate app that outputted pov among
> other formats - share the wealth and all that :)
My system can do collision detection with almost any POV-Ray object. How
could that be supported in an external app? Besides, I'm not able to program
separate apps either. I only know POV-Ray script.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ian Burgmyer" wrote:
> Hey, looking great!
Thanks! :)
> I like the look of the heightfield this time around...
> it seems more real.
Great!
> My one gripe is that in the beginning of the movie,
> in the upper stream, when the little "bowl" fills up,
> it looks like the water has the consistancy of gel
> (moving slowly). Perhaps it's because of this being
> the slow motion version?
I'm not sure, but it looks like the water has to flow a little bit upwards,
which could cause the slow moving. I could make the water more bouncy, and
to view the clip in real time instead of slow motion would probably also
help.
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" <run### [at] mobilixnetdk> wrote in message
news:3b2cceea@news.povray.org...
> "Tony[B]" wrote:
> > 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...
>
Not really - you're already doing collision detection, of a sort, in
your POV script, right ? Well then, you just run the overall physics in your
external app, have it write out particle location and velocity information,
and keep the collision detection in the POV script.
That's the way my particle system is going to work (seeing all this
discussion about particle systems got me to thinking about them and then I
just had to have a go at writing one - looking reasonable, so far, expect
anims in p.b.i. soon....), until I've got a full modeller written anyhow,
then I plan to be able to do it all from within that...
--
Scott Hill.
Software Engineer.
E-Mail : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com
*Everything in this message/post is purely IMHO and no-one-else's*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3b2ce8b3@news.povray.org...
> Perhaps one reason for the occasional errors could be that a ray
> accidentally hits exactly between two triangles of the heightfield?
Have you tried it with a plane for example? If you get misses there, it
can't be a triangle problem...
- Nikodemus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
BTW, you may have noticed there are no spilling anymore. I think that the
spilling particles were in fact partly caused by a bug - which I fixed...
However, it may be possible still to make it happen using certain settings.
But for now I like that I have better control over where the particles go...
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Nikodemus Siivola" wrote:
> "Rune" wrote:
> > Perhaps one reason for the occasional errors
> > could be that a ray accidentally hits exactly
> > between two triangles of the heightfield?
>
> Have you tried it with a plane for example?
> If you get misses there, it can't be a triangle
> problem...
According to the tests I've done, the errors always happen at "cracks".
There are small cracks both in height_fields an in CSG objects.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Scott Hill" wrote:
> "Rune" wrote:
> Not really - you're already doing collision detection,
> of a sort, in your POV script, right ?
Yes I am. That's the point. In my POV script I have access to the surfaces
of the object through the trace function. In an external program I wouldn't
have access to the surfaces.
> Well then, you just run the overall physics in your
> external app, have it write out particle location and
> velocity information, and keep the collision detection
> in the POV script.
Err, the particle locations etc. are directly dependent on the collisions.
The collision detection is an integrated part of the system. It's not
possible to calculate all the physics first and then the collisions later.
> That's the way my particle system is going to work
I don't know how you're going to implement it, but I expect you don't have
direct support for all POV-Ray objects for the collision detection?
> (seeing all this discussion about particle systems got
> me to thinking about them and then I just had to have
> a go at writing one - looking reasonable, so far, expect
> anims in p.b.i. soon....)
I'm certainly looking forward to that!
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:
> According to the tests I've done, the errors always happen at "cracks".
>
> There are small cracks both in height_fields an in CSG objects.
If the problem only occurs in these cases, try having the option of a
second (or multiple) test ray that is jittered slightly from the original
test ray. The jittering amount would have to be specific to the scene
(though it would not have to be much), and would increase claculation time,
but it might pick up these "cracks" in CSG or HFs.
MJL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Rune" <run### [at] mobilixnetdk> wrote in message
news:3b2e806b@news.povray.org...
> "Scott Hill" wrote:
> > Well then, you just run the overall physics in your
> > external app, have it write out particle location and
> > velocity information, and keep the collision detection
> > in the POV script.
>
> Err, the particle locations etc. are directly dependent on the collisions.
> The collision detection is an integrated part of the system. It's not
> possible to calculate all the physics first and then the collisions later.
>
Why ? Basically you run through the simulation physics, write an
intermediary set of particle locations, velocities, etc, out to a POV-script
readable file, launch the POV-script, which reads in these intermediary
values, computes collision detection and then writes the new values back out
to the intermediary file (which is then read back into the simulation app on
the next frame).
Of course, one thing I realised last night, is this means you have to
render every frame of the simulation, but if I can get it working this way
I'll look at packaging it up in a patch and so be able to utilise POVs
internal trace logic, or I might then just leave it until I've got Pandora's
Box written (which will support _all_ of POVs primitives) and hook it into
that....
--
Scott Hill.
Software Engineer.
E-Mail : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com
*Everything in this message/post is purely IMHO and no-one-else's*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Scott Hill" wrote:
> Of course, one thing I realised last night, is
> this means you have to render every frame of the
> simulation
Exactly, and that would be completely against the concept I've been working
on so far. It would be a major slow-down and it just wouldn't be worth it.
> but if I can get it working this way I'll look at
> packaging it up in a patch and so be able to utilise
> POVs internal trace logic
As I said, a patch would be the way to go...
> or I might then just leave it until I've got Pandora's
> Box written (which will support _all_ of POVs
> primitives) and hook it into that....
An external program with full support for POV-Ray object syntax sounds
impressive. Sure not something I'd be able to do. But then, I'm not able to
do any programming at all, except in POV script...
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 <run### [at] mobilixnetdk> wrote:
> "Christoph Hormann" wrote:
>> I wonder why they fall through at all, a simple test
>> whether the particle is inside the heightfield object
>> should help.
Sorry for jumping in here. I've looked for this 'simple test' before, but
haven't found it. Is there a function 'inside' available? I can see using
the object pigment to do it (in Megapov) and writing a macro, but is there
another way? Searching the docs (both pov and MP), I'm not finding anything
on insideness tests.
I could really use something like that at the moment.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune <run### [at] mobilixnetdk> wrote:
> "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 /
> \ / /
> \ / /
> `--o--?
> /
> V
> Then both the OldLocation and the NewLocation are rotated around the
> collision point:
> \ /
> \ /
> \ /
> <--`--o--?--<
> 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?
Have you considered only rotating the bit of the ray that you haven't
already travelled?
> \ V /
> \ / /
> \ / /
> <--`--o--?
Like so? That would keep the ray above the surface, just use a shorter
ray.
> In order to avoid errors the ray is moved a tiny bit along the normal vector
> of the surface:
> \ /
> \ /
> <-\---o---/-<
> `-----?
This might cause errors with highly contorted surfaces consider:
V
//
---------/
---------o-
V just misses hitting the tip of the upper surface. If it is moved along
the normal, it could end up inside the upper surface. You might want to
move a short distance along the ray itself. This means that any movement of
o will remain outside the surface.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Geoff Wedig wrote:
>
> Sorry for jumping in here. I've looked for this 'simple test' before, but
> haven't found it. Is there a function 'inside' available? I can see using
> the object pigment to do it (in Megapov) and writing a macro, but is there
> another way? Searching the docs (both pov and MP), I'm not finding anything
> on insideness tests.
No, i think you would have to use the object pattern. In povray source
code, there is the Inside_Object() function, maybe it would be useful to
have this available in SDL too so you don't need the pattern, but i doubt
this would lead to much gain in speed.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Geoff Wedig" wrote:
> Have you considered only rotating the bit of the ray
> that you haven't already travelled?
In effect that's what I'm doing. The rotated OldLocation is only used for
inertia calculations. The new trace ray is sent from the collision point
(plus offset) so the rotated OldLocation is irrelevant.
> > In order to avoid errors the ray is moved a tiny bit
> > along the normal vector of the surface:
>
> > \ /
> > \ /
> > <-\---o---/-<
> > `-----?
>
> This might cause errors with highly contorted surfaces.
> If it is moved along the normal, it could end up inside
> the upper surface.
It is moved by a very very small amount by the normal vector so it shouldn't
cause any problems.
> You might want to move a short distance along the ray itself.
> This means that any movement of o will remain outside the surface.
On the contrary. Because of the coincident surfaces problem I have to move
the ray along the normal vector or else it will be a matter of randomness
whether POV-Ray will decide that the ray is inside or outside the object.
Just like you can't expect correct behavior if you place a light_source just
on the surface of an object.
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" <run### [at] mobilixnetdk> wrote in message
news:3b2fdb5e@news.povray.org...
> "Scott Hill" wrote:
> > or I might then just leave it until I've got Pandora's
> > Box written (which will support _all_ of POVs
> > primitives) and hook it into that....
>
> An external program with full support for POV-Ray object syntax sounds
> impressive. Sure not something I'd be able to do. But then, I'm not able
to
> do any programming at all, except in POV script...
>
This is starting to go o-t for p.b.a, but, I've never understood this -
POV does it, so why can't a '3rd party' app ?
--
Scott Hill.
Software Engineer.
E-Mail : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com
*Everything in this message/post is purely IMHO and no-one-else's*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Geoff Wedig wrote:
>>
>> Sorry for jumping in here. I've looked for this 'simple test' before, but
>> haven't found it. Is there a function 'inside' available? I can see using
>> the object pigment to do it (in Megapov) and writing a macro, but is there
>> another way? Searching the docs (both pov and MP), I'm not finding anything
>> on insideness tests.
> No, i think you would have to use the object pattern. In povray source
> code, there is the Inside_Object() function, maybe it would be useful to
> have this available in SDL too so you don't need the pattern, but i doubt
> this would lead to much gain in speed.
After much angst, I've gone the route of fastest implementation: I'm writing
a patch to do what I need. So I can use the Inside_Object() function
directly. Thanks.
Geoff
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
