No smooth triangles (yet)!

This 'rubber' sheet consists of 100x100 atoms (174830 springs, 99x99x2
triangles).

My machine is working on a new animation of 150x150 atoms (221710 springs,
149x149x2 triangles). There are three spheres this time. (Too lazy/dumb to
implement torus and box.) The sheet is much more flexible this time, so
probably the angles between triangles will be sharper. Maybe I'll have to
render the thing using smooth triangles.

BTW should I normalize the normal vectors of the triangle mesh?
(#declare NormVec = NormVec / vlength(NormVec); )

Post a reply to this message

The collission detection doesn't need much extra time, because those
bounding things work really fast.

In fact I created those boundbox animations for testing purposes.
As you could see those boxes have different colors.
The color of a box shows if there are collissions between atoms inside the
box or between atoms of that box and atoms of a neighbor box.
(There are 26 neighbor boxes. Just check the first 13 of those neighbors,
otherwise you'll check the same collissions twice and would be a waste of
cycles.)
The colors of the boxes:
 - blue: no collissions
 - red: collissions between directly connected atoms --> ignore
 - yellow: collissions --> add springs to push atoms apart.

Post a reply to this message

"Apache" <apa### [at] yahoocom> wrote in message
news:3c60c70c$1@news.povray.org...

> No smooth triangles (yet)!
>
> This 'rubber' sheet consists of 100x100 atoms (174830 springs, 99x99x2
> triangles).

Well, it looks really smooth!

> My machine is working on a new animation of 150x150 atoms (221710 springs,
> 149x149x2 triangles). There are three spheres this time. (Too lazy/dumb to
> implement torus and box.) The sheet is much more flexible this time, so
> probably the angles between triangles will be sharper. Maybe I'll have to
> render the thing using smooth triangles.
>
> BTW should I normalize the normal vectors of the triangle mesh?
> (#declare NormVec = NormVec / vlength(NormVec); )

I suppose that POV normalizes them, because I don't and they look ok.

Fernando.

Post a reply to this message

Apache wrote:

> No smooth triangles (yet)!
>

There is another possibility. You could use your atoms as the
four inner points of a bezier patch and interpolate the border
control points.  This way you will get a surface that is by
definition continuous and smooth. It may increase the computation
time as internally they are converted to smooth triangles (I think),
but you may also be able to reduce the number of atoms.

Post a reply to this message

Some more info about my current sheet program:
It needs the following variables for input:
 1. Atom coordinates
 2. Stiffness value (higher stiffness --> more springs between atoms)
 3. Stepsize (smaller steps --> better results but slower movements in
animation)
 4. Steps per frame (more steps --> faster movements in animation)
 5. Amount of frames (ehhmmm... more frames --> longer animation)
 5. Solid objects data (sphere coords and size)
 6. Collission distance (minimum distance between not-connected atoms)

the current version of my program sorts out which atoms should be connected
by springs. So there's no need to do find that out by yourself.


If I decide to create a more user-friendly cloth-application, I'll have the
following 'to do' list (in no particular order):
 1. Fur   or Furr, I don't know :-)      (Not sure about this one, but it
would be very nice thing)
 2. Thickness of material  (A sheet won't be infinitely thin anymore)
 3. Smooth triangles / bezier patches (I was thinking about that one some
days ago)
 4. User defined springs (You decide which atoms will be connected by
springs, how stiff those springs are and how long they'll be)
 5. External forces: wind
 6. External forces: moving solid objects
 7. Output in 3.1 povscript that parses easily (with #declare I = I + 1; and
all)
 8. More solid objects like cones, boxes and toruses and triangle meshes,
including transformations.
 9. Resume option (If I would stop the program now, I'll have to start from
T=0 all over)

If number 4 very funny things are possible: sleeves or different cloths that
are interacting wich eachother.

Adding support for triangle meshes is just a small step. All solid objects
can be approximated by a triangle mesh, so I can skip the support of all
other solid objects.But I'm not sure if that would be a wise thing to do,
because testing for a sphere is much faster than testing for a bunch of
triangles. It will all depend on the speed and efficiency of my collission
detection bounding boxes algorithm and implementation.

Post a reply to this message

On Wed, 6 Feb 2002 07:31:52 +0100, "Apache"
<apa### [at] yahoocom> wrote:

> - yellow: collissions --> add springs to push atoms apart.

This approach gives rise to some problems:

1. It is a feedback approach, i.e. it corrects the error after it has
occurred. In this case, self-intersection may need several integration
cycles to be corrected, depending on inertia. Using a feed-forward
approach to predict self-collision early is definitely better, and
harder by a factor of [choose a random large number :)]

2. You need very stiff springs to improve the reaction time of the
collision avoidance algorithm, and this gives rise to very stiff
differential equations which need either a very small step to be
solved explicitly or an implicit integration routine of higher
complexity.

3. You do not account for friction between different parts of the
cloth, even if you do for the cloth-environment interface. I would
suggest using a feed-forward approach (collision prediction) to
identify imminent collisions. Then you'll have to decompose each
atom's velocity into normal and tangent to the plane tangent to the
cloth in the intersection point (this might prove difficult). Then
friction should be rather easy to apply, and as for self collision,
you'll probably want to apply penalties directly to the offending
atoms' velocities (i.e. cancel their normal component) rather then
introducing new springs into the problem.

Hope this helps. If you keep going at the pace you're currently doing,
you might as well get David Baraff's job at Pixar before the year is
over :) Good luck!


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Some years ago my mathematical knowledge went down the drain. So I'll need
an absurd amount of time to get hold of the backward Euler algorithm. And
I've got many things, but time....
And my brain seems to be tired too... :-(
And.... I really want to start a good city planning and generation thing for
a big animation project I'm working on. And I want to do this all in C so I
can get some BIG speed improvements.

Anyhow, before implementing backward euler I should rewrite some of the code
and make the executable publicly available and easy to use for other
pov'ers.

Post a reply to this message