Welcome to our community

Be a part of something great, join today!

Register Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Smoke on MAC is here!!

Lucas Wilson said:
It's not the only reason, but it's certainly the one that makes all other points useless to discuss.

Lucas
Click to expand...

Do you know of any limitations in the method that Smoke has used to implement SDI out?
 
Mark L. Pederson said:
One year from now you will have a more powerful tool with more features for a FRACTION of the price of Smoke on a MAC. I PROMISE. That's all I can say without getting sued. But that being said, I think there's lots of folks who can make some good ROI right now with the new SMOKE.
Click to expand...


hmmm ... some Eastern wind whispering? :wink5:
 
Andrae Palmer said:
Sheila Santos (visual technologies team lead at Autodesk) in the FXGuide interview, spoke of using OpenGL FBO (Frame Buffer Object) to emulate graphics overlay planes. She stated that this new emulation technology will allow for more Autodesk products to work with cheaper video cards that do not have a hardware overlay plane. This will be true for the Linux and Mac platforms. So the work on translating Smoke to Mac will actually pay off in allowing cheaper video cards to work with these high end applications. I'm happy to hear this news.
Click to expand...

I think this was more a result of Smoke and FFI being based on an ancient code base. All of the other Autodesk products had moved to emulated overlay planes years and years ago. Requiring a Quadro board and hardware OpenGL layers went out of style like 10 years ago.
 
digitalfx said:
selling Flare to non-Flame owners would be a colossal fail...I just cant see this happening.
Smoke makes sense...especially when you consider that its not really competing with the Smoke 2K system, which is still only linux and hardware dependent.
Click to expand...

then the price drops back at the beginning of this decade of maya and co were colossal fails as well, right? I mean what about those people who paid 100.000 dollars just months before maya unlimited was reduced to 35 K dollars or so? in my humble autodesk should bring flame, flint and inferno to the masses as long as they still has an advance over nuke which made and makes insanely huge steps in each release...
 
digitalfx said:
selling Flare to non-Flame owners would be a colossal fail...I just cant see this happening.
Smoke makes sense...especially when you consider that its not really competing with the Smoke 2K system, which is still only linux and hardware dependent.
Click to expand...

Sheila Santos said there is no Smoke 2k or Smoke HD systems anymore. There is only Smoke and Smoke Advanced. The main difference between the two being Batch. Smack can work with 8k, 4k, 2k, HD, SD, etc. Smack is completely resolution independent both for input and output. Smoke on Mac maintains the same feature sets as Smoke on linux except for RTD which they are working on.

Sheila Santos said:
Daryl – there’s no resolution restriction. You can mix 8K with SD in your timeline if you want. The linux products used to be called Smoke HD and Smoke 2K but now their just Smoke and Smoke Advanced with the difference being Smoke Advanced has Batch, a node based effects pipeline. Smoke for OS X is similar to Smoke (no Batch). The differences are basically due to things we couldn’t port easily. For instance the Linux Nvidia graphics cards support SDI output but the same cards on Mac don’t. We use the SDI out to support RTD and broadcast preview on Linux. On the Mac we were able to get broadcast preview working via the AJA Kona card but we couldn’t get RTD (Real time deliverables) working for version one. So no RTD on the Mac (for now!).

Comment by Sheila Santos — November 20, 2009 @ 10:18 pm
Click to expand...

http://www.fxguide.com/qt/1717/fxguidetv-smoke-on-mac/comment-page-1#comment-5189
 
Very informative responses from Sheila Santos at Autodesk to some questions posed to her in the comments section of FXGuide TV:

Sheila Santos said:
Ares – as John pointed out, preview is in SD and HD. That was a big chunk of the porting work, getting enough performance for 2 streams HD (disolves) on the preview.

Philip – like Andrae pointed out, there’s no restriction on file based output. Of course output to tape is limited to video resolutions.

Andrae, good question about the hardware overlays. You’re right, all the Nvidia Quardro FX cards (5600, 4800, etc) support hardware overlay. The Linux and Windows drivers let you access this but the Mac drivers don’t. Hardware manufacturers like ATI and Nvidia write their low level graphics drivers and Apple puts their OpenGL, Core Graphics and Core Video layers on top of that. Apple is very stringent with their graphics interface – see their Human Interface Guidelines for details: http://tinyurl.com/ybnp85b. High end features like overlays and SDI output are not supported by Apple because they want to give a consistent user experience regardless of your hardware.
Click to expand...

http://www.fxguide.com/qt/1717/fxguidetv-smoke-on-mac/comment-page-1#comment-5189

I have posed some more questions to her regarding how her team was able to triumph over the SDI performance issue. I do believe it is related to their emulation of hardware overlay planes... I've posed direct questions to her regarding this.
 
Etienne a member of Sheila's team had these responses to my questions:

Andrae – Having worked in Sheila’s team since the beginning the Mac project let me try to clarify a few points.

As Sheila said, the emulation of hardware overlay was done to overcome the fact that the Mac OpenGL driver doesn’t support them. It wasn’t done for a performance reason and doesn’t really gives us any performance gain.

Realtime preview out the the KONA SDI is possible for two main reasons. First, both the Quadro FX 5600 and 4600 are PCI-E second generation cards which give an improved transfer performance. Second, we spent a lot of time improving our code to make sure that we read and write from both the Quadro and KONA cards as efficiently as possible.

I hope it clarify things.
Etienne
Click to expand...

Now I'm wondering if all they had to do was make their code more efficient then why can't Scratch be on the Mac? If the SDI issue was one used to reason why it couldn't be on the Mac.
 
Andrae Palmer said:
Now I'm wondering if all they had to do was make their code more efficient then why can't Scratch be on the Mac? If the SDI issue was one used to reason why it couldn't be on the Mac.
Click to expand...

"All they had to do?" Do you have any idea how much R&D time it can take to optimize code for real time performance when the operating system and hardware manufacturer isn't helping you, and when their philosophy is to basically not have you do it in the first place? Not to mention the fact that Autodesk is one of the largest software companies in the world, and Assimilate is, well, not. A porting effort is a very, very major undertaking no matter how much companies like Apple want to convince you otherwise. And more so when real time video performance at high resolution is required. Frankly, I would ask Apple - who does understand the operating system and the hardware intimately - why they haven't been able to do the same thing for their own products - Color, for instance.

I'm not making up answers for Assimilate, but frankly, your statement is surprisingly naive for someone whose posts here seem to indicate a pretty good understanding of these things. Personally, I would much rather see them directing their efforts towards making their new versions more useful by doing things like supporting more file formats (MXF, Arri Raw and Phantom .cine come to mind...) and multiple video tracks, as well as making the current features even more solid, than undertake a porting project whose only real purpose would be simpler support of Apple proprietary codecs.
 
M Most said:
Personally, I would much rather see them directing their efforts towards making their new versions more useful by doing things like supporting more file formats (MXF, Arri Raw and Phantom .cine come to mind...) and multiple video tracks, as well as making the current features even more solid, than undertake a porting project whose only real purpose would be simpler support of Apple proprietary codecs.
Click to expand...

Yup.

But IF Assimilate would just make a command line - "render only" version for MAC - they would sell a TON of those. I'd buy that tomorrow. Work in Scratch (on Windows) - need ProRes - open up the project file on the MAC render-only node and render ... but what the hell do I know ...
 
Andrae Palmer said:
Now I'm wondering if all they had to do was make their code more efficient then why can't Scratch be on the Mac? If the SDI issue was one used to reason why it couldn't be on the Mac.
Click to expand...

Well, Assimilate aren't exactly alone...

Think Speed Grade... Or even Color...


EDIT:
Mike beat me to it... -:)
 
Mark L. Pederson said:
Yup.

But IF Assimilate would just make a command line - "render only" version for MAC - they would sell a TON of those. Work in Scratch (on Windows) - need ProRes - open up the project file on the MAC render-only node and render ... but what the hell do I know ...
Click to expand...

That's a good suggestion. A number of us have been asking for a command line driven render node for some time now. Making that cross platform might be one solution. Another possibility is the approach that Filmlight took, which is to use some existing code on the Mac side (after all, Assimilate did have something to do with Redcine.....) and write a communications protocol to drive it from the PC side (in Filmlight's case, on Linux, but it could just as easily be Windows) to send whatever data is required. The Mac would need to have an acceptable Nvidia card, but that's really not a big deal.

My point is that a full GUI port is, to me, not necessary to accomplish what is really needed (namely, the ability to render using Mac-only codecs).
 
M Most said:
but frankly, your statement is surprisingly naive for someone whose posts here seem to indicate a pretty good understanding of these things.
Click to expand...

I really don't have a good understanding of these things... in that sense I am naive. I'm asking a bunch of questions all over the internet (some misdirected) to come to some type of understanding. What Autodesk achieved I thought was impossible. I didn't realize that coding alone could solve the problem. I thought it was an hardware issue and that Mac users were just left in the cold because of it. I was lead to believe this by numerous posts on here regarding the SDI realtime issue. If the coding for this was a major undertaking then I congratulate the team at Autodesk for surmounting the issue. Hopefully others can implement this solution and we can move on from needing 7 grand GPU/SDI cards.... albeit cost was not really the major consideration... platform was. I already have a top of the line Mac Pro... I was tempted to switch over back to PC just because of this issue.

Since SpeedGrade already exist on the Mac... hopefully they can put the time in to code the same solution. If no one else can do it... then hopefully Autodesk will port over more of their applications to Mac. :yesnod:
 
Having worked on staff at facilities that owned Fire, Smoke and Flame I think this is outstanding news.

Smoke is a very different animal to FCP, Avid, After Effects or any of the other systems mentioned in this thread. It's just not apples and apples.

For those of you writing it off due to its perceived lack of RED support, please be reminded that not everyone shoots RED. The kind of client that would pay $900 (AUD) per hour in a Flame suite or $600/hour in a Smoke suite is not really that format savvy. Most of them (in my experience) are still shooting TVC's on 35mm. It's the small shops that are far more hip to RED. Agency jerks don't care about formats. They just want their decaf soy chai latte and catering sorted out while they duck off into the toilets to do a few lines. Either way, RED support would surely be on its way if not already implemented by official release. RED is the future why would Discreet ignore it?

I'm not saying this to start any wars... I use FCP, I use Avid and I have been on many jobs where Flame and Smoke via a traditional telecine/grade were the finishing tools. $15k plus maybe $10-15k for a souped up Mac Pro with Kona 3 is NOTHING compared to the current cost of a Smoke rig.

I can tell you now, after I invest in a RED camera system my company will invest in a Smoke on Mac. All network interstitials and promo's here in Sydney are done on Smoke. If I can get a piece of that pie at a price point the existing smoke facilities can't match I will be smoking $100 bills for fun in no time.
 
Kris Anderson said:
For those of you writing it off due to its perceived lack of RED support, please be reminded that not everyone shoots RED. The kind of client that would pay $900 (AUD) per hour in a Flame suite or $600/hour in a Smoke suite is not really that format savvy. Most of them (in my experience) are still shooting TVC's on 35mm. It's the small shops that are far more hip to RED. Agency jerks don't care about formats. They just want their decaf soy chai latte and catering sorted out while they duck off into the toilets to do a few lines. Either way, RED support would surely be on its way if not already implemented by official release. RED is the future why would Discreet ignore it?
Click to expand...

I agree. I personally prefer to work with image sequences most of the time anyway. And with short form commercial work you can hold about 2 tracks of 1080p for a 30 second spot in RAM let alone even needing to hit the RAID. Native RED is far more critical in long form editorial which isn't the first thing that comes to mind when I think smoke.

Especially since you probably are going to be caching your manipulated footage to disk anyway. It just means you'll start off writing it to disk one step sooner.
 
You must log in or register to reply here.
Back
Top