Page 5 of 11 FirstFirst ... 34567 ... LastLast
Results 61 to 75 of 156

Thread: Any hint of anew LW coming in 2020?

  1. #61
    Registered User
    Join Date
    May 2012
    Location
    Virginia
    Posts
    455
    Quote Originally Posted by jwiede View Post
    • Non-destructive dynamic disable/enable of node links on-the-fly while editing

    Excellent list!

    If they could only implement one of those, this would be my choice.

    I would guess that it would probably be the easiest to do as well.

  2. #62
    Registered User
    Join Date
    Jun 2014
    Location
    Right here
    Posts
    1,576
    Quote Originally Posted by Bernie2Strokes View Post
    I can't afford to buy a newer graphics card right now. In fact, I'm hoping to install a second GTX 1080 into my PC next year for possible multi-GPU support. Newtek can always upgrade a later version of whatever is next to adapt to a new raytracing technology.
    Already this this year it doesn't make sense to purchase / put an outdated GTX1080 in a machine, not to mention next year.

    RTX2070 is faster even without RTX acceleration (and with RTX support you can expect up to 7x the speed in specific scenes and render engines) .

    And even the Standard RTX cards are now outdated because the 'new' RTX2070 Super is already faster than a RTX2080.

    Mixing GTX and RTX cards is no problem btw.
    Last edited by Marander; 11-01-2019 at 08:34 AM.

  3. #63
    Registered User
    Join Date
    May 2015
    Location
    Philippines
    Posts
    154
    Quote Originally Posted by Marander View Post
    Already this this year it doesn't make sense to purchase / put an outdated GTX1080 in a machine, not to mention next year.

    RTX2070 is faster even without RTX acceleration (and with RTX support you can expect up to 7x the speed in specific scenes and render engines) .

    And even the Standard RTX cards are now outdated because the 'new' RTX2070 Super is already faster than a RTX2080.

    Mixing GTX and RTX cards is no problem btw.
    My motherboard can only support multi-GPU if they're the same model graphics card. Assuming the price will drop next year I think it will still be useful to me.
    System:

    i7-8086K / GTX 1080 / 32GB RAM

  4. #64
    Registered User
    Join Date
    Sep 2017
    Location
    MA
    Posts
    60
    Quote Originally Posted by RPSchmidt View Post
    I did see that. It looks pretty nice. But I'm also greedy and would like a shiny new Unity Bridge button positioned right below the Unreal Bridge button in LightWave.

  5. #65
    Registered User
    Join Date
    Jun 2014
    Location
    Right here
    Posts
    1,576
    Quote Originally Posted by Bernie2Strokes View Post
    My motherboard can only support multi-GPU if they're the same model graphics card. Assuming the price will drop next year I think it will still be useful to me.
    Never heard of that. If the board has enough PCI-E lanes and the PSU is strong enough there should be no issue. Note that multi GPU rendering doesn't require SLI.

  6. #66
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,612
    Quote Originally Posted by RPSchmidt View Post
    Excellent list!

    If they could only implement one of those, this would be my choice.

    I would guess that it would probably be the easiest to do as well.
    Agreed, muting of links and nodes are both highly valuable node editing capabilities. IMO, adding more debug features without improving basic organization capabilities is akin to putting the cart before the horse, though -- messy node flows just make it more difficult to use debugging features like muting.

    I think LW's at the point where just about everything in that list is direly needed, as well as encryptable compounds, and a much better node browser.
    Last edited by jwiede; 11-01-2019 at 03:07 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  7. #67
    I just thought of something that would be nice to add for the better functionality of Instancing!

    Suppose you needed an animation that required hundreds or thousands of virtual clones of an animated object.

    It would be similar to flocking, but different in a number of ways. For one, you would be able to offset the animated character you create for the first one by a number of frames. Right now, this can be done, sort of, but requires manually offsetting each normal cloned polygonal character item one at a time.

    What would be good is, if you could place Instances in Modeler and have those instances be able to be tracked somehow in Layout [using remembered ID's?] and that they then can be used to drive the [instanced] animated character you created. It would be sort of like having an instance which currently [normally] right now having to be a time-locked physical clone of the current animated character with bones, etc., but allowing time-shifting the animation forward or backward in time by X number of frames or seconds.

    This would make a large body of characters [think armies or hordes of characters etc.] able to be seen in a sort of random motion. It would all be driven by the placement of the point instances and where they are placed. If driven by Point ID's, could conceivably work, at least in theory. You could also use the random size parameters in instances to control difference factors of basic shape.

    Can this idea be Python scripted, or done as an Lscript maybe.


    I really think this would make a great feature request.


    What does everyone think?

  8. #68
    RETROGRADER prometheus's Avatar
    Join Date
    Aug 2003
    Location
    sweden stockholm
    Posts
    15,335
    Quote Originally Posted by JamesCurtis View Post
    I just thought of something that would be nice to add for the better functionality of Instancing!

    Suppose you needed an animation that required hundreds or thousands of virtual clones of an animated object.

    It would be similar to flocking, but different in a number of ways. For one, you would be able to offset the animated character you create for the first one by a number of frames. Right now, this can be done, sort of, but requires manually offsetting each normal cloned polygonal character item one at a time.

    What would be good is, if you could place Instances in Modeler and have those instances be able to be tracked somehow in Layout [using remembered ID's?] and that they then can be used to drive the [instanced] animated character you created. It would be sort of like having an instance which currently [normally] right now having to be a time-locked physical clone of the current animated character with bones, etc., but allowing time-shifting the animation forward or backward in time by X number of frames or seconds.

    This would make a large body of characters [think armies or hordes of characters etc.] able to be seen in a sort of random motion. It would all be driven by the placement of the point instances and where they are placed. If driven by Point ID's, could conceivably work, at least in theory. You could also use the random size parameters in instances to control difference factors of basic shape.

    Can this idea be Python scripted, or done as an Lscript maybe.


    I really think this would make a great feature request.


    What does everyone think?
    It probably is a great feature request, I have had a vision of being able to have Random Geometry instances..meaning you add one original geometry character, but then this is instanced as a volume object and not geometry, but each instance is unique in the way that it´s character will look different.
    May be impossible, but I think of it as if it could get morph data (it assumes morphs is set up) from various face morphs, sculpts and deforms of a face...and then it applies the volume shape based on what that geometry has built in as morphs, with variations per instance.

    Just a very crude vision of something I think would be awesome, but unfortunately..I am not technicly skilled enough around these things to judge on what would be possible.

  9. #69
    Registered User
    Join Date
    May 2015
    Location
    Philippines
    Posts
    154
    Quote Originally Posted by Marander View Post
    Never heard of that. If the board has enough PCI-E lanes and the PSU is strong enough there should be no issue. Note that multi GPU rendering doesn't require SLI.
    Ah, right. I specifically meant SLI. I don't plan on having more than 2 cards installed.
    System:

    i7-8086K / GTX 1080 / 32GB RAM

  10. #70
    Registered User
    Join Date
    Mar 2012
    Location
    Socal
    Posts
    428
    The ability to bake where your instances are placed would be great for landscapes, where you might have millions of instances. It can take 10-20 minutes on some older hardware to recalculate all those instances.

  11. #71
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    616
    Quote Originally Posted by jwiede View Post
    Having the ability to sign/encrypt compounds for distribution is essential to fostering a viable ecosystem, and something that most other node systems offer now -- I requested that from Newtek years ago, went nowhere, I even offered to help spec up such a system for them. That one, in particular, shouldn't even need anyone external to request it, it should be utterly obvious.

    Having much better ability to preview and organize externally-sourced nodes and compounds is another obvious, critical need -- the node panel is terribly inefficient for that, names alone aren't nor have ever been adequate labeling as to purpose/contents of substantial quantities of entities of any sort. Having some kind of visual preview of the node flow itself, along with embedded descriptive metadata (author, name, version, description, etc.) would be significantly more efficient. BTW, when you add features like "backdrops", having visual preview of node flows becomes even more valuable for identification and differentiation.
    I am not sure I would agree that signing and encrypting compound nodes is really necessary for a viable ecosystem. I mean, if people want to sell nodes there is a plug-in infrastructure in which devs can make nodes from scratch. I see sharing compounds as different. I think that with better sharing, easier access in the node list and better preview functions, perhaps simply the ability to add notes/ usage instructions to a compound node in a non-hacky way would be sufficient.

  12. #72
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,612
    Quote Originally Posted by hypersuperduper View Post
    I am not sure I would agree that signing and encrypting compound nodes is really necessary for a viable ecosystem. I mean, if people want to sell nodes there is a plug-in infrastructure in which devs can make nodes from scratch. I see sharing compounds as different. I think that with better sharing, easier access in the node list and better preview functions, perhaps simply the ability to add notes/ usage instructions to a compound node in a non-hacky way would be sufficient.
    Obviously third-party devs ARE selling compiled nodes commercially now. However, as part of compiling a node, there's also opportunities to ensure licensing, provenance, integrity, and so forth.

    With compounds as is, there's no real way to manage licensing or otherwise prevent trivial replication/redistribution of your product, nor even to reliably confirm origin or integrity. Nothing will stop the dedicated crackers, but historically at least some protection against trivial replication/redistribution (and assurance of origin/integrity) is needed in order to support a meaningful commercial market for digital assets.
    Last edited by jwiede; 11-02-2019 at 09:28 PM.
    John W.
    LW2015.3UB/2019.1.4 on MacPro(12C/24T/10.13.6),32GB RAM, NV 980ti

  13. #73
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    616
    I just don’t think putting together and sharing compound nodes should necessarily be treated as a commercial enterprise, you have the plugin infrastructure for that and that is a good (low) Barrier for entry into the commercial market. Commerce brings with it a host of concerns and issues (cracking, support, etc) that are just not worth it when anyone can link two nodes together and put it in a compound. I just want to be able to access shared and share my own custom compound nodes in an easy way. What I would like to see really would be some kind of Newtek hosted database, ideally accessible from within layout directly, that contains well-sorted community created compounds and other content (scenes for use with load from scene primarily). All of this stuff would be free to use and modify for any purpose. In this fantasy scenario content like networks and scenes would be shared and accessed direct from within layout. Just instead of loading from disk you could access a central repository.

    That said, I don’t imagine Newtek ever doing anything like this doesn’t seem like their MO.

  14. #74
    Vacant, pretty vacant pinkmouse's Avatar
    Join Date
    Aug 2003
    Location
    South Yorkshire
    Posts
    1,703
    Without proper notation and organization in nodes, the idea of a repository will never fly. Quite often I go back to a scene after a month or so and have to spend ages working out what I did and how I did it, and I constructed the networks myself. I hate to think how someone else would manage.

    Just like undocumented code, virtually worthless.
    Al
    "I conceive of nothing, in religion, science or philosophy, that is more than the proper thing to wear, for a while." Charles Fort

    My Website
    My Lightwave Tutorials

  15. #75
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    616
    Certainly notation improvements would be good to make compound node sharing really useful. At the very least you would want the ability to compose verbose instructions on a compound node. Currently you can only write a short little note. That said, I have a number of very useful compounds that I can’t remember how i built them and I never open them, but I know what they do and when to use them because they have clear names and properly labeled inputs and outputs. I use them as often as any other node. At the compound level you don’t really need massive improvements to have a pretty solid ground for shareable user made tools. If someone wants to dig into them and improve them or adapt them, better notation and background, grouping etc. would be appreciated, but that wouldn’t be the primary use case. The primary use case would be a complete self contained compound that does a thing that individual nodes can’t do.
    Last edited by hypersuperduper; 11-03-2019 at 02:21 PM.

Page 5 of 11 FirstFirst ... 34567 ... 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
  •