Page 1 of 1

BEPUPhysics with Monogame 3.2

Posted: Sun May 18, 2014 4:51 pm
by IAmCole
I'm trying to use the BEPUPhysics engine to power a game I'm making with Monogame 3.2. I'm using the BEPUPhysics Monogame fork, but I'm having some troubles. I'm getting the following error

Code: Select all

using System;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;
using Microsoft.Xna.Framework.Input;
using Microsoft.Xna.Framework.Storage;
using Microsoft.Xna.Framework.GamerServices;
using BEPUphysics;
using BEPUphysics.Entities.Prefabs;

Code: Select all

space.Add(new Box(Vector3.Zero, 30f, 1f, 30f));
Argument 1: cannot convert from 'Microsoft.Xna.Framework.Vector3 [c:\Program Files (x86)\MonoGame\v3.0\Assemblies\Windows\MonoGame.Framework.dll]' to 'Microsoft.Xna.Framework.Vector3'

It looks like Monogame has rewritten the Vector3 class from Xna.Framework, but BEPU wants the original Xna.Framework.Vector3. I can of course reference xna binaries in my monogame project and use the Vector3 that BEPU wants, but that means I'll be having to use 2 different versions of seemingly identical classes (not to mention the hassle of specifying which one I want everytime I use it in code).

I tried to strip out the XNA references from BEPU and add in the monogame.framework reference, but to no avail (internal BEPU calls using vector3 gave me the same type mismatch error). Is there something I've done incorrectly in setting up my game project and/or is there a way I can fix this?

Re: BEPUPhysics with Monogame 3.2

Posted: Sun May 18, 2014 5:30 pm
by Norbo
I didn't create the monogame fork, but at a glance, it looks like it is currently just the XNA version of v1.2.0 with no modifications.
I tried to strip out the XNA references from BEPU and add in the monogame.framework reference, but to no avail (internal BEPU calls using vector3 gave me the same type mismatch error).
If monogame's references are a drop-in replacement, then swapping references on all related projects should work. Both BEPUphysics and BEPUutilities references would need to be updated.

That said, v1.2.0 is 2 years old. A lot of improvements have been made since then. The new versions rely on their own BEPUutilities math, so making the engine use monogame math would take some work. It would be easier to just toss some implicit casts into the relevant BEPUutilities math classes to and from the monogame equivalent types. That would cover most of the API interactions.

Re: BEPUPhysics with Monogame 3.2

Posted: Sun May 18, 2014 5:38 pm
by IAmCole
Thanks for the quick reply. I'll see if I can follow your recommendations and get it to be manageable. My biggest worry is that as the game grows to a larger scale, I'll end up having to sink too much time into massaging things that could take away from game development time. Thanks again for your time spent addressing my questions and working on BEPU!

Re: BEPUPhysics with Monogame 3.2

Posted: Tue Jun 27, 2017 5:30 pm
by Nablablan
Hi, I am porting now (finnally!!!) to monogame and thus also to the actual BEPU engine, which I didn't do because of monogame.

So now the implicit conversions do not work.
Before, I just did things like
BEPUutilities.Vector3 asdf = new Microsoft.XNA.Framework.Vector3(1,2,3);
and it added an implicit conversion.
What do I need to make this work again?
I created a new Monogame project put in all my files. Added my GameEngine project (which is my higher level algorithms)
Then added BEPUutilities, BEPUphysics, BEPUphysicsDrawer and ConversionHelper to my solution.
I referenced all four of them in my new monogame project.
I had several hundred of these conversion errors. Then I also added the monogame reference to the GameEngine project and
now it is only 30 errors.
However it says:
Error CS0030 Der Typ "BEPUutilities.Vector3" con not be converted into "Microsoft.Xna.Framework.Vector3"
in some places.
The ConversionHelper only contains this single file which purpose is to remove those problems, right?
I don't understand these "Convert" methods is it part of c#?

Re: BEPUPhysics with Monogame 3.2

Posted: Tue Jun 27, 2017 5:47 pm
by Nablablan
I am so confused, has there been implicit conversions in oder BEPU versions? It did work, I am shure.
But the whole internet tells me, that it is not possible to do that.

Edit: okay, the answer is yes, there is a region called XNA Extension hahaha.
Why is it not incuded now?

Re: BEPUPhysics with Monogame 3.2

Posted: Tue Jun 27, 2017 7:52 pm
by Norbo
Hi, I am porting now (finnally!!!) to monogame and thus also to the actual BEPU engine, which I didn't do because of monogame.
BEPUphysics does not require monogame. The actual physics library is contained in the BEPUphysics project, which depends on the BEPUutilities project. (There's also BEPUik, but you most likely won't need that.) None of these depend on monogame.

The other projects are there only for the demos, and only the demos make use of monogame. You don't need the demos to make a game, and in fact, it would be a really bad idea to try to make use of the demos renderer for that purpose- it's not very good!
I am so confused, has there been implicit conversions in oder BEPU versions? It did work, I am shure.
In some older forks, I did set up some implicit conversions if I remember right. Those don't exist in the recent version because I wanted to keep the main libraries mostly free of external dependencies. In order to add in implicit conversions to the BEPUutilities types, BEPUutilities would have to depend on whatever package provides those other types- like monogame or XNA.

Not everyone uses monogame, so I didn't want to take that dependency. You're free to add the implicit conversion operators to the BEPUutilities types if you want, though.

Re: BEPUPhysics with Monogame 3.2

Posted: Tue Jun 27, 2017 11:28 pm
by Nablablan
yes you are right of course. but i am using the physicsDrawer very often because its the only thing that gives me the positions without doubt. heck i had all my items misplaced for the longest time because of an offset that wasnt quite right. the colored wireframes that take seconds to create, slow down everything and crash if there are too many, they help a lot :)
and secondly: yes it kind of was with the implicit conversions, just only now it isn't but i didn't know that.

New Problem though (https://forum.bepuentertainment.com/vie ... f=4&t=2484)