There are many ways to go to Rome.

[Patrice Terrier]

The GL_FLAT option does work well, even if useless with high poly models.

gP.hGL redraw on WM_PAINT to avoid an empty viewport

I have never seen an empty viewport on my gamer laptop, but that could make sense for other config, and the splitter redraw seems to be better when using double click on it to close/open.

[Michael Lobko-Lobanovsky]

Watch the video below to see what I'd been seeing (or rather NOT seeing) all the time before I added the case WM_PAINT: handler to gl_WndProc():


[ADD]

The GL_FLAT option does work well, even if useless with high poly models.

I never add useless options to ObjReader, Patrice. Do you remember the times when you used to call the entire multi-texture PPL effort a useless and artistically barbaric stuff?

[Patrice Terrier]

I couldn't duplicate the behavior by me, perhaps another difference between Windows 7 and 10.

[Patrice Terrier]

I have upgraded my C4D R17 to version R20 PRIME
unfortunatly the import of: Solidworks, STEP, Catia, JT and IGES CAD are only available in the STUDIO version that is much more expensive!

[Patrice Terrier]

Texture editor white paper:

1 - We must first select the mesh to work with (because the same texture could be used by several meshes)

2 - We must select the material to work with:
colorMapID
ambiMapID
bumpMapID
dispMapID
emitMapID
glossMapID

3 - Then select the correct mesh and material:
MobjMesh* pMesh = &gtm_meshes[select];
MobjMat* pMaterial = pMesh->pMaterial;

4 - Build the UV's array:
float* UVs = NULL;
GLuint index = pMesh->startIndex;
for (int j = 0; j < pMesh->triangleCount * 3; j++, index++) {
    UVs = gtm_vertexBuffer[gnm_indexBuffer[index]].texCoord;
    // The array must be set here
    // but i am unsure on how to convert UVs to texel/pixel POINTs coordinates
}

[Michael Lobko-Lobanovsky]

This is my vision of the same. (not actually tested; may contain bugs but the idea should be clear)


Texture editor white paper:

1 - We must first select the mesh to work with (because the same texture could be used by several meshes)

2 - Then select the correct mesh and material:

MobjMesh* pMesh = &gtm_meshes[select];
MobjMat* pMaterial = pMesh->pMaterial;

3 - We must select the tex map to work with from pMesh->pMaterial: (in many cases, any texture will do as they all have the same UVs for now)

colorMapID;  // these are OpenGL numeric texture "names" (IDs)
ambiMapID;
bumpMapID;
specMapID;
dispMapID;   // MLL 08-08-2018: heightmap ID
emitMapID;   // MLL 10-18-2018: map_Ke ID
glossMapID;  // MLL 10-18-2018: map_Ns ID
//(reflMapID UVs are generated automatically!)

4 - Build the selected mesh's UV and wireframe arrays. (those are different arrays!)

Building an array of Tor's unique tex map UVs/sprites/hotspots/bullets/whatever is not trivial because there's currently insufficient data in our existing structures. So for now, we'll start with drawing only the wireframe proper in the hDC of the bottom-most layer immediately above the texture image but below the sprites/hotspots/etc. so that they are not obscured by the wireframe lines.

The following is global code:

// TODO: Tor UVs/sprites/hotspots/bullets/whatever
// static FOO* torUVs = NULL; // any data type suitable for Tor sprite positioning
// Tor wireframe only
static POINT* torWireFrame = NULL; // array of wireframe vertex POINTs
static long* torVertCountPerPoly = NULL; // array of vert counts in each wireframe poly (actually 3 for all polies; see PolyPolygon() specs)

Now, the following goes into a dedicated procedure:

GLuint* index = &gnm_indexBuffer[pMesh->startIndex]];
int vertsTotal = pMesh->triangleCount * 3;
// TODO: Tor UVs/sprites/hotspots/bullets/whatever
// if (torUVs)
//     free(torUVs);
// torUVs = (FOO*)malloc(bar);
// Tor wireframe only
if (torWireFrame)
    free(torWireFrame);
torWireFrame = (POINT*)malloc(vertsTotal * sizeof(POINT));
if (torVertCountPerPoly)
    free(torVertCountPerPoly);
torVertCountPerPoly = (long*)malloc(pMesh->triangleCount * sizeof(long));

for (int j = 0; j < vertsTotal; j++, index++) {
    MobjVertexT* vertex = &gtm_vertexBuffer[gnm_indexBuffer[*index]];
    // We will have to keep track of images' actual pixel
    // sizes on model load or else use the ones from Tor
    torWireFrame[j].x = selTexWidthInPixels * fmod(vertex->texCoord[0], 1.0f); // OpenGL tex coords may be a multiple of 1.0f if GL_REPEATed
    torWireFrame[j].y = selTexHeightInPixels * fmod(vertex->texCoord[1], 1.0f); // ditto
}

for (int j = 0; j < pMesh->triangleCount; j++)
    torVertCountPerPoly[j] = 3; // three POINTs to each polygon (i.e. triangle)

5 - Whenever necessary, (re)draw the entire wireframe in the Tor bottom-most layer's hDC in one PolyPolygon() call using 1-pixel wide selectable-color pen and BS_HOLLOW brush:

PolyPolygon(bottomLayerHdc, torWireFrame, torVertCountPerPoly, gtm_meshes[select].triangleCount);

Hope this helps.

[Michael Lobko-Lobanovsky]

In the above torWireFrame[j].y calc, the 3D tex coord may need to be flipped because of the differences in OpenGL and GDI coord origins, like so:

........
    torWireFrame[j].y = selTexHeightInPixels * (1.0f - fmod(vertex->texCoord[1], 1.0f)); // ditto
........

[Patrice Terrier]

Thanks for the white paper feedback, now i shall try to turn it into real code, testing with a simple square surface (made of 8 triangles, 9 points) to work in debug mode.

[Michael Lobko-Lobanovsky]

... and to compare the UV's map with the one created with Blender.

No, the Tor unwrapped wireframe on the flat 2D texture will look exactly like it looks wrapped over the 3D surface of the model as shown in ObjReader's Inspect->Wireframe overlay mode.

OR doesn't re-unwrap the UVs, it just uses the ones that have been written in the model's vertex data at model creation time. Tor should display the dragon's body UV wireframe against its diffuse map something like below: (picture generated in LithUnwrap)

[Patrice Terrier]

Dragon is too complex for now, i am trying with a simple flat square made of 8 triangles (9 points)

[Patrice Terrier]

Here is the test project i have done to check the coordinnates

Code: [Select]

void CreatePointArray(IN long selected) { // 03-20-2019
    MobjMesh* pMesh = &gtm_meshes[selected];
    long* index = &gnm_indexBuffer[pMesh->startIndex];
    long vertsTotal = pMesh->triangleCount * 3;
    //if (gT.wireframe) { free(gT.wireframe); }
    //gT.wireframe = (POINT*)malloc(pMesh->triangleCount * sizeof(POINT));
    long x, y;
    long selTexWidthInPixels = 255, selTexHeightInPixels = 255;
    WCHAR zAf[64] = { 0 };
       
for (int j = 0; j < vertsTotal; j++, index++) {
    MobjVertexT* vertex = &gtm_vertexBuffer[gnm_indexBuffer[*index]];
    // We will have to keep track of images' actual pixel
    // sizes on model load or else use the ones from Tor
    x = selTexWidthInPixels * fmod(vertex->texCoord[0], 1.0f); // OpenGL tex coords may be a multiple of 1.0f if GL_REPEATed
    y = selTexHeightInPixels * fmod(vertex->texCoord[1], 1.0f); // ditto
    StringCchPrintf(zAf, strSize(zAf), L"x = %2d, y = %2d", x, y);
    zTrace(zAf);
}
}

[Michael Lobko-Lobanovsky]

... i am trying with a simple flat square made of 8 triangles (9 points)

Here is the test project i have done to check the coordinnates

I believe you understand that your simple flat square model must have valid UVs unwrapped in a 3D editor and exported in the model OBJ file as vt directives?

[UPD] Oh, I see you attached your test square model and it has been UV unwrapped.

long selTexWidthInPixels = 255, selTexHeightInPixels = 255;

I'd expect both width and height to be 256/P.O.T. pixels each, not just 255...

y = selTexHeightInPixels * fmod(vertex->texCoord[1], 1.0f);

It should be (1.0f - fmod(vertex->texCoord[1], 1.0f)) because OpenGL and GDI use different origins of their respective coordinate systems (bottom left and top left).

[Michael Lobko-Lobanovsky]

So, what's the typical output of your test code in zTrace, please?

[Patrice Terrier]

Here is the output in zTrace for a texture size of 256x256

x = 128, y = 128
x =  0, y = 128
x =  0, y = 256
x =  0, y = 256
x = 128, y = 128
x = 128, y = 128
x = 128, y = 128
x = 128, y = 256
x =  0, y = 128
x = 128, y = 128
x =  0, y = 256
x = 128, y = 128
x = 128, y = 128
x =  0, y = 128
x = 128, y = 128
x = 128, y = 128
x =  0, y = 256
x = 128, y = 256
x =  0, y = 256
x =  0, y = 128
x = 128, y = 128
x =  0, y = 256
x = 128, y = 128
x = 128, y = 128

[Michael Lobko-Lobanovsky]

Looks very much true. Now let's hope the image in Tor will be close to the following: (only with 1-pixel wide lines everywhere)