BLM768

Aha! I think I've got it. When you subtract 30 from the roll value, you're doing it in the conversion from model space to view space, so the second object's position will change by 30 degrees in view space, not in world space. Try splitting it into two transformations: one to rotate its position vector 30 degrees in world space, followed by the (-pitch, -roll, -yaw) transformation to get it into view space. You might have to swap the order of those two transformations because Cocos3D seems to perform matrix operations in the inverse order (at least from what I've seen your code do, but I'm not completely sure because I've never messed with it).

Yeah, that's what I initially thought but it looks like it goes the other way around. Not sure why... I don't think that is the issue here, since you can see on the first image that the I have the correct order. Otherwise you'd see both objects in the same ( -distance) position, just rotated differently.

That's quite odd. It seems as though the changing device rotation alters the objects' rotation, but the position is only affected by the first rotation value and then stays fixed. Weird...

 

Is the origin of each object (without any transformation) at the center of the rectangle, or is it at some other point?

I'm not too familiar with Cocos3D, but if I'm reading your code correctly, it looks like you're performing the rotation and then moving the objects in world space. The problem is that you're performing those two operations in the wrong order. In general, you want the most "local" transformations to be applied first; for example, if an object is rotating around its own axis, you'll perform that rotation first, then translate it to its position in the world. However, if it's rotating around the camera, you'll want to translate it before rotating. Every translation/rotation is applied in the camera's space, not in the space of the object that received the last transformation.

 

To visualize: using simple matrix transformations, if you put an object in front of yourself and translate it "up" (+Y), it will always move toward your "up", not toward its "top" side (unless it's already right-side-up). If you rotate it, it will always move as if it's orbiting around your head. If you want an object to be rotating around its own axis but staying in one location, you need to put it "inside" your head, rotate it there, and move it out to its final position; otherwise, it will move around your head as it rotates. A little unintuitive, but the math works out nicely.

I would like to see OpenGL to grow more mature because OpenGL can be programmed on the android mobile phones while DirectX can't.

 

I'm not aware of any major areas in which OpenGL is less "mature" than DirectX is. It's certainly less comprehensive because it only deals with graphics and not input, etc., but that doesn't make it any less powerful for graphics; you just need to use other libraries, such as SDL, alongside it. In the area it handles, which is just graphics, it's very mature and powerful as long as you're using a recent enough version.

 

Personally, I always use OpenGL for my projects because I hate being tied to one platform, and OpenGL has more comprehensive language bindings. With OpenGL, SDL, and optionally OpenAL, you should be able to write just about any type of game/simulation in a very cross-platform manner using just about any programming language.

I don't have much experience with this particular topic, and my experience is mainly in OpenGL rather than DirectX, so my answer might not be completely correct, but here is what I understand:

 

At least in OpenGL, a "patch" is basically like a triangle, but it has a user-defined number of vertices. Patches can only be used as the input for a tessellation shader, which breaks them down into triangles in a user-programmable manner. The main advantage is that patches allow you to take advantage of GPU tessellation, which can be a useful tool for some effects (especially subdivision surfaces) that would traditionally require re-generating the mesh on the CPU and pushing it to the GPU each frame. Unfortunately, patches and tessellation shaders are only available in recent versions of OpenGL (4.0, I think).

 

From the minimal research I've done on DirectX patches, they are fairly similar to OpenGL patches, but I'm not sure what all of the differences are. In some versions of DirectX, it appears that the number of vertices in a patch is more tightly restricted than in OpenGL 4, but the most recent versions are probably more flexible.

To properly obtain the coordinates, I think that you need to multiply the vertex coordinates by the projection matrix and then divide the x/y values by -z.
However, I'd recommend considering using the stencil buffer to mask out the non-mirror areas, render the reflection, then render the unreflected scene. It's a bit more complex than that, but that's the general idea. The advantage to this method is that you don't need an additional texture, and the stencil test prevents some of the unnecessary fragment processing from happening.