gimpact with ogreode - it seems to work - well quite well...

gimpact offers a number of advantages over opcode and I think I have nearly got it working (think speed and stability!)

basically guns hit the static trimesh and stay put rather than jittering about like opcode can do...

when I had a prescaled barrel.mesh (had to scale it smaller!) - think proper wheel shapes not spheres!(eventually!!) I get dNormalization4 asserts just as two trimeshes are about to settle together (might be a problem with near parallel tris?), a trimesh will work just fine with the primitives...

I've seen something similar when I was messing round with the contrib cylinder collider and did a hairy arsed hack to add a small delta to very small values but that was ages ago, but the fact that it only happens with trimesh vs trimesh means it can already be narrowed down to one or two source files - so an ode patch might be a possibility

However (the good news) going back to an unscaled gun.mesh and it seems to work fine.

I need to do more testing...

Is this normal behaviour if you scale a trimesh node ??? (the barrel.mesh is very large and I had to scale by a factor of .1)
node->setScale(size.x * .1,size.y * .1,size.x * .1);

I've noticed the textures loose their mipmapping briefly every time a mesh is added - i do hope this is a simpleApplication.cpp bug..... (possibly platform implementation differences? RC wrinkle??)

I'm working on code I pulled from svn (for ogreode) a few days ago and OGRE 1.6.0RC1 source for ogre and ode (svn) configured with ./configure --with-pic --with-trimesh=gimpact on Ubuntu Intrepid (64-bit)

I'd like to see these improvements make it into svn - what's the best way to go about it? could someone contact me directly. I don't own windows so I will have to work with some poor unfortunate that has windows.

at the moment its restricted to single precision ode but that's not much of a caveat as I'm not convinced there's any real benefit from double precision - but I've been wrong before..
(and that's only really laziness on my part I'm fairly sure it could be made to work with both)

I'd welcome any advice or thoughts people have. I think I've covered all the major highlights of this coding session...
must.... sleep.....

Not sure if I got what you speaking of here.

Mesh scaling is bad, as it breaks normalization, better scale off-line (editor or any tool like meshmagick) meshes.

Best way is to propose patches, you can submit on ogreaddons sourceforge patch tracker.

Not sure if I got what you speaking of here.

Mesh scaling is bad, as it breaks normalization, better scale off-line (editor or any tool like meshmagick) meshes.

Best way is to propose patches, you can submit on ogreaddons sourceforge patch tracker.

I've had to modify a number of files 12+ (some of the examples didnt compile and I've not got working media for the Landscape samples?) and add in files to Makefile.am alsorts of stuff so I would have a clue where to start with making a patch... I lost track of all the stuff I've had to do!

I have commented out the original code and added the new chunks of code underneath but I'm sure I might miss a file!

tbh I need a victim errm I mean volunteer with a windows box so I know I haven't broke anything - basically a zip after I've done make distclean

I've never used patch before wouldnt I need a virgin copy from before when I started? oh and there was an odd relative path in one of the makefile.am's I had to change to suit my own layout system and this value needs getting from the user?? and I've absolutely no idea how to do this with automake, I'm guessing it could be a configure option but I did do configure --help and didnt see anything like OgreHome

So I haven't got a clue as to the best way to proceed, but anyhow gimpact does seem to work a lot better so far (fingers crossed!)