There are many ways to go to Rome.

[Michael Lobko-Lobanovsky]

You could also try to split each expression into a series of equivalent arith operations. The way they are now is compact to write but difficult for the compiler to resolve. Such shit happens every now and then in any compiler, especially when some optimization mode is on.

For example, GCC which is also a mighty professional tool has difficulty to resolve the following expression and crashes the app:

drawMode = ++drawMode % 3; // !!! MLL: throws warning !!!

but compiles and runs OK when split into the following:

drawMode++; drawMode %= 3;

Go figure...

[Patrice Terrier]

I think i have been hit by the same syndrome… 

[Michael Lobko-Lobanovsky]

Hehe, it may also be what is called "blank page syndrome". That's when you can't make yourself do the work that has to be done from scratch/ground up, and you know in advance that it isn't going to be a piece of cake. (re. your Tor-based UV editor)

Another probable cause may be your fatigue from your spring garden exercises.

And of course, my own alleged procrastination (actually, there isn't any; it's just that I've quite unexpectedly got a hellofalot of orders to work on for a living and I'm reluctant to reject any of them) has set a bad example for you.

To stir you to life just a little, let me tell you I was able to fix my ATi Radeon W7 rendering. Actually the crash wasn't caused so much by the FBO code but rather by my earlier GLSL flat shading fixes. The toon, X-ray and microscope shaders were failing to compile by the ATi GLSL compiler due to the differences with nVidia in its functional implementation. ATi GLSL forbids reassignment/reuse of varyings (i.e. inter-shader global vars) in the fragment shader. Contrary to nVidia GLSL, ATi regards them as constants and crashes at shader compile time. One more difference under my Radeon is that it allows only up to 8x MSAA for the FBO while my GTX 1060 supports 32x.

Unfortunately W10 still refuses to launch OR for operation as if it is an XP program that W10 doesn't provide a forcible compatibility mode for...

[Patrice Terrier]

Hehe, it may also be what is called "blank page syndrome". That's when you can't make yourself do the work that has to be done from scratch/ground up, and you know in advance that it isn't going to be a piece of cake. (re. your Tor-based UV editor)

Indeed i am limited to 1024 objects/sprites/overlays/layers per graphic control, while i could extend this limitation it is not practical to extend it to more than 2048 that is still too few to render all the dots from a large UV's texture.

The only workable solution is to use a region of interrest, to stay within the 1024 limit, and consider only the UV's dots that are within the delimited section (PntInRect).

But my real problem, i that i am unsure that this is something that i would use myself to work with UV. However being able to create the UV's map transparent overlay is handy, because it allows me to use it as a helper to edit the texture in... PSD.

And i have a hard time to figure the other features that would make my 3D design easier than working directly with C4D. 

[Michael Lobko-Lobanovsky]

Indeed i am limited to 1024 objects/sprites/overlays/layers per graphic control, while i could extend this limitation it is not practical to extend it to more than 2048 that is still too few to render all the dots from a large UV's texture.

Indeed those are very limiting factors.

And i have a hard time to figure the other features that would make my 3D design easier than working directly with C4D. 

My friend, we can revert the code to pre-Tor state (actually, my test version I'm working with to debug the ATi/W10 glitch has no traces of Tor) and drop that matter till I translate my own FBSL code to CPP to implement a UV editor. Probably then you will be able to see the benefits of being able to fix the model UVs directly in OR.
____________________________________________________________

In the mean time, I have a suspicion that there may be compatibility issues between the VS 2008 DLLs I'm using and the VS 2013 OR that I generate. Every time I recompile the solution and have a new OR exe, its first launch for execution crashes under both nVidia and ATi W7's. Then, the OS throws a warning that it has set a compatibility mode for the program, and thereafter the exe starts and runs successfully on both video cards. Unfortunately, unlike W10, W7 doesn't notify me which compatibility mode exactly it has set.

My pandora code is very old and seems not compatible with the modern Splitter component. The OR binary throws an error on missing skButtonFoo/Bar/Baz entry points and aborts execution.

Can you provide me with fresher copies of pandora sources for me to be able to recompile usable VS 2013/2017 DLLs to try and resolve the compatibility issues? Probably it can help me resolve the W10/FBO collision too...

(Quote Patrice: AtiFbo.png (439.56 kB, 1189x755 - viewed 0 times.Unquote Patrice
Why wouldn't you even have a look at the screenie? I spent 7 hours rolling on my chair between the three PC boxes to make it work at least for ATi...  )

[Patrice Terrier]

Indeed those are very limiting factors.

No they aren't, it is just the constant value that i am using at compile time.

struct ZIMAGEPROP {
    HWND     hWnd;
    LONG     anchor;
    RECT     rc;
    HBITMAP  tiledBitmap;
    CHAR     order[2048]; // 2048 for 1024 objects
    LONG     ordersize;
    LONG     WMBit[32];
    LONG_PTR WMCodePtr[1024];
    LONG     centerx;
    LONG     centery;
    LONG     composited;
} ;

1024 is the value that i am using to sort out the z-order.

I shall attach the latest pandora version to this post (the one that is compatible with VS2017)

AtiFbo.png, why wouldn't you even have a look at the screenie?

Because i couldn't figure anything of what you have done from this static picture, that i have seen already on my Galaxy Note 3. 

You know what to do with the attachment once downloaded...

[Michael Lobko-Lobanovsky]

Because i couldn't figure anything of what you have done from this static picture, that i have seen already on my Galaxy Note 3. 

It displays an ATi logo to verify it's been taken on a Radeon GPU, and a vignette shader to prove FBO PP is now working on this HW platform too. Nothing much, really...

I shall attach the latest pandora version to this post (the one that is compatible with VS2017)

Muchas gracias, amigo.

[Patrice Terrier]

So far i have an extra parameter: ZoomFactor, to increase the zooming and decrease the size of the region of interrest, the red rectangle shown on the top right thumb control.
I am also using a unique color to draw each dots, matching exactly each of the coordinates within the array indices.

What could be done with this:
is to display a sprite at the same x,y location, and drag it to the new coordinates, then press a button to redraw the UVmap and update the vertex->texCoord accordingly.

However we should find a convenient way to create a close relation between the vertex->texCoord and the unique dot location that could match indeed several overlapped triangles. You probably had to solve the same problem with what you have done in FSBL, and we could use the same.

Clear as mud?

[Michael Lobko-Lobanovsky]

Why no, on the contrary, clear and concise!

I am also using a unique color to draw each dots, matching exactly each of the coordinates within the array indices.

You're obviously doing this in order not to lose time searching the UV array to compare the cursor coords against the vertices. But you're seeing only a few dozens of thousands mesh UV bullets at the most. Even a linear search of such a relatively small array should be blazing fast at today's CPU clock speeds even if done on the FPU let alone integer comparisons.

Rainbow colors of bullets is another no-no IMHO.

... press a button to redraw the UVmap and update the vertex->texCoord accordingly.

No. The selected bullet position (i.e. mesh vertex UV pair) should change immediately on each cursor move, and the associated wireframe tris should be redrawn along with it.

You probably had to solve the same problem with what you have done in FSBL, and we could use the same.

Ten years ago I dealt with game levels (see below) that consisted of polygon groups. You may regard them as static models and meshes, respectively. The total size of a model varied between 50 to 250K polies with ca. 500 to 2200 meshes and ca. 850 to 2500 textures. So, an individual mesh size was on the order of a few thousand polies at the most. Therefore I used a linear search directly through the mesh vertices. The search procedures however were written in hand-optimized floating point assembly. I never experienced any visible lag to redraw the viewports when dragging a bullet or even a group of area-selected bullets.

Hopefully the same may be done for today's much larger meshes given our much faster modern CPUs. Let's be practical: your huge heavily subdivided meshes like hulls or shells usually don't use direct texturing except perhaps refl maps. Other textured meshes are usually up to 100K polies large, and character models are only a fraction of even that. I think wireframe redraws may well appear even slower than the associated linear search through an integer array. Note the search to determine the vertex index should be done only once at the first LMB down on the bullet you want to drag around.

All this should of course be tested and proven true or false.

[Patrice Terrier]

I am working back on Tor. 

[Michael Lobko-Lobanovsky]

This sounds very encouraging indeed.

[Patrice Terrier]

Because UV's are unique to a specific material (newmtl), i couldn't see the point to render one for every texture size used with this material.

And because the textures are used only for a guidance, an UV's map of 2048x2048 should be quite enough to work with.

When editing the UV's to remove AO artefacts, that would also impact the other textures, thus extrem care must be used when changing the texCoord.
This is definitly not for the novice.

[Michael Lobko-Lobanovsky]

Because UV's are unique to a specific material (newmtl), i couldn't see the point to render one for every texture size used with this material.
..........................
When editing the UV's to remove AO artefacts, that would also impact the other textures, thus extrem care must be used when changing the texCoord.
This is definitly not for the novice.

I agree absolutely, on all the above points.

1. There's only one UV set in an OBJ file mesh. All the mesh textures can reuse it because UVs aren't expressed in absolute coords but rather in fractions of texture size (from 0.0 to 1.0). Very clever, I'd say! (but alas, not suitable for lightmaps that require a separate UV set because their topology differs from all the other textures)

2. But then, who said OR's editing modes (lighting editor included) are meant for the noobs?

And because the textures are used only for a guidance, an UV's map of 2048x2048 should be quite enough to work with.

This statement needs proof. It denies precision in case the texture is huge but the details in it are still minute.

[Patrice Terrier]

This statement needs proof. It denies precision in case the texture is huge but the details in it are still minute.

The ultime precision is always one pixel, nothing more, nothing less, and due to rounding error when converting textcoord float to pixel, 2048x2048 seem to be a good compromise.

This is how i compute the final texcoord from the new pixel tx,ty texture location.

gtm_vertexBuffer[gnm_indexBuffer[mtl_index]].texCoord[0] = float(tx / float(bitmapWidth - 1));
gtm_vertexBuffer[gnm_indexBuffer[mtl_index]].texCoord[1] = float(1.0f - double(ty / float(bitmapHeight - 1)));

[Michael Lobko-Lobanovsky]

Hmm, isn't 1.0f - double(...) going to throw a warning about possible loss of precision?