There are many ways to go to Rome.

[Patrice Terrier]

See the attached video.

This is the texture that fooled me at first, but now i understand that, Indeed, the mapping is absolutly correct.
As you said it is very important to look at the 3D view and the 2D's altogether to fine tune the map. and do some abstraction to understand how mapping is going on.

Once understood, the problem is solved, sorry for the confusion 

Now i can move on, and make the use of the editor more intuitive.

Thanks for the mods, Patrice! They fit in my .DDS and .TGA arsenal perfectly.

Pandora's version is slighty different to preserve the pixels allocation, thus i am using a g_Pixels BYTE vector that is much more easy to deal with. And FlipY has also been changed to deal with the new vector array.

[Michael Lobko-Lobanovsky]

See the attached video ... it is very important to look at the 3D view and the 2D's altogether to fine tune the map. and do some abstraction to understand how mapping is going on.

EXACTLY!!! The hot spot (bullet) you're dragging is definitely the wrong one to start with. There's so much going on in the bunch of affected tris that your mind simply refuses to analyze and accept the obvious. But once itemized into simpler events in just one or two tris, it suddenly dawns on you how it all works, and you start to feel yourself enlightened and in full control of this very important piece of knowledge and skill in your everyday design work!

... sorry for the confusion 

You've got nothing to be ashamed of, my friend! It took me months to figure out the same things without assistance and formulate the importance of being able to simultaneously see the effect of my actions in THE BOTH viewports. And I'm glad I was around to reduce this fuzzy period to just a few hours in your case.

[Patrice Terrier]

My friend

What to do if the texCoord are not within the range 0.0f to 1.0f
See the attachment, when trying to display the Harley Quinn model

example of vt from the HQ.obj
vt -0.05420000106096 1.62569999694824 0
vt -0.08179999887943 1.60469996929169 0
vt -0.07450000196695 1.651899933815 0
vt -0.02749999985099 1.64749991893768 0
vt -0.11209999769926 1.63160002231598 0
vt -0.04580000042915 1.68409991264343 0
…
vt 1.3798999786377 1.87689995765686 0
vt 1.36230003833771 1.85829997062683 0
vt 1.38380002975464 1.85710000991821 0
vt 1.3643000125885 1.83739995956421 0
vt 1.38769996166229 1.83589994907379 0
vt 1.36619997024536 1.81639993190765 0
vt 1.39160001277924 1.81459999084473 0
# 2258 texture coordinates

Of course the computation of the resulting x,y coordinates are totaly wrong 

[Michael Lobko-Lobanovsky]

Patrice,

This will require yet more effort on your behalf, my friend. Tor's zoom control must have the ability to not only zoom into the existing texture, but to also tile it, cross-wise, in any of the four directions while zooming, as many times as there are whole integer parts in the extreme floating-point UV coordinates of the mesh. (Think of how many of them would be cleared out if fmod() were applied). Then the offending UV coords would fit into the boundaries of their respective tiles, and the tris that are using those UVs would protrude in the correct directions as far as they should, again ultimately passing through as many tiles on their way as there are whole integer parts in the extreme UV floating point coords of a given mesh.

Then, when the pixel width and height of the texture involved in the calculation is multiplied times the number of whole integer parts in the extreme floating-point UVs, the calculations will return to normal again. But the zoom control should be prepared to depict those extended areas correctly in its 2D viewport too. You cannot simply wrap (map) the extended UVs to the same tile by fmod()'ing out the whole integer parts because then the tris associated with the extended UVs will not protrude in the correct directions.

Look again at the attachment to this message to see how Xandreale used to implement it in its vertex color editor.

Such mesh UVs occur quite often in tiled (GL_REPEATed) textures, but I think you should first get your one-tile (GL_CLAMPed_TO_EDGE) implementation straightened out and then proceed to that general-case extended solution...

[Michael Lobko-Lobanovsky]

On giving it a second thought, in order to protect Tor against attempts to display what it currently can't do, the floating point UVs should be evaluated for fitting in the 0.f to 1.f range. Those UVs (and their associated tris!) that fall outside those extrema should be discarded when drawing the UV map.

It's going to narrow the visible and serviceable part of the UV map display but it will also definitely help to avoid meaningless smear in the 2D viewport, straighten out the calc, and preclude possible memory crashes.

[Patrice Terrier]

I think i got it to work, crossing my fingers 

To ease UV mapping every texture smaller than 1024, is now resized to 1024 (while preserving the real size of the disk file). Of course, resizing the 8x8 "neutral_bump.png" to 1024, would cause bluring on edges, but that's the best way to work with such a small texture in Tor.

I plan to add a tolerance to select a specific dot with the MLB, then i shall put a sprite at the selected x,y location to easily change the coordinates, just like what i am doing with a marker in gMap64.

[Michael Lobko-Lobanovsky]

Patrice,

The tolerance should be +/-1 px with respect to the hot spot, i.e. 3x3 pxs all in all as I've been telling you all the time. Hopefully, the red sprite is going to be exactly that size?

Re. texture resizing, OK let's live and see how it works in practice.

Any further comments on what exactly have you got to work? Is it texture tiling for the protruding UV coords?

[Patrice Terrier]

i got "harley queen" VT to work in both 2d and 3d view.

[Michael Lobko-Lobanovsky]

May I ask how you managed to do that?

[Patrice Terrier]

Here is the Tor.zip able to render VT texCoord that are out of the 0-1 range.
(see the attached harley_quinn.mp4 video)

Search for rxCoord, ryCoord

This version is also able to deal with small textures, look for the comment:
// Resize everything to at least 1024, to ease working with UV's map

Note: tolerance + LMB selection not done yet in this version.

But, our biggest challenge is to update the .obj file with the updated VT texCoord 

[Michael Lobko-Lobanovsky]

Thanks for the update, Patrice! Is the video supposed to carry your voice record? Unlike your former videos, this one only produces a few unintelligible sounds on all my players...

I'll inspect your code and submit my review later as I have to attend to some real life duties first.


(our biggest and most immediate challenge is a full scale unlimited undo-redo stack to avoid possible irreparable damage to our model files likely to occur while debugging the .OBJ file save routines)

[Patrice Terrier]

No, there was no recorded voice of me in the video.

(our biggest and most immediate challenge is a full scale unlimited undo-redo stack to avoid possible irreparable damage to our model files likely to occur while debugging the .OBJ file save routines)

That's the easy part, first thing would be to create a .bak of the .obj when saving.
And as long as we test it, working on a copy rather than the original.

For undo-redo, a dynamic global vector array is what i would use, with a structure like this.

struct UNDO_REDO {
    long idx;
    float texCoord[2];
}
to save the
gtm_vertexBuffer[idx].texCoord[0]
gtm_vertexBuffer[idx].texCoord[1]
and two new buttons for undo, redo, and perhaps a third one to restore everything.

[Michael Lobko-Lobanovsky]

Since you refuse to describe verbally your train of thought while implementing your patch, I'll base my comments on what I could gather from the mods.

Here is the Tor.zip able to render VT texCoord that are out of the 0-1 range.

No, this Tor is only able to discard the UVs and tris that are at least partially out of the 0-1 range.

Search for rxCoord, ryCoord

These two functions are in fact your custom implementation of fast fmod(coord, 1.f) used to actually discard the UV coords that exceed the 0-1 range. If Tor doesn't entirely discard the tris in the areas that it can't draw, then it's going to draw them incorrectly. Consider the picture below. Tor can't draw the ABC tri because the C apex belongs to Tile 1 and is thus out of Tor's reach. If the entire tri isn't discarded from the drawing process, then on fmod()'ing its C apex down to C', the tri will be drawn as ABC', which is totally wrong.

This solution will help us survive for the time being. But it doesn't allow us to work with textures that are tiled (GL_REPEATed) purposefully in order to map some UVs, or triangles, or even the entire mesh across tiles 0, 1, 2, ..., etc. or arbitrarily in any of these tiles at the model designer's option.

Am I correct in my deductions?

[Michael Lobko-Lobanovsky]

For undo-redo, a dynamic global vector array is what i would use, with a structure like this.

struct UNDO_REDO {
    long idx;
    float texCoord[2];
}
to save the
gtm_vertexBuffer[idx].texCoord[0]
gtm_vertexBuffer[idx].texCoord[1]

This isn't sufficient. The stack should handle all data modifications that OR's editors are able to offer. ObjReader currently has 2 editors (lighting and texture) but your UNDO_REDO handles separate UVs only. It should be augmented with a flag to indicate what type of undo/redo operation exactly the current entry actually describes, and a union that would host any structure types we might need to restore the OR states (lights, texture UVs, vertex geo coords, etc.) arbitrarily step by step or across or over a number of steps.

Also consider group selection modes whereby an arbitrary number of indices with various associated data should be stored in one step...

[Patrice Terrier]

This isn't sufficient. The stack should handle all data modifications that OR's editors are able to offer.

I am walking one step after another, and so far UV map is my first editor's step.

About tiled texture i have to search a model from my collection to experiment with, because so far i couldn't remember of any.

To create the UV projection, most Google suggestions were based on the use of matrix, or the use of gluProject/gluUnProject to map object coordinates to window coordinates (also based on matrix).
https://docs.microsoft.com/en-us/windows/desktop/opengl/gluproject

https://www.khronos.org/opengl/wiki/GluProject_and_gluUnProject_code