PDA

View Full Version : LW 8.2, is it Mac optimised?



ackees
01-25-2005, 10:11 AM
Does anyone know if 8.2 is optimised for the Mac (G5 or G4), or is it the same as previous LW, a basic port from the PC?
Thanks

NigelH
01-25-2005, 10:37 AM
No more than any other version of LW, as far as I can tell.

ackees
01-25-2005, 11:48 AM
that's a terrible shame and lost opportunity if that is so. Looks like I'll have to wait to 9. I hope NT can do something dramatic on the Mac before someone else does.

stib
01-25-2005, 03:52 PM
I'm kinda secretly hoping that Apple will do for 3d what they did with final cut, shake and motion: buy up an existing app (here! Mr Jobs look here!) and turn it into a nice lickable apple application. Shucks they could even keep supporting the 'doze/linux versions for a while, for about three times the price, like they do with Shake..

ackees
01-25-2005, 04:37 PM
There was some talk a little while ago about NT getting serious Mac programmers, about really producing an optimised Mac version using all that lovely mac technology, but I am getting worried as it seems to be the same old tune with 8, I hope I am very wrong.
It’s true the one thing apple have not done yet is 3D, Hmmm! Perhaps the mac is not really 3D ready. But then again Maya was able to pump some serious juice out of the G5 for 6 on the Mac. And Lux is talking big about what they are going to do. I wish NT would talk big about their plans for the Mac, I get a feeling of ‘holding back’ on the Mac from NT, perhaps they do not have enough Mac seats to justify a bigger Mac push.

policarpo
01-25-2005, 08:40 PM
I'm kinda secretly hoping that Apple will do for 3d what they did with final cut, shake and motion: buy up an existing app (here! Mr Jobs look here!) and turn it into a nice lickable apple application. Shucks they could even keep supporting the 'doze/linux versions for a while, for about three times the price, like they do with Shake..

If Apple buys anything, it will be that app that is always @ MacWorld, and was on the stage a few times. ;)

pat-lek
01-26-2005, 01:59 AM
Bah... Steve Jobs have a good part of the Pixar Studio. Pixar surely have coders and programmers, and they have Renderman... Renderman cost the same price for PC ou Mac os X, No special gift for the Mac user. Now, the 3D market, is the only pro market where Apple is not on the top. Graphism 2D > Apple, film, movies > Apple , Music > apple... 3D> PC...

ackees
01-26-2005, 02:01 AM
Logically speaking because the Mac has the hottest technologies at the moment LW should be a port from Mac to PC, but it is going the other way. Take all the talk about 64bit, the Mac has it now, so why not show this off on a quad G5? Why wait for Windows, and then port it from Windows to Mac? O am I being greedy, wanting too much from NT when they are trying their best?

BeeVee
01-26-2005, 03:19 AM
As much as I would like it to be, OSX isn't 64-bit yet. Nor will it be fully 64-bit when Tiger comes out. The reason that a 64-bit version was proposed for Windows first is that there has been a beta version of 64-bit Windows available for some time now, and the final release of 64-bit Windows is planned for this April. As Chuck has said on several occasions, porting to a 64-bit Mac version isn't simply a matter of recompiling...

B

ackees
01-26-2005, 03:36 AM
So apple would not supply a company like NT a beta version? Maybe it's apple who are holding 3D on the Mac back.
So the LW 64bit is in Windows format (no need for a windows port) and must be 'ported' to the Mac? What is the core code of LW then, Windows?

BeeVee
01-26-2005, 04:01 AM
Yes there is going to be a "Windows port" as you call it. Windows 64-bit is different enough to Windows standard to require one, and work has been ongoing on that front for a long time.

B

eblu
01-26-2005, 07:16 AM
Does anyone know if 8.2 is optimised for the Mac (G5 or G4), or is it the same as previous LW, a basic port from the PC?
Thanks

you're kidding right?

eblu
01-26-2005, 07:40 AM
As much as I would like it to be, OSX isn't 64-bit yet. Nor will it be fully 64-bit when Tiger comes out. The reason that a 64-bit version was proposed for Windows first is that there has been a beta version of 64-bit Windows available for some time now, and the final release of 64-bit Windows is planned for this April. As Chuck has said on several occasions, porting to a 64-bit Mac version isn't simply a matter of recompiling...

B

beevee, x is 64 bit.
it may be difficult to access, and it may not coincide with your app's design, but os x is 64 bit, and quite capable of doing all of the things that windows is still promising it Will be able to do.

Apple took a different approach to the 64 bitness of an os compared to windows, and since they have actually shipped something (that works), I think its a little near sighted and over-simplifying to say that os x is not 64 bit. Its true the finder isn't 64 bit, but that is not the OS. Tiger opens up the availability of the tools for 64 bit calculations, but it doesn't change the way Apple approaches the problem. Apple believes (and I agree) that tools should be applied where they are most effective. UI stuff cannot benefit as much as pure number crunching from being 64 bit, so Apple has made it so that if you design your app in a modular way, you can keep the front end of your app the same without changing it, introducing bugs, issues or problems, while still making the number crunching parts 64 bit. I am an advocate of this approach and Have been for Lightwave specifically for almost 6 years now, you'll note that 6 years pre-dates os x, let alone the 64 bit question. It is my belief that Lightwave would benefit in many more ways than just this one, by a complete redesign of the rendering system, filetypes, and UI.

in the end I personally think that the 64 bitness of os x is generally irrelevant. Lightwave has historically ignored anything to do with optimization (on the mac side, for reasons that used to make sense) and if your going to go down the 64 bit path there are a whole host of other things lightwave should be doing from a 'big picture' perspective that would be very helpful.

http://developer.apple.com/technotes/tn/tn2086.html

theres a good bit of 'top down' advice for dev peeps looking to make faster apps in osX.

Lightwolf
01-26-2005, 08:28 AM
beevee, x is 64 bit.
it may be difficult to access, and it may not coincide with your app's design, but os x is 64 bit, and quite capable of doing all of the things that windows is still promising it Will be able to do.

Apple took a different approach to the 64 bitness of an os compared to windows, and since they have actually shipped something (that works), I think its a little near sighted and over-simplifying to say that os x is not 64 bit.
To jump in here...
Tiger is _not_ fully 64bit, and NT aren't the only developers having problems with it either... As long as the GUI isn't 64bit, it will be very difficult to create a 3D app with integrated 64bit rendering capabilities (plus it will wase ressources - what message passing? Are you kidding? Pass millions of polys from a 32bit task to a 64bit task to render? You might as well switch to PRMan and Maya if you want all the comfort of a command line renderer).

Also, so far, neither Apple nor Microsoft have shipped their 64bit OS, Tiger ain't ready yet, and nor is XP64.

Sorry, but you're blaming NT for not living up the hype that Apple have generated. Even 3D companies much "closer" to Apple (as in: Appering at Keynotes) report of the same problem.

Cheers,
Mike

eblu
01-26-2005, 09:01 AM
Light, I've never wanted an integrated renderer. I think its a mistake to build one. Its a design nightmare to start with, and it becomes increasingly more difficult to support, as you upgrade the app.
in the real world, what happens to integrated renderers, is that they get ignored, and get old, they are difficult at the very least to work with, and they don't offer any benefits over command line renderers. If newtek is pushing the idea that they don't have to save an intermediate file to render... thats plain BS. Lightwave is a madhouse of insane workarounds for render glitches, Network render glitches, and caching problems. Newtek lead the way a long time ago with renderers, they broke trail in the design of a 3d renderer, but time, and a fear of hurting the magic in the renderer destroyed that lead, they didn't grow with the rest of the industry and now they are in danger of letting the technology fall apart. the best renderers today, are dedicated, command line tools. And in this case, 'best' is used to refer to tools that are the most flexible, stable, lean, and massively extensible. Lightwave's "command line network rendering package" is lightwave itself without the GUI. Thats backwards.

I wasn't blaming anyone for anything. I was pointing out to beevee, a couple of bits of information he obviously didn't have, and generally getting behind the "other things" that should be more important to Newtek, such as optimizing for the g5. I think a 64 bit Mac Lightwave without actually doing some real optimization is a bit like getting the cart before the horse, it's going to have a zero net effect, and I might add... that this is exactly what apple says... 64bitness is a nice marketing gimmick, but real speed comes from getting to know your Shark.

http://developer.apple.com/tools/sharkoptimize.html

Lightwolf
01-26-2005, 09:16 AM
Light, I've never wanted an integrated renderer. I think its a mistake to build one. Its a design nightmare to start with, and it becomes increasingly more difficult to support, as you upgrade the app.
Eblu, ain't it funny then that other apps lean more and more _away_ from that design, by integrating the renderer more closely (like XSI and mr - no temp files, they share the data directly - If you see mr as being a leading renderer)? And the closer we get to FPrime style rendering, the close the renderer will have to be to the app...

Can you imagine an OSX 64bit LW with FPrime?
LW - core (scene database) 64bit
LW UI - 32bit
FPrime Renderer - 64 bit
FPrime UI - 32 bit.
and all of these communicating?

Whatever happened to clean and simple system designs, I thought Apple was smarter than M$ in that respect. Oh well ;)

Also, mind you, LW does have both, since lwsn is basically layout sans GUI but with a command line interface (and it would be nice if it supported other scene formats too ... once it gets updated).


I wasn't blaming anyone for anything. I was pointing out to beevee, a couple of bits of information he obviously didn't have, and generally getting behind the "other things" that should be more important to Newtek, such as optimizing for the g5.
...But that has zero zilch to do with 64bit. Optimizing for the G5 is something different. Currently you can blame the CodeWarrior team for not supporting the G5 fully (heck, Maxon are patching their CineBench code by _hand_ for G5 optimizations out of the same reason), and NT for not porting over to XCode yet and breaking all plugin interfaces in the process.
I'm sure one the XCode port is done, you'll all see more G5 performance (and, who knows, they might use IBMs compiler too). I'm quite sure that the dev team know how to use a profiler, and know how to tune a compile for performance (which is only the last straw anyhow, the difference in total runtime with different optimizing compilers is around 15%-20% overall).

Cheers,
Mike

ackees
01-27-2005, 03:12 AM
I know this is a crazy statement but I wish NT would just say when they will have true Mac optimization, in 9? in X? They have been very quiet about their mac plans, they have not come out at a trade show and ‘shown off’ the exciting mac developments they have in the pipeline.
The thing is I learned long ago not to upgrade until you upgrade your computer, you reach a critical point where a number of packages need the hardware upgrade (I am involved in publishing, video, multimedia, and 3D) because they are making use of the new features and performance, but some apps cannot keep up and do not make use of new technologies on a particular platform, in that case you switch, you have to.
Example Quark express could not keep up on the switch to G4 and OSX so I switched to Adobe Indesign and so did many other people leaving Xpress in a bit of trouble. They have changed their tune lately, all the talk about Mac users being only 4% of users and not wanting to waste development resources on such a tiny minority changed when they started to hurt financially.
There has been a lot of talk about NT making a truly optimised Mac LW but it just does not seem to happen, will it ever happen or are Mac users destined to be the poor relatives with NT? Can any of the more experienced users give an estimate at about what stage NT can achieve this, six months, a year, never?

BeeVee
01-27-2005, 03:27 AM
I think you'll find the reason there has been a lot of talk about NewTek making an optimised version of LightWave for the Mac is because people here have been talking about it. NewTek released a statement about moving to XCode on the 1st June 2004 (read it here: http://www.newtek.com/news/releases/01-06-04b.html) and has been working on it since. Changing the codebase for an application isn't a trivial job and it will take time. In the meantime, there has been other progress with LightWave - we've had version 8, 8.0.1 and 8.2 - so it's not as though the only job LightWave's developers have had is to convert to XCode.

B

Ade
01-27-2005, 03:53 AM
Steve Jobs IS bias towards Maya.
I dont know why, it must be an image thing.
I dont know if there are any features Pixar needs to make their films that are Maya specific, actually after watching incredibles...SSS was very apparent.

Lightwolf
01-27-2005, 04:01 AM
Steve Jobs IS bias towards Maya.
I dont know why, it must be an image thing.
I dont know if there are any features Pixar needs to make their films that are Maya specific, actually after watching incredibles...SSS was very apparent.
Well, since Pixar use their own renderer, which has a good Maya interface, I'm not surprised. Then again, Pixar renders of intel currently...

Cheers,
Mike

Captain Obvious
01-27-2005, 04:40 AM
If we disregard the 64 vs 32-bit mess for a bit, I would just like to point out that a "command line renderer" can be just as integrated with an application as one that is fully tied together with it. Hell, you could use AppleScript and an image object to tie them together seamlessly! I don't think there is something that says you have to have a temp file, either. Theoretically, the renderer should be able to load the scene directly from the main application's memory.

There are, in OS X anyway, quite a few applications that do things like this seamlessly. Proteus uses "command line utilities" directly, and probably sends commands to them via AppleScript. It's 100% seamless, and you can even see them in Activity Monitor or top (speaking of which, I'm pretty sure Activity Monitor is just a graphical front-end for top). Both Pages and OmniWeb use command line utilities for some tasks, and it's all tied together perfectly.

There is nothing that says a command line renderer can't be used in real-time, seamlessly. (Like FPrime, I suppose.)

Lightwolf
01-27-2005, 04:45 AM
There is nothing that says a command line renderer can't be used in real-time, seamlessly. (Like FPrime, I suppose.)
Well, except for the fact that you still have to shove tons of data around in memory, unless both apps can share the same memory space, which is a b*tch to code.
This is something FPrime does as well, since it seems to copy the geometry, but it can do that within the context of LW, and not as another process, which is a different beast.
After all, it did take XSI a couple of revs to get mr to render scenes natively, without any file-/memory based data pushing operation.

Cheers,
Mike

Captain Obvious
01-27-2005, 05:00 AM
Well, except for the fact that you still have to shove tons of data around in memory, unless both apps can share the same memory space, which is a b*tch to code.
This is something FPrime does as well, since it seems to copy the geometry, but it can do that within the context of LW, and not as another process, which is a different beast.
After all, it did take XSI a couple of revs to get mr to render scenes natively, without any file-/memory based data pushing operation.

Cheers,
Mike

Yeah, the memory shuffling would be a problem... Maybe not so much for final renders, or scenes that are fairly simple, but if you're going to have a real-time renderer (FPrime) on a big scene, I suppose it's a major issue. So, how does one make two tasks share memory? :p

Lightwolf
01-27-2005, 05:12 AM
Yeah, the memory shuffling would be a problem... Maybe not so much for final renders, or scenes that are fairly simple, but if you're going to have a real-time renderer (FPrime) on a big scene, I suppose it's a major issue. So, how does one make two tasks share memory? :p
Well, the larger the scene, the larger the issue. Can you say 64bit? ;)
Two tasks sharing the same memory would be using OS functions, and this can be hard if you mix 32 and 64 bit. Actually, going from 32 to 64 bit is no problem, because the 64bit app will be able to reach the memory the 32 bit app uses, the other way around is harder. Also, if the 32bit app has to be able to keep the whole scene in memory as welll, you'll still have a limited scene size, despite the renderer being 64bit capable.
The only way around it would be a 64bit core that does everything _but_ the GUI, which means it would need to communicate with the 32bit GUI for every openGL display call and such, a major re-design.
And, in the end, if the renderer is designed as, for example, a shared library, it doesn't matter if it is being used by a command line front-end, or integrated into the main app (XSI is using a similar approach).
Cheers,
Mike - now what was the topic again? ;)

ackees
01-27-2005, 06:34 AM
I think you'll find the reason there has been a lot of talk about NewTek making an optimised version of LightWave for the Mac is because people here have been talking about it. NewTek released a statement about moving to XCode on the 1st June 2004 (read it here: http://www.newtek.com/news/releases/01-06-04b.html) and has been working on it since. Changing the codebase for an application isn't a trivial job and it will take time. In the meantime, there has been other progress with LightWave - we've had version 8, 8.0.1 and 8.2 - so it's not as though the only job LightWave's developers have had is to convert to XCode.

B
So what is the timescale for this, when is it 'likely' that we will see full optimisation?
This timing is critical, it is not a case of ‘wait and see, trust us we know what we are doing’ anymore. We need firm dates, even if these dates are missed, you still get an idea of progress.
PS. I love the tek discussion, who cares about 'on topic' when it's so informative.

Lightwolf
01-27-2005, 06:52 AM
PS. I love the tek discussion, who cares about 'on topic' when it's so informative.
:p :D I'm glad you see it that way...

Cheers,
Mike

ingo
01-27-2005, 10:15 AM
..........Mike - now what was the topic again? ;)

The question is whether we are 64Bit and Lightwave optimized. So can you work in 64Bit mode, means handling the mouse and keyboard twice as fast to get optimal 64Bit performance ?? Or are you still working only 32Bit ?? Who knows ;)

Lightwolf
01-27-2005, 10:18 AM
I'm 8 bit externally, and 128bit internally, if that helps any ;)

Cheers,
Mike - off home after this stupid remark :eek:

Captain Obvious
01-28-2005, 04:12 AM
Forgive my lacking programming knowledge, but how big an issue is it to have a 32-bit task communicating with a 64-bit task? If you were to have the entire core of the application 64-bit, but using a 32-bit GUI, for example.

Lightwolf
01-28-2005, 04:21 AM
Forgive my lacking programming knowledge, but how big an issue is it to have a 32-bit task communicating with a 64-bit task?
Hi Cpt. Obvious,
no reason to apologize. :D

Well, think of it this way:
You have a 32 ft and a 64 ft guy standing next to each other. Obviously the 64 ft guy can reach places the other guy can't (and in CPU terms, his reach is 4 billion times as large as that of the 32 bit guy).
Now let's say they want to pass each other, erm, well, a beer ;)
If the 32bit guy holds it, the 64bit guy can get it no probs at his leisure.
If the 64bit guy holds it, he has to make sure that it is within reach of the 32bit guy so the smaller guy can have a sip.

So basically, it means the larger guy has more to do to pass stuff to the smaller guy, and also, he can't pass him anything that is larger than the complete reach of the smaller guy (obviously).

Does that help a bit or was it too stupid?

Cheers,
Mike - the 6 foot 3' guy ;)

BeeVee
01-28-2005, 04:37 AM
Will you please stop discussing it and reach down to give me back my beer! I never agreed to be part of this "discussion" and I'm thirsty!

Short Ben

Captain Obvious
01-28-2005, 07:26 AM
Does that help a bit or was it too stupid?

Well, I wouldn't mind something less dumbed down. I know a little about programming... ;)


Who doesn't want a beer, BeeVee?

Lightwolf
01-28-2005, 07:38 AM
Well, I wouldn't mind something less dumbed down. I know a little about programming... ;)

O.k. then, I hope I didn't offend you ;)

You basically have the problem of the 64bit app having to make sure that the memory (in our case geometry for example) passed to the 32bit app is actually accessible by the 32bit app, and not oustide of its 4GB adress range. This can be handled by the OS and some clever MMU (memory management unit) programming, but I'M not sure how this is handled in current OSes. This is also why a 32bit will never be able to utilize 4GB of Ram (in a real world scenario), because there still have to be memory locations available for the app to make system calls. After all, if the system happens to be outside of the 32bit space, how should the app call _any_ of the OS functions?

The other part is of course that the 64bit app can't hand over data that is larger than 4GB (or whatever the practical 32bit limit is), since the 32bit app couldn't handle it.
Also, care has to be taken with datatypes, since 32bit apps compile with 32bit pointers, and 64bit apps obviously with 64bit pointers. Passing around structures that point at something will thus fail as well...

And shared libraries don't work either, since they use the same adress space as the calling application. M$ currently has the problem (for example) of having a 64bit browser, but it can't run 32bit plugins, so there is no Flash support (hm, not such a bad thing may be ;) ).

Tricky stuff,

Cheers,
Mike - who hopes this explanation is a bit better, but please do keep bugging me ;)

Captain Obvious
01-28-2005, 02:27 PM
O.k. then, I hope I didn't offend you ;)

Not at all. :)


[...]

Hmm... Well, for the most part, a renderer won't be relying on more than 4 gigs of data at a time, right? I guess for really big renders, but you could simply disable the integration temporarily (have two renderers, very similar, one that's integrated and one that's completely stand-alone) for such situations, could you not? It's a bit more inefficient, but the actual renderer's code shouldn't consume a lot of memory, right?

The fact that Mac OS X can access more than 4 gigs of RAM right now should alleviate it somewhat too, shouldn't it? It's not, stricktly speaking, a 32-bit operating system. But I'm not sure if the actual OS X applications can assign more than 4 gigs... hmmm. Argh. Why, oh why, did I stop studying? My brain has steadily deteriorated over the past few years. ;) It's interesting, though.

Lightwolf
01-28-2005, 02:36 PM
Hi Captain,
Well, the command line app _can_ break the 4GB barrier, but no the GUI portion. So, your geometry and images might have to stay below 4GB (so that they can be passed to the GUI), but render buffers could use more (since they are only used by the renderer). On the other hand, once you think about LW, for example image filters, you'll see that the GUI part will somehow need access to those buffers as well, or you'll end up with a big mess.

Just a command line 64bit renderer would be o.k., but it would need 64bit plugins as well. And what should it render? I mean, if the part hooked to the GUI can only handle 4GB worth of assets, how would you want to assemble a scene that needs more than 4GB to render? Well, except for render buffers again (which only makes sense doing print-res renders, and in that case, it would be easier to re-write the renderer to render in scanlines and directly dump them to disk).

And while the OS can access more than 4GB of ram, that only means you can run more 32bit apps at their limit simultaneously (and, as I wrote before, you won't get a full 4GB of available RAM per app). Besides, that is nothing new, even certain windows versions did that on 32bit Xeons (with adress extensions, which all Xeons have, but not all motherboards support).

Still no excuse for not getting full 64bit support under OSX, and to be honest, I have no clue what Apple are doing. Linux for example has been running in full 64bit mode (on AMDs) for more than a year now, as a stable release...

As much as I like Apple for being innovative (sometimes), I resent them just as much for their unfounded hype (not that they're the only ones...).

Cheers,
Mike

Captain Obvious
01-28-2005, 08:15 PM
So why did they make it so craptastically complicated, then? I mean, they're not idiots, are they? ;) Is it for backwards compatibility purposes? I can see why Apple would want to be a bit careful about such things, since quite a few people are still pissed off about them abandoning OS 9...


Anyway... Another work-around, even more complicated! ;) Couldn't you have a "command line" application working behind the scenes in the GUI? The GUI exists to control the scene file, and sending simple control messages isn't very hard*. Theoretically, as long as the slightly less than 4 gigs of RAM is enough to handle the geometry, the Core could send dumbed down versions of textures and the like via some sort of messaging system. The Core has the full scene, with full textures/lights/shaders, and shares the geometry with the GUI in a separate task/memory space. On render, it simply uses the geometry from the GUI and the shaders/light settings/textures from the Core. The actual tools to, for example, manipulate shaders this way should be really easy to fix. Again, this is something even AppleScript could do. But the geometry sharing (well, either that or a very bloated application) and texture "down-dumbing" would probably be rather compex (you'd have to keep two copies of the textures, one for the GUI, one for the renderer, but if the OGL preview has, say, 256x256 textures, that's not a huge issue either)...

Or is sleep depravation getting to me? ;)


*:

tell application "LightCore" to add shader "fast_fresnel" to object "obj2" with settings "monkeystick: 59"
Or something such. That's not really the problem.