BEPUphysics

Hello,

I've just started writing a 3d voxel based game in mono game and BEPU seems like the clear best choice for a physics engine. I generally prefer not to clutter up my solutions with tons of other projects but instead to use nuGet when available. I did this and the BEPUphysicsDrawer assembly was not included, I download the latest stable zip of the assemblies for all platforms and it was not there either. I thought at first it had been deprecated as of 1.4.0 but that doesn't seem to be the case since it is still in the main source branch and I saw comments in the v 2.0 plan about a complete re-write. Also I download the GettingStarted tutorial which draws plenty of things without using the drawer. I assume this is because the drawer is strictly for debugging? For instance when you want to draw the wire frame or bounding boxes like in the pre-compiled demos?

To summarize:
What is the purpose of BEPUphysicsDrawer?
Why was it not included in the nuGet package or the latest stable assemblies zip?
What advantages are there to using it vs not using it which seems to work just fine? (Or when would I want to use it?)
Is it slower to use the InstancedModelDrawer all the time?
Should I only use it for debugging? (it seems like a fair amount of work to boot-strap it into the game and turn it on and off...)
Say I do want to use it and I wanted to use a compiled dll reference, is my only option to download the source code and compile it myself then add a reference? (just seems weird that it's the only assembly in the source that I cant seem to find a compiled version of)
Is my hesitation towards not just including the projects in my main games solution not warranted? RePhrased: Should I just include the actual source code in my assembly rather then consult it when I actually need to?

BEPU is a truly awesome product, kudos to everyone who has helped make it what it is today!

Thanks,
Mitch.

What is the purpose of BEPUphysicsDrawer?

Primarily, to render the test scenes in the BEPUphysicsDemos. Secondarily, to provide physics debug rendering for XNA games.

Why was it not included in the nuGet package or the latest stable assemblies zip?

1) It relies on XNA, unlike the library itself, and the number of people using using XNA is decreasing with time.
2) It's mostly a demos thing.
3) I'm pretty lazy about precompiled releases.

What advantages are there to using it vs not using it which seems to work just fine? (Or when would I want to use it?)

It could potentially be useful for debugging other graphical representations of the physics, at least in XNA-based applications. For example, if the physics shape doesn't match the graphics shape, having a direct visualization of the physics shape could be handy in figuring out the mismatch.

Notably, I don't even use it in my other projects- both because they don't use XNA, and because the other projects have sufficient visualization already.

Is it slower to use the InstancedModelDrawer all the time?

I'm not clear what the comparison is against, but the InstancedModelDrawer is definitely not super duper high performance, and I wouldn't recommend having it on unless you really need it.

Should I only use it for debugging? (it seems like a fair amount of work to boot-strap it into the game and turn it on and off...)

Yes, it's really not a good general purpose renderer; its value is very limited.

Say I do want to use it and I wanted to use a compiled dll reference, is my only option to download the source code and compile it myself then add a reference? (just seems weird that it's the only assembly in the source that I cant seem to find a compiled version of)

It's also in the precompiled demos download on codeplex.

Is my hesitation towards not just including the projects in my main games solution not warranted? RePhrased: Should I just include the actual source code in my assembly rather then consult it when I actually need to?

I do understand the reticence to pollute the solution, and I tried to do reference-only stuff for a while in internal development. A few things changed my approach:
1) The application(s) got big and there were over a dozen projects anyway, so I had to find ways to deal with the solution complexity regardless (e.g. adopting faster navigation habits).
2) I end up making small changes relatively frequently to BEPUphysics, and it was a pain to not have it immediately available. BEPUphysics twiddling probably won't be as common for a non-BEPUphysics developer, but I do similar things for some other dependencies like the corefx repo.
3) Debugging is made a little easier when you can dive directly into dependencies and make changes to illuminate problems more clearly.

One of the biggest reasons to use a built-from-source approach is that I just don't keep up with precompiled builds:
1) The last couple of packaged releases have had over a year between them, despite pretty frequent commits in the interim.
2) It's unlikely that I'll release a 'stable' precompiled release for BEPUphysics v2.0 this year, but there's a chance I'll have something runnable and useful before the end of the year sitting in a public repo.

Ideally, I'd set up an automated build that just handles it all so you could pull a build of whatever assembly with the latest changes right off nuget or wherever. I might get to that someday

BEPU is a truly awesome product, kudos to everyone who has helped make it what it is today!

Glad you like it

Thanks so much for all of the clarification, you answered all of my questions!

Ironically (Or maybe it isn't technically, I like to pretend that word means things it doesnt) I ran into an issue, and ended up adding all the source code to my solution about 10 minutes before you responded. It was my own fault, forgot to cast to a float and set the time step setting to 0 which it did not like haha. Other than that, everything has been going great, thanks!