Author Topic: There are many ways to go to Rome.  (Read 816 times)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #45 on: March 01, 2019, 09:17:25 pm »
This is how UV coordinates are created in C4D when saving into a .psd file (see the red overlay)...

... only in case the mesh is quadrangulated where possible, rather than triangulated. OR only uses glDrawElements (GL_TRIANGLES, ...) to draw the surfaces and/or wireframes, and thus it always re-triangulates the model in its Mobj_importGeometrySecondPass() at model load time. This is what we'll see in our OR UV mapper in the end too except the wireframe will be made up of tris rather than quads, and the tri corners will be marked with bullets for easier point-and-dragging around the tex map.

if you have already a working solution, then we can go for it, if you prefer.
However avoid to draw directly onto the texture, but unto a transparent bitmap of the same size.

I only have a working Vertex Color Editor (with many associated features of a UV map editor) in my Xandreale game engine project I wrote ca. 10 years ago in FBSL BASIC, C, and 32-bit Asm. This is what you saw in my snapshots earlier in this thread. I will have to rewrite it in equivalent 64-bit CPP where possible (alas, 64-bit MS VC++ has no inline assembler available). I would have done it if only you weren't promoting your Tor solution at all costs. ;)

Let's finish off with your Tor protégé first, and I'll switch back to my simpler solution if Tor fails to do what we need. :)
« Last Edit: March 01, 2019, 09:23:36 pm by Michael Lobko-Lobanovsky »
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #46 on: March 01, 2019, 10:20:21 pm »
Quote
I would have done it if only you weren't promoting your Tor solution at all costs.
I am not promoting it at all costs, it is just one of the many ways to go to Rome…

However this one is based on the code that already exist in the GDImage64.dll, and thus something i could help with.
But there is no guarantee that my way would be better than yours. ;)

The important point in Tor.cpp, was the GUI interface that has been tailored to fit inside of OR asside of the splitter.
This part was already a huge work, and i like the result.
The use of a zoom window is also serving us well, to deal with the view port size that follows the splitter move.


« Last Edit: March 01, 2019, 10:34:17 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #47 on: March 02, 2019, 02:08:59 pm »
Here is an example of the Dragon's UV map exported from Blender (Don't ask me how i was able to produce it with their complex GUI interface, because i couldn't do it twice).

And as far as i understand what to do, we are concerned only by the red border surrounding the shadowed polypolygons.

It is quite a challenging work to create the correct POINTS array  :o


« Last Edit: March 02, 2019, 03:15:36 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #48 on: March 03, 2019, 02:33:22 pm »
Quote
(Don't ask me how i was able to produce it with their complex GUI interface, because i couldn't do it twice)
;D ;D ;D ;D

Blender is a Linuxoid product. Linuxoids do not have GUI design skills or tradition, and GUIs of Blender level of complexity are certainly beyond their capabilities. And it is a real pity because functionally, Blender is a 100% professional software suite and a very good one at it.

Someone should do a great service to the humanity and go down in history by reworking Blender's crooked GUI to follow the principles of ergonomics and user-friendliness implemented in other similar editing environments like, say, Autodesk 3ds Max or Adobe Photoshop. The Blender source code is open to everyone, after all. :)

Quote
... we are concerned only by the red border ...

No, not in the least, my friend.

On the contrary, we are concerned by every line intersection point you're seeing in your upper UV map. These points (called UVs, or UV pairs) are the projections of model 3D vertices onto the texture map plane, and each flat triangle you're seeing is consequently the projection of a corresponding 3D mesh polygon (triangular rather than quadric in our case) onto the same plane. U stands for the plane X coordinate in a more customary high-school notation while V stands for the Y coordinate. Seldom used 3D textures also distinguish a third W coordinate to denote the texture "depth" level similar to the Z coordinate in our customary 3D space. 3D textures are sometimes used to efficiently colorize virtual volumes like sky clouds, or clouds of smoke, or street light volumes ("shafts").

In the most general case, a jaggie (or any other unwanted artifact) may occur at any point within the texture map borders. So, we should be able to drag an arbitrary triangular wireframe intersection point (i.e. some polygon corner or apex a.k.a. "vertex" in traditional 3D lingo), or some of them, manually a little around the nearby portions of texture map to try and hide the artifact from direct view if at all possible.

You've been evidently misled by the visible similarity of wireframe "islands" in the lower texture map with your USA outlines in your Tor demo video. :)

There's absolutely no problem to "project" the UVs written in the OBJ file and stored in their corresponding OR 3D vertex structures onto the texture plane. The UV (or XY, if you prefer) coordinates have already been pre-calculated and normalized to the [0.f,1.0f] range for you at model design time in the model designer's UV unwrapper software. All you have to do is multiply the floating-point U value by the texture pixel width, and V value, by the texture pixel height, and plot the resulting pixel point (a.k.a. apex, corner, vertex, UV, UV pair) in the texture map or against it if it is just a background "layer". However in practice it appears easier to denote the UVs as 3x3 px large boxes rather than just pixels (texels) in both 2D and 3D to be able to easily aim at them and select them for manual dragging as shown below.

(In Xandreale, I can select the UVs of interest (shown in red) in both 3D and 2D viewports whichever I find the easiest. What cannot be done in the existing 3D editing software but can be done in Xandreale is that you can walk up to any object of interest in the 3D viewport using the FPS (first-person-shooter) camera and mark manually any single vertex in the scene that you would like to work with in your current scene editor.)

OTOH drawing the associated wireframe map is more difficult in 2D GDI where I need to prepare a special UV (vertex, apex, etc) array in triples following the vertex indices that OpenGL uses to draw its GL_TRIANGLES (or GL_QUADS) based on the VBA or VBO data, and use a series of Polygon() API calls (or asingle  PolyPolygon() call) to draw the GDI equivalent of OpenGL wireframe projection on the texture map plane. Practice shows that drawing 30K of UVs using Polygon() is too slow due to the function call overhead while one single call to PolyPolygon() is almost as fast as its OpenGL glDrawElements(GL_TRIANGLES, ...) equivalent is for a VBA of polygons.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #49 on: March 03, 2019, 07:57:51 pm »
Quote
However in practice it appears easier to denote the UVs as 3x3 px large boxes rather than just pixels (texels)
My idea was to mimic the PSD brush size for the hot spot, and the real pixel location would be always the width and height size divided by 2, indeed any odd square size value could be used to compute the correct pixel/texel location.
« Last Edit: March 03, 2019, 09:24:51 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #50 on: March 04, 2019, 01:29:21 pm »
Indeed, the hot spot itself could be a square polypolygon that could be resized on the fly, to always look the same (whatever the zoom being used).
We coul also create a region of interest to limit the size of the working area, there is already a Tor function to create such a section (search for TOR_CROP within the code).

« Last Edit: March 04, 2019, 07:07:08 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #51 on: March 13, 2019, 09:38:09 am »
Because we are going on with Tor.

I shall post a new update with the latest change i have done (region of interest).
I have first to save the resulting region into a file, but to be really useful, we should save the x,y,w,h, coordinates to later put back the modified region at the correct location.
Working on a region of interest would limit the amount of points to render, and speed up the display.

Added:
The latest project is attached to this post.
Search for gT.nCropZoom, for the zoom factor to use with the region of interest.
See the video attached to the previous post on how to use the new crop button.

« Last Edit: March 13, 2019, 12:00:15 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #52 on: March 13, 2019, 02:27:00 pm »
Working on a region of interest would limit the amount of points to render, and speed up the display.

That's a good idea! Don't you think that once selected, the region should replace the whole texture in both the Tor main view and selection thumbnail (where the red view rectangle is usually seen) in order to be able to further select a yet smaller region if needed?

Quote
See the video attached to the previous post on how to use the new crop button.

Looks good indeed!

1. There are two artifacts in the selection quadrangle -- a missing dot on the left, and an extra dot, on the right sides of it.

2. I think we should add a menu entry to be able to disallow sound notifications altogether. (though I like them; they add some charme to OR ;D)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #53 on: March 13, 2019, 02:59:42 pm »
Quote
That's a good idea! Don't you think that once selected, the region should replace the whole texture in both the Tor main view and selection thumbnail (where the red view rectangle is usually seen) in order to be able to further select a yet smaller region if needed?
This is just a prototype, everything is possible. So far the zoom of the "region of interest" could be adjusted from a slider or a gauge.
If you run the program you will see that the selection thumbnail is already updated, and an arbitrary ratio of 4 is applied to the region of interest.

What i really need now is to get the correct UV's X,Y POINTs array, to move on.  ???
« Last Edit: March 13, 2019, 04:56:03 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #54 on: March 18, 2019, 10:46:22 pm »
Hi Patrice,

I've implemented three nice additions to OR:
  • View->Enable VSYNC (default is ON) allows us to override the turbo switch and disable vsync altogether to see the maximum FPS rate the video card is capable of for a given model in the continuous mode of operation. (see the monkey below) This mode can be rather heavy on the GPU especially if the model is complex, so it should be used with caution in order to avoid GPU chip overheating. The implementation also allowed me to fix the annoying bug whereby the gP.hGL stood empty if the OR main window was dragged by its caption bar beyond the screen borders and then dragged back in full view again.
  • FPS-independent animation of splitter movement on double click and model reset in the viewport. It works even if vsync is fully disabled. Model and mesh rotation animations can be made FPS-independent in a similar manner as well. (not implemented yet)
  • We now have an excellent GL_FLAT shading option in all our shaders. It works perfectly regardless of what normals the model has (flat or smooth) and whether it uses normal maps or not. (see your Unreal model below)
I will send you my code tomorrow. I have yet to sort out which files have been modified in the process of implementation...

Stay tuned! 8)
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #55 on: March 19, 2019, 09:57:12 am »
Ok, looking forward for the new changes... and what about the long awaited XY point array  ;D

I am upgrading from C4D R17 to version R20
that should let me import Solidworks, STEP, Catia, JT and IGES CAD
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #56 on: March 19, 2019, 12:15:18 pm »
Ok, looking forward for the new changes...

I'll clean up and upload the code after my lunch (it's 2 pm here now).

Quote
and what about the long awaited XY point array  ;D

Frankly, I don't understand what prevents you from building the arrays yourself; I think I've described a detailed algo a few times already. ;) OK I'll write the relevant code but you'll have to integrate it with Tor yourself because I'm reluctant to study its current functionality -- just as you are reluctant to read up on UV unwrapping and projection theory and practice. ;D

Quote
I am upgrading from C4D R17 to version R20
that should let me import Solidworks, STEP, Catia, JT and IGES CAD

I'm still nominally an employee at Serge's software company, so I've been able to use their corporate license to upgrade legally to Autodesk 3ds Max version 2018. I also installed their Autodesk Maya 2017 and am now able to read, edit, export, and convert .MA files.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #57 on: March 19, 2019, 04:09:18 pm »
Here are the mods I was talking of. (Tor arrays will come later)

Please let me know if they work well for you.
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)

Patrice Terrier

  • Administrator
  • *****
  • Posts: 1190
    • zapsolution
Re: There are many ways to go to Rome.
« Reply #58 on: March 19, 2019, 05:01:50 pm »
Downloaded, thank you!

I shall come back to you later.

Added:
The new VSYNC off mode, seems to work well by me, even with huge models.
Note: FPS count is always visible when VSYNC is off.
« Last Edit: March 19, 2019, 05:57:13 pm by Patrice Terrier »
Patrice
(Always working with the latest Windows version available...)

Michael Lobko-Lobanovsky

  • Administrator
  • *****
  • Posts: 1017
Re: There are many ways to go to Rome.
« Reply #59 on: March 19, 2019, 06:20:29 pm »
The new VSYNC off mode, seems to work well by me, even with huge models.

That's good to hear! What about the other two features (gP.hGL redraw on WM_PAINT to avoid an empty viewport and GL_FLAT rendering in all shaders including fancy and design mode ones)?

Quote
Note: FPS count is always visible when VSYNC is off.

That's natural because we disable VSYNC to know the maximum FPS rate our video cards are able to achieve in an unconstrained continuous rendering mode. It's yet another indirect way to evaluate both the model complexity and the OR renderer efficiency. There's no other reason to switch VSYNC off.

Use VSYNC OFF with caution to avoid overheating your laptop video chip!
Mike
(3.6GHz Intel Core i5 Quad w/ 16GB RAM, nVidia GTX 1060Ti w/ 6GB VRAM, Windows 7 Ultimate Sp1)