graphical user interface proposal

[Lord Crc]

What about we move the thread controls, intervals controls and renderer controls to a specific tab? Number of threads might not make sense depending on the renderer selected, and having the renderer selection directly available makes one think this is an inoccuous change while it might require a render restart.

This sounds like a good approach to me.

[Sheltem]

Just my 2 cents worth on the live navigation tab:
If we are able to move the camera along 3 axis there needs to be a way to select which axis. Currently the up arrow could mean to move the camera forward into the picture or literally move the camera up...
When it comes to rotating the same as above applies. Also and this is only a my personal preference when talking of rotation I am thinking of a circular looking kind of control.

Any way looking forward to see live controls in lux!

Sheltem

[Carbonflux]

I only wish to offer a warning and not make the debate more complex, my view is that thinking in terms of the UI has drifted into just showing a pile of features, the debate seems to be how much we clutter a given tab etc. The UI went thru a total reset with the Qt port and any refinements that had emerged were lost, now in the rush to release 0.8 and add even more features we get more of a UI pile.

At some point I think it will be important to start taking the UI more seriously and have a specific UI/WorkFlow release, which means a feature freeze. I don't think lux is at the point where this will be practical in the near term but at some point there will emerge a good resting place where we can pause, debug and perfect the feature set and then really dig into the workflow integration and functionality layering that is the true value added aspect of UI. This can be fun in fact, UI design does not always have to be tedious if framed correctly.

In this context I offer just one conceptual goal: Image first.

[jeanphi]

Hi,

You're absolutely right Carbonflux. That's why I think we should focus right now on giving access to the basic controls a user will need. Scene updates will be much more easily handled from within the host 3D application (I'm not sure we have currently the ressources to build a standalone 3D editor).

Jeanphi

[tomb]

Apropos basic controls - before xmas I started looking at unifying the network rendering tab with controls for OpenCL, but quickly ran into issues that needs to be discussed in plenum.

OpenCL nodes:
What parameters should be/can be edited on the fly?
How should we handle the parameters that mandates a full restart of the rendering? (how should this be presented to the user)
What (if any) params should be editable for networked opencl nodes?

What to do for renderers that are not opencl based? Just hide the "unified" opencl control tab/dialog?

[jeanphi]

Hi,

My take on this issue is that a unified interface should present the host and any known network node.
Network nodes should be able to be activated or deactivated from the interface and eventually show if they are already computing another scene.

All nodes should present the render engine used and the relevant tuning knobs:
- for CPU rendering : number of cores (read only) and number of threads (r/w)
- for GPU rendering : OpenCL devices with type, number of cores and load (read only), an option to use a given device (r/w), an option to change the number of feeding threads

I might be missing some stuff but that should give good control over the architecture.

Regarding network nodes, I think it would be nice to be able to tweak them, but not mandatory at first.

Regarding parameters wanting a restart, those should use the queryable interface and be identified as such. The user should be prompted before making the modification, with an option to remove the confirmation. Maybe those parameters should be displayed with a specific style that would differentiate them (in red, bold or whatever).

Jeanphi