I've been working an a custom content importer to import from the Collada files that Blender can export.

I've created some really simple Blender models to test this, such as a cube and a simple plane. By stepping through the content importer I've been able to verify that I am reading in the data correctly and with them being such simple models, I can check by hand that I have the right number of vertices and indices that I should have - 12 triangles, 8 vertices and 36 indices to describe how to draw it.

I am using a custom content processor to spit these out to a xnb file and have been able to confirm by stepping through in debug that the values that are pulled from the Collada file are being passed to the custom processor and the same values are being pulled out by my content reader. So I've confirmed I am not trying to render completely rubbish/garbage data.

The issue I have, is that although the program runs fine(!), it renders nothing to the screen. In one respect, this is good news as the xbox is not complaining about the data I am giving it so I haven't broken any fundamental 'rules' there.

I've written so much code to perform this whole process that I could be introducing problems at any stage in the process but ultimately, as soon as I call the DrawIndexedPrimitives method to send this to the graphics device, I am completely in the dark as to what is happening.

Is there any way that I can gain more visibility as to what is happening with the data I am sending to the graphics device?

It'd be very handy to know that I passed n triangles to it but it culled them because they faced the wrong way, or they were not rendered in the camera's viewport or whatever. Is there a way to find out what is going on after the draw call so I can trace back my entire process to find where I am introducing the problem?

Try this out: http://blogs.msdn.com/shawnhar/archive/2007/01/31/debugging-xna-graphics-problems.aspx.

PIX is definitely the way forward with any problem you might have, it may even solve any medical or financial issues you may be having, it's that good.

Thanks Nick,

Not sure if it will help as I am not getting any errors but I suspect once of those debug levels is going to give me an idea about what is going on.

What makes things harder is that the data may be going to the graphics device fine but it would be being back-culled or transformed off the viewport *after* directx has passed it to the shader. I'm going to need to strip out a lot of my engine and try to just render something that can answer my questions. I'm thinking two triangles, back-to-back (to get around backface culling) and remove all translations/rotations so I increase the chance of it appearing dead in the centre of screen.

It feels like debugging a houses electricity system through the letterbox on the front door.

Adam Miles:

PIX is definitely the way forward with any problem you might have, it may even solve any medical or financial issues you may be having, it's that good.

:-) I do have a few a jobs around the house that could do with some attention, I'll give it my best shot! Thanks for making me laugh out loud so late in the day!

cannontrodder:

What makes things harder is that the data may be going to the graphics device fine but it would be being back-culled or transformed off the viewport *after* directx has passed it to the shader.

That's exactly where PIX comes into play.

Single-frame capture mode, find the draw call you are interested in, and use the mesh debugger.

I've taken a little time off to start documenting my progress on my blog as I was feeling a bit down about trying to track down where I was going wrong with this but I've installed the SDK and had a look through the PIX help file.

PIX looks so unassuming when you run it but having looked at what it is capable of, I'm stunned. The following image from the help file puts into pictures exactly what I needed to be able to do:



I just never thought there would be a free application provided by Microsoft that would bring clarity to my state of stumbling-around-in-the-dark state! Whoever made the decision that this app needed to be written clearly felt my pain at some point. Bravo.

PIX is pretty sweet. I have kind of a love/hate relationship with it, because I only ever use it when struggling with some horrible rendering bug, so I mentally associate it with being frustrated and things not working, but that's not really fair because my bugs aren't PIXs fault :-)  It can take a while to get the hang of, but it's a very powerful tool with a lot of depth to really understand what your graphics code is doing.

Good luck with the Blender importer, btw: that sounds like a pretty cool project...

PIX is right up there with VTune and Valgrind in terms of coolness.

In addition to being able to trace your D3D calls for an entire frame, the source-level shader debugging is just plain awesome.

Just to bring a little closure to this and supply a happy ending(!), I managed to fix things using PIX.

I was sending the right number of vertices and indices and my indices were indeed correct. My vertices were all set to (0,0,0) though. By going into the vertex shader in debug mode, I noticed that the names of the inputs did not match what I though my shader was using. My shader was transforming an input called "WORLDVIEWPROJECTION" and I was populating the inputs my vertex shader needed called "WORLD", "VIEW" and "PROJECTION". It turns out that the technique I was using was compiling the WRONG vertex shader - one that happened to use "WORLDVIEWPROJECTION" as an input.

A quick edit to fix the technique definition in the shader to point at the correct shaders and I could see geometry at last! It was completely rubbish but using PIX again I was able to trace back to a parsing error in my content importer which was not populating my vertex buffer properly. And now it works!