Modularize Physics

[GoogleCodeExporter]

As an alternative to branching, we could make a class for each physics
model, extending an abstract one. Then users can choose the model they want
at runtime and specify some options in the config file. It would also be
easy for them to create their own models if they are so inclined.

Original issue reported on code.google.com by michael....@gmail.com on 13 Jul 2008 at 3:22

[GoogleCodeExporter]

I've made a step in this direction: I defined an abstract class for the force
calculation, another one for the force application, and then I derived them 
with the
"legacy physical model" of nodes (Files and Persons)

To do: need to implement some configuration and runtime loading (like plugins)

Original comment by sebastie...@gmail.com on 15 Jul 2008 at 11:08

[GoogleCodeExporter]

But not sure about how to do the dynamic class loading from config file...

Original comment by sebastie...@gmail.com on 15 Jul 2008 at 11:09

[GoogleCodeExporter]

Have done some more job on this way, with configuration options.

Now, after some more reflexion, I've seen that there is a need for some class
renaming for more clarity... will wait till tomorrow to give it a though, but 
feel
free to break it all if you have any idea on that !

Original comment by sebastie...@gmail.com on 16 Jul 2008 at 10:41

[GoogleCodeExporter]

Did one more step tonight.

Notice that I did divided the job on many very small classes, instead of 
putting all
three separate classes :

Thus we have 3 classes ForceCalc -> ForceToSpeed -> SpeedToPosition that we can
implements in many ways, and then make many combination.

That sound ok... but it may have been really more simple to get the job done by 
a
sole classe named "PhysicEngine", with the three forceCalc(), forceToSpeed() and
speedToPosition() methods !

What do you think of all this ?

Original comment by sebastie...@gmail.com on 17 Jul 2008 at 11:23

[GoogleCodeExporter]

3 classes does sound excessive, I think a single physics engine with different 
method
makes more sense. The engine class should be specified in the config file and
dynamically loaded by java. Let me know if you need help the dynamic loading 
part,
but it sounds like you figured it out. 

Original comment by acgour...@gmail.com on 17 Jul 2008 at 11:36

[GoogleCodeExporter]

With recent changes to the physics model, has this issue been sufficiently 
addressed?

Original comment by nawglan on 23 Jul 2008 at 12:15

• Changed state: Accepted

[GoogleCodeExporter]

In terms of modularlization, it looks good to me. There may be tweaks needed in 
the
future, but I'll consider this issue fixed.

Original comment by michael....@gmail.com on 27 Jul 2008 at 5:06

• Changed state: Fixed