WinLIFT Caps?

[Michael Lobko-Lobanovsky]

Does WinLIFT offer skinned tree view and toolbar controls?

[Patrice Terrier]

WinLIFT detects "TOOLBARWINDOW32" and "SYSTREEVIEW32", but i couldn't remember how good it handles them, because i do not use them myself.

[Michael Lobko-Lobanovsky]

Why I'm asking this is because frankly, I'm starting to dislike our right-side gray panel, Patrice. It doesn't look "professional" enough to me as compared to other modern 3D editing software.

What I'd rather like to have would be a skinned vertical rebar control that would host several (as needed) skinned panels each hosting, in its turn, a vertical toolbar filled with tools (again as needed, including the tree view to display the model/scene hierarchy) for a particular editor, pretty much like those in Blender, or 3ds Max, or LW Scene Layout or Modeler. (or, as it happens, in your own C4D editor)

The existing gray panel content might then go into the initially opened topmost panel of the rebar control...

[Patrice Terrier]

I don't like the rebar control myself, i prefer to use a tab control, or even better an autohide GDImage control to navigate from one view to another like in my OMO project, or in MBox 64, when selecting a movie.
http://www.objreader.com/index.php?topic=80.msg2117#msg2117

Idealy a new interface should be compatible with touch screen display 

But we could work on this after the long delayed features have been added to the existing project. 

For me "Surface Studio 2", is a good example of the next computer generation i would like to have for myself (if we make abstraction of the price).

[Michael Lobko-Lobanovsky]

Idealy a new interface should be compatible with touch screen display 

My friend,

3D editors have been around for a few decades now. Their GUIs have certain tradition in their expected (and optimal!) layout, so that when a pro opens up an editor, they can proceed to work almost at once without having to consult the manuals. Conversely, if instead they are seeing all the bells and whistles of a fancy GUI like in our lighting panel, they are likely to get lost. Moreover, most of them are right-handers, and having the controls on the left side of the window is just not handy nor natural for them.

The movie selector is out of the question because there's too little space in the gray panel while the gP.hGL window shouldn't be obscured with controls of secondary importance. Its function is to display your real time edits in every detail unhindered.

The tab control doesn't allow you to see all the tabs at once in a panel of such a restricted width and requires additional clicks on the scroller arrows to look them through until you find your target. OTOH the rebar has a stack of panel headers always visible and ready to be opened smoothly with a single click...

Last but not least, noone in his right senses is going to perform pixel-perfect edits on a touch screen display. A 3D designer's expected tools are high-res mice and stylus touch pads rather than their greasy fingers...

[Patrice Terrier]

Another thing we could focus first, is to find a way to speed up the loading of large models.
I have two models on my back burner, each of them with more than 40,000,000 triangles taking more than 2 minutes to load from disk.

About touch screen display, the problem is not about using the finger or a stylus, but the whole interface must be designed to use the new Windows paradigm. The interface i am using in MBox64 is exaclty the same on Windows and Android.

So far OR was designed to render 3d models and we can manipulate the model with the fingers or a touch pad.
However if we start to add new edditing features, then the whole interface must be redesigned.

And indeed the best solution would be to create a new editor application companion, to keep the viewer simple, rather than turning OR into a gaz plant.

This is what C4D is doing using distinct application modules;
BP 3D paint
BP UV edit
Modeling
Standard
Visualize

and we must restore the whole mobj.dll concept, to avoid code duplication from one module to another.

Thinking at loud voice 

[Michael Lobko-Lobanovsky]

Another thing we could focus first, is to find a way to speed up the loading of large models.
I have two models on my back burner, each of them with more than 40,000,000 triangles taking more than 2 minutes to load from disk.

There is no way to speed up loading of text files. OBJ files are text files. Any other type of data representation in a model is not an OBJ file.

The only strategy you can try to speed it up a little would be to abandon slow sequential fgets() and read the file as a whole (or in very large chunks) in memory first and then parse it directly in there.

So far OR was designed to render 3d models and we can manipulate the model with the fingers or a touch pad.

Then this is where and when OR development should stop. The splitter was already an overkill and nothing but a piece of bloat.

And indeed the best solution would be to create a new editor application companion, to keep the viewer simple...

As seen from your quotation here:

<<   This is what C4D is doing using distinct application modules;
BP 3D paint
BP UV edit
Modeling
Standard
Visualize   >>

it is not the editor that is the back end companion. On the contrary, it is the viewer that's a utility attachment to the editor ecosystem.

... to avoid code duplication from one module to another ...

What pertains to the OBJ loader proper is Mobj_importGeometry (1st and 2nd passes) and Mobj_importMaterials. You may isolate them in a separate  mobj.h file and compile it in a distinct DLL if you want to promote your application architecture.

Whatever else that's currently there in the project are pure renderer features and options irrelevant to the model data format that you happen to load in what is now called ObjReader using other similar DLLs, in which case the application will have no more rights to be called ObjReader any longer.

Note that what ObjReader effectively renders ATM are not OBJ files any more but effectively data in the application's own internal representation (mesh and material structures, vertex VBOs, texture maps, etc.) of the same.

... and we must restore the whole mobj.dll concept ...

You may, I won't. Not interested.

What attracts me primarily in this project is the editing functionality of the application that's not readily available nor handy enough in the existing editors.

[Patrice Terrier]

As i wrote i was thinking at loud voice…

But i am also listening, an your opinion is much of a value to me. 

Moving some parts of the code into DLL(s) makes sense only if we work with modules, to avoid code duplication.

The splitter was already an overkill and nothing but a piece of bloat.

Thank you for your appreciation on my work, however it was done on your specific request to put an editor on the right part.
But perhaps the whole interface must be revisited, for the purpose of the editor, that is something new that pops up only a few monthes ago.

What attracts me primarily in this project is the editing functionality of the application that's not readily available nor handy enough in the existing editors.

You must give me more insight about what you have in mind, because so far all the editing work i am doing is done in c4d.

[Michael Lobko-Lobanovsky]

Thank you for your appreciation on my work, however it was done on your specific request to put an editor on the right part.

You did not understand my message correctly, my friend. It is not your design or implementation that were bloated. On the contrary, they were clear and concise. It was the whole idea of the splitter as a part of OR projected editing capabilities that was a bloat of your concept of OR being just a simple OpenGL renderer and nothing more.

It is probably entirely my fault having failed to express myself loud and clear. But then I had asked you twice in advance if you were in favor of turning OR into something more than just another model viewer...

You must give me more insight about what you have in mind, because so far all the editing work i am doing is done in c4d.

• Can you correct AO jaggies in C4D? No, you can't. You need a UV editor that would project your mesh UVs on the AO map where you will be able to select and drag a couple of vertex UV projections slightly aside around your map to cover the jaggies while having immediate visual feedback from what you're doing, on your screen.
• Can you visually adjust your #rotate/#translate bounds using C4D gizmos and save them in the MAT file similar to how you can save the OR scene lights directly from OR's own built-in lighting editor panel? No, you can't.
• Can you adjust/correct the parameters for the projected texture matrix animations in C4D, visualize them and save them in the MAT file? No, you can't. There are no 3D editors that can work directly with the model texture matrices or visualize them, let alone animate them, on your screen.
• etc. ...

But perhaps the whole interface must be revisited, for the purpose of the editor...

I can do it myself -- unskinned, using the MS controls as I see fit for the purpose. Then your only task will be to apply WinLIFT/GDImage skinning where possible. And where impossible, to extend your framework capabilities to make it possible, or suggest and mock-up suitable alternatives without loss in functionality or user friendliness.

[Michael Lobko-Lobanovsky]

Regarding model format-specific loader includes and corresponding DLLs, I think it is a way to go. I was just afraid of vivisecting your mobj.h to just a couple of functions and adding half a dozen more task-specific includes like we have for tools, tool window, viewport tip, splitter, overlay, etc. You told me you don't like include files and prefer a horrible single miles long listing in the legacy PowerBASIC IDE or poor-man's Notepad style...

[Patrice Terrier]

This is another misunderstanding 
include files is the best solution to add new features especially when working in team, and to ease maintenance.

But then I had asked you twice in advance if you were in favor of turning OR into something more than just another model viewer

And i said yes…

Indeed if we can have a UV editor that would ease the whole texture creation process that would be of a great help to me!
But this tool is not intended to be used by the novice or the lurker.
AO editor YES
Visually adjust #rotate/#translate YES
Adjust/correct the parameters for the projected texture matrix animations, visualize them and save them in the MAT file YES

But please consider to make the builder/editor a standalone tool at least until the basic features have been settled, and before focusing on any skinned GUI. Then you can concentrate your work first on the core meat, and the bells and whistles will be added in a second stage once the basic features are working.

[Michael Lobko-Lobanovsky]

This is another misunderstanding 
include files is the best solution to add new features especially when working in team, and to ease maintenance.

I'm glad I've been able to make you change your preferences -- slowly but steadily.

But then I had asked you twice in advance if you were in favor of turning OR into something more than just another model viewer

And i said yes…

And then you reproached me of having deviated from your main objective to implement ObjReader as a simple finger driven model viewer, in fact just another show-off of your WinLIFT/GDImage framework.

But this tool is not intended to be used by the novice or the lurker.

If you want, we can even develop the editor extensions as a closed source commercial plug-in. But then I have strong doubts as to whether we'll be able to make it profitable with our respective expected hourly rates.

But please consider to make the builder/editor a standalone tool at least until the basic features have been settled, and before focusing on any skinned GUI.

Will do.

Then you can safely immobilize the splitter, clean up the code of my test exercises, and release the current ObjReader as version 2.75. It has a ton of improvements as-is to deserve an own minor version reference.