Page 6 of 7 FirstFirst ... 4567 LastLast
Results 76 to 90 of 92

Thread: LW 2019.1.5 vs LW 2020 render time comparison

  1. #76
    Super Member jboudreau's Avatar
    Join Date
    May 2003
    Location
    Halifax
    Posts
    939
    Quote Originally Posted by jwiede View Post
    And just to give an example of what I mean: ContentDir "lightwave_2015_content_20141215" is LW2015-provided content, subdirectory was "2015_New_Features/ImportanceSampling/Mecha_IS". Scene was "MechaImportanceSampling_MonteCarlo.lws". For both LW2019.1.5 and LW2020 allowed each to convert into a clean new scene, then did a one-frame render. Here are the results:

    2019.1.5:
    Attachment 147869

    2020(.0):
    Attachment 147868

    So, yeah, great scene "conversion", thanks LW2020. Not only did LW2020 not convert the background into anything it could use, but it messed up the scene's area light as well somehow. Clearly a lot of thought was put into comprehensively handling this sweeping environmental & UX change they forced on everyone.

    Waiting for a patch just to get a "fundamentally-operable 3D program" isn't even remotely acceptable for a commercially-sold product. The product shouldn't have ever been released with this many fundamental systems in such severely broken states. This is inexcusably poor quality for a commercially-sold software product.
    That was a bug where the backdrop was not working properly. Try your test in the new 2020.0.1 update that just came out yesterday.

    Thanks,
    Jason
    VFX Artist / 3D Animator
    Animatrix Productions

    Dell T7600 Dual XEON E5-2687W 3.8GHz / Dell M6700 i7 -3940XM 3.9GHz
    64GB Ram / 32GB Ram
    Nvidia Quadro K5000 / Nvidia Quadro K5000M
    Windows 7 x64

  2. #77
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    799
    Quote Originally Posted by vncnt View Post
    Problem is that I don't want to spend any more time on programming or transcoding 55.000 lines of code for this.

    I want to focus on character animation before I die.

    And nobody does that without a fast and effective pose and motion library, or an effective Copy/Paste feature, or an external Transfer function (scene file nesting).
    I understand your pain. I only just started scripting and have a mere few thousand lines of lscript code. I suppose it is good that they have at least made it clear what the situation is with lscript. Depreciation removes the ambiguity, which has hung over lscript for a while. They probably should have done this sooner, and taken the hit then, instead of letting lscript languish in limbo so long like it has, because even though it was in limbo people have still made a whole lot of cool stuff with it.

  3. #78
    Registered User 3dhotshot's Avatar
    Join Date
    Mar 2009
    Location
    Durban
    Posts
    328
    LW 2XXX shares some luv for the new kids
    Click image for larger version. 

Name:	LW Postcard.jpg 
Views:	124 
Size:	1.63 MB 
ID:	147992

  4. #79
    Super Member Kryslin's Avatar
    Join Date
    Feb 2009
    Location
    Prescott, IA
    Posts
    1,611
    Well, when the lScript subsystem gets torn out, there goes a number of useful tools.

    I might have fewer than 10K lines of lscript code to go through, but I'm not looking forward to it.
    --------
    My Scripts for Lightwave
    Intel Core i7 960 @3.20 Ghz, 24 GB ram, EVGA 6GB GTX980Ti "Classified" driving 2 x HP LA2405.

  5. #80
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,950
    Quote Originally Posted by Kryslin View Post
    Well, when the lScript subsystem gets torn out, there goes a number of useful tools.
    If they're no longer updating it or fixing bugs, it'll quickly start breaking (due to how it's wired into everything), well before it gets removed.

    I really get the sense they barely even considered the impacts and costs of deprecating lscript on customers before making the decision. There are a LOT of lscript plugins (f.e. all Mike Green's lscript plugins) that add tremendously to LW's usability and capabilities, and which are not likely to be replaced once gone. In order to legitimately "weigh" the cost of lscript maintenance, they also need to factor in the cost of replacing all the functionality currently provided by existing lscript plugins. Bob Hood's blog article about the deprecation made no substantial mention those aspects were considered in the decision-making.

    He positioned Python as the scripting engine to replace lscript, but failed to mention that LW's Python engine has serious issues itself: Until LW has Python v3-based capabilities, the unfortunate truth is that current LW Python (v2) is NOT a suitable replacement for lscript, because Python v2 is past EoL. Most LW Python code currently written will need upgrading to cover the imminent LW Python v2->v3 migration that must occur. Even if there were a bunch of third-party LW developers willing and interested in rewriting all the "soon-to-be-lost" lscript plugins in Python (there aren't -- yet another problem), it makes no rational sense to rewrite those plugins in Py2 when they'll shortly need conversion to Py3.

    There's also a long-standing issue with LW Python when it comes to packaging and distributing multi-module plugins (esp. multi-module plugins that provide multiple "LW server types" in a single plugin), as well as a serious "LW Python environment dependency mgmt." problem that must be resolved (plugin devs providing their own versions of dependent Python libraries isn't viable given a common interpreter engine). Presumably the answers for these issues are also awaiting the LW Python v2->v3 migration (v3 certainly provides better mechanisms to support solutions), and as both will also have substantial impacts on packaging and distribution of LW Python plugins, resolving them separately from the migration only further increases cost/effort put on third-party devs.

    There are many serious reasons why the LW Python v2->v3 migration should have been completed before lscript deprecation was even considered.
    Last edited by jwiede; 05-28-2020 at 09:40 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  6. #81
    Super Member vncnt's Avatar
    Join Date
    Sep 2003
    Location
    Amsterdam
    Posts
    1,700
    LScript even doesn't respond anymore to requpdate() during mouse move or after mouse up.

    Without functional guarantees of the most crucial parts, writing your own plugins in the long term is not very beneficial.

    Formal deprication of LScript should have been communicated at launch.
    Last edited by vncnt; 05-31-2020 at 04:23 AM.
    Download my free Legato plugin for CA in LightWave
    Pose- and Motion Libraries, tools to structure your story/poses/performances, X-sheet I/O, audio analysis, hotspot item selection, ...

  7. #82
    Registered User
    Join Date
    Aug 2016
    Location
    a place
    Posts
    2,342
    whats the incentive to upgrade?

  8. #83
    Quote Originally Posted by vncnt View Post
    LScript even doesn't respond anymore to requpdate() during mouse move or after mouse up.

    Without functional guarantees of the most crucial parts, writing your own plugins in the long term is not very beneficial.

    Formal deprication of LScript should have been communicated at launch.
    Bob Hood " First, while the LScript language will continue to be included with LightWave, its code will no longer receive updates or bug fixes; and second, the LScript system will be removed from LightWave in a later, to-be-determined release."
    As we all know this could mean LScript cold be around till LW2030 or gone in LW2021.
    Tim Parsons
    Technical Designer
    Sauder Woodworking Co.

    http://www.sauder.com

  9. #84
    Registered User
    Join Date
    Aug 2016
    Location
    a place
    Posts
    2,342
    just out of curiosity, could lscript be open sourced and left to users to maintain, if desired?

  10. #85
    Super Member vncnt's Avatar
    Join Date
    Sep 2003
    Location
    Amsterdam
    Posts
    1,700
    Quote Originally Posted by gar26lw View Post
    whats the incentive to upgrade?
    Not staying behind. Learn new methods. Anticipate compatibility issues. Modernize workflow.
    Download my free Legato plugin for CA in LightWave
    Pose- and Motion Libraries, tools to structure your story/poses/performances, X-sheet I/O, audio analysis, hotspot item selection, ...

  11. #86
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,950
    Quote Originally Posted by Tim Parsons View Post
    As we all know this could mean LScript cold be around till LW2030 or gone in LW2021.
    See OP's post. If aspects are already broken, it's already losing value quickly.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  12. #87
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    6,950
    Quote Originally Posted by gar26lw View Post
    just out of curiosity, could lscript be open sourced and left to users to maintain, if desired?
    Not really, not without open-sourcing LW itself.

    Lscript bindings into LW's feature systems are the critical lscript code that requires so much maintenance (and will break with changes over time), and those bindings are (by nature) tightly-coupled to LW's own source code. You can't work on the bindings without the code they're binding against, and that's the LW source code itself. Even if the two code bases were separable (likely not), without understanding the nature of the changes occurring in the LW source code at a deep level, there's no practical way to update the lscript bindings for those changes.

    (grossly-simplified version, but hopefully it made sense)
    Last edited by jwiede; 05-31-2020 at 04:37 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  13. #88
    Registered User
    Join Date
    Sep 2015
    Location
    Sweden
    Posts
    799
    Quote Originally Posted by jwiede View Post
    Not really, not without open-sourcing LW itself.

    Lscript bindings into LW's feature systems are the critical lscript code that requires so much maintenance (and will break with changes over time), and those bindings are (by nature) tightly-coupled to LW's own source code. You can't work on the bindings without the code they're binding against, and that's the LW source code itself. Even if the two code bases were separable (likely not), without understanding the nature of the changes occurring in the LW source code at a deep level, there's no practical way to update the lscript bindings for those changes.

    (grossly-simplified version, but hopefully it made sense)
    Would an lscript to python interpreter be possible? Obviously it would be slower than python or lscript, but as a way to keep useful legacy lscripts functional until they are superseded by native solutions or modern python plugins that might be a useful open source project.

  14. #89
    Registered User
    Join Date
    May 2012
    Location
    Virginia
    Posts
    545
    Quote Originally Posted by hypersuperduper View Post
    Would an lscript to python interpreter be possible? Obviously it would be slower than python or lscript, but as a way to keep useful legacy lscripts functional until they are superseded by native solutions or modern python plugins that might be a useful open source project.
    Well, that shouldn't be much of a reach since lscript is based on C programming language and there are already many C to python converters out there.

    The switch to Python is a very strategic move on LW3DG's part. Practically every 3d package currently on the market uses Python or has an embedded Python interpreter.

    The advantage here is that open-source scripts and plugins written in Python for other platforms can be modified more rapidly for Lightwave, meaning more plugins and scripts can be used with Lightwave.

    Also, since you can't swing a dead cat among programmers without hitting someone coding in Python (as opposed to lscript) you immediately gain the benefit of a greater volume of potential plugin content creators.

    So while in the short term there will be definite growing pains, the long term advantage is you gain a significantly larger pool of potential programmers and a programming language that is more congruent and/or homogeneous with that used by similar software packages.

  15. #90
    Founding member raymondtrace's Avatar
    Join Date
    May 2003
    Location
    Ohio
    Posts
    1,147
    Quote Originally Posted by hypersuperduper View Post
    Would an lscript to python interpreter be possible? Obviously it would be slower than python or lscript, but as a way to keep useful legacy lscripts functional until they are superseded by native solutions or modern python plugins that might be a useful open source project.
    Possible but not likely. Try running your existing LS through this:

    http://www.bobhood.net:21134/

    While I understand the question was about a live interpreter, this converter may help to show the obstacles in basic conversion (a baby step toward a live interpreter).
    LW4, 7.5D, 2015, 2018, 2019, 2020 running portably on a USB drive on an Amiga 2500 running Wine.

Page 6 of 7 FirstFirst ... 4567 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
  •