There are many ways to go to Rome.

[Michael Lobko-Lobanovsky]

My dear friend,

It looks very neat indeed and is fun to play with.

But alas, it is very impractical to work with, at least in its present state.

The major problem is that the wireframe/bullet overlay seems to be drawn only once and is then simply zoomed into/out of together with the texture image. This makes it impossible to either clearly see the wireframe or zero in on a bullet and drag it — at any zoom level other than the maximum/deepest one.

This isn't how it should be. A wireframe line should remain exactly one non-AA pixel thick, and a bullet, 3x3 non-AA pixels large, regardless of zoom level. This means the overlay should not be zoomed but rather redrawn each time the zoom depth is changed with the aid of the slider, or the zoom rectangle, dragged in the zoom widget.

The portion of the wireframe image to be drawn in the overlay should be enlarged according to the current zoom depth and clipped to within the zoom rectangle as seen in the zoom widget. This will dramatically reduce the number of wireframe tris and bullets to be drawn at any zoom level other than the full view, and drawing may arguably become significantly faster.

This tactics will enable the user to see, and work with, the UV mesh confidently at any zoom level rather than at the current deepest level only. The user then won't have to lose time adjusting the zoom just to make the wireframe visible, or dive to the deepest zoom to be able to drag one or two bullets around.

Do you think you can re-implement what I'm trying to describe?

[Patrice Terrier]

I am well aware that it is not practical like this, so far i have been fighting with something else, and now that it has been solved i can move on (as i said it was just a backup for security purpose).

My idea was to work with a delimited section (region of interrest), and/or with a mouse hover to detect the red dots and display a marker that could be moved to change the underlaying UV's coordinate(s)

Using a bitmap with the red dot coordinates is the only pratical way to detect fast, a specific XY location, without scanning everytime a whole array.
The other way would be to save the triangle coordinates, and perform a PtInTriangle detection (working like PtInRect).

I am also trying from my best to reuse the existing Pandora's code to avoid code duplication, and use the existing mechanisms.

Because of the spring work i have to do for the house, my wife is exercing a hard pressure on the time i could spend on programming, thus slowing doing my progress and ruining my concentration 

[Michael Lobko-Lobanovsky]

Thank you for the heads-up on your strategy! I'm looking forward to your progress in that direction.

Because of the spring work i have to do for the house, my wife is exercing a hard pressure on the time i could spend on programming ...

I understand those seasonal/rural factors perfectly well as I used to both have a wife and own a country cottage myself in the past as well. It is only too good you don't have to also plow your land in spring and shovel manure in summer to gather your harvest in autumn.

What regards me and my progress, I think we're going to see ObjReader's first practical FBO renders some time this week, most probably this weekend.

[Patrice Terrier]

What regards me and my progress, I think we're going to see ObjReader's first practical FBO renders some time this week, most probably this weekend.

Great news my friend!

Do you have a preference using

long dimDot  = (nW * nH) / 8;

between the new
long* Dot = new long[dimDot]; // Delete [] Dot
and the old
long* Dot = (long*) malloc(dimDot); // free(lDot);

to be used with BitSet and BitGet, to easily detect the triangle Dot locations without wasting memory.
BitGet(UsingLongArray(Dot), y * nH + x)

Note: nH is the stride value

[Michael Lobko-Lobanovsky]

1. Personally, I'd prefer to see long dimDot  = (nW * nH) >> 3;

2. If the Dot[] array isn't going to use CPP advanced features like quicksort or mapping, then I'd prefer to use long* Dot = (long*) malloc(dimDot); // free(Dot);. Our coding style is procedural ANSI C, not CPP, and it should look like one.

[Patrice Terrier]

OK, thank you!

[Michael Lobko-Lobanovsky]

I'm working, I'm working!!!

[Patrice Terrier]

I finally found what was causing me the array bound error in CreateUVmap

I am using a bit array and a bitmap of the same size than the original texture size (nW = width, nH = height)

then i compute the x,y coordinate like this

x = (long) ((nW - 1) * vertex->texCoord[0]);
y = (long) ((nH - 1) * (1.0f - vertex->texCoord[1]));

to bitset a single bit at location y * nH + x
however both x and y computation could result in a value much larger than the nW width or the nH height.

Thus to protect from array bound error, i have used this

        // Detect unique dot
        if ((x < nW) && (y < nH)) {
            dotXY = y * nH + x;
            if (BitGet(Dot, dotXY) == 0) {
                BitSet(Dot, dotXY);
                ++dotCount; // Unique dot count
            }
        }

[Michael Lobko-Lobanovsky]

Thanks for the array bounds fixes! But I do not have any code in my Tor.cpp that would actually use either BitGet() or BitSet(). I've got only their implementations.

Re. FBO, OR doesn't work for me either under my nVidia+W10 or ATi Radeon+W7.

I will need more time to check and fix the glitches. (everything's perfectly fine for me under my dev W7  )

[Michael Lobko-Lobanovsky]

I'm trying to isolate the cause of failure. But I'm almost certain it is a driver problem. Are you sure you have the latest driver for your nVidia card?

[Patrice Terrier]

I have the latest driver version 419.67 from 03-25-2019.

[Michael Lobko-Lobanovsky]

Good.

I think it is not the FBO code that causes the failure. When it's removed, OR still tends to crash on my AMD/ATi box...

OK that's enough for today; I'm a bit tired...

[Patrice Terrier]

Most probably the problem is in gl_Init() (PixelFormat ?).

[Michael Lobko-Lobanovsky]

No, my previous build (without the Tor and FBO code) enhanced with the new OpenGL 3.0 GL_ARB_framebuffer_object extension initialization in gl2.cpp and selection of simple pixel format in Mobj_choosePixelFormat() in mobj.h works flawlessly under both W10 and ATi/W7...

I need more time to check the code flow historically step by step to spot which mod exactly started to cause the OR crash.

[Patrice Terrier]

I have been fighting with a difference of behavior between VS2010 and VS2017 in GDimage64.dll, that was causing a problem when using WM_MOVING to move the Splitter.

This was because BitSet and BitGet are not working the same into the two compilers. 

I have replaced the function calls with their define counterparts, and bingo that solve my problem.
#define BitSet(Array, BitPos)   ( Array[(BitPos >> 5)] |= (1 << (BitPos % 32)) )
#define BitReset(Array, BitPos) ( Array[(BitPos >> 5)] &= ~(1 << (BitPos % 32)) )
#define BitGet(Array, BitPos)   ( Array[(BitPos >> 5)] & (1 << (BitPos % 32)) )