PDA

View Full Version : Should Lightwave go to procedural modeling?



Asticles
03-12-2017, 07:04 AM
I open this thread to discuss the convenience of going procedural. Now that Houdini is rising and modo is starting to be procedural, do we need it?

Is it feasible?

Note that I'm not saying that Lightwave should be Houdini.

hrgiger
03-12-2017, 09:50 AM
Seems like there are several bridges to cross in LightWave before we get to procedural modeling.

prometheus
03-12-2017, 10:37 AM
Seems like there are several bridges to cross in LightWave before we get to procedural modeling.

I suspect that too, what is on the carpet is the modifier stacks, if I only could have a sculpting brush in Layout ..I would have a decent workflow of creating main ridges then add procedural displacement on top of that as modifier stack, which I could turn on and off on top of the sculpted geometry, and even mix with other displacement layers to choose from on and off.
Now if Even the sculpted layers could be within a modifier stack..that would be awesome, but this is just me dreaming...we donīt even have a sculpt tool in layout so...

For modeling in modeler with non destructiv workflow, donīt think that would even start to happen before it is implemented in layout with new tools in there.

Asticles
03-12-2017, 10:48 AM
I think it can be achieved with some sort of displacement nodes, adding nodes as generators like point, square, circle. etc. And being multiplied and tweaked after that with arrays, lists and such.

Also this system could take advantage of the per pixel subdivision.

hrgiger
03-12-2017, 12:30 PM
Procedural modeling requires a stack based approach where you can change or reorder settings at any point in the modeling process. And so far l, we have only seen a deformation stack which isn't the same thing. And it can't be done in modeler so it would have to be with a new system in layout and has been mentioned, layout can now see points, polys and edges but expecting much beyond that for lw next is likely unrealistic.

Asticles
03-12-2017, 04:43 PM
As I remember reordering the stack on max was also dangerous...

wingzeta
03-12-2017, 05:43 PM
The new mesh engine should make this possible down the road. How soon we see it, may come down to how easy the new engine makes it to implement. I can imagine, the new engine, a set of basic modeling tools for layout, and a new set of modeling nodes, working with the existing node editor UI, would make it possible, in layout. You would need a new place to access the node editor, like in the modeler tools tab, or be forced to start with a primitive, which layout can already do, and then enter the node editor through the object properties panel. Displacement would still need to be separate IMHO, but it could be folded in as just another node. I think it would be cooler if you could skip ob properties, and just go straight into a modeling panel. Procedural modeling in Houdini seems really convoluted, and not the way I would want to work, but it can be very powerful for a lot of things. It would be great for LW to be capable of those kinds of workflows. My uneducated guess, is they will add this in layout in another version or two, and modeler will be phased out over time. What I would prefer is something like C4D mograph, where you can start stacking modifiers, rather than figuring out which node inputs and outputs to connect, in what order, or what intermediate node I need to make something work. I would definitely want a more intuitive interface than Houdini for LW (not that Houdini can't work outside nodes as well). I just think the future is going to be about user-friendly UI, and who can deliver the most speed and power into the users hands. That's how C4D became huge out of nowhere. LW may be able to combine the best of both, which is the one advantage of being late to the game, you get to see what everyone else is doing before you commit.

samurai_x
03-13-2017, 01:17 AM
Its a long long long road.
Imagine Modo added it in version 11 after a decade I think.
So think of Lw layout v2017 as Modo v1.
There isn't even real modelling tools in layout this year.

jwiede
03-13-2017, 10:25 AM
Imagine Modo added it in version 11 after a decade I think.

Huh? MODO added it in version 10, the sequence numbers accurately reflect the version number.

hrgiger
03-13-2017, 10:48 AM
Huh? MODO added it in version 10, the sequence numbers accurately reflect the version number.

Technically they added it long before that if you go by what Matt Cox said about it when the Nexus architecture was created. They just exposed it and gave it a UX for Modo 10. Which further illustrates the point that the procedural modeling done for Modo wasn't a huge task because the system already had the capability in mind all along. LightWave in contrast would have to develop the infrastructure to do the same and I'm guessing that wouldn't be a small feat in a well established application like LightWave.

prometheus
03-13-2017, 11:35 AM
My fantasy pick would be a system that allows the user to specify where and when you want to add a history stack or a modifer stack in both layout and modeler, so when I decide I need to work on architectural work or special designs with weird structures, I would add the history stack to the model operations and continue down the road to add things and modify, should I choose to have more direct head on figure modeling or rock modeling, I might want to choose not to start with a history stack and jump in to any "open" edit structure in the model without having to be careful about what level I am in etc, and it would probably work faster as well, for architecture I would need to change windows amount, sizes etc..when needed.

Same goes with modeler/ layout philosophy....if possible I would like to choose two alternatives when working on a model, either in Layout..or full focus with a single separate model instance module...I am all for the power of two, it gives two options instead of one strangely :)


What actually turns up in the real life we have to see :) it is just a wet dream I have.

wingzeta
03-13-2017, 01:19 PM
Technically they added it long before that if you go by what Matt Cox said about it when the Nexus architecture was created. They just exposed it and gave it a UX for Modo 10. Which further illustrates the point that the procedural modeling done for Modo wasn't a huge task because the system already had the capability in mind all along. LightWave in contrast would have to develop the infrastructure to do the same and I'm guessing that wouldn't be a small feat in a well established application like LightWave.

This is what my speculation about the new mesh engine in LW is referring to. If they built it to handle or at least be compatible with procedural modeling in the future, then it may just be a matter of creating the interface and/or node types. If they are doing this in layout only, it could become possible sooner than later. My understanding is that modeler needs a big rewrite, or that the layout rewrite will add modeler's abilities in the future, phasing modeler out. In any case, my point was, with a new engine under the hood, layout might be ready to do some of these things sooner than people think, because people assume it won't be possible in LW until modeler has a massive rewrite, but that may not matter now.

Asticles
03-13-2017, 04:22 PM
I prefer hands down the node approach, specially because the use of math nodes.
I think it is important to be able to reference any other parameter of the software within the nodes to establish interesting relationships. Also the node system must be coherent between the interfaces.

If you have time, take a look at Sverchok. Or also at Animation Nodes. They are plugs that extend the software capabilities.

Regards

jwiede
03-13-2017, 08:57 PM
This is what my speculation about the new mesh engine in LW is referring to. If they built it to handle or at least be compatible with procedural modeling in the future, then it may just be a matter of creating the interface and/or node types.

Anything's possible, but what you're suggesting seems quite unlikely.

All the "mesh/geometry engine" (as they've described it) appears to refer to is the spatially-ordered geometry db*, at least based on the descriptions a while back of what they expected were still needed to yield modeling capability in Layout (incl. an explicit mention of needing an abstraction that allowed performant modification of db contents for modeling, and after that the actual modeling ops). From those descriptions, it really doesn't sound like there's a whole lot more coming in LW.Next beyond a geometry db/engine capable of storing vertex, edge and polygon data in a spatially-organized medium.

In order to add even the most basic forms of procedural modeling on top of that as described, above and beyond said needed abstraction for modeling access, LW would also still need an entire suite of basic modeling operators, selection operators, etc. capable of operating as a parametric stack. From a coding perspective, whether coding for procedural operation or coding for destructive operation, the actual algorithms for basic modeling ops/tools are the same, the difference rests in how parameters are handled/abstracted, and so forth.

It's entirely possible LW3DG has extended past the earlier description, but as adding modeling tools and adding procedural modeling ops are two sides of the same coin internally, there's not much rational basis to expect that one aspect will arrive significantly before/after the other. Put another way, when they implement the basic modeling ops, etc. they'll presumably do so in a manner that supports both procedural and destructive operation (even if they only initially expose destructive access), if they have any intent of procedural ever. It won't be a case where they magically make procedural happen without implementing destructive forms as well, because they're really the same ops/tools, just with different levels of operand abstraction (where procedural's is the more complex).

Hope that makes sense.

*: That interpretation also correlates well with the specific areas where they described seeing acceleration simply from replacement (MDD playback), which would be bounded by the rate they can extract per-frame geometry data from such a geometry db/engine.

jwiede
03-13-2017, 09:16 PM
Technically they added it long before that if you go by what Matt Cox said about it when the Nexus architecture was created.

Right, a long time ago there was actually a thread in the MODO forums where Matt (or Brad?) was describing the toolpipe internals, and I pointed out that same parameterization/abstraction really gave everything needed for procedural geometry (presuming they also added some means for parameterization of selections as operands). I'll see if I can find it, but I'm not sure they still have the threads from that long ago, they've re-organized their forums a couple of times since then (circa MODO 3xx or 4xx, IIRC).

samurai_x
03-13-2017, 09:21 PM
Huh? MODO added it in version 10, the sequence numbers accurately reflect the version number.


There's no Modo 11 yet. Could it be.....a typo. :D

50one
03-14-2017, 12:57 AM
There's no Modo 11 yet. Could it be.....a typo. :D

It's not far away. Defo closer than Lw next.

hypersuperduper
03-14-2017, 05:25 AM
I think that, yes, Lightwave should focus on procedural modeling in layout. That makes a lot of sense to me as a first step towards proper geometry creation in layout. Implement the things that modeler CAN'T do first, chief among them procedural geometry creation. Implement the modeling operations that are substandard in modeler after that, and then finally, just before the sun sets on human civilization, move modeling to Layout in its entirety.

robertoortiz
03-14-2017, 07:56 AM
I think that, yes, Lightwave should focus on procedural modeling in layout. That makes a lot of sense to me as a first step towards proper geometry creation in layout. Implement the things that modeler CAN'T do first, chief among them procedural geometry creation. Implement the modeling operations that are substandard in modeler after that, and then finally, just before the sun sets on human civilization, move modeling to Layout in its entirety.

Great post

wingzeta
03-14-2017, 02:25 PM
Yeah, the end of human civilization when we find out we were all procedurally created in the great 3D package in the sky, and dropped into this game engine we call life.

prometheus
03-14-2017, 03:12 PM
Yeah, the end of human civilization when we find out we were all procedurally created in the great 3D package in the sky, and dropped into this game engine we call life.

Someone would already have pulled the plug if that was the case, or the entity creating that game with all its complexity is really messed up, especially if the entity tries to plan something or controll it, it could ofcourse be a huge joke and for fun watching whatever happens in a random scrambled life soup, itīs not a procedural non destructive game, itīs the opposite.
Off..topic, please pull the plug on all this and donīt let this go viral :)

scallahan1
03-14-2017, 03:43 PM
Ha ha. 3D package in the sky is so right! My girlfriend obviously has "Set Driven Keys" that do things to me. We'll leave it at that. :) :)

Steve-o

mummyman
03-15-2017, 09:06 AM
This method seems very cool (after trying and brain hurting)...but very slow.

https://vimeo.com/169438726

I can't ever think that LW would be able to do something like this.. converting geo to volume then back to polys with full history. I'd like to bake it out somehow and test it in LW. Alembic I guess until open VDB is implemented?