Tri-state Toggle Switch?

[Michael Lobko-Lobanovsky]

Hey Patrice,

Does your GDImage arsenal include a tri-state toggle switch that looks like the ones used for the FPS counter and Turbo mode ("running man") but with three fixed states rather than two?

[Patrice Terrier]

Indeed you can have as many states as you want, assuming they have all the same width.
Search for the ZD API,  FrameCount, FrameToUse, etc.

See the attachment

[Michael Lobko-Lobanovsky]

Thank you!

[Patrice Terrier]

Mike,

If you need to edit/display large textures, the GDImage zoom control has already almost everything to zoom in/out.
And the gMap64 project would be a good candidate to start from. Displaying aĺl the textures on a thumb band, to select the one to work on. The right floating panel could be used to display graphic components or tool icons.
Of course that is just a suggestion, but because it is alreay written that could be a huge time saving.
Have a look to the features list into the "Eye candy" section.

[Michael Lobko-Lobanovsky]

Yes Patrice,

The zoom control could be a nice canvas for the UV editor if we can have fast and easy access to its GDI (not GDI+ !) hDC and can draw and redraw non-antialiased GDI poly-polygons of unwrapped UV wireframe directly on top of its zoomable textured background to match the wireframe scale with the current zoom ratio in a pixel-perfect manner.

The vertical thumb strip with tool thumbs (in fact, an equivalent of Windows pager control) could probably replace the standard rebar control. But how can we combine it with our current view of the controls on the gray panel? OTOH they (or rather their Windows standard control equivalents) could be hosted in the rebar's initially open topmost panel...

And that small bottom right corner strip of square buttons looks almost like a toolbar...

In short, you're a designer and you should generate the ideas of how we can nicely combine what we already have with what we need to implement easy access to a number of projected editor tools. I can subside to a floating tool window (like the fancy shader control windows) for immediate interaction with each individual editor. But we absolutely must have a common full featured and very finely detailed per-mesh tree view of scene object hierarchy visible at all times instead of our current simple mesh list. Probably its scrollable viewport should be synthesized from several simpler controls/control strips synchronized with one another as the "tree view" vscroll thumb moves up or down... (see your DreadRoamer hierarchy in Blender below)

[Patrice Terrier]

My friend

GDImage works internally with DIB bitmap not GDI+, for historical purpose, and also to render OpenGL directly into it.
There are several API that could be used to retrieve the internal DC and bitmap, ZI_GetDC and ZI_GetBMP.

For poly_polygons, there is already the ZD_PolyPolygon (sprite object).

The vertical thumb strip with tool thumbs (in fact, an equivalent of Windows pager control) could probably replace the standard rebar control. But how can we combine it with our current view of the controls on the gray panel? OTOH they (or rather their Windows standard control equivalents) could be hosted in the rebar's initially open topmost panel...

If it was me, i wouldn't try do this inside of the existing OR, but in another standalone companion EXE, with an interface specifically designed for editing purpose.

But we absolutely must have a common full featured and very finely detailed per-mesh tree view of scene object hierarchy visible at all times instead of our current simple mesh list.

I am not familiar with tree view programming myself, the only one i have ever used was the one from my zBFF utility (Browse For Folder) but that was long ago 
The C# project is here (the DLL itself is written in PowerBASIC)
http://www.jose.it-berater.org/smfforum/index.php?topic=3767.msg12476#msg12476
Note: Eros Olmi is using it inside of the editor of ThinBASIC
I could try to mimic the behavior of a treeview within a GDImage control if there is no other solution, but that couldn't be done in a snap.

[Michael Lobko-Lobanovsky]

For poly_polygons, there is already the ZD_PolyPolygon (sprite object).

Sprite object?

I'm talking about GDI PolyPolygon() and PolyPolyline() APIs, not sprites. They are used for fast drawing of UV coordinate wireframes on top of GDI images of texture maps. They are based on arrays of POINT structures derived from the mesh UVs by expanding the [0,1] range of tex coords to pixel coords in the texture width times height pix range.

Therefore there should be absolutely no anti-aliasing as everything needs to be done pixel perfect.

... in another standalone companion EXE, with an interface specifically designed for editing purpose.

It means first I have to write yet another (unskinned) OR clone and migrate perhaps 95% of pandora-independent code into it. I need immediate results to be seen in real time in a renderer that's 100% compatible with OR, rather than do all that senseless leapfrogging between a 3D editor and a final renderer.

I am not familiar with tree view programming myself, the only one i have ever used was the one from my zBFF utility (Browse For Folder) but that was long ago ... I could try to mimic the behavior of a treeview within a GDImage control if there is no other solution, but that couldn't be done in a snap.

I can build it all myself from the Windows standard controls. But what are you then going to do racking your brains with porting it all back to OR?

[Patrice Terrier]

My friend

I will not argue on the advantage to work with sprite object, suffice to say that it is just like working with multiple transparent layers in PSD, and when you are pleased with everything then you merge (flatten) all the layers.

Vectorial objects could be antialiased or NOT, using the ZS_DRAFT style to work like GDI32.

See the attached screen shot
top DRAFT mode
bottom antialias mode
and this could be changed on the fly, something impossible when you work directly with a GDI32 DC.

Thus better to work with vectorial sprite objects, and flatten them once to create the final texture file, but only when the whole editing process is over, this is exactly what gMap64 does when you use the "Create a project image" button.
Morever gMap64, shows always the real mouse cursor coordinates (in pixel) whatever the zoom being used to help the whole editing process, and for each of the sprite their respective XY top left coordinates. In GDImage, vectorial objects could be moved arround and manipulated just the same than raster bitmap. You can even move them pixel by pixel, using the arrow keys, for ultimate precision.

BTW, the main window of gMap64 could be moved inside of OR, and the splitters could be used to enlarge the view port just like gMap64 does. Then you could put it aside of the current unused splitter, but we will need also the windowtool zoom.
If you haven't tried gMap64, perhaps you can give it a run to better understand how it works.

[Michael Lobko-Lobanovsky]

Hehe,

The Blender model tree hierarchy control shown in Reply #4 is known as TreeListView. There's a ton of its implementations around written in Java, C#, VB.NET, Qt C++, etc. but almost none implemented in C and flat WinAPI.

Yet what you'll find in the attached zip is its 32-bit Unicode C implementation that has almost the exact same looks and functionality as in Blender except that it doesn't show full row selection. Here it is limited only to the treeview item string length proper like in an ordinary tree view. Otherwise the icons and font are customizable on a per grid cell basis. The test executable doesn't have a manifest which is why the header control has a legacy appearance. Here the TreeListView features that the executable utilizes are linked in statically from the control include file but the control can also be compiled as a full-featured ca. 650KB large standalone DLL.

Now my only task is to make it compile in 64 bits and there we go with probably the trickiest part of editor interface.

[Patrice Terrier]

Downloaded, thank you!