View Poll Results: Upgrade Sasquatch to LW201x compatibility please!

Voters
9. You may not vote on this poll
  • [*]Yes, I'd love to upgrade Sasquatch!

    8 88.89%
  • Maybe!

    0 0%
  • No, I don't need that. LW2015 handles Sasquatch good enough.

    1 11.11%
Results 1 to 5 of 5

Thread: Sasquatch upgrade to LW2020 compatibility?

  1. #1
    Super Member vncnt's Avatar
    Join Date
    Sep 2003
    Location
    Amsterdam
    Posts
    1,787

    Sasquatch upgrade to LW2020 compatibility?

    I just sent a desperate email to [email protected] begging for an upgrade from Sasquatch 64-bit to get LightWave 2012019/2020 compatibility.

    Hence, I wonder if more users would be interested.

    See also https://forums.newtek.com/showthread...atch-in-LW2020
    Last edited by vncnt; 11-20-2020 at 06:02 AM.

  2. #2
    ack ack Markc's Avatar
    Join Date
    Feb 2006
    Location
    England
    Posts
    1,709
    I didn’t think Worley where even about any more.....
    I have FPrime and Taft from way back, but havn’t worked on Mac since about ver 9.6.
    Mac Pro (2010) OSX 10.14 RX580 Pulse LW2020
    (plugins: LWCad 2020, TFD 1443, Syflex 2018, StarPro(2.3) 2020, ExrTrader 2020, Ubercam 2.0, Daz Mocap, DP Light 2020, Quadpanels 1.53)

  3. #3
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    8,471
    Quote Originally Posted by Markc View Post
    I have FPrime and Taft from way back, but havn’t worked on Mac since about ver 9.6.
    Because each version and revision NewTek developers are changing nodal access structure without maintaining compatibility,
    so there is required update of the all nodes and the all node editor using plug-ins to handle new bigger extended structure..
    In LW 9.x ... LW 2015.x it was called LWNodalAccess,
    in LW 2018-2020 it was so dramatically changed that even changed name to LWShadingGeometry.

  4. #4
    Electron wrangler jwiede's Avatar
    Join Date
    Aug 2007
    Location
    San Jose, CA
    Posts
    7,315
    Quote Originally Posted by Sensei View Post
    Because each version and revision NewTek developers are changing nodal access structure without maintaining compatibility,
    so there is required update of the all nodes and the all node editor using plug-ins to handle new bigger extended structure..
    In LW 9.x ... LW 2015.x it was called LWNodalAccess,
    in LW 2018-2020 it was so dramatically changed that even changed name to LWShadingGeometry.
    Actually, no. The reason Worley plugins are broken on the Mac side past LW9.6 is because the LWSDK HostDisplayInfo return type changed when LW moved from using Carbon frameworks to Cocoa frameworks in LW 9.6.1, and Worley never got around to updating his Mac plugins for Cocoa-based HostDisplayInfo. Even if that were fixed, they'd also need fixes for subsequent UB64 and Mach-O changes in order to work on current Cocoa-based Mac LW 9.6.1-2015.x.

    To work in Cocoa-based Mac LW2018+, they'd also need the changes Sensei mentions, but that's not what caused the break asked about (post-LW9.6).
    Last edited by jwiede; 12-22-2020 at 03:45 PM.
    John W.
    LW2015.3UB/2019.1.5 on MacPro(12C/24T/10.13.6),64GB RAM, NV 980ti

  5. #5
    TrueArt Support
    Join Date
    Feb 2003
    Location
    Poland
    Posts
    8,471
    Quote Originally Posted by jwiede View Post
    Actually, no. The reason Worley plugins are broken on the Mac side past LW9.6 is because the LWSDK HostDisplayInfo return type changed when LW moved from using Carbon frameworks to Cocoa frameworks in LW 9.6.1, and Worley never got around to updating his Mac plugins for Cocoa-based HostDisplayInfo. Even if that were fixed, they'd also need fixes for subsequent UB64 and Mach-O changes in order to work on current Cocoa-based Mac LW 9.6.1-2015.x.

    To work in Cocoa-based Mac LW2018+, they'd also need the changes Sensei mentions, but that's not what caused the break asked about (post-LW9.6).
    Worley in the all his plugins used some proprietary UI instead of what LW delivers. Porting from Windows to Mac is as easy as recompilation, if you're not using OS directly to do some stuff. But if you use some proprietary UI toolkit... you've damn troubles..

    LWSDK's HostDisplayInfo global just contains window pointer. Pretty meaningless for 99.9% of plug-ins. Because you never ever touch OS directly.. but custom made UI toolkits may need it...
    I could count on one hand how many times I needed HWND window pointer in some plug-in..
    Last edited by Sensei; 12-22-2020 at 04:00 PM.

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
  •