PDA

View Full Version : how to achieve fast workflow in LW 2019+ : what features would you want ?



gar26lw
03-20-2019, 06:51 AM
Identify the shortcomings in your everyday workflow and present a desired solution.

Tim Parsons
03-20-2019, 07:21 AM
For what we do Layout is almost perfect so my comments will be about Modeler. First and foremost Modeler needs to be able to handle more polygons and a better representation of textures and procedurals in the openGL viewports. Second it needs a consolidation of tools. Third a real workplane not the hack they got now. Let's start there. To be honest, even though I hardly ever use it anymore, copy a lot of Modo's modeling workflows and Modeler will come to the top of the heap in modeling again.

JohnMarchant
03-20-2019, 08:50 AM
Modeler and its tools need to be completely overhauled. Many tools do similar jobs and many could be substantially enhanced. I would agree look at how Modo and LWCad in LW do it. But overall modeler needs to handle more polys smarter and proper representation of textures in OGL.

Ryan Roye
03-20-2019, 10:14 AM
In some ways I think LW 2018 took some steps backward in the surfacing workflow. Now that it's mandatory to go through the node editor, there is no longer a fast, convenient way to apply images, normal maps, etc; as it requires a few more steps to do. This is tedious in larger scenes without some form of automation in place, and it is less user friendly because new users now have to learn two interfaces in order to utilize lightwave's surfacing functions. In the future, i'd like to see the old interface make its way into other node types than standard; even if all it does it create and hook up the nodes for you.

There's modeler too but... that's so obvious it hurts.

prometheus
03-20-2019, 11:31 AM
In some ways I think LW 2018 took some steps backward in the surfacing workflow. Now that it's mandatory to go through the node editor, there is no longer a fast, convenient way to apply images, normal maps, etc; as it requires a few more steps to do. This is tedious in larger scenes without some form of automation in place, and it is less user friendly because new users now have to learn two interfaces in order to utilize lightwave's surfacing functions. In the future, i'd like to see the old interface make its way into other node types than standard; even if all it does it create and hook up the nodes for you.

There's modeler too but... that's so obvious it hurts.

I agree, but not only for surfacing, I feel the same for setting up volumetrics, where we lack the direct drop down list to add hypertexture, you have to go to edit nodes, add your node plug it in to the right slot, and this YOU HAVE TO KNOW..
while the old hv, just go to hypertexture and choose desired procedural, done.

And the hypertexture speed effect is gone..you Have to set up a null and reference it.

And..with the old single hv module window, you didn´t have to select your item to edit it, that is a must for the new volumetrics, and as such..you can not move other items around in the scene at the same time, you loose your volumetric properties and the settings within.

And the direct vpr animation preview is gone, takes some more steps to render a preview..not impossible though.

And we can not use volumetrics on points as old hv was able to, not without adding particles on to it.

And random scaling was a breeze to just slide the random scalar value in old hv, with new volumetrics you have to either add a random node, or change particle scale in the emitter itself..it´s wonky.

Apart from the workflow of setting it up, I like the realism of it and it Enhances volumetrics in one way..realistic lighting(except for that I miss better deep multiscattering), and using several nulls and cloning will not halt your system as old hv did.

So summing it up(for volumetrics), workflow turned out not so good..sacrificing the setup speed of volumetrics, and sacrificing the ease of use, especially for newbies, while rendering realism in shading lighting, and edge softness and render speed has become better, as well as getting cubic shape in there.


I think I have a thread about the newly added multiprocedural node, which should allow for switching procedurals without breaking the connections, when you have output to multiple input in the shader, that may be good, but
these procedurals lacks some things like invert, and the multiprocedural node requires to enter another button and popup window "options" for tweaking it´s finer settings, I find it frustrating...and that particular setting is
also easy to get hidden behind other window popup items, and hard to bring to front even if you stand on the main multiprocedural node.

I may think it would be wiser to have a switch node, wich could consist of pre-made connected procedural nodes, in to a switch..then you simpley bypass or activate the node you need...this would allow for clicking on any of the procedural nodes and tweak them as they are normally without having to enter options, and with the invert option intact.

Dan Ritchie
03-20-2019, 11:44 AM
I think modeling in the perspective view could be improved.

Modeling along the view plane doesn't make sense for many things, where modeling along the ground plane, or along tangent space would be much more intuitive.
For example, just drawing out a rectangle would be much simpler and intuitive if it worked along the ground plane.
Extruding would be much simpler along a normal

- - - Updated - - -

Agreed on consolidation of modeling tools.

hypersuperduper
03-20-2019, 11:46 AM
They really should make it possible to expose nodal inputs in the main window (surfacing, volumetrics, motion etc.) i shouldn’t need to open a node network to change a single scalar value, change an item reference, or swap a texture. They should also improve preset capabilities (let me make a node network, expose the inputs I want, and save it so it is accessible in a drop down). If they did this and included a whole host of nodal presets that users could just use or open up and play around with it would be pretty great.

robertoortiz
03-20-2019, 12:00 PM
In some ways I think LW 2018 took some steps backward in the surfacing workflow. Now that it's mandatory to go through the node editor, there is no longer a fast, convenient way to apply images, normal maps, etc; as it requires a few more steps to do. This is tedious in larger scenes without some form of automation in place, and it is less user friendly because new users now have to learn two interfaces in order to utilize lightwave's surfacing functions. In the future, i'd like to see the old interface make its way into other node types than standard; even if all it does it create and hook up the nodes for you.

There's modeler too but... that's so obvious it hurts. Great post.

prometheus
03-20-2019, 01:04 PM
They really should make it possible to expose nodal inputs in the main window (surfacing, volumetrics, motion etc.) i shouldn’t need to open a node network to change a single scalar value, change an item reference, or swap a texture. They should also improve preset capabilities (let me make a node network, expose the inputs I want, and save it so it is accessible in a drop down). If they did this and included a whole host of nodal presets that users could just use or open up and play around with it would be pretty great.

:i_agree:

ernesttx
03-20-2019, 01:35 PM
I actually love the node setup. I don't see how you could expose all the different hooks in a menu or window layout, that would be a mess to manage. And if you have to delete or add nodes, having to manage which hooks to expose in a window layout, etc. how big a window would you need? The size of the existing node window? I have node graphs on second monitor and make changes or add/delete nodes as needed and go about other things on the other monitor. Nodes are easier in my opinion, just like compositing w/ nodes is far superior than layers.

hypersuperduper
03-20-2019, 01:50 PM
Exposing an input would have to be an option, sort of like when you add inputs to a compound node. That works quite well. I imagine it looking sort of like a motion modifier in the “parent” window. Depending on the number of options exposed it could appear under the motion options like motion baker or if it had more options it would open a dedicated window like relativity. Obviously for advanced nodal work you would still work in the node editor, but for simple setups, or things you reuse a lot but with slightly different settings It would be nice to do this. Particularly when it comes to nodal motion where I tend to be applying nodal motion to lots different objects often largely identical setups but pointing at different items. And having everything hidden in the nodal network means that I can’t see at a glance what a network does. I need to open it.

ernesttx
03-20-2019, 02:59 PM
I guess there could be some middle ground within certain use cases. I was leary if setup became to complex.

RebelHill
03-20-2019, 03:10 PM
XSI ICE did a fine job of that, letting you build node networks and expose certain inputs to a "panel" interface. For most reusable networks, you only ever want a half dozen items at most to present directly to the user, more than that and you're getting into the territory where you really want to be editing the node tree itself. Though that said, in the odd case where you do want a long list of options exposed... there're scrollbars to keep the panel size itself neat.

stoecklem
03-20-2019, 06:11 PM
This would be great. Xsi had it right for sure. I don’t know why more nodal software doesn’t just copy the render tree/ice

RebelHill
03-20-2019, 07:44 PM
Because most interface designers and software developers want to feel a sense of ownership and creativity over what they make... to have their own original input be thing that makes something what it is.

Kinda like asking why more animation studios dont just remake Toy Story.

Sensei
03-20-2019, 08:00 PM
Make color picker in Surface Editor non-modal. So user will be able to pick color, not yet accept it for real, and VPR will be updated.. and color picker won't be blocking entire LW.

Sensei
03-20-2019, 08:27 PM
how to achieve fast workflow in LW 2019+ : what features would you want ?

Everything should be implemented on commands...
e.g. we have interactive tool "Box",
it should internally call "Box x0,y0,z0,x1,y1,z1 [other params]",
not do it immediately and hidden..

Then these commands should be put in the history.
User would press "Record", do something, "Stop", and then e.g. save on disk, or "Play".
Load previously saved history, and "Play" to repeat actions.

Edit these commands on the list, replace them by something else, export to Lscript/Python if needed.

Tim Parsons
03-20-2019, 09:02 PM
Make color picker in Surface Editor non-modal. So user will be able to pick color, not yet accept it for real, and VPR will be updated.. and color picker won't be blocking entire LW.

Agreed! I use the little widgets swatches a lot because I like the interactivity of them. Not sure why that can't make that area a little bigger and put in a color wheel or something.

BigHache
03-20-2019, 09:06 PM
Haven't upgraded to 2019 (yet) so can't confirm this doesn't exist, but I would REALLY like the ability to rotate the pivot for layers.

Tim Parsons
03-20-2019, 09:06 PM
Everything should be implemented on commands...
e.g. we have interactive tool "Box",
it should internally call "Box x0,y0,z0,x1,y1,z1 [other params]",
not do it immediately and hidden..

Then these commands should be put in the history.
User would press "Record", do something, "Stop", and then e.g. save on disk, or "Play".
Load previously saved history, and "Play" to repeat actions.

Edit these commands on the list, replace them by something else, export to Lscript/Python if needed.

Some kind of macro recording and applying to a button. You can kind of do that in Layout, but there is nothing like that in Modeler.

Sensei
03-20-2019, 11:01 PM
Infinite refiniation of renders. Like in Fprime.

gar26lw
03-21-2019, 12:28 AM
scene live link to unity.

Marander
03-21-2019, 12:43 AM
This would be great. Xsi had it right for sure. I don’t know why more nodal software doesn’t just copy the render tree/ice

Other modern 3D software have a much more advanced node editor than LW that allows to expose / propagate parameters into the (layer based) Uber Material and much more.

What I would need for a faster workflow in LW? Complete UI redesign, context-sensitive and dockable property panels, get rid of the countless and ineffective drop down menus, consolidate duplicate tools, implement (optional) industry standard navigation. Non-destructive basic modeling in Layout.

Sensei
03-21-2019, 12:56 AM
Faster workflow: have search box in the main UI always visible and at hand, where you can start typing name of plugin, tool or command, there is drop-down list of available entries showed, which is getting shorter and shorter, the more letters are entered. User can click on one of them. And UI goes to tab were is tool, highlight it, and then run.
I am doing it in the all my Android apps and Windows .NET apps..

Currently user has to click on Edit, then Edit Menu Layout, then start entering name, then learns were it is placed.. close Layout Editor.. click on tab.. click on tool..

hypersuperduper
03-21-2019, 01:10 AM
What exactly is the issue with the dropdowns? Prior to 2019 I would have agreed, but the dropdowns got infinitely better in 2019 thanks to live text filtering, and IMO this is no longer a big issue at all. I can assign things with dropdowns in layout as fast as I can in any other program (Assuming I don’t run into some horror-show legacy dropdown without text filtering, which do still exist in some of the more cobweb-covered corners of the program).

hypersuperduper
03-21-2019, 01:14 AM
Faster workflow: have search box in the main UI always visible and at hand, where you can start typing name of plugin, tool or command, there is drop-down list of available entries showed, which is getting shorter and shorter, the more letters are entered. User can click on one of them. And UI goes to tab were is tool, highlight it, and then run.
I am doing it in the all my Android apps and Windows .NET apps..

Currently user has to click on Edit, then Edit Menu Layout, then start entering name, then learns were it is placed.. close Layout Editor.. click on tab.. click on tool..

Isn’t this exactly how the new ctrl-spacebar menu works?

hypersuperduper
03-21-2019, 01:45 AM
Edit multiple modifiers/materials for multiple items at once. Currently even with multiple items selected you can only edit one of them (good luck guessing which one you are editing) and need to copy/paste-into to apply them. Layout should just assume that if I have multiple modifiers/materials of the same type on multiple items/materials selected in the properties/motion/surface window that this is what I am trying to do and let me skip that needless step.

Marander
03-21-2019, 03:51 AM
What exactly is the issue with the dropdowns? Prior to 2019 I would have agreed, but the dropdowns got infinitely better in 2019 thanks to live text filtering, and IMO this is no longer a big issue at all. I can assign things with dropdowns in layout as fast as I can in any other program (Assuming I don’t run into some horror-show legacy dropdown without text filtering, which do still exist in some of the more cobweb-covered corners of the program).

The new 2019 list filtering is a big improvement I agree. I got the Quick Panel from db&w which is nice to use as well as OD Workspace and OD Pie Menu, I highly recommend these for any LW user.

However there are still better ways than drop down menus, for example collapsible / expandable sections in property panels. Further missing are duplicating, locking / unlocking, setting as new root, arranging / docking / undocking of property panels and menus, custom tabs, free choice where to use icons, text or both, adding tools and HUD elements to the viewport, workspaces.

LW lacks an easy-to-use filter for UI elements, for example for hiding bones (RHiggit helps here), grid or other viewport items.

My main pain are all the floating panels and sub dialog boxes and the inability to define the UI the way I want it to be, position and orient tools and buttons as I like. And the fixed-width dialog boxes with truncated text in the tabs of course. Many LW menu items disappear in More... sub menus due to its inflexible interface. CTRL+Space in 2019 or the mentioned OD Tools mitigate that to a degree.

Plugins and settings are hidden all over the place and makes it tedious to work with. Scene Editor, Surface Editor, Image Editor, Motion Options, IK Booster, Backdrop, Legacy Volumetrics, Pixel Filter, Image Filter, Volumentrics in Render panel, Object properties, Light properties, Camera properties, Node Editor, FiberFX, Dynamics, several Option panels and so on... all in individual dialog boxes and many of them with endless list of plugins with their own sub dialogs. On top of that the hundreds of OD Tools with their own panels - most of this could be ONE context sensitive Attribute Manager / Properties dialog. On top of that a Preset system that is incredible poor in its implementation and default content.

When I watch LW tutorials, I see users spending a lot of time moving around dialog boxes because they're often all over the UI and in front of the viewport. On the other hand, I cannot even have the properties of two separate objects open at the same time. Because all of this, LW is a very "clicky" application and feels like a giant patchwork of tiny tools to me.

hypersuperduper
03-21-2019, 04:55 AM
I personally prefer the classic floating window approach, and am generally pretty unenthused by the modern trend towards docking ui panels and workspaces, which I find restrictive but often unnecessarily complicated (program developers put WAY too much effort into designing new and exciting ways to for users to divide up their screens into lovely little rectangles in my opinion). For me, this approach is neither fish nor fowl. When it comes to speed, hotkeys will always beat any GUI, and the simplicity and ease of use of a simple properties sidebar on one side and toolbar on the other is quickly lost when it is expanded to accommodate a program with the complexity of something like lightwave. Suddenly, even with all the context awareness in the world, you have multiple panels with multiple tabs all of which are designed to be accessed primarily through the gui, whereas currently in lightwave I have nice minimal HUD and use hotkeys to open different panels and close when they are not in use. I agree that there are lots of things that could be improved, particularly through some smart consolidation and getting rid of a lot of the fixed-width panels but I would find Lightwave more tedious to use if it adopted a docked-UI Paradigm. To each his own I guess.

vncnt
03-21-2019, 05:02 AM
I just finished a project that had lots of full body replacement and screen replacement.
A few things that were not very easy in Layout (in this case LW2015) that I ended up doing in Fusion for 90%:

* Matching the shape of objects near the left/right border - to match the lens distortion of the backplates.
* Matching the shape of objects - to remove body parts that would stick out behind the replacement body.
* Fixing inaccurate match-moving results in a few difficult shots.
* Fixing colorspace issues per item groups.

I would love to see more tools in Layout for doing this kind of stuff.

BeeVee
03-21-2019, 08:02 AM
Faster workflow: have search box in the main UI always visible and at hand, where you can start typing name of plugin, tool or command, there is drop-down list of available entries showed, which is getting shorter and shorter, the more letters are entered. User can click on one of them. And UI goes to tab were is tool, highlight it, and then run.
I am doing it in the all my Android apps and Windows .NET apps..

Currently user has to click on Edit, then Edit Menu Layout, then start entering name, then learns were it is placed.. close Layout Editor.. click on tab.. click on tool..

Ctrl-Space does this.

B

PS. Sorry, hadn't read down and seen HyperSuperDuper already said this :)

gar26lw
03-21-2019, 08:14 AM
keep it coming... i think this is the most constructive thread i’ve seen on here in a while. maybe some fb users will come back ;D
you guys are kicking it!

Sensei
03-22-2019, 05:35 PM
Let the user to decide about background settings.
e.g. amount of transparency/opacity of background layer lines.
color of background layer lines.
(global settings of Modeler)

Allow editing them per-layer basis.
e.g. user wants background layer XXX to have red lines, background layer YYY to have green lines, background layer ZZZ to have blue lines.
Save it in LWO
(local settings of object file)

Allow editing them per-surface and per-part and per-layer basis.

I don't want to merge multiple background layer lines into one hard to distinguish "mass"...

tburbage
03-22-2019, 05:53 PM
Make color picker in Surface Editor non-modal. So user will be able to pick color, not yet accept it for real, and VPR will be updated.. and color picker won't be blocking entire LW.

I agree. The LW Color Picker is quite nice, but it would be a lot better in terms of interactivity if it were non-modal.

tburbage
03-22-2019, 06:54 PM
I personally prefer the classic floating window approach, and am generally pretty unenthused by the modern trend towards docking ui panels and workspaces, which I find restrictive but often unnecessarily complicated (program developers put WAY too much effort into designing new and exciting ways to for users to divide up their screens into lovely little rectangles in my opinion). For me, this approach is neither fish nor fowl. When it comes to speed, hotkeys will always beat any GUI, and the simplicity and ease of use of a simple properties sidebar on one side and toolbar on the other is quickly lost when it is expanded to accommodate a program with the complexity of something like lightwave. Suddenly, even with all the context awareness in the world, you have multiple panels with multiple tabs all of which are designed to be accessed primarily through the gui, whereas currently in lightwave I have nice minimal HUD and use hotkeys to open different panels and close when they are not in use. I agree that there are lots of things that could be improved, particularly through some smart consolidation and getting rid of a lot of the fixed-width panels but I would find Lightwave more tedious to use if it adopted a docked-UI Paradigm. To each his own I guess.

Most apps I'm familiar with which support docking panels -- Maya for example -- let you dock them or drag them out as floating -- as each user prefers. And then let you save arrangements of panels as workspaces for specific workflows. A good UI design lets the user decide how they want to set up the app. A good design for docked panels also lets you collapse/expand them to/from a tab set across the top or side of the app. I like how both Maya and Unreal deal with panel/window management. For the devs, Visual Studio provides a similar design.

I personally don't care *as* much about docking in Layout as in Modeler. In Modeler, I would love to see a consolidated panel set on the right side of the app frame with the Numeric (aka Tool) panel, Layers, Vertex Maps, etc. This lets you keep the main application frame maximized while keeping those panels visible, but not blocking the viewports. My proposal for that would be that the Tool panel would be visible "on demand", as in, when a tool is activated, the Tool panel would show, and when you drop the tool, the panel would hide. I logged a suggestion for the proposed Tool panel visibility behavior a year or two ago, but nothing came of it.

I do agree with you re: hotkeys, and that implies that the thing you want to assign a hotkey to is exposed as a command. There are things buried in the viewport menus which are not exposed as commands, and so we can

tburbage
03-22-2019, 07:10 PM
The new 2019 list filtering is a big improvement I agree. I got the Quick Panel from db&w which is nice to use as well as OD Workspace and OD Pie Menu, I highly recommend these for any LW user.

However there are still better ways than drop down menus, for example collapsible / expandable sections in property panels. Further missing are duplicating, locking / unlocking, setting as new root, arranging / docking / undocking of property panels and menus, custom tabs, free choice where to use icons, text or both, adding tools and HUD elements to the viewport, workspaces.

LW lacks an easy-to-use filter for UI elements, for example for hiding bones (RHiggit helps here), grid or other viewport items.

My main pain are all the floating panels and sub dialog boxes and the inability to define the UI the way I want it to be, position and orient tools and buttons as I like. And the fixed-width dialog boxes with truncated text in the tabs of course. Many LW menu items disappear in More... sub menus due to its inflexible interface. CTRL+Space in 2019 or the mentioned OD Tools mitigate that to a degree.

Plugins and settings are hidden all over the place and makes it tedious to work with. Scene Editor, Surface Editor, Image Editor, Motion Options, IK Booster, Backdrop, Legacy Volumetrics, Pixel Filter, Image Filter, Volumentrics in Render panel, Object properties, Light properties, Camera properties, Node Editor, FiberFX, Dynamics, several Option panels and so on... all in individual dialog boxes and many of them with endless list of plugins with their own sub dialogs. On top of that the hundreds of OD Tools with their own panels - most of this could be ONE context sensitive Attribute Manager / Properties dialog. On top of that a Preset system that is incredible poor in its implementation and default content.

When I watch LW tutorials, I see users spending a lot of time moving around dialog boxes because they're often all over the UI and in front of the viewport. On the other hand, I cannot even have the properties of two separate objects open at the same time. Because all of this, LW is a very "clicky" application and feels like a giant patchwork of tiny tools to me.

It's interesting how quickly Oliver has recognized the numerous opportunities for workflow improvement and tried to fill in those gaps from the outside looking in. I wish all of those things were integrated directly into LightWave. In my mind, that's core functionality. I bought OD Pie menu as well. My biggest disappointment with it is that SDK limitations presumably prevented his implementing it for Modeler. where it could really shine!

erikals
03-23-2019, 02:13 AM
AntiAliasing = on thin lines it is just way too slow in LW

Realtime = make 'everything' realtime

Modeler = ... well... you know...

hypersuperduper
03-23-2019, 04:18 AM
Most apps I'm familiar with which support docking panels -- Maya for example -- let you dock them or drag them out as floating -- as each user prefers. And then let you save arrangements of panels as workspaces for specific workflows. A good UI design lets the user decide how they want to set up the app. A good design for docked panels also lets you collapse/expand them to/from a tab set across the top or side of the app. I like how both Maya and Unreal deal with panel/window management. For the devs, Visual Studio provides a similar design.

I personally don't care *as* much about docking in Layout as in Modeler. In Modeler, I would love to see a consolidated panel set on the right side of the app frame with the Numeric (aka Tool) panel, Layers, Vertex Maps, etc. This lets you keep the main application frame maximized while keeping those panels visible, but not blocking the viewports. My proposal for that would be that the Tool panel would be visible "on demand", as in, when a tool is activated, the Tool panel would show, and when you drop the tool, the panel would hide. I logged a suggestion for the proposed Tool panel visibility behavior a year or two ago, but nothing came of it.

I do agree with you re: hotkeys, and that implies that the thing you want to assign a hotkey to is exposed as a command. There are things buried in the viewport menus which are not exposed as commands, and so we can

A good UI adapts to each user, yes. I feel that the dockable UI plus workspaces way of working becomes a problem when a program becomes overly reliant on the paradigm and assumes everyone wants it in all cases. Blender is perhaps the worst offender here in my experience. Maya strikes a pretty good balance and unity works well. The key word there is balance, and I think it is difficult to strike that balance without iteration which takes time. During which users just have to adapt.

There are certain things that lightwave does that I haven’t seen anywhere else that I fear would get lost in the mix if the UI is overhauled to be completely dockable. The example that comes to mind is the graph editor. A lot of people ***** about it, but I truly love lightwave’s graph editor. it is easily my favorite graph editor ever. It’s keyframe and copy/paste tools may not quite stack up to Maya’s, and yes it’s treatment of Bézier curves is embarrassing and it only JUST got more than one undo, but boy is it quick and powerful with tools galore and for the most part they are in right places. It feels almost like a whole program in itself... which it basically is. A byproduct of this is it that even at its smallest it’s a pretty big window and tends to obscure stuff, so lightwave has a weird fix: When you manipulate keys the window becomes transparent so you can see the effects in the scene behind it. I haven’t seen this anywhere else and I love it. Yes, newtek could make a graph editor that was both dockable and worked like this, but in my experience, little quality of life features like the transparency effect are the first casualties when a program makes a paradigm shift, which a dockable UI in lw would have to be. The graph editor would likely need to be redesigned entirely in order to be scalable enough to be useful as a UI panel. There is simply too much in it.

At the end of the day it’s about the balance between mature solutions and fresh starts. The graph editor is just one example, A fully Dockable UI would not be simply a value-add. it would invariably involve major changes to tools that some of us really like, even if potentially the replacement solution would eventually, once all the kinks are worked out, become superior. The OP asked what would speed things up, not what would be objectively superior, and while a dockable UI this may speed things up for some, I just look at the new material system which while much more powerful, is a good deal slower to work with for many things (it needs those iterations and quality of life fixes that only come with maturity.

erikals
03-23-2019, 05:04 AM
A lot of people ***** about it, but I truly love lightwave’s graph editor.
like you mentioned, i think most people used to ***** about it, since it only had one undo. Luckily that is fixed.

as for LightWave Ui, i feel it has a very nice workflow overall (except split App) + some minor Ui quirks.

a minus in 2019 is that it is a bit slower to work with, when it comes down to Ui stuff. (nodes, more render settings, remember FPrime? click and go? i miss the KISS principle in 2019, but overall, nice work in 2019)

robertoortiz
03-23-2019, 05:45 AM
So summing it up(for volumetrics), workflow turned out not so good..sacrificing the setup speed of volumetrics, and sacrificing the ease of use, especially for newbies, while rendering realism in shading lighting, and edge softness and render speed has become better, as well as getting cubic shape in there.



This reminds me A LOT the time Adobe Flash transitioned from Actionscript 2 (that was designer friendly) to Action Script 3 (that was oriented more towards hardcore Object oriented programmers)
thus killing its ease of use. It was a BADDD move that killed the support of its core user base, Graphic Designers.

I am terrified of how Photoshop would have looked if if had been designed by PURE programmers and not artists like John Knoll.

LW needs to rethink what made Lightwave Lightwave,and that includes streamlining the app to make it EASIER and MORE INTUITIVE to use.
Generalist are the core users of Lightwave, and they need speed and re-usability.
Because seeing the app with a fresh set of eyes, from the point of view of a newbie, what I see is that I have a mess of nodes to learn, and a unforgiving not intuitive interface that takes too long to do a simple task,
(Something that used to be easy to do, like shading or NPR rendering).
I might as well go to Houdini, or Blender.

erikals
03-23-2019, 06:04 AM
I might as well go to Houdini, or Blender.
nah, i don't think we're anywhere close to that, though i see your point, like mentioned in post #39

(except FiberFX, they really need to clean up that workflow)
(at least FiberFX is not buggy now)

jwiede
03-23-2019, 12:59 PM
(at least FiberFX is not buggy now)

ROFLMAO! Thanks for that!

erikals
03-23-2019, 01:58 PM
:)  alright rephrase >


(at least FiberFX rendering is not buggy now)

2019 render by the way >

https://i.imgur.com/PAagEhQ.png


though yep, FiberFX guides is a wrestle, no doubt 'bout that. https://i.imgur.com/iAv5b1S.gif

Tim Parsons
03-23-2019, 04:14 PM
. A byproduct of this is it that even at its smallest it’s a pretty big window and tends to obscure stuff, so lightwave has a weird fix: When you manipulate keys the window becomes transparent so you can see the effects in the scene behind it. I haven’t seen this anywhere else and I love it.
What? How do you make that happen?

Ztreem
03-23-2019, 04:24 PM
What? How do you make that happen?

I was thinking the same, but I only have lw2015 so maybe this is something new. You could of course use a tool for making transparent windows and use it in all editors. I still prefer non overlapping UI’s instead of overlapping windows all over the place.

tburbage
03-23-2019, 08:01 PM
Everything should be implemented on commands...
e.g. we have interactive tool "Box",
it should internally call "Box x0,y0,z0,x1,y1,z1 [other params]",
not do it immediately and hidden..

Then these commands should be put in the history.
User would press "Record", do something, "Stop", and then e.g. save on disk, or "Play".
Load previously saved history, and "Play" to repeat actions.

Edit these commands on the list, replace them by something else, export to Lscript/Python if needed.

I really agree: almost "Mel"-like (in Maya). When you record commands, or the result of the settings of a tool like that, you can also implement "Repeat Last Command" and assign to a hot key. With repetitive tasks, that can be a great time-saver.

tburbage
03-23-2019, 08:06 PM
Let the user to decide about background settings.
e.g. amount of transparency/opacity of background layer lines.
color of background layer lines.
(global settings of Modeler)

Allow editing them per-layer basis.
e.g. user wants background layer XXX to have red lines, background layer YYY to have green lines, background layer ZZZ to have blue lines.
Save it in LWO
(local settings of object file)

Allow editing them per-surface and per-part and per-layer basis.

I don't want to merge multiple background layer lines into one hard to distinguish "mass"...

Well, I just keep agreeing with people :) Modeler BG layers should be able to be solid shaded for better reference/readability. I think the Layers panel implementation could be a whole thread on its own. So much room for improvement there...

gar26lw
03-23-2019, 10:53 PM
like modo. in a way it’s lucky, modo did a lot of the heavy lifting in finding out what would be good for an improved lightwave.

erikals
03-24-2019, 02:34 AM
like modo. in a way it’s lucky, modo did a lot of the heavy lifting in finding out what would be good for an improved lightwave.
Good note!

i hope NewTek looks into its workflows.

hypersuperduper
03-24-2019, 02:49 AM
I was thinking the same, but I only have lw2015 so maybe this is something new. You could of course use a tool for making transparent windows and use it in all editors. I still prefer non overlapping UI’s instead of overlapping windows all over the place.

Hmmm..Perhaps this is a Mac only thing. Its not new for sure. It goes as far back as 11 at least. iirc it was even more pronounced then, the user could manually adjust the window transparency. it was silly. I remember maybe 10-15 years ago all sorts of Mac apps were experimenting with wacky new windowing gimmicks including transparency. Then it all started to disappear when windows 7 came out and all of the big guys like adobe settled on good cross platform solutions (primarily docking based) instead since Microsoft had finally gotten its UI ducks in a row.

edit... Sorry, my Bad. am misdescribing the behavior. The graph editor window turns transparent when you click anywhere in the MAIN window, not edit in the graph editor (other popups work like this too). Regardless, the end effect is similar. press play and you can see through the graph editor. does it work like this in windows? Only lw does this. It is not a normal mac thing.

Ztreem
03-24-2019, 05:38 AM
Must be a Mac thing. I like the idea of transparent windows, could be quite useful.

robertoortiz
03-24-2019, 06:54 AM
Here si the problem, as I see it

Generalist tend to want :
INTUTIVE USE / SPEED

Studios tend to want:
TOTAL CONTROL OF APP

Guess who usually has the ear of the development staff. Look at what happened when it was rumored that Autodesk would deep six Maya over Softimage (A program that BTW that had a more advanced interface and amore modern codebase). From what I heard the BIG studios pressured Autodesk to Keep Maya as their top dog.

In Newtek case they need to talk more to smaller studio and frankly consult with a good functionality expert.

OlaHaldor
03-25-2019, 03:20 AM
Radial menu system would be nice. And it should be possible to customize like you can with the list menus today.

lwanmtr
07-20-2019, 06:18 PM
Modeler tools being updated, optimized and enhanced....as well as high poly handling.
for Layout, again speed up display on high poly scenes.
Color picker should be realtime, so you select a color and see it immediately, rather than having to close it before the color shows

Im actually getting happier with the node interface and more used to using it.

there's prolly more on the actual workflow front, but for me the speed comes more at rendertime...

FiberFX needs to have a sampling setting, and probably some optimizations so it doesnt take an age to render.

Cloth also needs to be updated...yeah there's syflex, but its finicky to use..Bullet is also not easy to setup for cloth..and the classic clothfx is just too darn slow (but it at least allows using weight maps to control how much effect there is)

motiondigital
07-21-2019, 02:21 AM
First of all Lightwave is fantastic and a killer app, but some commonly used functions can be repurposed, fixed or redesigned, to improve the workflows




Layout


There are too many panels when setting up a new scene such as:

Preferences (d)
Image editor (F6)
Render Properties (Shift F6)
Effects (Shift F5)
Camera/Light Properties (p)

Suggestion:
These panels need to be amalgamated, grouped etc into fewer panels


Setting up HDRI is too buried in sub menus, and new users have to press a thousand clicks to set up a HDRI, for example:

Press F5 Effects
Select backdrop Tab
Add environment
Select Textured Environment
click Textured Environment
Select Y Axis (Does nothing)
Press texture button
Select Spherical Projection (This should be a default)
Select your HDRI Image
Select Y as texture axis (This should be a default)

Suggestion:
This doesn't sound like a fluid, simplified workflow for something as simple as a HDRI map



Modeler

Destructive workflows and tools need to be fixed:

Mirror (Destroys or flips mirrored polygons)
Chamfer (should be smart enough to remove junk geometry like 1 or 2 point polys, and use a merge function before applying the chamfer)
Rounder (As Above)
Radial Array (non responsive at times, need to close and re-open Modeler)
Lathe (non responsive at times, need to close and re-open Modeler)

Some tools do not preview

Clone (c) comes to mind

Surface presets

Need more presets for: Ceramic, Fabric, Leather, Liquid and Wood


Panels never remember the last settings

Layer panel is ALWAYS collapsed when opening Modeler
Select surfaces (If you resize this panel due to many surfaces, it never remembers its previous re-sized setting)
Graph Editor (If you have zoomed into a set of key frames for a particular object, if you re select that object it reverts to a default zoom)

Extender plus

There is no visual clue when pressing "e" that edges are duplicated. When pressing "e" the edge needs to flash on and off to give the user a visual cue that the extend is done.

Subdivide

If I select a quad polygon and want to subdivide it 3 times on the y axis i cant, it defaults to dividing it equally on the x and y axis, there's not many options in this tool, and not very versatile

Kryslin
07-21-2019, 07:29 AM
Layout - FiberFX
-The lag on scrubbing the timeline, trying to rotate or manipulate joints and bones, because the VPARM system has to update everything, is very frustrating. Yes, there is a simple work-around, but we shouldn't need to toggle FiberFX on and off all the time. (Create an object and apply 3 to 5 layers of FiberFX to it, one of which is a fairly heavy (2-3 million fiber) layer. Interactivity slows to a c.....r.....a.....w....l....., 1/2 to 3 seconds per frame/ 1/10th of a degree/coordinate/scale factor)

-I agree, Some sort of sampling control for Fibers would be welcome.

-A simpler, native solution to setting up HDRI would be welcome as well.

Modeler
-Consolidation of certain tools would be a good start (Bevel, Multishift, extend, extend plus, chamfer, rounder, for instance, are all essentially the same tool, just used with different options).
-Hair guide grooming tools, either here or in layout.

tburbage
07-21-2019, 01:04 PM
I'm going to post separately for Layout and Modeler...

Layout, having gotten virtually all of the development investment for the last 10 years or more, is moving forward nicely. Here's a few things about Layout though that I think would be solid workflow improvements:

- The basic transform tools are way too basic, and there are many opportunities for improvement. One can envision a general purpose Transform tool where you can do most of the positioning, rotating, and scaling operations without having to switch tools.

The Move tool doesn't support "spacial snapping", either snap to grid (world space), or relative snapping (incremental, e.g. snap to 1m increments from the current position). Features like those can make scene setup go much faster. Remember, Layout has no grid snapping support. Alternatively, if the basic transform tools had a Tool panel for providing UI for tool options, additional constraints could be implemented and the panel would give the developer a place to put the user inputs.

- Layout has an apparently fundamental restriction where you can only select one kind of thing at a time, and this leads to some awkward workflows. Where in other apps, you are not restricted in this way, but you instead can set selection filters if you only WANT to select a particular kind of thing e.g. when marquee selecting in the view port.

- When I think of use of Layout in larger scale production, it seems to me that scene referencing would be a better alternative to Load From Scene (reuse by reference rather than by copy). Because then scenes can be reusable components in the same sense as objects. As with mesh objects today, changes to the base scene would be immediately reflected in all scenes in which they are referenced. If any of you are using Unreal, a scene could be likened to a Class Blueprint: an assembly of objects, potentially all rigged and animated and ready to be instanced into your broader scene. But update the components, and all usages of the base Blueprint are automatically updated (a change-resilient workflow). I'm imagining a fully rigged character, perhaps with a set of motions already defined for it, this character being used in multiple scenes. But then the decision is made to modify that character, either the mesh or the rig...

tburbage
07-21-2019, 01:34 PM
In some ways I think LW 2018 took some steps backward in the surfacing workflow. Now that it's mandatory to go through the node editor, there is no longer a fast, convenient way to apply images, normal maps, etc; as it requires a few more steps to do. This is tedious in larger scenes without some form of automation in place, and it is less user friendly because new users now have to learn two interfaces in order to utilize lightwave's surfacing functions. In the future, i'd like to see the old interface make its way into other node types than standard; even if all it does it create and hook up the nodes for you.

There's modeler too but... that's so obvious it hurts.

Per connecting up image maps, that's a good point. Maybe if we could drag-and-drop an image, either from an OS view, or from the Image Editor, onto a channel of a material in the Surface Editor, it would just make the node hookup for you. And if multiple surfaces are selected, do it for all of them...

tburbage
07-21-2019, 04:22 PM
XSI ICE did a fine job of that, letting you build node networks and expose certain inputs to a "panel" interface. For most reusable networks, you only ever want a half dozen items at most to present directly to the user, more than that and you're getting into the territory where you really want to be editing the node tree itself. Though that said, in the odd case where you do want a long list of options exposed... there're scrollbars to keep the panel size itself neat.

Yes, Unreal e.g. Class Blueprints provide this sort of mechanism, where you can expose variables on the BP while hiding the implementation (the construction and event graphs). When you have an instance of the BP selected, the Details panel (like a Properties panel) shows the exposed properties which you can tweak directly. Substances (i.e. Substance Designer) archives have a similar mechanism.

hypersuperduper
07-22-2019, 04:42 AM
Unity has the same thing (they call them prefabs) and it is an absolutely essential part of the workflow. The one reservation I have is that while it is fantastic for static setups, when it comes to animation it adds a little setup time initially in that animations are always separate files that you have to save and define what channels are included and it is a minor thing, but you lose the immediacy of a global timeline that you can just mess around in, which is quite nice in layout. I could see Lightwave expanding or replacing Motion Mixer to achieve something similar while retaining the immediacy of layouts basic timeline for simpler animations/experimentation. They already have motions and actors there. I could imagine an improved motion mixer where actors and motions are saved externally and loaded dynamically. An actor could contain not just a list of objects and channels that are affected like now, but their relationships and modifiers as well. The motion mixer timeline could be owned by the scene, but all the contents (actors/motions) defined in these external files.