This will probably get me 'flamed' but I felt I had to mention it and please note I've posted this in the "Requests and Feedback", emphasis on 'Feedback'.
The way newton uses callbacks seems to be a limiting factor in my game in that, it forces me to have a lot of static member functions. The alternative is to use global functions or store pointers to other objects in the 'UserData' of a Newton object. I can see that this is a good idea for the material callbacks - such as two objects colliding and I've written functions to deal with that but.. is it really necessary to have the 'ForceAndTorqueCallback' ?
I'm sure quite a few people won't even see this as a problem but my feeling is that after looking at the Newton 1.6 examples, which use callbacks even more heavily, it seems like it's not always the best solution, or even needed to have so many callbacks. My problem with the 'ForceAndTorqueCallback' is simply that, it feels redundant. I know that adding a force at any time during the program isn't really good in terms of the physics integrator but, couldn't Newton just store an accumulator for the object which stores all the ApplyForce / ApplyTorque etc and then uses and clears the values during the world update step. That's literally what my code does, storing 2 vectors per object and simply passing them over during the ForceAndTorque callback. It'd speed up the program somewhat and also clean up the general flow of things.
The buoyancy system is another example of this, my view is that it would be a LOT easier to simply define a bounding volume for a "buoyancy region" which newton will then automatically apply buoyancy for using a set of parameters you define for it. The current method is fairly longwinded by comparison and requires; working out what is in water, within the 'NewtonApplyForceAndTorque' callback call 'NewtonBodyAddBuoyancyForce' and finally applying a buoyancy force within that second callback. The Newton 1.6 demos include a version of buoyancy where Newton "triggers" a callback from a material but, I still think being able to define regions is a better method than callbacks. It's redundant to have to keep passing "dFloat fluidDensity, dFloat fluidLinearViscosity, dFloat fluidAngularViscosity" to the buoyancy force EVERY time you call it and also means if you have multiple water volumes your program has to do determine which it is in, (as well as IF it is even in water) - which isn't a huge problem but, again sounds redundant as newton must already be doing some spacial indexing. The callback also has you calculate / pass over the plane equation again and again which realistically probably never changes from 'Up' and you'd only really need to pass over once during creation of the water volume (and possibly have a function to change it if for some reason your water surface changes drastically during gameplay). This may have some problems like the inability to ignore/override or to change things but - I don't really think something like 'fluidLinearViscosity' needs to change on a per frame basis, (or indeed less).
I would propose that perhaps something like:
"CreateBuoyancyRegion(dFloat fluidDensity, dFloat fluidLinearViscosity, dFloat fluidAngularViscosity, dFloat* BuoyancyPlane)"
could be used and work as I described and you could use it for other things besides water and liquids such as, an 'air lift/anti gravity lift' where in game a strong wind carries an object upwards such as the 'Wind Temple' from the famous Zelda series. It could also take the direction of the Newton 1.6 demo and accept a Newton CollisionShape to define the volume.
This post might seem terribly negative and that I'm heavily criticising Newton but that's not my intention, I'm trying to suggest improvements and I'll continue to use Newton as I do believe it's the best free physics system available and I commend Julio for the work he's doing - I'm just worried that it seems less and less like I 'integrate Newton' and more and more like I have to build my program around Newton. Which I suppose is my main concern that it's very easy to make demo's but not so easy to get working nicely with larger more complex projects. I think the callbacks are perhaps leftovers from the original design of Newton.
I think one major thing that needs addressing is "game" specific needs. Stacking up 1000 boxes is very impressive for a physics simulation but, it's rare to round a corner in the 'abandoned research station' to find 100 barrels on top of one another. I do know however that the Newton 1.6 SDK includes an enhanced character controller and vehicle 'joints' which will, I think be of far greater use to a game developer. Newton is also aimed at 'Physics Simulation' so I'm not suggesting make it all games specific but just to try to offer features games developers 'need' rather than the ones that are most impressive.
I know some of the problems mentioned might be due to the design of my program and again, most people who just make demos etc won't see any problem but, please don't post replies telling me alternatives to how I deal with the callbacks or things like "if you're not happy with newton use something else" as that isn't the point I'm making. I just wanted to state I was worried about the direction Newton is taking in it's design such as the direct integration with cal3d, as oppose to a more generic implementation which the developer can then convert to.
Also, as a final note - the new version of Newton is still in beta so.. I'm criticising something that's still in development and may change dramatically and render some of my points invalid but, I'm hoping Julio will see my constructive criticism as it's intended and take something from it as he develops the new version of Newton.