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