@YesCop

Why ? Is there any interest to define three or more triangles?

Why? It's more efficient that way. There is a certain amount of setup/overhead involved per rendering operation. So, rendering many small objects in one operation using vertex arrays is much faster than rendering each item one by one.

Of course, vertex arrays also allow complex shapes to be rendered efficiently.

My second question is there is some advantages to use verteces except for rotations ?

@whose

For homogenous coordinates, Hans is far more competent than me. I live in a 2d games world ;-) As far as I understand it, the homogenous coordinate is not used by compositing directly, but it´s an calculation aid for 3D graphics on 2D displays.

Homogeneous coordinates do have their use in 2D, which is why they are included in the compositing API. They come in handy when warping images (e.g., in morphing), of which 3D perspective projection is just one very special case. AFAIK, Hans-Joerg wasn't thinking about 3D projection at all when he designed the API (IIRC, he didn't realise that it was possible until he saw the Composite3DDemo ;-) ).

So, what's their use? Well, imagine that you have rendered a rectangular texture/image on-screen. Next, you grab one of its corners and pull it out, warping the image. 2D linear interpolation can't handle this correctly, so the rendered image will start looking pretty bad. The more that it's warped away from a parallelogram shape, the worse it becomes. Using homogeneous coordinates allows the interpolation of the texture coordinates to match the warping, thereby correctly rendering the warped image.

This may not be of much use in most cases, but I could see it being used in drawing & morphing programs.

I was planning to write a demo & tutorial to show how this is done, but I never found the time.

Hans

P.S., Such "warp" transformations are known as homographies or projective transformations. Beware that information about this topic is usually written by mathematicians, and so can be pretty abstract.

@AmigaBlitter:

There is some code out there that demonstrates the very simple use of Compositing, putting some source bitmap into a destination bitmap using some operation modes. But that isn´t different to the blitting techniques used in earlier days (and I believe you know how to use the classic Amiga blitter and its minterms. Essentially this is how CompositeTags() operates in its simplest mode. It´s a "blitter" that is additionally aware of alpha channels). As Hans already said, if you would use this very simple mode to display lots of rectangles, the overhead for setting up the hardware and internal structures would outrun the advantage of hardware accelleration at some point. Using the vertex mode could reduce the need of hardware/software setup significantly.

But as soon as vertex mode is used, things get a bit more complicated for YOUR code. A very simple code would use a minimalist engine to show some things. Nonetheless it´s a kind of engine. Functions to set up the triangles (vertices), functions to manipulate the triangle by its vertices (rotation, scaling), functions to set up the textures, functions to set up the vertex array and at last some function calling CompositeTags() to draw all the triangles contained in the array. Thats roughly the way CompositePOC works. There is some unnecessary complexity in this code, but the principle I explained above is used in it.

Maybe it needs much more commentary to make clear how it works?

@YesCop:

I understand the mathematical relations regarding rotation, scaling, translation and so on. The problem is, that these transformations use a homogenous coordinate just as calculation aid (it´s always 1), and you don´t need it, if you don´t use matrix calculations. This differs as soon as you get "perspective", and "warping" is a perspective transformation. That´s where the homogenous coordinate of CompositeTags() steps in (if I understood Hans correctly) and I think it´s a different beast there (different to 1.0). And the german WikiPedia article describing e.g. "central projection" is really, really bad for non-mathematicians. Way too formal and badly written as all other articles describing the maths of perspective graphics.

My demo is a rather simple one. In the essence it´s the same you did, but much more triangles used ;) Btw., it uses the first technique you´re asking about (blitting background, displaying objects). The difference is, that the "background" is indeed blitted "in the background", as it is a hidden BitMap (not on display) and the objects are drawn to it, too. This BitMap is then blitted into the display after a WaitTOF(). I could mail you the executable, if you wish.

The "specialty" of it is, that it uses just one call of CompositeTags() to draw all objects at once (you asked for this). This is rather easy to achieve. Allocate a vertex buffer that is big enough to hold all objects you want to see (each object consisting of 30 float values representing texture coordinates and vertex coordinates), then fill it with the "object" data. The texture information is given by some Init...() function, which intializes the object (texture coordinates, initial destination vertex coordinates). Moving is done by manipulating only the triangle (vertex) data each new frame. Give the buffer address to CompositeTags() and all objects are drawn by one call per frame. The "big secret" is the manipulation of object data and how you handle all the data in a fast way.

It´s even more easy to do parallax displays, as it was "mandatory" in good ol´ times. Just fill the vertex buffer beginning with "back" objects and walk through to "front" objects. If those object "layers" get different movement speeds: voilá, Parallax scrolling ;-) The advantage of using Compositing for this is, that there is no speed penalty regarding the number of "layers". It´s just ordering of the objects and careful adjustment of moving speed differences to achieve the Parallax effect. For this, you could use one specialized call to CompositeTags() per layer or use fixed "slots" within the vertex buffer (that´s what I do in the demo).

Edit: dang... just saw the link in Hans´ first post... must have been blind this day :-/ way better than Wikipedia, well explained. But, it´s missing "warping" :-(

@whose

I just need some hint how homogenous coordinate and the "warping" effect are connected. Say, e.g. some coordinate of a texture is moved away from the rectangle shape (say, it´s the upper left corner), how does this affect the homogenous coordinate? As soon as I understood it, I will set up some quick demo and maybe I understand better how other 2D transformations work...

When you render a texture/image to screen, you are implicitly mapping pixels in screen space back to points in texture space. With affine transformations, this mapping is described by the following equation:

|x|   |a b c|   |s|
|y| = |d e f| * |t|
|1|   |0 0 1|   |1|

You may not have explicitly created this matrix, but it's there implicitly in your vertex data. If you look at the equation above, you'll see that the graphics card can calculate values of the texture coordinates s & t between vertices using 2D linear interpolation; that third row can be ignored.

However, when you warp your quad, then the equation above can't describe the mapping. Now, you are using a full homography:

|x * z|   |a b c|   |s|
|y * z| = |d e f| * |t|
|z    |   |g h i|   |1|

I've written it in this odd way, because you get the final x & y coordinates by dividing them by the 3rd element z (i.e., converting homogeneous coordinates back to 2D coordinates). This notation should give you a clue as to how to calculate the third texture coordinate... Yes, divide everything by z:

|x|   |a b c|   |s / z|
|y| = |d e f| * |t / z|
|1|   |g h i|   |1 / z|

This is exactly what Composite3DDemo does.

So, how do you find z for each vertex? You need to have the 3x3 matrix that maps the texture coordinate for each vertex in your quad, to its respective destination coordinate on-screen. When you're doing set transformations such as 3D projection, then you already have that matrix. If you're arbitrarily moving vertices, then you're going to have to calculate that matrix it based on the vertices. Yes, it's linear algebra time! The matrix above is defined for any set of 4 vertices (i.e., any quad). Plug 4 vertices into the equation above, and you have 12 equations with 13 unknowns (9 unknowns in the matrix, and one z for each vertex: z1, z2, z3, z4). You need one more equation to be able to solve for the matrix. It can be as simple as z1 = 1, or something similar (z1 + z2 + z3 + z4 = 4 works just as well, and would probably be better for floating-point precision).

If you are familiar with C++, then I recommend using the Eigen library to do the linear algebra for you. I'm not sure what linear solvers are available for C.

I hope that this clarifies the link between homogeneous coordinates and image warping for you.

Hans