[Bf-committers] Particle experiments - looking for feedback

[trip]

OSX patch build with make files gives me this. Note: scons is being =20
buggy with me again to, but no post yet

/ftfont/libftfont.a =20
/Users/ranch/projects/blender/../lib/darwin-7.0.0-powerpc/ftgl/lib/=20
libftgl.a /sw/lib/libfreetype.a =20
/Users/ranch/projects/blender/../lib/darwin-7.0.0-powerpc/gettext/lib/=20=

libintl.a =20
/Users/ranch/projects/blender/../lib/darwin-7.0.0-powerpc/iksolver/lib/=20=

libiksolver.a =20
/Users/ranch/projects/blender/../lib/darwin-7.0.0-powerpc/moto/lib/=20
libmoto.a =20
/Users/ranch/projects/blender/obj/darwin-7.0.0-powerpc/blender/=20
readblenfile/libreadblenfile.a =20
/Users/ranch/projects/blender/obj/darwin-7.0.0-powerpc/blender/src/=20
libsrcpublisher.a /sw/lib/python2.2/config/libpython2.2.a -lGLU -lGL =20
-lz -framework Carbon -framework AGL  -framework QuickTime -framework =20=

CoreAudio -framework AudioUnit -framework AudioToolbox =20
/Users/ranch/projects/blender/../lib/darwin-7.0.0-powerpc/sdl/lib/=20
libSDL.a -framework Cocoa
ld: Undefined symbols:
_do_effects_panels
_effects_panels
make[1]: *** =20
[/Users/ranch/projects/blender/obj/darwin-7.0.0-powerpc/bin/blender] =20
Error 1
make: *** [all] Error 1
[Doritoss-Computer:~/projects/blender] ranch%




On May 3, 2004, at 9:17 AM, Leon Turner wrote:

> Hi All,
>
> I've updated the patch and the windows binary (same links as before):
>
> http://reblended.com/www/leon/bfpatch.txt
> http://reblended.com/www/leon/bf-blender.zip
>
> There are a few improvements:
>
> 1) I've changed the triangle intersection routine to the one suggested
> by Alex below. It also checks both triangles of a quad, so non-planar
> quads should no longer be a problem. Calculation times are a little
> slower (but not too much, and the result is better), so any speed
> improvement suggestions welcome!
>
> 2) I've added a "contact force" element which kicks in when particles
> are moving in contact with the surface. The result is that leaks
> should be pretty much gone, unless the deflector itself is moving.
>
> Alex - I wasn't sure whether transforming the particle co-ordinates /
> velocities to object space would help much, given that I need to cycle
> through many possible deflection objects. What do you think?
>
> Cheers
>
> Leon
>
> On Sun, 02 May 2004 11:32:51 +0100, Alex Mole <nal@blueyonder.co.uk> =20=

> wrote:
>>
>> Hi Leon
>>
>> [apologies for huge post...]
>>
>> reblended.com is back up again now :)
>>
>> I have a few optimisation tips for this code, which should easily =20
>> speed
>> it up enough that you'll be able to treat all quads as tris.
>>
>> For every particle, every deflection mesh gets converted to world
>> coordinates. This means potentially a lot of duplicated effort [not =20=

>> too
>> much for single quads, but to bounce it off interesting meshes and =
use
>> it to its full potential, there will be a lot]. Have you considered
>> transforming each particle by the inverse of the object's matrix and
>> carrying out the calculations in object-local space [and then
>> transforming back again once you're done]? That means at most 4 =
matrix
>> mults per mesh, and most likely only 2. This would probably speed it =20=

>> up
>> by an order of magnitude :)
>>
>> The other point I'd make is that pointintriangle() uses an algorithm
>> that is easy to understand, but has been shown to be much slower than
>> what is possible. M=F6ller&Trumbore presented this much faster =
technique
>> for testing whether a line segment crosses a triangle [in this case =20=

>> the
>> line segment is the line from the old position to the new position]. =20=

>> You
>> can have a look to find others at
>> http://www.acm.org/pubs/tog/editors/erich/ptinpoly/
>>
>> pseudocode:
>> params: o =3D start pos, b =3D end pos, v0,v1,v2 =3D triangle =
vertices
>> def LineTriIntersect (o, b, v0, v1, v2)
>> [returns ({REJECT,INTERSECT}, u, v, t)]
>>         e1 =3D v1 - v0
>>         e2 =3D v2 - v0
>>         d =3D b - o
>>         p =3D d x e2
>>         a =3D e1 . p
>>         if (a > -E and a < E) return (REJECT, 0, 0, 0)
>>         f =3D 1 / a
>>         s =3D o - v0
>>         u =3D f * (s . p)
>>         if (u < 0.0 or u > 1.0) return (REJECT, 0, 0, 0)
>>         q =3D s x e1
>>         t =3D f * (e2 . q)
>>         if (t < 0.0 or t > 1.0) return (REJECT, 0, 0, 0)
>>         v =3D f * (d . q)
>>         if (v < 0.0 or v > 1.0) return (REJECT, 0, 0, 0)
>>         return (INTERSECT, u, v, t)
>>
>> u&v are the barycentric coordinates of intersection on the triangle, =20=

>> and
>> t is the parametric point of intersection on the line, so that:
>> point_of_intersection =3D start_point + t*(end_point-start_point)
>>
>> There are almost certainly faster methods of doing this still, but =
the
>> above will be substantially better than the angle-summing method :)
>>
>> I'm happy to help with the implementation of this stuff [and I'm =
happy
>> for you to just ignore it, as you probably have better things to do =20=

>> than
>> reimplement your work ;)]
>>
>> One other tip, that applies to all graphics coders, is to get hold of =
=20
>> a
>> copy of Real Time Rendering by M=F6ller and Haines
>> (http://www.amazon.com/exec/obidos/tg/detail/-/1568811829/=20
>> qid=3D1083493711/sr=3D8-1/ref=3Dpd_ka_1/104-4857886-1060759?=20
>> v=3Dglance&s=3Dbooks&n=3D507846)
>> It is *by far* the best book I've seen on the topic, and covers all
>> manner of rendering techniques, intersection tests, higher-order
>> surfaces, etc. etc.). I really can't reccommend it enough :)
>>
>> Cheers-
>>
>> Alex
>>
>>
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://www.blender.org/mailman/listinfo/bf-committers
>>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers@blender.org
> http://www.blender.org/mailman/listinfo/bf-committers
>