Forcefield Implementation. How to best contribute ?

i am currently writing some stuff that i thought might be useful to others too. As a concrete example i am doing a Forcefield implementation
that roughly speaking provides a way to apply global forces to your simulation. Mainly meant for things like attracting or repelling bodys,
doing simple im- or ex-plosions, introducing wind or just have it for weird effects.

Now i was wondering if i am maybe redoing something that exisits already (havent really found anything) and if it would be of interest for
others or the Farseer trunk ?

IF it is useful how would i best contribute it ? Checkout the source, add my classes and send the files as a patch ? Provide completely
seperate assemblies ? Or have them as a seperate project containing a simple Farseerproject demonstrating them ?

I am not that much of a c# guru so i am not sure wich of the possibilities (or maybe some completely different way ?) makes most sense
from both a usability and a technical point of view.

The only force generator we have is the gravity controller. The best way of contributing is to
submit a patch that contains the classes you have created and a sample that can be plugged into the testbed project. If you have changed any of the engine files, you should comment them and submit them as well.

Looks great Thorsten. I'm wondering how you implemented it, and if you have not already done it, I think you should use the Shape class as the area the force should affect. You have all you need in there to check if a point is inside a shape or more detailed
tests like polygon vs. polygon intersection. Users should be able to supply a lists of shapes the the force generator should apply force to.

Great idea there Genbox. Haven't thought about that one so far. Currently it is a very straightforward approach basically treating
bodies similar to particles, apply corresponding forces and let Farseer do the rest (wich it does great btw hehe).

In the vortex example basically i iterate over the bodies, calculate a vector perpendicular to the vector between the body
and the vortex center, scale it to a strength value, calculate a cetripetal force based on the current velocity and apply them
as forces. simple, yet seemingly rather effective. Here's a quick summery i wrote for myself as to what i was aiming for.
(This doesn't include the Shapes idea yet, but i would definitely like to see that happen!)

BTW. I am coming from a 3D Background (Technical Director at www.mackevision.de) hence my approach is leaning towards the way ParticleFlow and Spacewarps work in 3d Studio Max.
And so far i'd say that seems to work great.

To Provide some general and global forces a set of controllers will be implemented. There will be an abstract base-class derived from the Farseer controller to provide common features (as outlined below).
I am not too keen on introducing breaking changes to the current controller implementation, and i think it serves well for many other purposes so i'd say this additional level of abstraction makes sense.
I'll definitely leave that descision to Genbox tho, as he knows a LOT more about the architecture and c# in general.

Planned features for initial Alpha Version (which would basically be a first feature-freeze):

- The Path class in FPE 3.0 contains controlpoints that are used to generate a curve. If you need any curve functionality, feel free to edit the Path class and/or implement it in your implementation.

- Make sure to modularize your explosion logic. As seen in the PhysicsLogic folder, we have a rather advanced (realistic) approach to explosions (I guess it support shadowing of sorts) and I would like to keep a couple of different explosion strategies in
that folder. Another contribuer (pnikosis on the forums) implemented the explosion logic and he is working on more of them as we speak.

- FPE 3 already have a maximum speed setting in Settings.cs called max translation. But maybe it is good to have one that is force generator only.

thanks for the input. Regarding Path classes i was already thinking about some additions that are not really part of the forces part but would be still nice to have. For example having a method to adaptively
subdivide a path (converting it to edges or a polygon). 2 Methods that i got in mind from my 3d tesselation experienced. Based on a maximum angle threshold and based on a maximum chord height
threshold. That way one could make sure that parts of Paths that don't need many subdivs (=straight and only slightly curved parts) arent subdivided as much as detailed areas. Will look into that as well

Modularizing is definately high on the priority list. I will take a closer look at the PhysicsLogic parts and try to make sure not to reinvent the wheel for any of the parts!

The Maximum speed in the force generators would be useful if you have different forces with a different maximum effect. For example a wind implementation would never accelerate bodies beyond its own
speed/strength, while an explosion would still accelerate the bodies a lot more.

Just a quick question regarding the naming of things, as am not sure about naming conventions and alike.
Currently i am following this scheme:

AbstractForceController.cs (Abstract class inheriting Controller to provide the common features (wich might not be necessary or useful in other controllers ?)
VortexForceController.cs (Sample name for a force)

Objections or different wishes ? As i will be refactoring quite a bit to integrate with the core there wouldnt be much additional work involved following a different scheme

Oh and while i am at it, i was wondering if i got that right that for any tests to be carried out i'd simply implement a new test in the testbed-project ?

Just a quick question. The issue tracker looks rather empty. Was wondering if it would be okay if i'd create a bunch of feature issues to track my own progress ? More granular than the general Issue entry created from this thread (e.g. an Issue for each
force planned).

On a second note i was wondering what i am doing wrong when adding the new classes to the project. The existing classes all have a link overlay on their icons (the little error) whereas mine always appear without that overlay. I dont wanna fuck up the project
setup. Initial commit of the baseclass has just been sent :) In order not to fuck up i only commited that .cs file (in the Controllers folder) and not the whole project.

As a sidenote a quick update for those not following the comments in the issues as well as current status not there:

I am mostly done with the first implementation of the abstract base class. I did my very best to comment a lot to provide information on the properties and how to use and implement forces

I did a bunch of tests for the different modes and they seem to work fine ( Triggered: http://vimeo.com/17200349 Curve: http://vimeo.com/17201151)

I did a quick test with noise/turbulence to get my head clear in a moment i seamed a tad stuck ( http://vimeo.com/17172252 There's a LOT to be done to integrate that of course)

There's a bunch of things i want to add on top of what i outlined above (e.g. Shapes as masks as proposed by genbox, some more forces and thought about more complex forces acting on body vertices rather than bodies as a whole)

Feel free to create issues, tasks and features in the issue tracker. You can assign them to yourself - that way they appear in the "check-in" dialog when you check-in changes (if you are using Team Explorer).

The reason you don't see the link icon is that all the files are referenced as links instead of the actual files. Here is what you do:

1. Open the source control explorer. Add the files you have created to the SourceFiles folder in the correct folders.

2. Then you add them to each of the FPE project branches (XNA, Silverlight, Library) by rightclicking the same folder that you placed the files in step 1. When you add the files, you don't click the add button (!) you click the little arrow next to the add
button. Then you have the option of adding as a link.

Using links instead of the actual files, makes it possible for us to change one file and then the changes apply to all the branches. A neat little trick ;)

Ah. good to know, thanks for the heads up! Setup is a bit twisted here on my laptop (including a VPN to work :P). I am so used to using SVN from work that i didnt even look into Team Explorer and the Team Features. Will definately read up and try to get
things right.

Okay, that worked and i added the abstract base class via Team Explorer and i think that worked just fine now *phew*

Sorry for the comment-less check-in

For the record do you check things out for edit (essentially locking it in Source Control i assume?) or shall i simply work without checking things out and rely on conflict management
for the rare case (rare as i am currently only working on rather seperated parts)

Btw. had accidently checked in a placeholder instead of the actual class. Fixed. But lead me to another question.
While playing locally with the Testbed i didnt want all the other Tests to be run, but only see the Test i use for testing the class.
I simply commented out the other tests in the TestEntries file. Is there a different way i should use or is it fair game to do it
like that ?

I checkout files before working on them. However, I don't lock the files at the same time. If someone edits the file (in Team Explorer you can see what files are checked out) and submits the changes, I merge the changes manually to make sure everything is
as it should be. In your case, I would not worry too much on conflicts as the Controllers are not in focus at the moment (other than you).

As for the Testbed, I usually put in the test I just created (together with the other FPE 3 tests) and create a copy of it at the top of the test list (the first one is the first one loaded). This way I just have to remove the duplicate line at the top and
commit.

Great work so far Thorsten. I can't wait to see them in action in the testbed and playing around with it.

Hey again with another question...Engine Architecture related again this time :)

I've been thinking a bit about the DebugView part of the forces system. There might be some forces that do rather heavy draw operations in DebugView, so
i was wondering if it was feasible to keep them with the force implementation rather than in DebugView (as the DebugDraw will HEAVILY vary from force to
force). So basically i was thinking i'd give the abstract base class a DebugDraw method and in DebugView iterate over the Controllers and if a force is
inheriting from AbstractForceController simply call its DebugDraw method and let the force draw its own data.

Do you think that would work ? Or do you think it should be done differently ?

I try to keep all drawing code and out of the engine and in projects for themselves. The debug view is only responsible for taking out data that is exposed by the API and draw it in a constructive manner. Debug data as the ones you have shown in your videos
are cool to look at, but might be a little too extensive for debugging games. Debugging data can be collected in engine code, but only if Settings.EnableDiagnostics is enabled.

That being said, here is what I think:

1. Keep an extensive debug data view in the testbed. It should pool the data it need from the controller in the sense that the controller and test should be separate (decoupled). It could visualize the path bodies take (have taken) and more.

2. Create a more primitive way of visualizing the forces:
- Area of effect like in the explosions demo. (this also gives us an indication of the position of the controller)
- Perhaps magnitude of force applied?
- Could also color bodies with a different color if they are affected by a controller?

This way the debug view tell us that there is a controller and it is working. At the same time we also have a neat looking test that shows every detail of the force applied like in your videos.

Good points there. Will put some more thought into it. Seperating out all Drawing Code from the Engine is definitly a good idea. I guess i was thinking too much inside my "force box" there.
I need to find a way to add some more elaborate DebugView stuff for the forces tho. After thinking a minute i think i kinda misinterpreted "Debug" in this case. It is of course meant to Debug
a WORLD and not a force implementation. I am of course looking for ways to debug force implementations. Some things might be useful in a World Debug situation too tho.

General properties of a force should be visualized with the normal DebugView (Position, Direction, Magnitude etc). I still need to put in some thought there as they differ quite a lot from force
to force and its prolly not a good idea having to update DebugView itself when adding a new force.

In addition i think it would be neat to provide a debug visualisation class to debug force implementation during development ( kinda ForceViewer to illustrate Forces and their effect in a VectorField
like overlay or similar. Will think, but push back in priority, as for now and initial implementations this can well be done in the Testbed

sorry, left a bit of a mess in the changeset. I'll be checking in a bunch of changes soon that will have the reference to Noise removed. As i'll have to redo that properly. For now i guess it makes more sense to concentrate on getting AbstractForceController
finished and cleaned and add a basic Force as a start and then dive into the more complex stuff. Just couldnt hold myself back while playing with the classes

Well it is rather hard for me to predict the time i can actually spend working on it as that's highly dependent on the non-planning firstborn :P

Here's a quick and updated overview of what i'd say should be there before moving on to implementing actual forces.

A lot of testing for the current core functionality using SimpleWindForce as a reference implementation (demonstrating all available core features and adding some custom ones)

Some of the core features have only been quickly checked and definitely need in-depth testing once SimpleWindForce is done (mainly DecayModes, ForceTypes and TimingModes)

Make SimpleWindForce a feature complete Force implementation demonstrating all aspects of the base class and implementing some custom stuff

Make SimpleWindForceTest a feature complete test to illustrate and test all SimpleWindForce features as well as base class features

The last two being the main effort as the rest depends on these to quite some extent.
I am currently thinking about a bunch of the planned features and kind of postponed them to "later releases" somewhat as i am not sure yet how to best tackle them and where
they should live exactly. For example i think that it might be a good idea to de-couple the turbulence code from the forces implementation and just use it where appropriate to
keep the abstract base class reasonable in regards to complexity. It has already grown quite a bit over my expectations and i am pretty surprised of the pace things are going.
I usually move on a lot slower, but something just seems work with Farseer and me lol.

Long story short i am hoping to finish Core + Reference Implementation (SimpleWindForce) + SimpleWindForceTest this week.
Afterwards i will try and implement some other rather basic forces to put the base class to the test and see if it is flexible enough to handle different kinds of forces.
If that works out well i think adding the bells and whistles (turbulence for example) is on the table.

As a "side project" i have some more sophisticated but more "proof of concept" like forces in the backhand. Been playing with a fluid-force to get my head free for example (basically
simulating a fluid grid that is queried from a force to drag bodies along). But these are rather foggy and unclear at them moment and mainly used to clear my head if i feel stuck.

Just checked with the 3.2 release planning and read about the fluids there. Is this supposed to be similar to the Diver water or particle based ? Just wondering as i really dig fluid stuff :)

Sorry for the lack of updates. Been drawn in a bit of crunchtime both at work and home heh.

Anyways i did work a bit further than in the last post and things seem really messy to me as i add features. E.G. Decaymodes end up in shitloads of nested if or switch statements and that seems as if it will lead to hard to maintain let alone extend code.
And i'd love the forces system to be a solid foundation for everyone to contribute force implementations!

So i was wondering if it was a good idea to decouple things some more (yep, consulted the Design Patterns book once again hehe ) and Move DecayModes and similar things to seperate abstractBase/class combinations and maintain a list of decay modes to be used
in the actual force implementation. This would ease addition of new modes as well as enable combination of multiple decay types (e.g. Left to Right along with a slight radial one to create more complex decays).

On a similar note i am wondering if it would be a good idea to switch the force implentation away from beeing a controller directly. I was thinking about a ForceController that would apply a force, but have forces implemented seperatetly with an "EvaluateForce"
Method rather than ApplyForce. This way a force could also be evaluated for other things not affecting or affected by the simulation more easily.

Am totally not sure if these changes would help or overcomplicate things so i am hoping for opinions there.