There are many ways to go to Rome.

[Patrice Terrier]

The ZI_CreatrImageComposited API returns directly a HBITMAP if the the file name is empty, however for the purpose of the demo i used a file name in case you want to inspect the resulting png file with PSD.

For further details see the GDImage.chm help file.

The composited polypolygon is made of 2 overlapped objects using the same coordinates to ease the sprite move hover the texture (ZD_DRAW_FILLED).

The composited image always use the real size (ratio 1/1), thus that should be easy to replace the xy[] array with real UV coordinates.

[Patrice Terrier]

I m thinking to embed all the controls on the right side of the main window into a single "rightpanel" control, to let them work like a TABed control.

[Michael Lobko-Lobanovsky]

That looks very impressive and real smooth, Patrice!

However,

1. We need a much much deeper zoom. Why? Because the overlapping projections onto the same tex map region of, say, two 3D quads may have their corner vertices so close to each other that we won't be able to select just one of them with the mouse pointer and drag it around as necessary if the zoom ratio is too low. In terms of real UV values, we should be able to always depict easily a difference of approx. 0.001f between the UVs of two vertices.

2. We will need many more "toolbar" controls than the existing 3 (+1 "test") buttons to operate even the simplest UV mapper efficiently. I 'm going to provide you with a list of what we might need for the starters and then please think over how we could arrange them all in the existing bottom space.

3. Tex maps designed as CLAMP_TO_EDGE often have many mesh UV sets layered over one another in one and the same map (UVs are all within [0.f,1.f] rather than cloned across 1.f/2.f/3.f/N.f boundaries). In other words, there are often too much vertex UV data within the same [0.f,1.f] map for the mouse pointer to work with. Do you think it will be possible to clone the same tex map image along U and/or V to separate the mesh UV sets each into its own map clone, e.g. like below:

[Patrice Terrier]

Mike

Once a sprite object has the focus, it could be moved with the arrow keys by pixel units, this is more accurate than with the mouse.
And you can select several sprites with the CTRL key and move them all with the mouse.

So far i think it would be easier to work with "quad" rather than "triangle", or even only peripherical dots (hot spot).
Once a shape is selected, we could display the hot spots, because they use the same xy coordinates.
However the ultimate precision will be always 1 pixel unit for the resulting image…

(thinking at loud voice)

[Michael Lobko-Lobanovsky]

I m thinking to embed all the controls on the right side of the main window into a single "rightpanel" control, to let them work like a TABed control.

Perhaps it will also be handy to make the draggable zoom and thumbnail windows (do we need the latter at all?) "sticky" windows. Such windows tend to optionally "snap" (as if magnetized) to the main window if they are moved close to its sides and/or corners. When "snapped" and the main window is dragged around by its caption bar, the satellite windows are moved as well keeping "attracted" to their respective sides/corners.

[Patrice Terrier]

Yes i could snap the floating windows (this is what i am doing with gMap64, that was used to create the single Tor Template).

Except when working in maximized mode, in this case they should work the same than now.

[Michael Lobko-Lobanovsky]

Once a sprite object has the focus, it could be moved with the arrow keys by pixel units, this is more accurate than with the mouse.

That's all right but in real practice, still a lot can be done by picking the vertex projection rect (in fact its UV point) with LMB and dragging it around with the mouse. We do not always need pixel-perfect placement. We must have a choice of working either with the mouse or arrow keys at our own option.

However the ultimate precision will be always 1 pixel unit, as long as a texture is concerned…

That is not correct. The ultimate precision will always be 1 texel which is 1 texture pixel times the texture zoom ratio times the OpenGL current texture screen space projection mini- or magnification factor times sub-pixel stretch due to i) multisampling, ii) anisotropic correction, and iii) color interpolation across OpenGL viewport screen pixels.

That's why I insist on being able to see the results of my UV work in real time immediately in the main render window.

And you can select several sprites with the CTRL key and move them all with the mouse.

The notion of "sprites" is alien to my ears in this context.

I am going to work with vertex UVs which are point projections of 3D vertices onto the flat tex map plane. I need to be able to pick a point (a pair of UV coords) or a group of points by mouse pointing-and-clicking, or freehand rect and/or lasso area selection. Point selection is done by sensing if the mouse pointer hits the UV box color (cyan in the snapshots I provided) under the mouse. The UVs will be stored in 2D UV arrays.

Where do you want to squeeze your "sprites" (layers?) in this scenario?

[Patrice Terrier]

Here are 2 videos, showing you the use of a {sprite hot spot} to change the shape of a polyline.

Remember, a sprite hot spot can be as small as one single pixel, and we can give the focus to the sprite we want, just like when selecting it with the mouse.

After moving one or several of our sprite hot spots, we can redraw the wole polyline on demand (video2).

Thus what could be done, is to select a specific mesh in the listview, then create and array of XY UV, that will be used to display the hot spots (we could use larger dot sprites of say 5x5 or even more) to easily move them around, and add a new button to redraw the UV polyline on demand.

Is that clear enough?

The notion of "sprites" is alien to my ears in this context.

A GDImage sprite, is anything floating above the background that could be moved up or down along the object z-order.
Just like regular controls inside of the same window (and they have almost the same scope of properties).

[Michael Lobko-Lobanovsky]

Excellent! I think I got you idea finally, Patrice, thank you!

So, what you suggest is to use a memory array of hot spots to represent the set of mesh vertex UVs, and a matching array of sprites (e.g. red bullets/circles), to visualize the hot spots against the tex map background -- plus one more sprite (= layer) to draw the polyline that would interconnect the hot spots in a wireframe fashion, isn't it?

[Patrice Terrier]

Yes you got the picture

Provide me with just an array of XY POINTS matching a specific mesh, that is the first step to move from...

[Michael Lobko-Lobanovsky]

Take my copy of Astellia-dragon below (I love this model and I think it should go into the Collection). It has 1 mesh ("body") with 16934 vertices that all map into the [0.f,1.f] range. Loop through its vertex array, build a matching set of UV hot spots from the "body" mesh vertex structure MobjVertexT.texCoord[2] member fields, and project it onto the tex map plane using the smallest one of your bullet sprites and optionally interconnecting them with a polyline to emulate the wireframe. If your hot spots/sprites use texel  units rather than real UVs then multiply the hot spot array elements by the tex map actual width and height when populating the hot spot array.

The "body" mesh is a very lightweight "sample" of real world meshes we're going to deal with in our heavyweight models.

If Tor's speed of redrawing this "net" of UVs as the bullets are being dragged around appears smooth and fast enough, we will proceed with your vision of bending Tor's built in features to our needs.

[Patrice Terrier]

Loop through its vertex array, build a matching set of UV hot spots from the "body" mesh vertex structure MobjVertexT.texCoord[2] member fields, and project it onto the tex map plane using the smallest one of your bullet sprites and optionally interconnecting them with a polyline to emulate the wireframe.

This is exactly where i need your help, i need a function that would create the right XY[] POINTS pixel array, from the mesh vertex structure MobjVertexT.texCoord[2] member fields. I have never worked with UV projection myself.

gP.bTexUV ?

Could you do that for me?

I shall probably have to write a custom code to process large array, to create the composited bitmap on the fly.

[Michael Lobko-Lobanovsky]

Could you do that for me?

No problem though I'll need a little time to do that.

I think we'll simplify the task a little by first drawing the hot spots/bullets array only. A true wireframe will require one more elaborate array of 2D vertices (UVs) organized by triples according to their indices in the mesh to form up the actual array of triangles, and a PolyPolygon(hDC, triarray, 3, numoftris) WinAPI call to draw the entire wireframe by three points to a poly. (OR re-triangulates the mesh by triangles automatically at all times even if it deals with a quad-coded model file)

[Patrice Terrier]

This is how UV coordinates are created in C4D when saving into a .psd file (see the red overlay)

[Patrice Terrier]

My friend

if you have already a working solution, then we can go for it, if you prefer.
However avoid to draw directly onto the texture, but unto a transparent bitmap of the same size.