anyone? algos for calculating good contact info for solids

yeah, I wonder about this. this is a long standing problem for which a good
solution is not apparent, and I am not clear on how to compute the "best"
contact points/normals, or even what they would be in many cases...

[note: I have looked in the faq and online, but couldn't find much
clear/helpful].


eg: obb/obb, hull/hull, ...

actually, really, I think that likely the "best" approach for obbs and hulls
is likely to be similar, but I don't know.

so, I have some half-assed approaches, which at least sort of work.

for planes/faces (eg: static meshes and bsp's), I use the face normal, and
the average of all points below the plane. this works pretty well (a
different algo is used for spheres which works better in this case...).
the limitation is, that, things like obbs and hulls will not roll off
ledges.

simple variations, such as only averaging points lieing within the faces'
volume (defined as within the space defined by the edges, and any point
below the face's plane), have unstable and otherwise crappy general
behavior.
otherwise, this is acceptable for the most part.


for obbs and hulls, I use a line passing between the objects' origins as the
normal, and the midpoint of the contact area (overlap when projected on this
line) as the approximate contact point. things will not stack. objects will
tend to roll off of each other or other similar behaviors.

it is acceptable for now, at least on the grounds that generally
interpenetration seems to be rare, objects are not flying off or spinning at
high speeds after contact, ...

this is the main one I hope for a better solution for. stacks and piles of
obbs or hulls would be cool. just, I can't come up with ideas for good
contact points or normals.

additional issues:
restitution is computed per contact, so multiple contacts on the same plane
(or similar planes) typically results in "super bounce/friction" and similar
effects;
objects may be interpenetrating at the start of a frame;
this should be "as fast as possible", so typically integration and similar
is ruled out;
current time step sizes are expected to be between around 0.01s to 0.1s;
....

basic csg based approaches may be necessary (line clipping, edge/face tests,
....), but I feel unsure about trying many of them (given the additional work
required to test vs simpler approaches). I just don't know what I would be
trying to compute using csg either...


imagining things has ruled out most previously considered approaches (normal
of least penetration, normal most directly opposing velocity, ...).
likewise goes for means for computing the points. ideas come up for which
the computed point is sub-optimal.
I have not come up for good ideas for effectively knowing when to switch
between possible calculations.


I don't really need code, just a good/understandable description of what
constitutes "best" contact info, and roughly how to go about computing it
(preferably light on "fancy" mathematical notations).

of course, something else may be wrong, that is always a possibility.



project overview [may be skipped as it is not essential to the question]:

the project is a physics engine.

it is now working enough that it should be possible to replace my old
physics engine for a 3d engine project of mine (some things have not been
tested yet though, eg, I have not tried attaching the camera to a solid and
doing things like directly adding forces/setting velocity or such).

it uses a somewhat opengl-influenced api.
the frontend api does not use any structs or classes, rather just handles
and constants used with fairly general-purpose functions for manipulation
and creation of objects.

for some things (presently just bsp's, later may include ragdoll and
similar, along with the basic solid types), an interface consisting of
begin/end pairs, properties, vertices, and normals is used. later on this
may become the preferred way to construct solids (the current approach is
use of specialized constructor functions and setting attributes to set up
the solids).

some people have before insulted my idea of not using oo for the api, but in
this case I feel that oo is probably not the best choice (and most of the
other api's I have looked at are to varying degrees oo, or have other
details I don't entirely like). what I could I tried to base my ideas on
api's I actually like, namely, opengl, posix, ...

of course, people may either like or hate my non-use of oo, but, hell, this
could be done as a "second level" (actually, I may write such a
wrapper/utility library as well, and I could use an oo interface to that,
but I have not decided yet). it is the point of utility libraries to do such
things as provide an oo interface, do basic file loading/saving, provide
nifty vector math functions, ...

imo, these do not belong in the core library though. imo, the core library
is cluttered if it provides too many features such as this. maybe it is just
an odity of mine to try to seperate these from "utility" libraries.

imo, it would be cool if there were clone libraries as well, this would give
weight to the api (eg: multiple physics engines with a common api), but I
doubt this will really happen. I have been trying to avoid (when reasonable)
exposing too many implementation details.


if I can compete well enough (eg: in terms of performance, features, and
behavior) with existing physics engines, I may have some chance of some
people actually having interest.

for the time being, not so good obb/hull behavior, lack of some constraint
types, some solids generally being unfinished/non-working (brep/tri-meshes,
cylinders, ...), ... are likely to be problems.


in the end probably nothing I do matters anyways.

I feel alone as no one really seems interested in talking to me (online and
not).
it has become pretty much no email except spam, and lack of people
responding to any of my posts.

I can guess why though, my usual pointless crap.


.

Relevant Pages

  • Re: Library functions vs System calls
    ... portable api to the set of system functions you are interested in"). ... the libraries provide the platform to the application. ... It's none of ones business. ... not to the support for the API. ...
    (comp.os.linux.development.apps)
  • Re: Library functions vs System calls
    ... portable api to the set of system functions you are interested in"). ... the libraries provide the platform to the application. ... It's none of ones business. ... not to the support for the API. ...
    (comp.os.linux.development.system)
  • Re: strange error when accessing TLS data
    ... POSIX interface to handle TLS. ... not an API. ... static linking against shared libraries, ... block allocation for static TLS. ...
    (comp.programming.threads)
  • Re: is the C library a wrapper for windows API?
    ... Am i right in saying that the C library i use on a windows machine ... Big parts of the C library can be implemented in a platform-independent way, and those may use particular calling conventions but not need to defer to any external API implementation that calls such an API). ... The former will only work on Win32, the latter on a great multitude of platforms. ... You may not always be able or even willing to use libraries to increase portability, but it's worth thinking about it. ...
    (comp.lang.c)
  • Re: Surface normals?
    ... Wolfgang Draxinger wrote: ... it possible to provide a small example of how normals are handled? ... Look up any toping on advanced lighting techniques. ... Some legacy parts of the API, like lighting and fog, now are ...
    (comp.graphics.api.opengl)
Loading