I think your not stepping the debugger through that line. Make sure your break point is set on the next instruction after float vc =dd.x; The debugger can reflect random values in variables that are not initialized.
You can verify with
float vc = 0.0f;
vc = dd.x;;
vc should be zero instead of a different number if you place the breakpoint at vc = dd.x;
Infectedbrain to break down what ApochPiQ stated simply create a class called node that contains a pointer to a node, contains a defined space either 2d or 3d, and contains a container of collidable game objects. Set a max number of game objects allowed per node. Define a node in which its defined space covers the entire scene then begin checking the number of Objects within it. If the number exceeds the max then evenly split the space with two new nodes each with thier parent set as the original node it spawned from. Then repeat that process untill the number of collidable objects is less than the max allowed with the node and add those game objects to that nodes game object list.
Then test which node your bullet is in and only check the collidable objects within that node.
That is the basis of a quad tree. For an Oct tree split the nodes by 4 instead of 2. Here is a link utilizing quad trees for terrain rendering. Its pretty much the same concept just replace vertices with enemies. http://www.rastertek.com/tertut05.html The code is in c++ but you shouldn't have difficulties making the change to c#.
There are many different formats. Its best to look at different file formats and see how thier data is stored. If you look at milkshape (to me its one of the easier model formats to load from), if I remember right, first the vertex information for the entire model is stored. Then the index, or triangle data is stored for each mesh subset which includes normals. After which the material information is stored, and then finally bone and weight information.
I have never had to use any such system professionally nor on my hobby projects. I certainly don’t see any point on hobby projects, and if you have to do it for work then they will tell you what to use.
I keep my plans in my head and only execute after all the plans come together and I see how the well oiled machine is going to work in its entirety.
Note that this is not the same as documentation which is much much more important. I Doxygen all of my personal engine code religiously (important considering it is meant to be sold to and used by others).
I really like doxygen but I have never taken full advantage of it because of the additional comment formats. Though I do use it to make a documentation of my code.
I use UML, but I don't bother to map out the entities' methods and attributes - it is the structural relationship between the elements that is important. A whiteboard is the best place to do this, especially when one is working in a team.
Crucially, I don't try to keep and maintain the UML as a form of documentation. The problem with this form of documentation is that it quickly gets out of date. Things like UML are best used when working something out as a team, agreeing on responsibilities, etc.
I usually do the same. When trying to work out how each of my classes will inherit from each other I will create a diagram with the classes consisting of only names.