Model With Many Meshs Disregards Bones
Re: Model With Many Meshs Disregards Bones
Thinking about it a bit more, in this specific case, I don't think .fbx is going to help- the structure of the meshes and meshparts should be indentical in either a .x or a .fbx unless I'm mistaken. Displaying the mesh should match the collision mesh; since it doesn't, it means something is still messed up. The overlap (and missing triangles) is most likely caused by not taking into account what amounts to extra instructions. What I'm probably going to do is provide an example content processor, assuming the Picking with Per Triangle Accuracy sample on the creator's club site doesn't already do exactly what is needed. Doing it that way should be easier in the end, and more robust.
Re: Model With Many Meshs Disregards Bones
Well I've found .X to be incredibly retarded and seeing as the XNA standard X file importer is pretty awful it could be the X file
Re: Model With Many Meshs Disregards Bones
After returning to this issue (having finished up some other things for v0.5.2), I did some deeper investigation and found that there were repeated triangles in the static triangle group. I'm still thinking this could be an importing problem over a model problem, but I did find that the repeats disappeared when I used a .fbx version of the model. This at least implies that the .x format confuses things- I'll keep trying things out on that front.
I've also optimized various things within the StaticTriangleGroup, so it should run a bit faster even on 'valid' meshes.
EDIT:
Just a heads up- during profiling, the draw call took a significantly higher percentage of total time than the physics. This caused FPS to dip below 60 during the simulation at times. If you're using a per-mesh draw call method like the demos, you could probably get some performance back by combining meshes.
I've also optimized various things within the StaticTriangleGroup, so it should run a bit faster even on 'valid' meshes.
EDIT:
Just a heads up- during profiling, the draw call took a significantly higher percentage of total time than the physics. This caused FPS to dip below 60 during the simulation at times. If you're using a per-mesh draw call method like the demos, you could probably get some performance back by combining meshes.
Re: Model With Many Meshs Disregards Bones
Grabbing the vertex data by using a content processor works great. I've decided not to include a content processor, as the sample on the creator's club website can be used to do it with no changes (the initialization method could be faster if the tag included indices and vertices over just a vertex list, but it still works either way).
Given this information, I'm pretty sure the source of the problems all along was just the 'naive' way the vertex/index buffers were extracted. I'll probably add some usage notes to the naive method rather than going through the whole process to get it working perfectly without a processor in the interest of getting v0.5.2 out faster.
Given this information, I'm pretty sure the source of the problems all along was just the 'naive' way the vertex/index buffers were extracted. I'll probably add some usage notes to the naive method rather than going through the whole process to get it working perfectly without a processor in the interest of getting v0.5.2 out faster.
Re: Model With Many Meshs Disregards Bones
Cool stuff ;o
.X for the loss
.X for the loss