There are many ways to go to Rome.

[Patrice Terrier]

Rough video to show you, the use of a GDImage zoom control inside of OR.

It could be either a native child control, or an internal window (the same that you did to embed HH).

At least, this is how i would reuse my existing code, using a GDImage callback to create the point array for Bezier curve or whatever polypolygon in draft or antialias mode.

There are many ways to go to Rome.

 

[Michael Lobko-Lobanovsky]

Hehehe that's a cool demo Patrice!

What does this tiny square do, if at all?

[Patrice Terrier]

This tiny square is specific to the un-skinned zoom control scrollbar, to avoid the nasty empty scrollbar section when Windows redraws the NC area.

[Michael Lobko-Lobanovsky]

Patrice,

1. Can the control run completely unskinned including the top and bottom splitters and the top thumbnail strip?
2. Can the little widget with the zoom slider on the right be placed in a separate window (e.g. tool window) together with the other controls of UV editor?
3. Can you add yet another layer (what you call a "sprite") on top of the texture map main display and draw an array of lines in it to demonstrate the synchronicity of both layers' zoom factor as the slider in the little widget is dragged left or right?

(I'm going to the hospital this Thursday morning and won't be able to enjoy the demo before I return in (hopefully) 3 weeks' time but I'd like to at least see the video before I go)

[Patrice Terrier]

1. Can the control run completely unskinned including the top and bottom splitters and the top thumbnail strip?

Yes, and the top and bottom splitters are indeed custom buttons.

2. Can the little widget with the zoom slider on the right be placed in a separate window (e.g. tool window) together with the other controls of UV editor?

It is already an anchored tool window, that you can move everywhere.

3. Can you add yet another layer (what you call a "sprite") on top of the texture map main display and draw an array of lines in it to demonstrate the synchronicity of both layers' zoom factor as the slider in the little widget is dragged left or right?

It could work just the same to what you can do with the GDplus project, see the bottom control using the green open polyline with the red dots that are used as hot spots to change the shape of the polyline, the red dots are indeed an array of x,y locations.
Inside of a GDImage zoom control all the tedious computation work is done transparently and you always refer to the array with ratio 1/1, it means using the real pixel location value.

As i told you already i would cannibalise the gMap64 project, to create the OR specific edit control, because it has already 90% of what we need to do in OR (at least in my understatement of what must be done).

I could customize the code to create the array of point using multiple mouse clicks to setup the hot spot following a specfic UV shape, then ask to create the polypolygon from the array, but the final sprite array will be flatten only when we ask for saving, and untill there we can change everything. Clear as mud?

There is also a specific contextual menu inside of gMap64, and we need it too, see the attached video.
See also the use of the green markers that could be used to create the array of points.

I have added another video to show you the synchronicity, the little widget being also a GDImage control, and the RED rectangle inside of it, is a vectorial polypolygon that i can drag around to move the main view port accordingly

[Michael Lobko-Lobanovsky]

Thanks for your efforts Patrice,

The videos are rather comprehensive! The control seems to be gorgeous and rather rich in features. I'd even say it's too rich for our modest purposes.

The arrays of UV points aren't normally created manually but are rather flat 2D projections of mesh 3D vertices on the texture map plane. There can't be an UV pair that doesn't have at least one matching mesh vertex. So, it isn't the UV editor task to create the UV points but rather the task of the mesh vertex editor to create the 3D vertices. The UV editor just uses the existing mesh vertex array to unwrap it on the map's plane algorithmically using planar, cylinder, conic, spherical etc. primitive projections as well as certain more advanced algos like e.g. the one to unwrap facial and other predefined body part projections across the skins of predefined configuration. You've seen and used them in a number of your character and monster models.

If the model is already equipped with UVs, the UV editor's task will be just to draw the UV wireframe overlay over the texture image, denote the mesh vertex UVs with typically 3x3 px boxes, and allow the boxes to be dragged around the texture in order to fine tune their UV coords as may be necessary, e.g. to hide the texture map jaggies. The new UVs may then be optionally written back into the model file. That's what OR's UV editor should be able to do in the first place.

OK we're going to come back to that topic later when I'm back from the hospital. Thanks again for the nice demos, my friend!

[Patrice Terrier]

If the model is already equipped with UVs, the UV editor's task will be just to draw the UV wireframe overlay over the texture image, denote the mesh vertex UVs with typically 3x3 px boxes, and allow the boxes to be dragged around the texture in order to fine tune their UV coords as may be necessary, e.g. to hide the texture map jaggies

Of course i understand that, just remember that in GDImage the X,Y coordinate of a sprite object (overlay) is always the top left corner, thus in the case of a 3x3 hot spot, there will and offset of 1 (there are API to retrieve the X, Y, width, and height of an object). Due to clone optimization the hot spot bitmap will be stored only once in memory, and we can also have a library of hot spots to select from the floating list on the right, like the green/red one shown on the video. They can have also multiple states (see the video). And we could save the sprite locations within a .gns file for further retrieval.
The contact sheet on the top that could be hidden with the splitter, is to select a specific texture to work on (more visual than selecting from a treeview).

So far my main concern is to guess what would be the best solution to use the zoom control:
- from an internal window (embedding a modified version of the gMap64 application, using WM_COPYDATA to communicate)
- or from a standard GDImage class, as we did for the other controls.

The internal window was what i had in mind when i was speaking of a standalone application (slave application).
This architecture could be used to swap from one module to another, WM_COPYDATA works very well and this is what i am using to mix 32-bit and 64-bit altogether (my OpenGL BassBox visual plugins are a good example of this). It is just like working with multiple threads, the main thing to be aware of, is to make sure that the application is not already running and to kill the slave application when the main one goes down. The slave application could also check peridodically that the main application is still there, and if not then shut down itself.

I am thinking at loud voice again

[Michael Lobko-Lobanovsky]

I am thinking at loud voice again

I like that voice of yours.

Is WM_COPYDATA capable of re-mapping data pointers when crossing the process boundaries or rather does it only pass data values one by one? If it does the latter, then it will be too slow to set up a real time "bridge" between the "master" editor and "slave" ObjReader because the amounts of data to be passed are going to be huge.

My intention is to have OR to depict immediately in its high-quality viewport every minute change to the model data that I might be making in whatever editor I happen to be working with.

If I can't do that, then I'll have to re-create a clone of full-featured (if only unskinned) OR as the editor's own main rendering viewport. I want to have a 100%:100% WYSIWYG correspondence between the 3D pictures in the both applications.

[Michael Lobko-Lobanovsky]

OTOH there's nothing preventing us from compiling each such editor as a DLL plug-in to the main OR app. The DLL can have a single "property getter" that would expose a pointer to the DLL's entire "vtable" in the form of a strucure of FARPROC pointers to the editor procedures, and possibly, editor specific data.

Then if the editor DLLs are available in the installation (which can be polled by a set of simple calls to LoadLibrary()), then OR would reveal the corresponding main menu elements, set up its "vtable" interfaces with the DLLs, and exchange the actual model data with the editors fast and free because the plug-ins and the OR host would share common process memory.

[Patrice Terrier]

WM_COPYDATA is very capable, you can pass a full UDT in one single call.
See my post there
http://www.jose.it-berater.org/smfforum/index.php?topic=4932.msg20600#msg20600

Note: BB64 process the audio signal in real time, and call a 32-bit application bridge to sync with the BassBox plugins.
See the attached video showing the use of WM_COPYDATA in context.

[Michael Lobko-Lobanovsky]

I can't notice any perceptible lag between the sound and visual response via WM_COPYDATA. I think such a speed of data interchange will be sufficient for "slave" OR's real time response to the model data changes in the "master" editor application.

[Patrice Terrier]

I am experimenting right now to create a container on the right part of the slider to host the editor(s).

[Patrice Terrier]

I can't notice any perceptible lag between the sound and visual response via WM_COPYDATA.

The whole Windows paradigm is based on the message pump, and sendmessage is the basic and fastest way to use for IPC.
And the WM_COPYDATA message has a high priority.

[Michael Lobko-Lobanovsky]

No, I can't agree with that statement. Everything that's based on the window message processing pump is turtle slow, computation wise. That's because MS Windows has got its own idea of task priorities and tends to block and kill the apps that don't agree to play by its rules.

BTW where's that:

Note: The source code is provided to help those wanting to learn more about low level SDK programming in C++, and to get the most of WinLIFT and GDImage.

? ? ?

[Michael Lobko-Lobanovsky]

How would you live for three weeks without a computer close to you   

Oh Patrice,

Don't you say that! I'm in panic and everything keeps falling out of my hands. I'm not actually scared as I know I need that treatment anyway and I can't avoid it.

But I hate losing three weeks of my life for that sick and silly hospital environment of decay and entropy...