BEPUphysics

The BoundingBox computation for each new Terrain seems to be the primary bottleneck. If you know the whole bounding box ahead of time, you could create add a little custom constructor which takes the heights/terrain shape, a transform, and the bounding box. In the constructor, do the same things as the regular constructor but
1) set the BoundingBox to the passed in value, and
2) set IgnoreShapeChanges to true before setting the Shape property (and set it back to false afterwards). The OnShapeChanged handler just computes the bounding box for Terrains, so the passed-in bounding box makes it redundant.

Another option: because each Terrain construction is totally separate, you can build them using multiple threads. The Space.Add should only be called sequentially, though. (If you pass in a bounding box, building them with multiple threads will likely become pointless since the Terrain constructors will be basically instant.)

Bounding box computation might be a good reason for why all chunks take the same amount of time to create. And good design with the IgnoreShapeChanges.

I wish I could try this out, but I am still running on 1.2. I tried updating to the latest version from Codeplex, but it seams that it is no longer 100% compatible with 1.2. I'm getting dozens of compilation errors, anything from not being able to find types, to some function returning new types and a lot of conversion errors from BEPUutilities.Vector3 to XNA.Vector3.

This is not an update I can do in a short period of time. It will take some time and even more testing to make sure that everything works as it did before. My space is configured very tightly and even the smallest change in parameters can cause the simulation to spaz out on small objects. Even as it is, once in every few hundred collisions some objects will spaz out a bit in problematic areas. I once had a small cube get thrown into a small crevice with relatively slow momentum, spaz out for a few seconds and then change course and hit my character controller with significant force, knocking me back .

I'm getting dozens of compilation errors, anything from not being able to find types, to some function returning new types and a lot of conversion errors from BEPUutilities.Vector3 to XNA.Vector3.

Most of the missing type errors should be caused by a few namespace moves. If you have a question about a particular class, I can tell you what happened to it.

I suspect the conversion errors are due to inconsistent versions in the assembly references.

This is not an update I can do in a short period of time. It will take some time and even more testing to make sure that everything works as it did before. My space is configured very tightly and even the smallest change in parameters can cause the simulation to spaz out on small objects. Even as it is, once in every few hundred collisions some objects will spaz out a bit in problematic areas. I once had a small cube get thrown into a small crevice with relatively slow momentum, spaz out for a few seconds and then change course and hit my character controller with significant force, knocking me back .

v1.3.0 should actually handle that sort of stuff noticeably more robustly than v1.2.0. There have been quite a few low-level fundamental improvements.

The namespaces I can manage. The rest is more time consuming and difficult. Things are more complicated because I am heavily using the character controller class and camera class from the demos. I also modified them. So after fixing the namespaces and merging the controller, I was still left with 350 compilation errors. Over 100 were fixed by adding ConversionHelper.MathHelper.Convert. I can't say I like the way the new BEPU is doing the basic types. I would rather have a separate DLL for each fork than having to convert types.

Anyway, after I was finished the engine wouldn't display anything. I tried to fix it but got nowhere, so I started fresh. This time I removed all the references to the controller from the engine, leaving only the basic camera. I kept the 1.2 camera but updated the rest of BEPU to 1.3. Now I am stuck with only flying camera and no static meshes, but at least the rest seems to work fine.

I tried updating only the camera to 1.3 but again it does not render anything and somehow my entire world is marked as being inside the view frustum. I'll try and fix somehow the 1.3 camera to work with my engine and then try to reintroduce the rest of the controller. I'm hoping that the controller is more robust than in 1.2.

I have fixed the 1.3 camera, temporarily at least. What is LockedUp? I set LockedUp = BEPUutilities.Vector3.Up in the camera constructor.

I also needed to update The Yaw function: Without these changes, my view direction was always NaN.

It seems the better solution was to initialize viewDirection in the constructor. I kept the LockedUp initialization.

The good news is that the new character controller seems to be smoother. Running fast on uneven terrain is less jerky, starting to move or stopping has less of an ease in so the sky box seems to stay put and falling is also better. Getting stuck in terrain after large jumps is I think also better. I'll continue and test the new controller and the overall build of 1.3.

BTW, how far are we from a real release of 1.3?

Over 100 were fixed by adding ConversionHelper.MathHelper.Convert.

You may want to use implicit type casting if you find the conversions to be all over the place.

For example, you could put this in the BEPUutilities.Vector3 struct: This isn't done out of the box because it would require a reference to every supported math framework within BEPUutilities, but since you've got a fixed target, it could be helpful.

I can't say I like the way the new BEPU is doing the basic types. I would rather have a separate DLL for each fork than having to convert types.

That is how it currently works. XNA was 'demoted' to a fork, but it's still there (though currently out of date by a couple of months).

That said, it's too much extra work for me to merge changes continuously to all of the forks, so I typically only do it on major releases. In fact, it's tedious enough that I'm probably going to drop my personal management a couple of platforms with the release of v1.3.0. I may drop all of the forks, depending on how things shake out.

I'd much rather focus on the single platform agnostic codebase and have community members help out with any forks they wish to use.

I tried updating only the camera to 1.3 but again it does not render anything and somehow my entire world is marked as being inside the view frustum.

By the way, I generally recommend against linking too deeply to the graphics bits in the demos. They're not made for external re-use like the main engine, and I don't worry about breaking things when I'm fiddling with it. (The BEPUphysicsDrawer, which is meant to be used externally as an optional debug helper, is ideally treated as an unmodifiable black box to avoid running into breaking changes.)

I have fixed the 1.3 camera

The camera is now safety-fied.

What is LockedUp?

The characters now fully support arbitrary up vectors. In order to demonstrate it effectively, the camera was modified to allow arbitrary up vectors. The name is less clear than it could be, but it's the up vector of the camera that doesn't change as you look around (contrasted with the Camera.WorldMatrix.Up, which does change when you look around). The ViewDirection and LockedUp together uniquely specify a basis for the camera's world/view matrix.

BTW, how far are we from a real release of 1.3?

I initially planned to have it out late spring/early summer of this year. Oops.

While I have a large to-do of things remaining, v1.3.0 is already an enormous update. It's probably larger in net effect than any previous version, as would be expected given the year+ gap since v1.2.0. I could package it right now and it would be plenty good enough to justify the new version label.

It's being continuously delayed for a few reasons:
1) The continued source updates provide the majority of the benefit already. A precompiled 'dependency free' binary isn't really any more useful than the source, and, in many cases, it is actually less useful. The main extra benefit of performing a release, as far as the dependency free code goes, is having a more modern BEPUphysicsDemos downloadable executable.
2) Because the benefit is small, the other stuff I'm working on consistently wins on priority.
3) I'm procrastinating because the release process is very tedious. This is primarily because of the multiple forks I obligated myself to support. If I don't change the way I've been doing it, this release will probably take me a couple of days of solid tedium to get rolled out. That is super duper unappealing and makes me flinch every time I think about it.

Realistically, #3 is probably the biggest effect. #2, while being a good and rational explanation (the other stuff really is more important), feels like a rationalization. I probably would have ended up releasing v1.3.0 when I got bored on some afternoon if it wasn't so annoying to do.

Now that things are merged, I managed to pass in the bounding box. For some strange reason, a few of the boxes are slightly tighter when computed by BEPU, especially on the Y axis. I don't think that this will be a problem. The world creation time is down form 2.7 seconds to 0.1. Great improvement . After I test things for a few more days, maybe the new constructor can be added to the repository since it offers such a great improvement for when you know the bounding boxes. I'll further investigate if the population of the world with the static meshes performs well.

Norbo wrote: That is how it currently works. XNA was 'demoted' to a fork, but it's still there (though currently out of date by a couple of months).

That said, it's too much extra work for me to merge changes continuously to all of the forks, so I typically only do it on major releases. In fact, it's tedious enough that I'm probably going to drop my personal management a couple of platforms with the release of v1.3.0. I may drop all of the forks, depending on how things shake out.

I'd much rather focus on the single platform agnostic codebase and have community members help out with any forks they wish to use.

So if I understand correctly, the main branch uses the platform agnostic types and the forks use the platform specific types and that's the only difference?

By the way, I generally recommend against linking too deeply to the graphics bits in the demos. They're not made for external re-use like the main engine, and I don't worry about breaking things when I'm fiddling with it. (The BEPUphysicsDrawer, which is meant to be used externally as an optional debug helper, is ideally treated as an unmodifiable black box to avoid running into breaking changes.)

I'm just using the character controller and the camera just came with it. BEPUphysics is great and all, but one huge advantage it has over the competition is that it comes out of the box with the CharacterController class. It is not perfect, but helps a lot with rapid prototyping and is a lot more robust than other controllers from other toolkits. In 1.3 it is even better than in 1.2.

The characters now fully support arbitrary up vectors. In order to demonstrate it effectively, the camera was modified to allow arbitrary up vectors. The name is less clear than it could be, but it's the up vector of the camera that doesn't change as you look around (contrasted with the Camera.WorldMatrix.Up, which does change when you look around). The ViewDirection and LockedUp together uniquely specify a basis for the camera's world/view matrix.

As suspected as much and used it as such, but I was confused by the name: to look vs. to lock.

And regarding the camera, I don't like the way the new Pitch and Yaw work. I want to read and write this values like in the old camera, so I updated the implementation to provide this. I can paste the code here if you wish.

the new constructor can be added to the repository since it offers such a great improvement for when you know the bounding boxes.

I'm a little wary of tossing in additional corner case features as a baseline. I'd first like to work out a more elegant method of exposing the needed bits without offering as many subtle ways to create an partially functional inconsistent state.

So if I understand correctly, the main branch uses the platform agnostic types and the forks use the platform specific types and that's the only difference?

That and the fact that I don't merge all changes into them continuously, yes.

And regarding the camera, I don't like the way the new Pitch and Yaw work. I want to read and write this values like in the old camera, so I updated the implementation to provide this. I can paste the code here if you wish.

I prefer to prune features down to the minimum necessary set. The demos never make use of yaw/pitch reads and the camera isn't intended for general re-use, so I probably won't add them until the requirements of the demos change.