PDA

View Full Version : LightWave Mac v9.6 Hotfix/Cocoa Update - 15 Jul 2009



Chuck
07-15-2009, 01:08 PM
Hi, Mac 'Wavers! :)

Welcome to this week's progress note on our Mac development activities!

Cocoa/Hotfix LightWave v9.6.x: As noted in our last update message, the v9.6.1 maintenance update/Cocoa conversion has gone into beta testing in the limited beta group. Reactions have been pretty good, but there are several issues we will need to resolve before we commence Open Beta. One of the major issues seems to be already resolved, subject to testing results: we believe we have resolved the performance issue affecting the use of FPrime on 8-core Mac systems.

Bugfixes continue on all fronts for the update, as does completion and polishing of the Cocoa conversion. We expect that in a few weeks we should be able to bring this to Open Beta for all v9 owners.

That's it for this week! :)


Please Keep Those Bug Reports Coming: Getting in reports on any bugs you may have encountered but not yet reported is very important. Don't forget to include steps and content, as they are needed to insure that we can duplicate your bug properly and get it fixed. For those of you who need a refresher as to how to report bugs, check this link:

Instructions for Bug Report and Feature Request Database (http://www.newtek.com/forums/showthread.php?t=73227)

Phil
07-15-2009, 03:24 PM
Tell whichever dev was responsible that they are a hero. That FPrime-related fix is really huge news.

jwiede
07-15-2009, 06:01 PM
Yeah, no question, I'm really looking forward to multicore FPrime.

Chuck, the discussion on this had gone back and forth a bit, is there a current position on whether there will be both UB32-Carbon and UB32-Cocoa builds available? Barring that, will the 32-bit UB-Cocoa build be fully compatible with existing UB plugins?

It'd be a shame to get the update only to get stuck with no alternatives for running existing UB plugins while waiting for them to be ported to "UB-Cocoa", esp. in the case of plugins like Dynamite where further updates are unlikely to happen.

P.S. Has Newtek approached Can _recently_ about acquiring the Dynamite plugin? He (or heirs, whatever) might be more amenable now that there is no potential for further revenue -- even if he were to reappear, he kinda poisoned the well for himself w.r.t. future sales.

Chuck
07-16-2009, 10:48 AM
Yeah, no question, I'm really looking forward to multicore FPrime.

Chuck, the discussion on this had gone back and forth a bit, is there a current position on whether there will be both UB32-Carbon and UB32-Cocoa builds available? Barring that, will the 32-bit UB-Cocoa build be fully compatible with existing UB plugins?

It'd be a shame to get the update only to get stuck with no alternatives for running existing UB plugins while waiting for them to be ported to "UB-Cocoa", esp. in the case of plugins like Dynamite where further updates are unlikely to happen.

LightWave v9.6.1 and forward will be only UB Cocoa builds. UB plugins, whether Carbon or Cocoa, should work with no problems, as long as used with the correct bit-depth LightWave build. There will also be no further CFM builds.


P.S. Has Newtek approached Can _recently_ about acquiring the Dynamite plugin? He (or heirs, whatever) might be more amenable now that there is no potential for further revenue -- even if he were to reappear, he kinda poisoned the well for himself w.r.t. future sales.

We've tried no correspondence lately (and previous attempts to contact Can have not always received responses), and our future plans for dynamics and volumetrics improvements center on implementations for LightWave CORE.

Iaian7
07-16-2009, 01:21 PM
We've tried no correspondence lately (and previous attempts to contact Can have not always received responses), and our future plans for dynamics and volumetrics improvements center on implementations for LightWave CORE.

Unfortunate, but understandable. I'm looking forward, very much, to a world without HyperVoxels, replaced by something completely new (gaseous/liquid, volumetric shaders even?), and obviously better. :D I wish you all the greatest success!!!

kfinla
07-17-2009, 04:02 PM
Great news on the Fprime fix. Now if only Fprime didn't lose the ability to preview all those nodes that now have a pre-process. I miss being able to see Fast skin in fprime.

Littleghost
07-18-2009, 10:46 PM
Dumb question: I haven't updated my copy in a long time, so I forget exactly how. After I've unzipped everything, do I just dump it all into the proper folder so it replaces the old versions, or is there more to it? I'd rather not mess up any of the stuff I've added or re-install the whole program. Thanks :o

rsfd
07-20-2009, 05:45 AM
@littleghost
have a look here http://www.newtek.com/forums/showthread.php?t=94245].
The download and install guide should answer all of your questions.

jwiede
07-20-2009, 06:44 AM
Chuck, I'll also file this as a feature request, but in the name of getting it to the right people quicker...

There's a few 32- vs 64-bit config issues on MacUB which will need to be addressed, as well as some automated launch control issues...

1. It'd be nice if there were a way for LW to offer an lscript / SDK API for detecting and changing the state of the 32-bit toggle in the app's info (e.g. changing the button in Finder's Get Info settings for the app). The API would make it much easier for the farm controller to switch between 32- and 64- operation remotely. The API would go out and change the state of the app info, which would then get picked up upon relaunch.

2. There will be many prefs which get set differently between 32- and 64-bit program configs (anything involving buffer sizes, other limits, and most importantly, related to plugins incl. menu/key config). Having separate dirs for everything seems pointless, instead can there just be different tags for 32- and 64-bit fields within same prefs file?

In the case of plugins, perhaps allow plugins to either cohabit, or create 32-bit and 64-bit subdirs under the existing plugin dir? Not quite sure what best approach is for key/menu, esp. while many plugins lack 64-bit support, and thus wouldn't have 64-bit equivalents when LW runs in 64-bit mode. Folks don't want to reconfig menus/keys every time a plugin that disappears in 64-bit mode then subsequently reappears in 32-bit mode.

What I'm trying to avoid with these, is situations that'd require entirely different preference trees, plugin trees, etc. based on bitness, as that would make renderfarm configuration painful (and break some Apple standards about prefs). Being able to share out a single network share/dir, containing both sets of configs, etc. is rather important IMO.

Thanks! Will send in as a feature request, but trying to determine whether to write this up as one big FR, or as individual FRs for the API, and the individual config/pref/preset dirs -- Chuck, any preference?

Scazzino
07-20-2009, 07:30 AM
I don't think too much extra effort should really go into making 32-64 co-habitate together in the same folder since going forward the 32-bit version would really just be for legacy plugins/hardware. All new Mac's and all new Mac OS's are now 64-bit. 32-bit LW will just be for older systems or older plugins, much like the CFM version was kept around for similar purposes. There were no special features related to the CFM/UB versions.

The easiest way to set up both 32-64 bit for those that may need to switch back and forth for older plugins will just be to duplicate your application folders with a local preferences folder in each. Then change the switch in one to "launch in 32-bit" and put your old 32-bit plugins in that one.

For screamerNet you should just be able to have two ScreamerNet config directories and launch the nodes with the command line argument to select which config and which architecture.

Done.

:hey:

Chuck
07-20-2009, 10:24 AM
Chuck, I'll also file this as a feature request, but in the name of getting it to the right people quicker...

There's a few 32- vs 64-bit config issues on MacUB which will need to be addressed, as well as some automated launch control issues...

1. It'd be nice if there were a way for LW to offer an lscript / SDK API for detecting and changing the state of the 32-bit toggle in the app's info (e.g. changing the button in Finder's Get Info settings for the app). The API would make it much easier for the farm controller to switch between 32- and 64- operation remotely. The API would go out and change the state of the app info, which would then get picked up upon relaunch.

2. There will be many prefs which get set differently between 32- and 64-bit program configs (anything involving buffer sizes, other limits, and most importantly, related to plugins incl. menu/key config). Having separate dirs for everything seems pointless, instead can there just be different tags for 32- and 64-bit fields within same prefs file?

In the case of plugins, perhaps allow plugins to either cohabit, or create 32-bit and 64-bit subdirs under the existing plugin dir? Not quite sure what best approach is for key/menu, esp. while many plugins lack 64-bit support, and thus wouldn't have 64-bit equivalents when LW runs in 64-bit mode. Folks don't want to reconfig menus/keys every time a plugin that disappears in 64-bit mode then subsequently reappears in 32-bit mode.

What I'm trying to avoid with these, is situations that'd require entirely different preference trees, plugin trees, etc. based on bitness, as that would make renderfarm configuration painful (and break some Apple standards about prefs). Being able to share out a single network share/dir, containing both sets of configs, etc. is rather important IMO.

Thanks! Will send in as a feature request, but trying to determine whether to write this up as one big FR, or as individual FRs for the API, and the individual config/pref/preset dirs -- Chuck, any preference?

We always prefer each feature request to be a single item. I would note that there is no feature work other than the Cocoa code conversion planned for v9.6.1. Any new features would be beyond the v9 cycle.