 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] mobilixnet dk> 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
|
|
| |
| |
|
|
|
|
| |
