Page 1 of 2 12 LastLast
Results 1 to 15 of 23

Thread: Should Lightwave go to procedural modeling?

  1. #1
    Registered User
    Join Date
    Apr 2016
    Location
    Barcelona, Spain
    Posts
    519

    Should Lightwave go to procedural modeling?

    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.
    Last edited by Asticles; 03-12-2017 at 07:06 AM.
    English is not my native language so please be patient.

    Salvador Ureņa
    http://urenasalvador.wixsite.com/portfolio

  2. #2
    Seems like there are several bridges to cross in LightWave before we get to procedural modeling.

  3. #3
    RETROGRADER prometheus's Avatar
    Join Date
    Aug 2003
    Location
    sweden stockholm
    Posts
    14,676
    Quote Originally Posted by hrgiger View Post
    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.

  4. #4
    Registered User
    Join Date
    Apr 2016
    Location
    Barcelona, Spain
    Posts
    519
    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.
    English is not my native language so please be patient.

    Salvador Ureņa
    http://urenasalvador.wixsite.com/portfolio

  5. #5
    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.

  6. #6
    Registered User
    Join Date
    Apr 2016
    Location
    Barcelona, Spain
    Posts
    519
    As I remember reordering the stack on max was also dangerous...
    English is not my native language so please be patient.

    Salvador Ureņa
    http://urenasalvador.wixsite.com/portfolio

  7. #7
    Registered User
    Join Date
    Jan 2011
    Location
    Seattle
    Posts
    369
    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.

  8. #8
    Super Member samurai_x's Avatar
    Join Date
    Jul 2015
    Location
    lalaland
    Posts
    1,231
    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.

  9. #9
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,470
    Quote Originally Posted by samurai_x View Post
    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.
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  10. #10
    Quote Originally Posted by jwiede View Post
    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.

  11. #11
    RETROGRADER prometheus's Avatar
    Join Date
    Aug 2003
    Location
    sweden stockholm
    Posts
    14,676
    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.

  12. #12
    Registered User
    Join Date
    Jan 2011
    Location
    Seattle
    Posts
    369
    Quote Originally Posted by hrgiger View Post
    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.

  13. #13
    Registered User
    Join Date
    Apr 2016
    Location
    Barcelona, Spain
    Posts
    519
    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
    English is not my native language so please be patient.

    Salvador Ureņa
    http://urenasalvador.wixsite.com/portfolio

  14. #14
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,470
    Quote Originally Posted by wingzeta View Post
    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.
    Last edited by jwiede; 03-13-2017 at 09:10 PM.
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  15. #15
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,470
    Quote Originally Posted by hrgiger View Post
    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).
    Last edited by jwiede; 03-13-2017 at 09:19 PM.
    John W.
    LW2015.3UB/2018.0.7 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

Page 1 of 2 12 LastLast

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •