In the video, the thrusters creating torque on the y axis are opposite so there is no translation. There are no thrusters on top of the ship, but there is gravity, so they shouldn't be necesary (as far as I know, quad copters don't need propellers pushing downwards to keep level). It is to be assumed that the ships should always have opposite thrusters -- the idea is that players can customize the locations of thrusters on the ship, so they'll learn soon enough that they can't turn properly without meeting that condition. It is unstable in the video because I'm using a PID system but at the time of recording it had only implemented the P. The controller works separately for each variable (velocity, orientation, location, orientation velocity). I am however having some trouble combining these variables, but have had success correctly controlling just one at a time.
What I meant by (2) in my first post was if there's a way to algorithmicly determine which pairs of thrusters to fire to execute a turn. Right now, turning left is hardcoded to activate the front right thruster and the back left. Instead of specifically setting it to fire the front right and back left, have the AI figure that out for you. Is there a better option than to have the AI try all possible combinations of thrusters until it finds a combination of thrusters that is able to create thrust in the correct direction each time a new target is set (by try, I mean calculate the projection of the thruster's force internally for each combination, and not actually activate any thrusters until it finds the best one).
This isn't an answer to your question, but, most of the functions you are calling are deprecated now (everything in D3DX). I'm assuming you're using VS2012, so you should use the tutorials that come with the new SDK.
So is there no way to just have 3DS Max export a list of the exact vertices the triangles should use? Meaning, if I export a cube with each face in a different smoothing group, it will export three vertices per triangle (totaling 2 triangles per face * 6 faces * 3 vertices = 36 vertices), while at the same time any edges in the same smoothing group will not have their vertices duplicated? I've tried every option I could, and it seems that I can either just export a list of non-duplicated vertices and completely rely on smoothing groups for knowing whether my engine should duplicate them, or I can export a list with every single vertex duplicated for each triangle, and then the engine doesn't have to duplicate anything to render the model correctly, but it wastes a lot of memory.
Also, apparently you can export FBX in ASCII. However, the C++ SDK for FBX doesn't work with VS2012 (my main IDE). There's a link for a beta version, but they have to manually add you to it when you email them (they haven't gotten back to me yet). VS2012 lets you edit FBX, Collada, and OBJ models inside the IDE. It's pretty cool.
Yes I am aware that I should not directly import the intermediate formats to my engine, but it is a necessary step at the moment so I can learn how it works. I need to be able to parse these intermediate formats if I wish to convert the format to what my engine eventually uses.
I currently parse the ASCII model files directly to my engine. It is slow, but it is a necessary step for the engine at the moment because I know very little about how files like this are stored in the real world, and how graphics theory translates to practical use. I don't know what the best way to make my own format for use directly with the engine will be.
It is a better option for me to first load the models directly from human-readable formats so I can understand everything about them. Once I know exactly what's practical to have in a final format and what needs to be stored, or what's better to calculate in real-time instead, I will settle on a format.
.FBX is useless to me for this because I can't open the file and look at it.
Also, Collada is not working very well either. I can't figure out how to export a cube the way it should be exported.
With the ASCII format, 3DS Max would not generate duplicate vertices for non-smoothed faces. So my engine generates additional vertices for faces that are meant to be not smooth based on the smoothing groups.
Collada does not seem to support smoothing groups. Instead it just duplicates every vertex no matter what -- even if I set the entire object to all be in the same smoothing group. If I turn off the duplication, then the triangle list in the exported file still tries to use indices of vertices that weren't output by the exporter.
For example: this is the output of the collada exporter for a model with a cube with all faces set to the same smoothing group:
The exporter still thinks there are 6 vertices per side of the cube (36 total) even though the output of the vertex list is just 8 vertices total. This is completely broken.
How do I get around this?
EDIT: I think I interpreted those lines wrong -- I think the offset tag means the that for each triangle three of those integers are part of a single vertex description, so every 3rd integer in that list is a vertex index, and the indices in that list that go higher than the number of vertices must refer to the normals.
But I still don't understand why there are more normals than vertices. If they are all smoothed together, why isn't it just exporting a single normal per vertex? Is it possible to correctly reconstruct the model if I use Collada? How can I know whether or not each triangle needs to have its own three distinct vertices whose normals aren't averaged with those of the surrounding faces?
You use C++ / CX to interface with the operating system. All code you would write in a C++ Direct3D program for Win32 (xp, vista, 7) will be identical in a C++ Direct3D Windows RT application. Almost all of the Direct3D code will be the same. The only difference is the code used to create the window and bind it to the device context, and to get the user input (event handlers instead of directinput).
None of the code in C++ / CX is managed. The WinRT components use reference counting, but you do not have to use the components except to create a Window. There is no overhead of the XAML layer.
This might look pretty, but it's a relatively easy scene for a ray-tracer to render. It looks like it's mostly geometric shapes, which can be checked for intersection as a whole instead of with triangles. The effects are nice, but they're not the bottle-neck for a ray-tracer.