PDA

View Full Version : PROPOSAL: Keep MODELER Alive and develop a Procedural Modeling Tools for LAYOUT



robertoortiz
04-11-2018, 12:03 PM
141157
I can hear you guys already typing ,
but before you un-sheat those swords hear me out...

Maybe the fact that Layout has so few Modeling functions blessing in disguise.Here is an idea I have been kicking around and i would like to present it to the forum:
Maybe the Lw group should just streamline the Modeler program as a PURE polygon modeler
and develop a procedural Modeling tools for Layout. these new tools could take a page from Houdini and allow for full history control, parametric modeling and (since this is a pie in the sky) full nodal control.

You would not be stepping on any toes in terms of modeling for LW since the tools are NOT THERE in layout.
I would then streamline modeler with consolidated modeling tools, upgrade on the UV mapping and retopoly tools.

What do you guys think?
Is this Pie in the Sky a good idea or bad idea.

I would love to hear your opinions.

-R

N_A
04-11-2018, 02:08 PM
native procedural modeling tools for Layout - good idea

Chris S. (Fez)
04-11-2018, 02:20 PM
I like this idea.

Hopefully the Modeler geometry engine can be replaced in a timely manner. Modeler needs a major performance boost.

js33
04-11-2018, 02:22 PM
141157
I can hear you guys already typing ,
but before you un-sheat those swords hear me out...

Maybe the fact that Layout has so few Modeling functions blessing in disguise.Here is an idea I have been kicking around and i would like to present it to the forum:
Maybe the Lw group should just streamline the Modeler program as a PURE polygon modeler
and develop a procedural Modeling tools for Layout. these new tools could take a page from Houdini and allow for full history control, parametric modeling and (since this is a pie in the sky) full nodal control.

You would not be stepping on any toes in terms of modeling for LW since the tools are NOT THERE in layout.
I would then streamline modeler with consolidated modeling tools, upgrade on the UV mapping and retopoly tools.

What do you guys think?
Is this Pie in the Sky a good idea or bad idea.

I would love to hear your opinions.

-R

Or instead of waiting for that to happen you could start using Houdini Indie today for $265 a year or Houdini Apprentice for free.

Ztreem
04-11-2018, 02:57 PM
If we would have full parametric modeling in Layout why would we still need modeler??? I don't get it...

hrgiger
04-11-2018, 03:41 PM
If we would have full parametric modeling in Layout why would we still need modeler??? I don't get it...

Having used procedural tools for a while now in MODO, you ideally want both procedural and non-procedural methods for modeling. There are advantages to both. Having both is more flexible then having one or the other.

Ztreem
04-11-2018, 03:54 PM
Having used procedural tools for a while now in MODO, you ideally want both procedural and non-procedural methods for modeling. There are advantages to both. Having both is more flexible then having one or the other.

Of course, but I never seen a procedural/parametric implementation that doen't do both that's why I wonder, because it seems quite stupid or even impossible to make a procedural modeling app that can not freeze or export the model as a non parametric model.
I just think, make LW a whole app and skip the separate module thing as it's just an old legacy with no benefits at all.

hrgiger
04-11-2018, 03:58 PM
The workflows are different, freezing a procedural mesh isn't the same as working with non-procedural tools.

Ztreem
04-11-2018, 04:19 PM
The workflows are different, freezing a procedural mesh isn't the same as working with non-procedural tools.

No, but once it freezed you can work on it with non-parametric tools.

Ok, let me phrase it like this. if the idea is to only have procedural/parametric modeling in layout and non-procedural/parametric in modeler then I think its a bad idea. My idea is to have everything in layout, but I donít think it will ever happen.

3D Kiwi
04-11-2018, 04:24 PM
Unification is the key. Dont give them any ideas. It has to happen.

hrgiger
04-11-2018, 04:29 PM
Well I will just say, at least in my case, that there is often not a need to work procedurally and when you don't need to, its a hassle to work with the procedural stack. Its also the case that even if they were to put procedural modeling into Layout, they won't for a long time replicate all the tools that already exist in Modeler. Just won't happen overnight if at all. They implemented MeshOps in MODO in version 10.1 and they're still adding procedural equivalents to the traditional modeling tools every release (which is 3 times a year). How long do you think it would take LW3DG to replicate Modelers tools?

Ztreem
04-11-2018, 04:44 PM
Well I will just say, at least in my case, that there is often not a need to work procedurally and when you don't need to, its a hassle to work with the procedural stack. Its also the case that even if they were to put procedural modeling into Layout, they won't for a long time replicate all the tools that already exist in Modeler. Just won't happen overnight if at all. They implemented MeshOps in MODO in version 10.1 and they're still adding procedural equivalents to the traditional modeling tools every release (which is 3 times a year). How long do you think it would take LW3DG to replicate Modelers tools?

I know what you mean. Iíve been working with CAD modeling (all parametric) and while you gain some time when the client want to change things, you also loose time while you need to keep the parametric tree working. I agree, for LW to add parametric modeling that is so complete as modelers toolset will take a lifetime. I just donít think LW will ever be unified and if they ever pull it off it will take too long for me to wait for it.

Nicolas Jordan
04-11-2018, 05:56 PM
Considering the small dev team behind Lightwave I really don't think it worth their time or effort to implement procedural modeling in Lightwave. I think that there are many other more urgent things that should be given priority. There are likely many things that can be done to improve Lightwave that would take less resources and pay off way more.

jwiede
04-11-2018, 07:42 PM
Considering the small dev team behind Lightwave I really don't think it worth their time or effort to implement procedural modeling in Lightwave. I think that there are many other more urgent things that should be given priority. There are likely many things that can be done to improve Lightwave that would take less resources and pay off way more.

In any case, they still have a bunch of stuff that requires fixing/addressing before adding ANY modeling in Layout is feasible. Undo, entity-selection/snapping/constraints, full (and working) CC sub-d handling, UV handling, etc. Regardless whether Layout modeling is procedural or not, without those listed features it won't be particularly general-purpose or useful. Targeting procedural modeling first doesn't magically make the need for all those support features disappear, in many cases their need in procedural modeling is even greater.

samurai_x
04-11-2018, 08:31 PM
Maybe the Lw group
-R

There is no more LWG. Its back to Newtek.

robertoortiz
04-11-2018, 08:34 PM
Targeting procedural modeling first doesn't magically make the need for all those support features disappear, in many cases their need in procedural modeling is even greater.
And that is why I think they should start with that. It FORCES an overhaul of those same areas you mentioned.

Look I am not saying that, eventually, Layout could not do exactly the same functions as Modeler.
What I see is, for now, a more deliberate approach fpr layout development:
Infrastructure (undo/history/full Modal control of all functions)-->Parametric tools(start with simple tools/commands )---> poly modeling tools (end goal)


There is no more LWG. Its back to Newtek.

My bad, I stand corrected.

jwiede
04-12-2018, 09:13 AM
Infrastructure (undo/history/full Modal control of all functions)-->Parametric tools(start with simple tools/commands )---> poly modeling tools (end goal)

Roberto, what you need to understand is that by the time you've implemented a proper parametric primitives+operators+misc toolset, you've already implemented the non-parametric/"destructive" tools as well -- the parametric versions are, by definition, a superset of the non-parametric versions of the same prims & ops. All the parametric versions are really is just the same algorithms with specific abstractions around how the operands/parameters are manipulated and passed. By the time you've implemented the non-parametric primitives and operations with Modo-like "Toolchain" operand-mgmt functionality, it's just a reasonably direct jump to implementing fully-parametric operation. There are even significant advantages to implementing in that order, as it lets you validate and verify in stages, where jumping directly to parametric necessitates a HUGE amount of up-front validation and verification done at once.

robertoortiz
04-12-2018, 03:57 PM
Roberto, what you need to understand is that by the time you've implemented a proper parametric primitives+operators+misc toolset, you've already implemented the non-parametric/"destructive" tools as well -- the parametric versions are, by definition, a superset of the non-parametric versions of the same prims & ops. All the parametric versions are really is just the same algorithms with specific abstractions around how the operands/parameters are manipulated and passed. By the time you've implemented the non-parametric primitives and operations with Modo-like "Toolchain" operand-mgmt functionality, it's just a reasonably direct jump to implementing fully-parametric operation. There are even significant advantages to implementing in that order, as it lets you validate and verify in stages, where jumping directly to parametric necessitates a HUGE amount of up-front validation and verification done at once.
that is a fantastic reply....

Is there a midpoint that could be reached? Maybe some basic CORE tools and build up from there?

robertoortiz
04-13-2018, 11:56 AM
A friend pointed out that Layout 2018 does have some BASIC parametric modeling tools


https://www.youtube.com/watch?v=cgZOE80vfkc

bobakabob
04-13-2018, 03:39 PM
Just the facility to directly edit points, polys and edges of meshes in Layout with a basic translate / rotate tool would be a huge step forward.

jeric_synergy
04-13-2018, 05:57 PM
Just the facility to directly edit points, polys and edges of meshes in Layout with a basic translate / rotate tool would be a huge step forward.

Yeah, that should certainly be possible... I mean, a great deal of the infrastructure is there already, EXCEPT, notably, Selection tools.

But I can imagine a heinous HACK: using "virtual BONES", created (and erased) on the fly, to Translate and rotate Points. then you'd auto-Save Transformed. This would "work", for low values of "work", but there's still the problem of Selection.

I did a "Plexus" like thing by generating a bone for every point in a cloud-like object: it 'worked', and allowed me to bake a displacement motion into the bones and THEN manipulate them individually. But that was really a special case.

EDIT: wait, doesn't 3rd Powers have a weight painting in Layout tool? Have they solved "selection in Layout"?

vncnt
04-13-2018, 11:21 PM
What's missing is: animation tools and animated deformation tools.

There are many workarounds and alternatives for missing features in Modeler but there is none for missing animation tools that should bridge the gap between Layout and the virtual actors on the stage or the virtual director.

This is an important reason why we don't see (too) many examples of animated features in Lightwave.
Improvements are technically simple and easy.

I understand the forces behind LW 2018 (renderer update) but I can only hope animation receives some love in 2019.

jeric_synergy
04-14-2018, 01:29 AM
What's missing is: animation tools and animated deformation tools.
Not sure what you mean here: can you be specific?

N_A
04-14-2018, 01:42 AM
The basis for creating procedural modeling tools exists, but not completed yet.
Http://static.lightwave3d.com/sdk/2018/html/classes/meshmodifier.html
"...The Mesh Modifier class on Theother hand allow for more general modifications, such as the creation of vertices and polygons.
NOTE that support for this class is unavailable limited to doing deformations... "

vncnt
04-14-2018, 04:02 AM
Not sure what you mean here: can you be specific?

A few specific examples:

- Working with Keyframer feels like painting Rembrandts Nachtwacht with a keyboard. It's a script that never moved away from a text/files based method and it's missing a lot of features and ways to handle exceptions. Recycle a part of a facial animation from some archive? Which one should I take when I can see only a list of files (perhaps made by someone else)? Can I preview anything? Maybe apply it and Undo it when it's wrong? Start praying. Reversing an animation? Barely possible in Layout. Pose mirror? Layout doesn't even know (or know a lot of) the concept of a character. Does it understand Left/Middle/Right?

- Apply Mirror Hierarchy to a Null or a Camera and watch the message: "Item selected is not a bone". So what? Character rigs actually contain Nulls these days!

- Frame/framerange identification - we have markers but they are difficult to see, difficult to read marker text, difficult to handle or to actually make them useful with other Layout tools. Import/Export? Select a range between markers and preview or apply some function or store them for later?

- Sketching/drawing on frames and store/retrieve other meta data? Related to a clip, or a sequence of clips?

Motion Mixer has very interesting (layering) concepts. Make it default and build from that point. Make it easy to isolate and transparently drill into the pieces that create the performance of the character(s) on a virtual set. Add higher level handles/controls to sculpt the scene into its final shape. Make it easier for an animator in situations the director changes his/her mind.

Multiple timelines with Markers and Ranges. Choose from multiple "Current Frame" definitions to allow comparisons. Visual access to a pose/animation archive. Copy/Paste between compatible rigs. Handle incompatibilities between rigs - and store the solution for reuse. Click and drag entities, not file based. Access to different Animation Takes so we can change our mind after a few days? Inserting a few poses and adjusting surrounding poses/animations in multiple characters? Lots of work but these requests are real.

I don't care if people say it's an unprofessional way of doing my job, there should be more planning, etc.
It's 2018 now. I want more flexibility. I want to be in control.
We double click and drag and drop these days.
That's how we should handle tiny details, Director level controls and every level of control in between.

Building a new Renderer or a new Modeler seems a lot more complicated to me than a good key handling system.
3DCoat and other sculpting programs are great and very useful - but we don't need another copy of those programs while still waiting for animation tools.

hrgiger
04-14-2018, 07:18 AM
Yeah, that should certainly be possible... I mean, a great deal of the infrastructure is there already, EXCEPT, notably, Selection tools.



Is it? Rob's claim that Points, Polys, and Edges are now visible to Layout didn't turn out to be the case according to third party devs who know the changes for 2018.

Marander
04-14-2018, 08:36 AM
Is it? Rob's claim that Points, Polys, and Edges are now visible to Layout didn't turn out to be the case according to third party devs who know the changes for 2018.

Yeah Rob claimed a couple of things that didn't turn out to be true (like LWNext would have the most modern architecture for example).

The 'parametric' objects in 2018 are a joke. No parameters beside size and no way to convert to polys.

But the worst is UI, non-working Undo, usability, workflow and efficiency to me.

However I do believe that some underlying architectural changes have been made for some improvements in future releases. But unification will never happen in my opinion.

On the positive side, NewTek is providing fixes in a timely manner.

robertoortiz
04-14-2018, 10:12 AM
On the positive side, NewTek is providing fixes in a timely manner.

Well since we seem to have a better communication workflow what would you tell them to concentrate on considering the resources they got?

Marander
04-14-2018, 10:50 AM
Well since we seem to have a better communication workflow what would you tell them to concentrate on considering the resources they got?

UI fixes, Undo, better overall handling, Scene & Graph Editor improvements, weight painting in Layout, simple modeling tools in Layout like Translate and polyginal and parametric Bevel. Parametric Text.

Not sexy selling features I know but long overdue in my opinion.

jeric_synergy
04-14-2018, 11:50 AM
How can it NOT see points?? Manipulating points is what it mostly does. Now, if you mean "exposes points to 3rd party devs in the SDK", you're probably right.

N_A
04-14-2018, 12:51 PM
..Parametric Text.
for the text already now can use the plugin, for example:
http://www2.trueart.pl/?URIType=Directory&URI=Products/Plug-Ins/TrueTypeText

Marander
04-14-2018, 01:13 PM
for the text already now can use the plugin, for example:
http://www2.trueart.pl/?URIType=Directory&URI=Products/Plug-Ins/TrueTypeText

Yes it offers basic text in layout but no bevel / caps and other detailing like live kerning as far as I know.

And the workflow... this should be one click to generate a text object with my prefered default text, font etc., not so many steps.

"Usage

Use*Items > Add Null*to make empty object in scene. Open*Object Properties*window. Then in*Object Replacement*pick up*TrueArt's TrueType Text*entry from drop-down list and press*Options.

Once text is generated, use*File > Save > Save Current Object..*to save object to disk. This will make sure that surfacing data will be stored."

Generally speaking, LW should have a general purpose object type.

jeric_synergy
04-14-2018, 01:54 PM
Well, it's what we got, not perfection. I'd suggest using it to generate a "close enough" object for rough cuts, with the finished object after client approval.

jwiede
04-15-2018, 01:21 PM
Well, it's what we got, not perfection.

Except it's not "what we got" -- just LW customers who choose to pay additional for it have it. What LW offers as native text functionality is actually much, much less capable, and that's the real problem.

bobakabob
04-15-2018, 01:46 PM
How can it NOT see points?? Manipulating points is what it mostly does. Now, if you mean "exposes points to 3rd party devs in the SDK", you're probably right.

Imagine...
* Being able to select vertices on a model in Layout to correct a model that looks great in Modeler but rubbish in Layout. You could work far more efficiently than syncing Modeler via the Hub which works but is outdated and inefficient.

* The freedom of being able to select geometry on an animated character and create a corrective morph directly in Layout in seconds rather than switching between Modeler and Layout.

* Being able to model the mesh of, say a face, directly in Layout, all the while checking the play of light and shadow on the surface through a camera, and live VPR renders...

Lightwave has loads of strengths (I love the new PBR renderer which is very close to Arnold). But unless the above limitations are addressed, why would young animators and character artists be persuaded to use it?