64 bits of half-truth?
Oops, looks like Apple got caught with their pants down. I was depressed enough by what I consider to be a fumble with the Tiger release, now this.
MAXON's dedication to integrating new technologies and providing users with the fastest workflow and rendering possible is evidenced in its outstanding support for multiprocessing, multithreading, Hyper-Threading and Dual-Core.
And now, immediately following availability of Windows' 64-Bit operating system, we are proud to announce the availability of CINEMA 4D in 64-Bit!
Note for Apple users
Even though the G5 processors of the Apple Power Mac series are 64-Bit CPUs, 64-Bit applications are not entirely supported by the OS X operating system. Only command line based programs can take advantage of the 64-Bit memory adressroom. Programs with a graphical user interface (GUI) can only run in 32-Bit mode. Therefore we can unfortunately not offer a 64-Bit version of CINEMA 4D for Macintosh. More information on this topic can be found here:
http://developer.apple.com/macosx/64bit.html
MAXON's dedication to integrating new technologies and providing users with the fastest workflow and rendering possible is evidenced in its outstanding support for multiprocessing, multithreading, Hyper-Threading and Dual-Core.
And now, immediately following availability of Windows' 64-Bit operating system, we are proud to announce the availability of CINEMA 4D in 64-Bit!
Note for Apple users
Even though the G5 processors of the Apple Power Mac series are 64-Bit CPUs, 64-Bit applications are not entirely supported by the OS X operating system. Only command line based programs can take advantage of the 64-Bit memory adressroom. Programs with a graphical user interface (GUI) can only run in 32-Bit mode. Therefore we can unfortunately not offer a 64-Bit version of CINEMA 4D for Macintosh. More information on this topic can be found here:
http://developer.apple.com/macosx/64bit.html
Comments
That's probably not that easy to make for existing cross platform apps though.
blaming the GUI for 'forcing' it into 32-bit is lame-o.
GUI interaction shouldn't be in the same process as computationally intense operations. Besides GUI responsiveness issues, it makes maintainance a real bitch.
Originally posted by dfiler
This seems more like an admission that cinema 4d's codebase is a complete mess. A cleanly architected program could easily split 64bit computations to a background process.
GUI interaction shouldn't be in the same process as computationally intense operations. Besides GUI responsiveness issues, it makes maintainance a real bitch.
phew i'm glad i'm not the only one that feels this way. edit: and thanks for putting what i was trying to say above in a nice technical way
i may not be a big shot coder but i've done some Flash actionscript here and there in the past several years... helping to teach a college class now...
i'm still figuring out how to tell students umm.. your code and .fla structure is just totally jacked, start again from scratch
it's art school though so i'm not gonna take it too seriously, it ain't a computer science subject on object-oriented programming or anything like that
the developer page puts it as succinctly:
"Once the 64-bit executable has been launched, communication between the two executables can be accomplished using one or more of the following strategies:
Simple message passing using the standard input and output pipes of the command-line task.
Message passing using a UNIX domain socket.
Shared memory.
Mach based IPC messaging.
Any of these strategies will work. However, you should use the simplest possible strategy for your application so that you can preserve future flexibility. For example, if you use a filesystem-based socket to communicate between the 32-bit and 64-bit executables in your application, you have the ability to later convert your application to use a TCP/IP client-server approach. This would let you run the 32-bit client on any Mac while communicating with a 64-bit server process running on a G5-based Xserve."
check it out, it even takes into account distributed computing needs, to a certain extent...
with cinema4D, it's an issue of software design and constraints on their code development strategy... and economics of course
______________
From http://www.cgtalk.com/showthread.php?t=240949
Two things come to mind, rendering in editor and codebase.
Being able to render in editor means it would be needed to maintain two completely different renderengines, one limited 32 bit for the editor and an unlimited for the 64 bit commandline.
Currently Maxon get's much of it's development advantage from having the same codebase for Mac and PC. If we were to create two seperately maintained codes (split 32GUI /64 commandline for Apple, combined 32/64 GUI for PC) this would slow down development and testing very much, not to mention it would be more error prone.
I'm sure Apple will move on to a completely 64 bit OS in the not to distant future. This would mean we had to do the work all over again and revert the process.
I'm sorry, i don't like the idea of Maxon and it's customers paying the bill for this, especialy when the solution is half satisfactory at best.
____________
If anyone comes off looking like they don't know what they're doing here, it's Apple.
Actually it is YOU that looks like the one here with no clue. 2 posts and somehow we're supposed to believe your word versus Apple? AI isn't that easy pal.
I'm inclinded to believe what dfiler said more so than castigate Apple for quasi 64-bitness.
Personally 64-bit doesn't stand to help Cinema4D as much SMP savvyness and a fast 3D card. The apps that truly need 64-bit are likely to support CLI already because they are UNIX carryovers.
However if you feel like more of a man to pick and prod here then by all means beat your chest some more.
It doesn't neccessarily follow however, that their OS vendor has somehow done wrong.
Since the cinema4D codebase has mingled GUI and computational processing, Maxon and their customers will have to wait until OS vendors rewrite entire operating systems. If cinema 4D's codebase was cleaner, they could take advantage of cutting edge technology without having to wait for OS APIs to be completely reworked.
When an app's codebase is messy and intertwined, new features are slow in coming. APIs become set in stone and any slight tweak brings everything down. The best and worst aspect of popluar/legacy tools is that they are stable; kinks have been worked out. This leads many development houses to basically stop structuring their code for flexibility and maintainability. Instead, they focus on the quick fix, not on elegant and compartmentalized APIs. Once this happens... new features can't be incorporated unless they are 100% backward compatible...
It sounds like this is what is happening with cinema 4d. However, this is just a guess on my part so don't read this as a jab at Maxon in particular. At first glance, the shoe simply seems to fit.
Originally posted by Sao_Bento
First off, it's hard to defend the Mac OS's shortcomings by suggesting that every developer focus exclusively on the Mac platform. Secondly, Maxon make some of the most reliable and stable software I've ever used on the Mac OS. If anyone comes off looking like they don't know what they're doing here, it's Apple.
______________
From http://www.cgtalk.com/showthread.php?t=240949
Two things come to mind, rendering in editor and codebase.
Being able to render in editor means it would be needed to maintain two completely different renderengines, one limited 32 bit for the editor and an unlimited for the 64 bit commandline.
Currently Maxon get's much of it's development advantage from having the same codebase for Mac and PC. If we were to create two seperately maintained codes (split 32GUI /64 commandline for Apple, combined 32/64 GUI for PC) this would slow down development and testing very much, not to mention it would be more error prone.
I'm sure Apple will move on to a completely 64 bit OS in the not to distant future. This would mean we had to do the work all over again and revert the process.
I'm sorry, i don't like the idea of Maxon and it's customers paying the bill for this, especialy when the solution is half satisfactory at best.
____________
Bjorn (the clueless Maxon "QA" engineer) doesn't know OS X coding from a hole in the ground. Sao, if you believe him at face value you are just as clueless. There is no NEED for Maxon to create separate codebases for differing platforms, that would show maximum stupidity when your goal was cross platform from the start. While it is actually a bit more complicated than that, the cross platform decision explicitly means you have accepted added complexity and work to minimize unnecessary complexity through well engineered code.
This is really a business decision of abandoning cross platform code, not a technical limitation. The specific reasons given all fail the reasonableness test. Apple is not at fault, Maxon just decided to abandon a platform and try to hide it behind poorly reasoned incorrect technical mumbo-jumbo.
The real lesson here is never let the QA department "engineer" (talk about a PC feel good term there) do your engineering communication. There is a reason that person is in QA and not on the active dev team. Either they don't have enough experience yet, or you won't trust them with the code if they are experienced enough. Either way it shows poor judgment of the management to let them be in that position. And if management is that hosed up, they probably have other flaws too.
I am definitely clueless as I am not a software developer. The reason I posted this here in the first place was to see if someone could shed some light on this apparent shortcoming. I'm just a Mac OS user who's disappointed to find out that this thing they have been touting as 64 bit for a year is not really fully hatched. I mean how can Windows have incorporated this in a product no one's really heard of until the last couple of months?
Maxon's approach to their apps is based on 100% parity of features and behaviors between platforms. Anyone who's used Maya knows this is the better route, even if it makes things a little harder on the developers.
If you have to use a 32 bit GUI or a CLI just to get to the 64 bit part, doesn't this automatically break anything that needs interactivity between the GUI and the result? In a 3D app, you need to be able to interact with the scene to place all those giant textures and shaders and things that will need the 64 bits. But I can't see the result of the 64 bits unless I render it out and look at the result?
Originally posted by Sao_Bento
If you have to use a 32 bit GUI or a CLI just to get to the 64 bit part, doesn't this automatically break anything that needs interactivity between the GUI and the result? In a 3D app, you need to be able to interact with the scene to place all those giant textures and shaders and things that will need the 64 bits. But I can't see the result of the 64 bits unless I render it out and look at the result?
A very basic description between 64 and 32 bit is if you want to calculate a piece of information that has 33 bits of data then you need to send it twice to the cpu to process the data and the system will process a cycle to controll the flow(3 cpu cycles). A 64 bit system would process this in one cycle.
99% of the time you won't need this so a 64bit system will only be as fast as a 32bit or even 16 bit.
Don't forget we have had 64bit systems since 1991 (DEC Alpha).
If they had had that much of a performance increase then you probably wouldn't be using a mac or pc now.
Cheers,
Dobby.
Originally posted by Sao_Bento
[B]>>Bjorn (the clueless Maxon "QA" engineer) doesn't know OS X coding from a hole in the ground. Sao, if you believe him at face value you are just as clueless.<<
I am definitely clueless as I am not a software developer. The reason I posted this here in the first place was to see if someone could shed some light on this apparent shortcoming. I'm just a Mac OS user who's disappointed to find out that this thing they have been touting as 64 bit for a year is not really fully hatched. I mean how can Windows have incorporated this in a product no one's really heard of until the last couple of months?
Maxon's approach to their apps is based on 100% parity of features and behaviors between platforms. Anyone who's used Maya knows this is the better route, even if it makes things a little harder on the developers.
If you have to use a 32 bit GUI or a CLI just to get to the 64 bit part, doesn't this automatically break anything that needs interactivity between the GUI and the result? In a 3D app, you need to be able to interact with the scene to place all those giant textures and shaders and things that will need the 64 bits. But I can't see the result of the 64 bits unless I render it out and look at the result?
sao i would say don't take things too hard from the other appleInsiders, it's just that heaven forbid apple did anything wrong
nah seriously though, in this case, for example, if you have seen the music software program reason 2.5 run with 30+ racks and 'virtual cables' joining between all of them, plus reason handling midi and knob control, etc, etc,... you will KNOW what a brilliantly-coded Mac application is. extremely stable, runs beautifully on a g5, has almost never ever crashed on me. oh, and they make reason for PC too...
"If you have to use a 32 bit GUI or a CLI just to get to the 64 bit part, doesn't this automatically break anything that needs interactivity between the GUI and the result? In a 3D app, you need to be able to interact with the scene to place all those giant textures and shaders and things that will need the 64 bits. But I can't see the result of the 64 bits unless I render it out and look at the result? "
if you are talking about 3D i understand your concern, but perhaps you are buying into the hype? lets say giant textures and shaders to interact realtime with the scene, that's more a question of GPU, good openGL support and GPU VRAM... for realtime 3D scenes, the GPU is the focus, not a 64-bit CPU, IMHO
the 64-bitness would only come in handy if say you were doing renders and given the 3d program 6GB or more of RAM ~ in this case the "separating out" of the 32-bit GUI and the render process is not as bad as you might think, because like the apple developer website says, there is a way of "linking" the two quite well...
Maybe things have changed, but C4D used to be the most Mac-friendly 3d application around. They probably just don't want to hack up their code to make it work.
Originally posted by failedmathematician
Everybody here is piling on Maxon, but I wonder how many of you have ever used Cinema4D? I don't that much now, but I did a couple of versions ago. From the end users perspective there is nothing to suggest a messed up code-base. It was rewritten from the ground up just a few (five?) years ago. It is probably the most stable "sophisticated" app I have ever used. Features have been piled on at an amazing rate since then.
Maybe things have changed, but C4D used to be the most Mac-friendly 3d application around. They probably just don't want to hack up their code to make it work.
I'm with you, at the end of the day Tiger is not a kosher 64 bit OS, and I don't see why Maxon should all of a sudden spin off their codebase to keep Apple users happy, for what will be about a year or two until OSX does become a fully fledged 64bit OS.
Soon no doubt, we'll be seing 64bit Photoshop, and a hundred other 64bit apps for windows, and in most cases there wont be 64 bit OSX versions until OSX is fully 64 bit.
And BTW, Cinema is one of the most beautiful code bases around. It was completely re-written at version 6, when until then Cinema and Maxon were unknowns, and in less than 5 years has become one of the 3d Heavyweights. The reason for that is that the codebase is tight and highly modular, and have allowed Maxon to develop new features at a rate that doesn't happen in any other app. Ever.
Didn't you wonder 'WHY' Maxon is the first developer to release a damn 64bit version of a major application a few weeks after win64 was released?
It was just supposition based upon this Maxon QA employee's relatively clueless explanation.
There are valid business reasons for not currently making a 64 bit version for OS X. His justifications don't touch on these and somewhat misrepresent the development issues involved.
Originally posted by failedmathematician
Maybe things have changed, but C4D used to be the most Mac-friendly 3d application around.
Interesting, as it was originally an Amiga application.
(hmmn, that sounds like I'm taking the piss, I'm not just found what you said interesting)
I'm definitely unclear on exactly where the advantages come in, but it's not unusual to have a single texture map that 2+ GB, and that's only in 8 bit per channel colorspace, so that stacks up pretty quick - having more RAM available would be a benefit in itself. On the Maxon site, they have an example file containing a scene with 50 million polygons. It takes 7.2 GB of RAM to open it.
I guess, ultimately, my point was that *technically* the Mac OS is 64 bit, but in practical terms, it's not up to par with the 64 bit version of Windows. This is a specific example of Windows users having an advantage not available to Mac users. I'm used to Apple products exceeding my expectations (in most cases), and it seems out of character for Apple to have something they've been talking up for over a year turn out to be only semi-true.
edit: I see there's a pretty detailed thread about this at Ars. It addresses many of the topics and misunderstandings in this thread.
____
Yes, Cinema 4D began on the Amiga. It is now an integrated part of Sony Pictures workflow for creating matte paintings. It was also used on matte paintings in the current Star Wars movie. It's currently the leading application in designing "motion graphics" for television and movie title sequences.
As a company, Maxon is generally a pleasure to do business with. Their .X free upgrades often contain more new features and improvements than most company's full version upgrades. Anyone who's tried to do serious 3D work on a mac will appreciate dealing with a company who doesn't consider you a third class citizen because of your OS choice.
____
Originally posted by Sao_Bento
...I'm definitely unclear on exactly where the advantages come in, but it's not unusual to have a single texture map that 2+ GB, and that's only in 8 bit per channel colorspace, so that stacks up pretty quick - having more RAM available would be a benefit in itself. On the Maxon site, they have an example file containing a scene with 50 million polygons. It takes 7.2 GB of RAM to open it.
I guess, ultimately, my point was that *technically* the Mac OS is 64 bit, but in practical terms, it's not up to par with the 64 bit version of Windows. This is a specific example of Windows users having an advantage not available to Mac users. I'm used to Apple products exceeding my expectations (in most cases), and it seems out of character for Apple to have something they've been talking up for over a year turn out to be only semi-true.....
i would have to admit that if we are talking about a 3D scene that requires 7.2GB of RAM
Moving the GUI to 64 bits is the 20% of the remaining problem that will take 80% of the work. Cocoa might be (relatively!) easy to drag into the 64-bit world, but Carbon will be a real challenge.
Apple is busily replumbing the interface code anyway, in preparation for the transition to resolution independence. I suspect that 10.5 will be the first Apple OS capable of running purely 64-bit applications. Maybe they'll roll out 10.4.5, instead (a paid upgrade, natch), but something tells me it'll be near the Longhorn rolllout.
As much as I understand the original poster's frustration with the situation, this is exactly the kind of transition that you have to nail the first time, or you're in for a world of grief. The implementation can afford to be a bit flaky right out of the starting gate, but the frameworks and APIs have to be clean and extensible, because Apple and all of their developers will be stuck with them for years afterward (even if Apple breaks and replaces the APIs, they'll be around as legacy).
I'm sure that Maxon is not pleased about this situation. C4D has done very well on the Mac. I'm sure that Apple isn't pleased about it either. But nevertheless, moving the GUI code toward 64-bit compatibility while maintaining backward compatibility... that'll be a project. It's not something Apple can or should take lightly.