Some General Questions, Roadmap, Relation to Farseer

[ilexp]

Hello everyone,

let me preface this by saying that I'm incredibly happy to see a glimpse of life in this project again. We're using a custom port of Farseer 3.3.1 in the Duality project and have been quite happy with it for a few years. I've been considering the possibility of updating to Farseer 3.5 for performance and efficiency reasons, but abandoned the thought as there seemed to be (some of them potentially critical) unresolved issues and no further maintenance, making this switch daunting endeavor.

So, I guess the core question for me is where the project is headed:

• I don't see a license yet - what will it be? MIT or similar?
• What are the main goals and focus point for the future development of this project?
• Is there a rough roadmap on planned short term / long term improvements?
• Who is behind the VelcroPhysics organization? Are there long-term plans to open up for community-driven development and maintenance?
• How will you (short-term) handle contributions?

And, going into some more technical detail:

• The most efficient still viable way of batch processing lots of data in C# I've known so far is packing that data tightly into an array of structs. No garbage, no abstraction overhead. Any thoughts on moving into that direction for some of the internal data structures on critical paths?
• Are there plans to get rid of the XNA / MonoGame dependency?
• What are the main to do points on the technical side?

Apologies if my posting is a bit like "falling through your front door" - just very curious and I thought it wouldn't hurt to ask :)

[OlegSkripnyak]

Well, if its general questions, let me ask.
See, i have some platformer game, where each 64x64 sprite has corresponding 1.0x1.0 body, and actual sprite transformation matrix is calculated based on translation & rotation of the underlying body, which feeded to the GPU vertex shader
Now, i want to clue 2 sprites together firmly, and don't see how - if i could findout the transformation of a fixture of the body so i can transform the sprite linked sprite, it can be solved.
PS. Actually now i use WeldJoint, but its not suitable because its not actually fixed, so in collisions there are holes in sprites appeared.
Any ideas ?
PPS. Found on inet some FixedJoint for Box2D with equations, tried to implement this in the Farseer without success :(

[ilexp]

@OlegSkripnyak This is not intended to be an aggregate thread for questions regarding usage of the library. Please create a different issue for those.

[OlegSkripnyak]

@ilexp Well, it maybe feature request ?

if i could findout the transformation of a fixture of the body

[Genbox]

@ilexp Hi, glad to hear.

As for your questions, I'll number them in order below:

1. I will have to work on license stuff. There are a couple of things I need to consider first, one being that I have a few contributions in the code written by some awesome people back when it was FPE. I don't want to step on their toes, so I will add a license that is compatible with MS-PL, which they contributed under, and in the future, I will add an agreement to it such that I can relicense contributions in the future.

2. I have no idea. I wanted to release the new samples that never got released and I want to make full use of nuget. Some bugfixes, cleanups etc - as for new features, it will be limited since I don't have too much time for this project.

3. Not really. I hope to look at some of the improvements made the past 4 years in the physics field and work on that.

4. I am - as the only one for now. I used to have a couple of active contributors that made some of the really awesome features now in Velcro Physics. There will be a page soon acknowledging their contributions (their names are in the source and have always been).

5. It depends largely on what those contributions contain. I'd like to focus on the physics engine and associated tools. In FPE I put too much effort into maintaining many different platform, which Microsoft slowly killed anyway. The XNA discontinuation was the final blow to FPE.

6. You are completely right. The project is now using Roslyn instead, which changes a lot of the assumptions I made back in FPE for the hundreds of micro-optimizations I made by hand. It might sound stupid to do micro-optimizations, but FPE were actually 20% faster than Box2D with no algorithmic changes. I wrote a lot about this back in 2007-2010. As always, I'll try to optimize the engine - any improvements are welcome.

7. There is no XNA / MonoGame dependency. There has always been a plain old .NET Framework (and now .NET Standard) version with 0 dependencies. You might think it has an XNA dependency due to the fact that Vector2 (and the like) are in the XNA namespace, however, that is just a trick to provide zero-copy compatibility when people are using XNA (and now MonoGame). I tried a lot of solutions to abstract the Vector2 stuff away from XNA to provide zero-copy for other frameworks, but they all just seem to make the problem worse.

[Genbox]

As for the features, I brushed off an old todo file and added some of the new stuff I've been thinking about. See the ideas page

[ilexp]

Great answers, thank you!

I will have to work on license stuff. There are a couple of things I need to consider first, one being that I have a few contributions in the code written by some awesome people back when it was FPE. I don't want to step on their toes, so I will add a license that is compatible with MS-PL, which they contributed under, and in the future, I will add an agreement to it such that I can relicense contributions in the future.

The biggest concern for me will be whether I'll be able to upgrade to VelcroPhysics in the future, e.g. whether it continues to be compatible with the MIT license that Duality is using in the sense that we're allowed to make changes and release a binary that will be packaged along with the framework. It seems like the answer will be yes - but for obvious reasons I'll wait until there's an official license file around here :)

Some bugfixes, cleanups etc - as for new features, it will be limited since I don't have too much time for this project.

In my opinion, the project doesn't "need" more features anyway and I'm 100% supportive of any decisions away from elusive billboard-ready features that sound great, vs. maintaining, optimizing and polishing what's already there in order to ensure great infrastructure for developers to use. 👍

As always, I'll try to optimize the engine - any improvements are welcome.

Great, glad to hear. In case you're open for brainstorming some more specific topics, feel free to ping me in an issue thread or another.

There is no XNA / MonoGame dependency. There has always been a plain old .NET Framework (and now .NET Standard) version with 0 dependencies. You might think it has an XNA dependency due to the fact that Vector2 (and the like) are in the XNA namespace

At least for Farseer 3.3.1 I've had to remove some of the math stuff and replace some others with a wrapper class in order to compile it without that reference. But maybe I missed something, or got unlucky on the specific version I forked. In any case 👍 for the continued goal of a framework agnostic version.

As for the features, I brushed off an old todo file and added some of the new stuff I've been thinking about. See the ideas page

Sounds good, especially like the unit tests and feature demo part. You may have thought about that already, but in my experience sample projects serve an excellent second purpose as a standardized testbed for checking engine behavior and also reproducing bugs that people report. Switchable narrow phase sounds interesting on the extensibility side, although I'm lacking the domain knowledge to understand exactly what this means.

I realize that you're still in the cleanup / maintenance / setup phase of reviving this project, so I won't spam your issue tracker with feature requests and all that, but maybe I can share an informal list of things that I would appreciate being tackled at some point or another. Not expecting a concrete response, just some impressions:

Note that I'm still on Farseet 3.3.1, so feel free to disregard what's already obsolete

• There seems to be no way to safely replace or adjust a fixture that is already on an in-simulation body. Whenever that is required I usually re-create the entire body to be sure that everything works as expected, which is fine in some cases, but not great for things like an object gradually scaling up every frame or similar. Would be awesome if there was a way to "update" a bodies fixtures.
• A lot of the API are convenience wrappers around what are actually quite simple calls. This makes using the library more confusing, as it's just harder to see what is vital and what isn't, and which way to use to do X. Personally, I'd prefer sacrificing convenience for clarity of only a single way to do X.
• A lost of custom collision response and resolve works by me subscribing to per-body or per-fixture events. It would be nice if there was a World-global event that would fire once after the update and provide me with a (struct- ?) list of every collision, separation and active resolve that occurred. I'd imagine that this would also be more efficient for larger scenes.
• Features that dynamically create bodies, like cutting tools or breakable bodies are hard to integrate with a game engine or game logic, because for the higher-level code that uses Farseer, those dynamically created bodies do not exist. There needs to be a way to easily associate those bodies with higher-level objects, something like an event or callback either tells me exactly "Okay, I created X and Y, because A was cut by cutting operation B, or broke because of C" or allows me to easily infer that information.
• Exposing API to allow users to pull off tricks like conveyor belt surfaces.

None of this is critical - as I mentioned, we've been using Farseer for years without problems. Think of it more as a wishlist.

In any case, thanks again for your answers to far and feel free to close this issue as you see fit.

[Genbox]

whether it continues to be compatible with the MIT license

Box2D is released under the zlib license and FPE was the MS-PL license, they are both compatible with the MIT license, and Velcro in it's current form will continue to be so.

I've had to remove some of the math stuff and replace some others with a wrapper

You used the XNA version. Had you used the "class library" version, those wrappers would already have been in there. Sorry for your trouble, I've not communicated that too well in the past.

in my experience sample projects serve an excellent second purpose as a standardized testbed

Very much so. Box2D already had a testbed project to showcase functionality and serve as a way for people to extend to help with debugging. I have already extended the testbed to include many of the features we have, but they don't cover everything.

I won't spam your issue tracker

Maintaining FPE was a nightmare and I spend pretty much every waking hour for many years on trying to help out in the forum and reported issues. I'd like Velcro to be a bit different. The main thing being transparency that welcome contributions and discussions rather than fragmented "on the whim" communication.

Not expecting a concrete response, just some impressions:

Let's get this ball rolling!

Would be awesome if there was a way to "update" a bodies fixtures.

One thing Box2D does not provide is to manipulate objects already IN the engine. This is by design. You are expected to save your "changes" into a temporary list and then do the changes before the next update happens. I "automated" this work with regards to removing and adding items to the world, by having a couple of internal lists of changes. That means, in a collision event, you CAN remove a body, but it will not be applied immediately, only right before the next update.

Could you expand on what you mean by updating a Fixture?

I'd prefer sacrificing convenience for clarity of only a single way to do X.

Arh, that is always the other edge on the double edge sword. The factories are the main way of creating stuff and attaching them together, but they are just a shorthand for writing the whole setup yourself. I kept the "old" way of doing it for people that wanted to port from Box2D to FPE. There are a couple of "usage patterns" that people use, and I'd like to keep them in place. I will actually be implementing yet another one with #6, but I'll be sure to hide it away as much as I can so that it does not confuse too much. If you have any API suggestions, create an issue with the details and let's take a look at it.

It would be nice if there was a World-global event

Alright. One thing though is that currently, if you don't need a collision, you just don't react to it. If we save all the collisions, you would probably get a list of hundreds of events in scenarios where you have stacked objects (things on terrain etc.). This unfortunately will probably slow down the whole thing rather than speed it up. That being said, it could be sped up if this was implemented as a "tracer" - you mark your objects and the engine check for that mark, and if they are marked, their events are recorded for bulk consumption. This would have to be thoroughly tested as it is not clear if it would actually perform better. Create an issue on it and let's take a look at it.

there needs to be a way to easily associate those bodies with higher-level objects, something like an event or callback

Oh, I never thought of that. I never really used it for anything other than tech demos, so I were not aware of the practical issues of using it. Please make an issue on it.

[ilexp]

Box2D is released under the zlib license and FPE was the MS-PL license, they are both compatible with the MIT license, and Velcro in it's current form will continue to be so.

Great!

You used the XNA version. Had you used the "class library" version, those wrappers would already have been in there. Sorry for your trouble, I've not communicated that too well in the past.

No trouble at all - certainly much less work than writing something like Farseer myself :) Your work is super appreciated and I definitely know the uphill battle of documentation.

Let's get this ball rolling!

Great! Created some issues :) Only for the things I felt somewhat confident about - the rest might follow once things have proceeded and I got some hands-on experience with the new library.

Arh, that is always the other edge on the double edge sword. [...] If you have any API suggestions, create an issue with the details and let's take a look at it.

Nothing specific, I think I'll leave this for now and get back to you with an issue once that changed.

One thing Box2D does not provide is to manipulate objects already IN the engine. This is by design. You are expected to save your "changes" into a temporary list and then do the changes before the next update happens. I "automated" this work with regards to removing and adding items to the world, by having a couple of internal lists of changes. That means, in a collision event, you CAN remove a body, but it will not be applied immediately, only right before the next update.

Could you expand on what you mean by updating a Fixture?

Totally makes sense, and I wouldn't change that either! The thing I was getting at wasn't actually adding or removing bodies, but the second point you mentioned, updating fixtures.

Imagine you have a body that changes its shape, for example by changing the radius and position of a circle shape or replacing the vertices of a polygon shape. As far as I understand it, there are caching techniques in place that will break if you do that on a fixture that is part of a simulated body - so the workaround right now is to remove that fixture entirely and create a new one to be added to the body, leading to old collisions suddenly being "new" again and similar ripple effects.

What I'm inquiring about is a way to achieve the same without "deconstructing" and "reconstructing" the body, allowing me to just grab the vertices of a polygon shape, modify them as I want and have the effects applied either this or next simulation step.

However, this is really only worth considering if it is possible within the existing design of Velcro. Nevermind otherwise :)

[dsaf]

Please be aware that the name contains a registered trademark: http://www.velcro.co.uk/legal-privacy/patents-and-trademarks . I am not a lawyer so I don't know whether the difference in industries is enough.

[Genbox]

@dasf
Yeah, and I just know I will get a letter at some point trying to lecture me on trademarks. This project has nothing to do with hook and loop fasteners (actual name of the velcro product - VELCRO is the name of the company) and I'm not about to infringe on their trademark by releasing a competitive product or use their name to further this project.

Fun fact: The correct way of writing Velcro Physics is actually VelCro Physics as the full name is 'Velocity Crocodiles Physics Engine' and thus it becomes Velcro Physics. The short-hand just happen to collide with the company name of popular hook and loop fasteners maker,

[Genbox]

@ilexp

Imagine you have a body that changes its shape, for example by changing the radius and position of a circle shape or replacing the vertices of a polygon shape.

I see. This 'limitation' is also by design. Erin Catto has always been quite clear on the fact that he designed the algorithms around an imitation of the real world, and thus, features like having a shape suddenly disappear, transport (setting the position) or change it's size (in a rigid world) was out of scope. There are physics engines out there (Jello Physics) that with changing shapes, but it works with completely different algorithms that take this into account.

Changing shape or the vertices of a polygon is probably never going to be supported with this engine. Mind you that I'm talking about basic shapes here. I do support the scenario of a shape changing, but that is emulated using multiple shapes associated with a one-to-many bodies. See the Marching Squares demo in the testbed where you can free-form shapes.

That being said, Box2D was never really good at solving the whole "shape in a shape" problem, so should you suddenly change the shape to be bigger and encapsulate another shape, it will have a hard time trying to solve it by 'pushing' the inner shape out. Your best bet is to solve that yourself by using the engine collision tools to find the path-of-quickest-exit and manually move the bodies.

[Genbox]

Closing this as the questions has been answered.