BEPUphysics

I tested the BEPU demo on my Samsung Focus. Seemed to work just fine except for the car demo. The car demo was completely unresponsive and looked like something was wrong with the terrain mesh.

Is the developer of BEPU going to get a Windows Phone 7 phone soon?

Is the developer of BEPU going to get a Windows Phone 7 phone soon?

Yes, as soon as possible.

In the mean time, I'm still trying to figure out why the behavior differs so much between the emulator and device when it comes to meshes. It might be different in other ways, but it appears the common thread amongst the reports so far is the content loading process.

I assume that it has something to do with the way the TriangleMesh model->vertex/index buffers convenience method is working on the Models, but I don't know why it would be different between the emulator and device.

There's always the option of creating a TriangleMesh directly from vertices/indices without using that convenience method, but it would be really nice to know what is going on. One report I got a while back implied something on the Microsoft side, but that was back in the beta and that particular problem may have been fixed.

Could you describe what the terrain mesh looked like? Were triangles misshapen and occasionally shooting off to NaNs or infinities?

Here's a pic of the car screen. The car would not move.

Interesting, thanks.

i got the same thing... also have a samsung focus but i dont know if that matters

I'm currently waiting on the GeoTrust identity verification to finish so I can begin testing on my new device (also a Focus), so it shouldn't be too much longer before I find the cause or work around it.

I've got it running and reproduced that scene. About 2/3's of the vertices are indeed junk. It seems the intense lag is being caused partially by the hierarchy choking on that vast number of junk degenerate entries.

My estimate of 2/3 was based on the number of values in the vertex list that were set to (0,0,0). Further investigation reveals that many of the non-zero entries are incorrect also. This might be caused by the .fbx importer.

Narrowed it down a bit more. Since drawing models works fine (directly using their vertex and index buffers), it doesn't appear to be an issue with the actual importer. A simple test application shows that the extracted vertices drawn by themselves are completely different than the original Model drawn along side it, implying that something about the GetData methods or their usage is goofy.

I posted on the msdn forums (http://forums.create.msdn.com/forums/p/ ... spx#407742). Putting something up on Connect might be necessary.

By the way, to anyone affected by this issue, I recommend using a custom content processor to collect the vertex data. I haven't tested it yet, but it should work.

Given that this is a known bug with the used overload of GetData, I'll see what I can do to work around it and release a v0.14.3 (with a few other minor fixes too).

Norbo wrote:Given that this is a known bug with the used overload of GetData, I'll see what I can do to work around it and release a v0.14.3 (with a few other minor fixes too).

Glad you got a device! I checked out v0.14.3 on my Focus. Looking good!