PDA

View Full Version : LightWave Mac v9.6 Hotfix and Cocoa Update - 2 Jun 2009



Chuck
06-02-2009, 04:11 PM
Hi, Mac 'Wavers! :)

Wow! A quick week that was! Welcome to this week's progress note on our Mac development activities!

Hotfix/Cocoa LightWave v9.6.x: In our original planning we had expected that for at least a time, we would end up with first a Carbon version of Mac v9.6.x maintenance update in testing, and later we would introduce Cocoa Mac LightWave for testing. For that reason I have been reporting here on the Hotfix v9.6.x and Cocoa LightWave v9.6.x as separate entities. As things stand now, however, the hotfix v9.6.x and Cocoa v9.6.x are most likely to end up being one and the same, and we will not issue a Carbon v9.6.x.

As "hotfix" it really affects both platforms with plenty of bug-squashing; and at this point on Mac it looks like Cocoa will be ready to enter testing at such a time that trying to shepherd both a Carbon and a Cocoa Mac v9.6.x build would not make sense.

This should not affect UB plugins. If they worked with Carbon UB (which is 32-bit), they will work with 32-bit Cocoa UB. You would need to acquire 64-bit UB plugins for the new 64-bit UB application version that will be available.

Some have asked if the hotfix has something to do with HardCORE; this is a maintenance update to v9.6, and as such is not directly related to LightWave CORE. All v9 owners will receive this at no charge. We have still not received information from management on the possibility of an Open Beta for LightWave Mac Cocoa.

Cocoa Conversion Status: Adapting Mac CoreAudio is still in progress and still needs a few more days work to complete. Preview Playback has received some attention, though, and is improved on both platforms, with more work to come. Work has also begun on the remaining aspects of the UI, mouse performance, and other areas that needed attention for the Cocoa transition. Despite the progress, it's still the case that some things are still in progress that we had hoped to have resolved already, so we're still keeping the estimate at about four to eight weeks out from beta release, subject to change based on the issues encountered.

Multiplatform Fixes: The team is still killing those multi-platform bugs for the v9.6 hotfix update. As the conversion work is completed, we will also be identifying those existing bugs that the Cocoa conversion did not eliminate so as to clean up as many Mac issues as possible for this hotfix update.


Yep, We're Going to Mention This Every Time, Dept.: 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)

wargum
06-03-2009, 02:15 AM
Excellent! So I think the big news here is that 64 Bit will be free of charge for all 9.x owners, which wasn't clear yet, at least to my knowledge.

And Chuck, I know how hard it is in software development to give a good estimate on how long it'll take. Especially if you do things you haven't done before (like switching the thing to Cocoa :hey:). All the best for the coming weeks from another software developer :thumbsup:

jwiede
06-03-2009, 03:23 AM
Chuck, since you mentioned preview playback, I know there have been a bunch of long-standing bugs on VIPER for LW Mac. 9.6 helped a bit (got mosaic working for many cases, etc.), but it still has lots of cases where it misbehaves or goes dormant.

How much improvement can we expect for Mac VIPER in 9.6.x? Can we expect parity with VIPER on PC?

I'm happy to file more bugs, but it might also be useful if someone from Newtek could clarify precisely what VIPER should and should not be able to preview at this point. The documentation isn't very clear on how we should expect it to behave when previewing scenes containing unsupported elements. There also isn't much info about which elements need f9 (or f10) renders before previews will work, and which we should expect to work without needing renders.

3dworks
06-03-2009, 09:02 AM
great updates, thank you, chuck... :thumbsup:

for me the big news is that, apparently, plugins won't needed to be updated when running in 32 bit mode on the upcoming cocoa version..

from the developers side, will it be lots of work to change a plugin's code to run under 64 bit? i imagine there will be differences from plugin to plugin - and probably it's one thing to make them compatible and another one to optimize them for 64 bit. any inside thoughts on this?

cheers

markus

Darth Mole
06-03-2009, 09:10 AM
Yep, thanks from me too. Great to see the lines of communication firmly open!

However, for people like me who are a bit dev-illiterate, could you describe what the pros/cons are for us moving from Carbon to Cocoa? Obviously I know this is the preferred development platform for Mac, but does it bring any demonstrable advantages - 64-bit notwithstanding?

rsfd
06-04-2009, 03:09 AM
Carbon was Apples library to help large software developers to port their "Classic Applications" (software from OS 9 and below, i.e. Photoshop etc.) to run under OSX with not too much efforts.
Cocoa is native OSX software, and can use all OSX features. Native software runs faster and smoother as it can be better optimized.
You can wiki for carbon/cocoa if you're interested in more info.

Darth Mole
06-04-2009, 06:03 AM
So are we looking at more stable as well as faster/smoother? Better user experience?

rsfd
06-04-2009, 09:41 AM
yep, should be.
(stability is were NewTek comes in, faster & smoother should be a cocoa result, better user experience again is NewTeks deal - it depends on how they implement OSX features - I'm quite confident on that)

Chuck
06-04-2009, 10:46 AM
Chuck, since you mentioned preview playback, I know there have been a bunch of long-standing bugs on VIPER for LW Mac. 9.6 helped a bit (got mosaic working for many cases, etc.), but it still has lots of cases where it misbehaves or goes dormant.

How much improvement can we expect for Mac VIPER in 9.6.x? Can we expect parity with VIPER on PC?

I'm happy to file more bugs, but it might also be useful if someone from Newtek could clarify precisely what VIPER should and should not be able to preview at this point. The documentation isn't very clear on how we should expect it to behave when previewing scenes containing unsupported elements. There also isn't much info about which elements need f9 (or f10) renders before previews will work, and which we should expect to work without needing renders.

Mac Viper is getting a rework as part of the Cocoa transition. Yes, the goal is to bring it to at least parity with PC performance and behaviors. I'll refer your comment on the Viper Documentation to the Docs manager.

Chuck
06-04-2009, 10:54 AM
yep, should be.
(stability is were NewTek comes in, faster & smoother should be a cocoa result, better user experience again is NewTeks deal - it depends on how they implement OSX features - I'm quite confident on that)

Couldn't have summed it up better myself! Thanks, rsfd! :)

Chuck
06-04-2009, 10:56 AM
from the developers side, will it be lots of work to change a plugin's code to run under 64 bit? i imagine there will be differences from plugin to plugin - and probably it's one thing to make them compatible and another one to optimize them for 64 bit. any inside thoughts on this?

cheers

markus

I'll check with the engineers for input on this question, and will add that info to this post when it comes in.

Edit: And here it is from one of our Mac specialists:


The short answer is: it depends.


The longer answer is:
Plugins that make use of APIs that are already available for Mac 64-bit will avoid the need to rewrite for an API that is available for 64-bit. An example is the QuickTime API, which only exists for 32-bit (Mac and Windows btw). Some alternatives for Mac QuickTime API are CoreVideo/CoreAudio and/or QTKit frameworks. Plugins that make use of the 'long' data type need to be aware that these are 8-bytes for Mac 64-bit, but only 4-bytes for Win64.

One aspect that can be confusing is the LWItemID data type: it is always a pointer data type which means it is 4- bytes on all 32-bit systems and 8 bytes on all 64-bit systems. However, LightWave only uses the lower 32 bits of it, always. The LWSDK has useful macros available for plugin developers for converting between this data type and 4-byte integers and vice versa.

If a plugin is already ported to Win64, most 64-bit issues should have already been accounted for. When building for 64-bit, developers may notice that some things that are warnings for a Win64 build can be errors for Mac 64-bit. In other words, building with gcc/XCode can be more picky but usually with good reason. Apple has a 64-bit transition guide at this link:

Apple 64-bit Transition Guide (http://developer.apple.com/documentation/Darwin/Conceptual/64bitPorting/intro/intro.html)

On a personal note, from my experience with the NewTek provided LW plugins, many had only build warnings that I chose to correct. Some had issues with using using the 'long' data type or using 4-byte integers to store 8-byte pointers. Only a few required rewriting for modern 64-bit available APIs. For anyone porting software that they wrote originally, it should be a relatively quick process.

Phil
06-04-2009, 11:48 AM
Will this address Steve's threading issue for texture/ACT evaluations?

Link removed

Chuck
06-04-2009, 12:04 PM
Will this address Steve's threading issue for texture/ACT evaluations?

Link Removed

Probably not in the early builds. The read-write locks perform with no problem on Windows multi-core systems, but incur a major performance hit with the Mac 8-core systems. The team is looking into the issue, but so far it appears that it is not going to be trivial to resolve this.

jwiede
06-04-2009, 12:39 PM
Chuck, is LW using OS-provided sync primitives (such as r/w-locks in question), or does it have its own implementation of them?

jwiede
06-04-2009, 12:43 PM
Mac Viper is getting a rework as part of the Cocoa transition. Yes, the goal is to bring it to at least parity with PC performance and behaviors. I'll refer your comment on the Viper Documentation to the Docs manager.Glad to hear Viper's getting reworked, thanks!

Chuck
06-04-2009, 01:19 PM
Chuck, is LW using OS-provided sync primitives (such as r/w-locks in question), or does it have its own implementation of them?

We don't discuss our development in that level of detail outside the team, but I'll pass the question along just in case it may end up being helpful in the team's review of the issue.

toby
06-04-2009, 02:26 PM
Chuck,
I still can't figure out what your avatar is.
( I just had to be part of the conversation :D )

Kuzey
06-04-2009, 04:12 PM
Hi Chuck,

Just wondering if there have been any progress made into using pre 9.6 files/objects in the current version of LW.

Kuzey

Chuck
06-04-2009, 04:45 PM
Hi Chuck,

Just wondering if there have been any progress made into using pre 9.6 files/objects in the current version of LW.

Kuzey

Kuzey, we're not seeing a general problem with using content created in earlier versions in v9.6, even on the Mac side. The specific bug you put in on will get looked into but likely after we get the first Cocoa build into testing with the closed beta group. Which still sounds funny. We used to call it the core beta group, but had to give that up recently. Ah well, I'll get used to it. :)

Chuck
06-04-2009, 04:50 PM
Chuck,
I still can't figure out what your avatar is.
( I just had to be part of the conversation :D )

A version of Thor's hammer blending some of the Marvel interpretation with my own take on the descriptions from the myths. I need to widen up diameter of the handle just a bit, and then spiral wrap it in leather, and add the lanyard on the stud modeled at the bottom of the handle (not visible in this render).

Scazzino
06-04-2009, 05:33 PM
A version of Thor's hammer blending some of the Marvel interpretation with my own take on the descriptions from the myths. I need to widen up diameter of the handle just a bit, and then spiral wrap it in leather, and add the lanyard on the stud modeled at the bottom of the handle (not visible in this render).

I had been wondering that myself...
I thought it was a hunk of cheese on a stick! :D

toby
06-04-2009, 06:23 PM
I somehow thought it was a room on a pedastal... I know, :confused:
Well it does look like adobe!

Chuck
06-04-2009, 06:56 PM
I had been wondering that myself...
I thought it was a hunk of cheese on a stick! :D

<sigh> Yup, sorta. The metallic aspect is completely lost in down-res-ing for the avatar.

Scazzino
06-04-2009, 07:22 PM
<sigh> Yup, sorta. The metallic aspect is completely lost in down-res-ing for the avatar.

Not to worry, once you finish the handle it'll read much better. :thumbsup:

kfinla
06-04-2009, 07:23 PM
I knew it was thor's hammer :) And am also anxious to see the Fprime 3.5 OSX issues resolved so the plugin can make use of more than 2 processors!