PDA

View Full Version : LW 64 bit for Mac



dhatch01
12-22-2004, 11:56 AM
Sorry if this is a stupid question. I haven't been keeping up with things for a few months.

Is Newtek planning a version of LW 64bit for OSX and the G5s?

DrCuervo
12-22-2004, 02:22 PM
Good question. I don't see why not since it is a 64bit.
Maybe Peter can answer this if he's there...

Chuck
12-22-2004, 02:31 PM
Yes, and we've posted this information about the issues related to doing a Mac port:



Among our issues are that we need to migrate our development to Xcode and we've announced that this is indeed our roadmap for Mac development, as is a 64-bit port....


On the Windows side we've had a 64-bit OS for development for more than four years and the overwhelming majority of the work holds good for the forthcoming Windows® XP Professional x64 Edition OS, currently in beta. We've not had that kind of a leg up on the Mac 64-bit project, so yes, we do feel that there is a great deal more work to do for Mac 64-bit development than remains in completing the port to Windows 64-bit.

If I am understanding the situation correctly, there are a number of remaining OS issues to be addressed as well for a Mac 64-bit port, even as of the forthcoming Tiger. While the G5 is a 64-bit CPU, Mac OS X is not fully 64-bit at this time. Tiger will allow non-GUI based programs to be 64-bit – but this excludes Layout and Modeler from becoming 64-bit applications until Apple updates the GUI layer to 64-bit.

We do intend to solve those issues that are on our end at best possible speed, as fast as the needed OS changes allow, but there certainly is the possibility that we may not be able to release a Mac 64-bit LightWave concurrently when we release the Windows 64-bit version. That would not be our preference, any more than it would be our Mac users' preference, but it may well be the case given the situation.

DrCuervo
12-23-2004, 05:53 PM
Yes, and we've posted this information about the issues related to doing a Mac port:

Gracias! :)

eblu
12-27-2004, 01:53 PM
in response to the text chuck quoted:

re: non GUI only 64 bit support
ummm... its high time screamernet, was killed, and replaced with a standalone non GUI, command line based renderer anyway. this is a feature mac users have been scrambling for since the advent of os x. with it, lw could still work exactly the same, the renderer could be 64 bit (right where you want all that goodness anyway), there would be a LANDSLIDE of awesome render controllers, two words: xgrid compatibility, and one of my favorite parts... it would actually get easier to fix bugs in the renderer on the dev side of things!

theres no reason at all to not do this, it makes good business sense, as the renderer, is vastly different enough to necessitate a separate app (specially now at the Advent of 64 bit cpus), it makes taking care of it easier (because it will be designed not cobbled together like screamernet), users will LIKE it (and that crazy 'unrealistic' end user demand will let up some)

I've posted numerous tirades on this subject. Apple has great support for it, it makes sense from a design, business, and cross platform perspective. its high time somebody sucked it up and got to work on this. Work smarter, pass the intelligence along to your users.

Lightwolf
12-28-2004, 01:46 AM
ummm... its high time screamernet, was killed, and replaced with a standalone non GUI, command line based renderer anyway. this is a feature mac users have been scrambling for since the advent of os x.
I'd assume you'll get this for free once LW gets rid of legacy support and is ported over to XCode (which, on the other side, will probably make it incompatible to all current plugins without a re-compile).

And yes, that is how lwsn works on the PC side of things, and man do I hear complains here too ;)

Cheers,
Mike

eblu
12-28-2004, 09:29 AM
sorry Lightwolf,
I been down this road b4, Newtek was supposed to have no recourse with screamernet in the transfer to osx from 9, but somehow they bought some time then, I expect the same thing this time as well. The net result is always glitches due to an overtaxed design being retrofitted for something that it was never envisioned working with.

but if by some miracle they do indeed put their effort into the rendering/network rendering/modernization of LW's architecture... the only real issue is
that to make a real world class renderer, they need to do more than just "what they will get for free" from xcode.

they would have to:
carve the renderer completely out of Lightwave.
make a standalone GUI based renderer that does all of the rendering (not "LW without an interface", thats ridiculous. worse yet, it implies wasted cycles).
make a logical language that is robust and extensible, for communicating with the renderer, and publish it (so that end users can create controllers).
basically blow away the entire plug-in architecture, and make a new one that is easier to talk to.

just don't see it happening.
I mean, when has LW ever leveraged platform specific technologies that made sense? the "kill screamernet project" would invest LW into some serious platform dependent code, that they have been happily ignoring for oh... 4-5 years. I just don't see the resources being "wasted" on something like this when we could have... uberVoxels, or the ability to rotate bones around 6 axes at once. the bean counters won't let it happen.

euge04
12-28-2004, 11:46 AM
What happened to this promise?

http://www.macworld.com/news/2004/01/07/lightwave/index.php

fxgeek
12-29-2004, 02:51 AM
I have to agree. A command line renderer is badly needed. In fact, having the renderer as a background service would be cool - much like the way compressor works. But again, I cant see anything platform specific being done - and I cant really blame NT for that either. We will probably never see mac specific technologies in a 3d app unless apple decides to build one.

As for the 64bit thing, apple have a page for developers at:
http://developer.apple.com/macosx/tiger/64bit.html

this pretty much explains what's going on.

Lightwolf
12-29-2004, 04:02 AM
I have to agree. A command line renderer is badly needed. In fact, having the renderer as a background service would be cool - much like the way compressor works. But again, I cant see anything platform specific being done - and I cant really blame NT for that either.
What is platform specific about a command line renderer?

Actually, the Mac used to be the only platform where trying to get anything command line based was non-standard, hence the problem with the current implementation of lwsn on the Mac. (After all, OS-X is the first real OS for Apple ;) ).

...as for the promise... I guess they're still trying to find a way to get legacy plugins to work with an XCode build... as well as adapting to the new OS APIs they'll have to use.

Cheers,
Mike

fxgeek
12-29-2004, 07:12 AM
What is platform specific about a command line renderer?

Sorry, i meant other things like xgrid and core image and other mac specific technologies (forgot to put new paragraph between trains of thought)

Lightwolf
12-29-2004, 08:06 AM
Sorry, i meant other things like xgrid and core image and other mac specific technologies (forgot to put new paragraph between trains of thought)
Ah, o.k. then.
Well, a command line based renderer would help with XGrid anyhow, but any decent support of distributed rendering would need a re-write of the LW renderer.
I'm not sure if core image really helps in a 3D app though...
Let Apple get openGL right first ;)

Cheers,
Mike

eblu
12-29-2004, 09:12 AM
personally,
I have been greatly disappointed with the lack-of-enthusiasm that Newtek has for anything new under os x. day one there was a command line, and we are still using an emulated one?

light, I've always wondered why NT designed screamernet the Way they did, its poor design any way you cut it. But, after research I found out that it was designed a very long time ago, as most of the modern approaches to distributed solutions were still just fantasies. So one one hand, screamernet is a testament to the ok-ness of its design. it still works. but on the other hand, its barely limping along, where other, younger, better designed solutions are leaping. the fact that Newtek doesn't want to 'waste' resources on this is infuriating.

I was very happy to move from animation master to lightwave because of the industrial toolset. Not its list of features, just the mindset of putting ability in the user's hands without getting in the way. Animation master has way more capabilities "on the box" than Lightwave, but animation master was adding broken features at a break neck pace, that usually left them no time to fix the bugs. So I don't go in for the flash. Half designed and worthless tools, bugs or glitches that stay with us forever because getting rid of them won't sell product. Ever since the inclusion of Motion designer, I've notice a trend to be heavy on weak features in LW, and its really making me look at other 3d platforms.

re-writing the renderer sounds like a big hassle. I don't envy the poor souls who get that job, but i think I have been patient enough. LW needs a new architecture, they need to put a bullet right through screamernet, they need to make one and only one rendering application that handles both the network and application level rendering, they need to off the lame LScript engine and make something that isn't bolted on, and fix the aging scene file format (specifically so that it can better understand and find associated files while network rendering, what lw does now is crap ). these things are not wants, but needs for lightwave to be an industrial strength package again.

Lightwolf
12-29-2004, 10:00 AM
So one one hand, screamernet is a testament to the ok-ness of its design. it still works. but on the other hand, its barely limping along, where other, younger, better designed solutions are leaping. the fact that Newtek doesn't want to 'waste' resources on this is infuriating.
While it doesn't infuritate me (well, not as much as it seems to infuriate you ;) - what a nice word :D ), I absolutely agree with you.
There are plenty of renderers out there that allow you to distribute rendering tasks in a more flexible fashion.
However, in the case of LW it would mean a complete re-design. And while I don't have a doubt that the new team is thinking along those lines (and may be even already coding along those lines), it will take time.
This is no platform centric issue either, since XGrid is just a small, very small, part of a decent distributed rendering environment (and there are cross-platform alternatives as well).

Cheers,
Mike

eblu
01-01-2005, 02:58 PM
lightwolf, I agree.

except that to say that I have known about the need to re-write Lightwave for -oh... at least 5 years now. And I haven't kept very quiet about it either. I've gone toe to toe with some employees of netwek, and made out fairly well in my 'verbal crusade' to see Lightwave be the best it could be. But somehow, my points being credited as having merit have never once solidified into actions taken By newtek on behalf of its users.
its going to take time, to re-write Lightwave, to learn about the different platforms it runs on, to make a better product. So why, exactly, have they wasted 5 years trying to pretend everything is fine?
it is not acceptable to me that a company would leave something as important as the heart of their flagship application go this long. whatever they are doing in the bowels of the application right now, its all stop gap measures. 8.2 will (like every other update going back to at least 6) fail to deliver on major problems, skip bugs deemed "not dangerous enough", and introduce major bugs that were never tested against (illustrator bug comes to mind here). the last 5 years has been spent introducing even more problems and now, the application is a victim of feature bloat. it does everything, and none of it well.

I know how this story ends, and its not pretty. the only way i can see NT saving face at this point is to halt production on new features completely, kill whats left and start from scratch. theres a lot thats good in Lightwave, ideas of things that are worth saving, but there is no overall vision that is in line with modern software. and if it takes 5 years? then it would be done NOW if they started when it became obvious to everybody.

Beamtracer
01-03-2005, 02:20 PM
re-writing the renderer sounds like a big hassle. I don't envy the poor souls who get that job Who's re-writing the renderer? I don't think anyone is.

I'm disappointed that Apple's Tiger OS requires a 32-bit application interface to be bolted onto a 64-bit command line renderer. I thought Tiger would be completely 64-bit, and can't understand why it isn't. Why wouldn't Apple have had 64-bit applications in mind from the outset with OS X?

So what does it all mean? Why are developers of 3D applications not using this method of 64-bit apps with 32-bit GUIs? Is it too impractical?

What about the Windows side? According to Apple's literature Windows will require a different app for 32-bit and 64-bit uses which will have to be distributed separately. Apple also says that 64-bit Windows will only be able to run 32-bit apps in a "32-bit compatibility mode".

Why is everything so difficult?

Lightwolf
01-04-2005, 06:03 AM
What about the Windows side? According to Apple's literature Windows will require a different app for 32-bit and 64-bit uses which will have to be distributed separately. Apple also says that 64-bit Windows will only be able to run 32-bit apps in a "32-bit compatibility mode".

Obviously, 64bit code will require different binaries.
Then again, nobody complained on the Mac when fat binaries came up during the PowerPC transition, did they?

Yes, 32bit apps will tun in compat mode, they have to, since they can't access any ressources out of their native 32bit/4GB address range. What if they eed to call an OS function that happens to sit outside the 32bit window the app can see and access?
Then again, in most cases it won't be a speed penalty. In some cases legacy apps seem to even run a bit faster on XP64.

Cheers,
Mike

eblu
01-04-2005, 07:30 AM
Who's re-writing the renderer? I don't think anyone is.

I'm disappointed that Apple's Tiger OS requires a 32-bit application interface to be bolted onto a 64-bit command line renderer. I thought Tiger would be completely 64-bit, and can't understand why it isn't. Why wouldn't Apple have had 64-bit applications in mind from the outset with OS X?

So what does it all mean? Why are developers of 3D applications not using this method of 64-bit apps with 32-bit GUIs? Is it too impractical?
Why is everything so difficult?

beam,
while you wait for enlightened minds to answer your questions, here is something to chew on...

alias' maya, the competition, has a renderer. it is a unix tool. it is the only renderer alias uses... by that I mean, rendering in Maya, calls this command line renderer, making it seem like maya (the application) is doing the rendering itself, while in truth the network renderer is doing it. It is because of this separation of application and rendering, that enabled, maya to change renderers at will (mental ray), and it is this design that allows xgrid intergration, and will allow minor changes to Only the renderer to make the transition to 64 bit. Maya itself doesn't need ANYTHING, to make the transition to 64 bit. and thats why Apple did it this way, 64bit is more effective in situations that need: vast amounts of ram, and vast amounts of number crunching. its a tool not a cure all, and Apple started it down the path of most acceptance.

Now Lightwave, has shot itself in the foot. it can't keep up with the competition here, because for the last 6 years Lightwave has slowly been falling behind with the design of lightwave's core. They need to redesign, they know it, and they know that they will risk giving up the market completely if they do redesign. Because no "potential new user" will wait for any company to fix problems, when they aren't adding features (instead of losing features). Anyway, thats the perception, as irresponsible as it is. the bugs in Lightwave, its major design flaws, the future of the platform... they are all being ignored in order to pack one more dissatisfied user into the user base.

why is everything so difficult? because of short term gains, beating out stability and good design with the bean counters.

Zarathustra
01-04-2005, 09:20 AM
NT has it rough. As you say, they need to rewrite the program, but the time it takes for that is something they can't afford. You can't sit idle for a couple of years and then suddenly emerge. You'll die.
So they have to rewrite pieces of it, and have the added burden of making the new stuff work with the old sections that they have to keep in until they have a chance to get to them. TOTALLY blows, but they have no other choice.

Showing a 64-bit PC LW is part of the attempt to still appear cutting edge while in truth, they're patching this and re-programming that to try and bring LW up to speed.

The more I looked at what was going on and the fact that all the PC guys are going to gain is more memory, which is a luxury we've been enjoying for some time now, I'm not really bothered by this PC only 64bit thing. It pales in comparison to the other, more glaring disparities between PC and Mac version.

As a LW user, I can only hope that NT manages to emerge down the line with this new, modern LW but we're going to have to suffer for some time as they try to MacGuyver the new pieces and old pieces together. Look at this new patch that's coming out soon. Perfect example - they're showing off the first stages of the new renderer (or newly re-programmed renderer, however you prefer to word it).

Chuck
01-04-2005, 04:12 PM
Indicating that the core was obsolete and needed to be redesigned as of five years or six years ago and saying that it hasn't been ignores the fact that the core structure was redesigned for the 6.0 release in 2000. Redesign and restructuring of the core has again been in progress very heavily during the 8.0 cycle, and we're confident that this can be carried out in a manner that regularly delivers maintenance and improvements that alleviate rather than cause any suffering on the part of current users.

eblu
01-05-2005, 07:55 AM
chuck,
what you are talking about was an intentional stop-gap measure to shoe horn LW into a few new environments. it was an engineering feat, but ultimately it allowed lightwave to stay stagnant where it matters.

stealthnet, the transition to a new windows compiler, the transition to os x... these were/are great ideals, but not what 'made sense' to the guys in the trenches. At least one of them felt that re-writing, and breaking some compatibility for a modern approach to many of the things LW did was the way to go. but that was a long time ago, and spilt milk is spilt milk.

do you think that Screamernet doesn't take a speed hit by working through an emulated command line on mac os x? Because it is that kind of legacy enveloping that is slowing down the application, and it is where a mountain of headaches are coming from for the users, and the engineers. there are technologies that are obsolete embedded into it, lowering its effectiveness. there are choices out there that are better, more standard, and freely available. it takes training, effort and time to fix these problems of engineering convenience, and I was told that training and time were economically engineered out of the equation.

right now, the dev team has all its eggs in one basket, they write LW, including the renderer, and then 'remove' the interface and compile screamernet with a command-line interface (emulated for the mac btw, which is horribly redundant, and bug ridden), this was convenient 10 years ago, and probably good design... then. But now, with a multitude of examples and pioneers in distributed problem solving, tools that are better than the ones available 10 years ago, and free training... screamernet is showing its age. it would be easier and more advantageous, to develop the app and the renderer, separately. this would lower their respective complexity, eliminate the possibility of bugs from one effecting the other, make it easier to maintain and upgrade each, and give a better ROI. this is obvious to a first year software engineering student. the reason I was told it wasn't going to happen was 'economics.' the initial investment could cost alot. Right now I don't see where Newtek has a choice, but I expect another engineering marvel, that lets Lightwave stay the way it was designed, relatively unchanged for 10 years.

I don't want to take away from the good tweaks done to LW over the last few iterations, but they don't even come close the the scope of change that is necessary for lightwave to become an 'industrial tool' once again.

Lightwolf
01-05-2005, 08:17 AM
screamernet is showing its age. it would be easier and more advantageous, to develop the app and the renderer, separately. this would lower their respective complexity, eliminate the possibility of bugs from one effecting the other, make it easier to maintain and upgrade each, and give a better ROI. this is obvious to a first year software engineering student.
Then that student must be learning something wrong, tell him to talk to the users before making a design decision like that ... ;)

It makes sense to develop it seperately, but then separate it completely from any scene parsing etc. so it can still be hooked into the animation part without shoving data about.
You would _not_ however develop it seperately with a new binary as the goal of that.
This is for example why XSI still has the most solid mental ray implementation, because it doesn't write out a file to render it using the command line, but mental ray takes the data that is natively in XSI already.

Cheers,
Mike

Chuck
01-05-2005, 10:47 AM
Right now I don't see where Newtek has a choice, but I expect another engineering marvel, that lets Lightwave stay the way it was designed, relatively unchanged for 10 years.

If that's what you expect, then your expectations are, thankfully, going to be much different from the reality. Seriously, there is a lot more going on under the hood than you are realizing. As for how you choose to characterize the changes at 6.0, that's certainly in disagreement with how our engineering staff characterized their efforts at that time.