Is anyone using the gravity modes?
I'm asking because I'm sort of urged to remove everything that has to do with them; I just tried on the test, and it's broken – I've got no idea of why it's not working, and the whole gravity thingy is a rather large chunk of code. On top of this I don't like the implementation; it's completely hardwired to the PhysicsWorld's update logic, using flags and such.
So if noone is using this I don't want to put down the effort of learning how it works and fixing it, and maybe making a cleaner implementation.
The gravity stuff is DP's creation, and he's not supporting it any longer as you know.
I intended to but never got around so far 
I think "directional" gravity (used in most tests) should stay in at least, as this one has sure proven useful.
Yup, that one is provided by ODE so it'll still work the same.
Not sure about planet and point, but PLANE mode is certainly useful as I'm using it currently.
I'd like to keep it in…how long do you think the rewrite will take you?
Can you do a parrallel implementation, and just replace it when you are finished?
best,
sv
Don't worry – plane is the default gravity and will stay there. You'll still be able to control it via PhysicsWorld.setGravity(Vector3f).
Let me clarify: I'm interested to know whether or not people are using the POINT and PLANET modes.
IIRC DP said that the PLANET gravity mode wasn't implemented correctly either and that he was planning some sort of more general solution, like a magnetism-like mode (which I think sounds much better).
Edit: okey, so not actual magnetism involving poles and such – that wouldn't be very general at all, but just a way make a point in space (i.e. the position of an object) attract objects. This could right now be accomplished by calling the explosion method with a negative force, but this isn't very practical when you want a force to act over more than one frame (an explosion only acts over one frame if you don't call it repeatedly).
Edit2: typo.
re: forces - you might want to check out the Fuze3d stuff in the AI threads. Conceptually the model of forces that boids/flockers uses might be useful.
Thanks for the tip!
Okey, I've reverted to only using normal gravity, and added a more general attraction effect.
See com.jmex.physics.effects.Attractor and jmextest.physics.effects.AttractorTest.
nice!
Yes, very nice 
, gives me steady 50 - 60 frames with 300 boxes swirling around the attractor
on linux with my amd xp1800+ 512mb / gf fx5900xt
I recently started playing with the Attractor class a bit.
Yeah, sounds reasonable to me.
But I don't use it - any comments from people using the attractors?
Well, I use an attractor in Roll-A-Rama…my first application of it was to try to set it in the middle of the field and when a score is made the attractor is turned on and the ball is pulled back to the center. However, I got scary sling-shot effects that took forever to stabalize and I believe these changes might resolve that problem.
darkfrog
hmmm…
I'm retarded! I spent the whole day working on it and finally figured out my problem. Should have been obvious. The normalizeLocal method was being applied before the calculations in the multLocal so the thing was basically dividing the force by the length of the unit vector which is 1 and giving full force at any distance. I had to create a temporary float value to hold the value while I normalized the vector. I also added mass into the equation so that all bodies are acted upon equally by the gravity. That may slow it down somewhat, but shouldn't be too significant. The result looks something like this:
float temp = (force*obj.getMass())/distance.lengthSquared();
forceToApply.set(distance.normalizeLocal().multLocal(temp));
I haven't noticed any real performance hits. All of these things only give me problems when the items all get stacked up around the attractor. Then the collisions give me stack overflows sometimes. As long as there aren't any collisions it runs smooth for me.