[ODE] GIMPACT merged to trunk

[Francisco Leon]

Hey man!! Thanks a lot.

At this point you've done the dirty work !!! (:D :D
cheers!)

--- Jason Perkins <starkos at gmail.com> wrote:
> A big question for Francisco: at
> collision_trimesh_gimpact.cpp(474)
> you call FetchTriangle() and use the results, but
> you never
> implemented FetchTriangle(). I filled in with an
> assert for now.

Oh, excuse me, I haven't cleaned the ODE-GIMPACT patch
yet. In the past FetchTriangle was used only for
trimesh collisions, but with GIMPACT this function
becomes unnecessary. So I didn't decide what to do
with that function.

--- Jason Perkins <starkos at gmail.com> wrote:
> A couple of notes: I only applied the changes
> directly related to
> GIMPACT support. So the trimesh/box "null normal"
> fix and the
> autodisable fix were not applied. Those should be
> submitted and
> considered separately.

I've noticed that you've done a very carefully,
meticulous work with this SVN. That is valuable.

I'll explain briefly what means those ODE changes:
-  Concerning to the trimesh/box "null normal" patch,
As I many people noticed that sometimes boxes passing
through trimeshes unexpectly. So That fix becomes
urgent. I've fixed it on the GIMPACT implementation, 
but with OPCODE it still remains.

-  Concerning to the autodisable fix patch, It is more
an "ODE fix" than a "ODE-GIMPACT" fix. That was an old
known bug from ODE, and that bug makes harder to
setting  auto-disable values safely. So you should
consider to include this patch ("util.cpp"). No body
will be damaged.

--- Jason Perkins <starkos at gmail.com> wrote:
> test_trimesh fails with GIMPACT, apparently because
> the triangle
> winding is wrong. We need to fix either GIMPACT or
> OPCODE so that it
> works consistently.
> 
> I think that's it for now. Give it a try and let me
> know what you think.

Yes, it happens. At this moment, I don't know why it
happens. But on my Gammaleon Engine static trimeshes
behaves very well, you will notice it in the Gammaleon
Demos: The whole scenary is a large trimesh. So it is
an unexplainable exception, may the "testtrimesh.exe"
demo was written unproperly. With standar OpenGL
meshes it should never happens.

--- Jason Perkins <starkos at gmail.com> wrote:
> That was messy, but GIMPACT is now merged with the
> ODE trunk. For the
> time being, I have added the GIMPACT sources
> directly to the ODE
> repository. If Francisco sets up a separate
> repository later we can
> link there.
> 
> For the moment, you will need Premake
> (http://premake.sf.net/) to
> build with GIMPACT. In the future, once we've
> cleaned up all the
> #if... blocks you will be able to flip a switch in
> <config.h> but
> until then. In the ode/build directory run
> 
>   premake --with-gimpact --with-tests --target xxx
> 
> ...where "xxx" is one of vs2005, vs2003, vs2002,
> gnu, or cb-gcc (type
> `premake --help` for help). That will create a
> solution ode.sln (or
> makefile or whatever) you can use to build ode and
> the tests. Works
> for Visual Studio, might have issues elsewhere,
> YMMV.

You have to excuse me, but the SVN Development Style
still confuses my mind. I'm trying to learn how it
could benefits the developent process.

I'm a quite rustic in my programming style. So when I
make changes to a source, I make them coarsely,
somehow violently. Usually I didn't care about ripping
or dropping code, and sometimes I love the Idea of
refactoring the whole system. ( That's because  I feel
comfortable with the XP programming style ).

However, thanks a lot man. I will try to move GIMPACT
to SVN too, and I'll complete the documentation of
GIMPACT (Explanations of the algorithm, Advices,
Limitations) as my best. 

Thanks to understand my limitations.

We'll keep talking about these topics. 


 
__________________________________________________________________________________________
Check out the New Yahoo! Mail - Fire up a more powerful email and get things done faster. 
(http://advision.webevents.yahoo.com/mailbeta)