There are many ways to go to Rome.

[Patrice Terrier]

you must read float instead of double, this was a survival of one of my many tests

[Michael Lobko-Lobanovsky]

No, I'm not talking about type propagation to achieve correct rounding precedence. I'm talking about an attempt to perform direct arith on different-precision values. It normally causes a warning by the C/C++ compiler unless one of the operands is explicitly cast to match the type of the other one.

[Patrice Terrier]

Here is a quick video preview to show you the Tor UV's editor in action.

The keyboard arrows are used to move up, down, left, and right, pixel by pixel.

[Michael Lobko-Lobanovsky]

That looks cool indeed!

I'm starting to believe the project is feasible, after all...

[Patrice Terrier]

For speed purpose i took the option to work with bit pointer directly within the UV's map memory bitmap.

I shall post a trial version later on, for you to test for speed on your computers if you are available?

Note 1: textcoord is updated in real time, thus in theory the changes should be visible when moving the splitter 

Note 2: The .obj file is not updated yet, because i haven't thought yet on how to save the changes, this a point we must discuss together based on your futur plans.

[Michael Lobko-Lobanovsky]

... if you are available?

I'm always available for testing.

The .obj file is not updated yet, because i haven't thought yet on how to save the changes...

The file should be re-saved as Wavefront Object Specs-compliant in its entirety even if you change just one UV pair by just one pixel.

This means the entire model-loading tool chain should be re-created backwards to be able to reconstruct the OBJ file contents down to our metacommands based on the actual state of model data in the process memory as of the moment the Save button is pressed.

Sounds like it isn't going to be a piece of cake at all, doesn't it?

[Patrice Terrier]

My friend.

Here is the new Tor, for test purpose.

We don't need anymore the extra "Marker" folder, because we do not use them.
My plan is to select a specific mesh from the  IDC_CHECKLIST to populate the contact sheet (not done yet), and hide all other controls from the right panel as long as Tor is visible.

Adjust the slider zoom to increase magnification and ease the hot spot selection (perhaps this could be done automatically).

Sounds like it isn't going to be a piece of cake at all, doesn't it?

So far the "save" button becomes visible when needed, but the ShallWeSave is empty

[Michael Lobko-Lobanovsky]

My friend,

My sources have been severely affected by my FBO/PP WIP in general, and FBO W10/ATi compatibility issues in particular. So, they aren't now compatible with your project to an extent where I could just add those three files and proceed with testing. In fact, my sources are now completely devoid of Tor as a safety measure to make sure I'm using only rock-solid time-proven code for my experimentation to narrow down the bug-prone area in my FBO/PP efforts.

Can you please supply me with a full set of your OR sources so I could roll back safely and test your recent Tor mods in an isolated environment?

TIA

[Patrice Terrier]

Here it is…
(source code only)

[Michael Lobko-Lobanovsky]

Haha thank you!

It works for me exactly as shown in your recent video!

I'm seeing bugs trying to also depict the current UV changes in gP.hGL in real time. I'll report on those later.

Good job, my friend!

[Patrice Terrier]

looks like you remove your latest message that i have seen only on my Galaxy note?

[Michael Lobko-Lobanovsky]

(Yes, I did because here follows my full report)

Patrice,

1. BUG: please change the ptInCircle declaration to BOOL ptInCircle(...).

2. FEATURE: use the texture below to know your exact disposition in both 2D and 3D, and add the following code to your long CALLBACK CallBack_ZoomCtrl(...):

........
    case WM_KEYDOWN:
........
            // WE UPDATE THE UV texCoord HERE
            gtm_vertexBuffer[gnm_indexBuffer[gT.wasIndex]].texCoord[0] = float(gT.wasX / float(nW - 1));
            gtm_vertexBuffer[gnm_indexBuffer[gT.wasIndex]].texCoord[1] = float(1.0f - float(gT.wasY / float(nH - 1)));
            CreateUVmap(gT.meshselected, gT.wasIndex);

            wcscopy(sAf, STRL(gT.wasX)); Add_Str(sAf, L" ");
            SetWindowText(GetDlgItem(gT.hPanel, TOR_ID_COORD_X), sAf);
            SetWindowText(GetDlgItem(gT.hPanel, TOR_ID_COORD_Y), STRL(gT.wasY));
            ShowSaveButton();

            // MLL 04-18-2019: update VBO and redraw immediately
            long idx = gnm_indexBuffer[gT.wasIndex];
            glBindBuffer(GL_ARRAY_BUFFER, gP.nVBO);
            glBufferSubData(GL_ARRAY_BUFFER, idx * sizeof(MobjVertexT),
                sizeof(MobjVertexT), &gtm_vertexBuffer[idx]);
            glBindBuffer(GL_ARRAY_BUFFER, 0);
            gP.bRedraw = TRUE; gl_DrawScene();
        }
        break;
........

Now watch how different the OpenGL viewport events look from what we see in the GDI+ zoom control window.

This is exactly why I've always insisted on every change being immediately reflected in the 3D viewport. WYSIWYG is the key to success in visual design activities.

3. BUG: if the texture is small enough like e.g. our neutral_bump.png, zooming it in the zoom control actually minifies it till it flips at zero size and then starts to grow to its original size.

4. BUG: Tor still doesn't reliably select and build the UV map for meshes other than the 0th one. In some models it does, but in many many others it doesn't. For instance, take a simple carousel.obj model and see that it doesn't build the UV map for any mesh in it other than center (OR logo)...

5. BUG: Tor doesn't handle .TGA or .DDS textures.

6. FEATURE?: those blurry lines and bullets "are driving me slightly mad"(c) ...

[Patrice Terrier]

ptInCircle, is currently not used, it is there to remind me on how to do it.

Thanks for the texture!

Tor doesn't handle .TGA or .DDS textures.

I didn't even thought of those

Tor still doesn't reliably select and build the UV map for meshes other than the 0th one.

Did you try to click on the check ListView to select a specific mesh?

those blurry lines and bullets "are driving me slightly mad"(c)

I did try to use something visible hover any texture background, but if you have another preference this is not a problem for me, except using RGB(255,0,255) that is a reserved color to achieve transparency with indexed color (mainly GIF).

About small texture size, i did not focuse on that problem, because until now my main concern was to find a relying way to move the hot spot in real time.

Now that texcoord update is solved, we can start to add bells and whistles.

[Patrice Terrier]

Now watch how different the OpenGL viewport events look from what we see in the GDI+ zoom control window.

This is because the coordinates are inverted, we have to figure the best way to work around this problem into CreateUVmap.

[Michael Lobko-Lobanovsky]

That's what I thought too when I first saw that "animation".

Now take another, simpler chance with, say, the top left (LT) bullet and think deeper whether what you're seeing in 3D is correct. Account for the geometric vertex staying put where it is with only its UVs moving, say, down in 2D. Is the coloration of the two immobile 3D tris associated with that vertex correct given where the borders of their animated UV counterparts are sliding to in 2D?

Making the same two 3D tris occupy a smaller portion of their texture as their UV values grow smaller is equivalent to upscaling the texture visually larger. This is exactly what you're seeing in your 3D viewport.