Migrating encoding presets from an older Premiere Pro CC to Premiere Pro CC 2017

loocas | miscellaneous,software | Tuesday, December 13th, 2016

premiere_presets

Adobe changed the folder structure for the presets files, again, which is a huge pain in the ass when migrating to a newer version of Premiere Pro, etc. Especially when the presets are not carried on automatically (as they should!)

Navigate to your current presets folder and copy all the presets you’ve got there into your clipboard.

Then navigate to this folder:

C:\Users\<username>\Documents\Adobe\Adobe Media Encoder\11.0\Presets and paste them there.

Done, now your presets will show up in Premiere Pro CC 2017 as well as in Media Encoder CC 2017.

Shotgun

loocas | Shotgun,software,technical | Tuesday, April 12th, 2016

Shotgun

I’ve done quite lot of work with teams using Shotgun, the production tracker, and I’d like to share some of my experiences, tips, tricks and how-tos in context of a Technical Director gluing everything together in a pipeline full of various tools using mainly Python and also MAXScript.

I hope to keep this section of my blog alive as much as possible, so, please, stay tuned. :)

Premiere Pro CC and QuickTime encoding error

loocas | software,technical | Wednesday, March 23rd, 2016

premiere_pro_dr_max

Have you seen this error while trying to export your project to a QuickTime movie?

Here’s a simple tip how to continue using this piece of shit of software on higher-end machines:

  • Simply open up the Task Manager
  • Search for the Adobe Premiere Pro process
  • Change its affinity in a way that you disable a few CPU cores for the process
  • DONE

That’s it. Premiere will, suddenly, magically, allow for QuickTime exports.

I hate this software so much…

Nuke 9.0 licensing shenanigans part 2

loocas | Nuke,software,technical | Wednesday, June 17th, 2015

As a followup to my previous post about the new licensing scheme in Nuke 9.0 and up, here’s another, little tip that might help you speed up Nuke launch times:

Watch for the port you’re looking for the licenses on. I know this sounds obvious, but I just recently had to restart my license server after a long time and suddenly Nuke started booting up very slowly. Not as slow as before (as discussed in the previous article), but noticeably slower.

After some investigative work on the server (read: I had no idea what was going on) I launched the FTL tool and ran diagnostics. Everything seemed OK at first, but then I noticed the service was running on a different port than what I had it setup in my environment variables.

After adjusting for this error, all runs as smooth as butter now once again.

So, just a heads up, keep an eye on the port you’re asking for the license on, it will find the license eventually, but it’ll take a lot longer than if you explicitly set the correct port number up.

Nuke 9.0 licensing and speed shenanigans

loocas | Nuke,software,technical | Wednesday, November 26th, 2014

nuke_studio_banner

If you’ve upgraded to Nuke 9.0 or even Nuke Studio, like I did, recently, you might’ve bumped into some licensing and boot-up issues with Nuke. So, allow me to share my experience with this upgrade.

First off, Nuke 9.0 is just fabulous. I’m really in love with the software, even though there are a few issues I’m having from time to time. So, after upgrading to NukeX and Nuke Studio 9.0 I also had to update my licenses and with that, the license server. I’m not sure whether The Foundry completely abandoned the FLEXlm license server, or not, but I transferred all my licenses to the newer RLM licensing scheme. With that came a few issues. The most notable one was that Nuke simply did not start up. Easy fix:

  • Stop the foundry FLEXlm server
  • Uninstall any older FLT software, completely, delete your old licenses, especially from the C:\ProgramData\The Foundry\RLM and C:\Program Files\The Foundry\RLM locations on your license server
  • Install the latest version of the FLT software
  • Run the FLT tool and drag-drop the newest license in there. It should install automatically for you.
  • Restart the RLM server

license_server_status

Now this worked. Nuke started booting up, but it took terribly, terribly long. I mean, Nuke 8.xx took about 2-3 seconds to check for the license on my server (via VPN) and boot up. Nuke 9.0v1 took over 20 seconds (!!!) to check for the license and even longer (!!!) for Nuke Studio to fire up.

Something was wrong and I wasn’t sure what. All I suspected was that my setup was acting up as I’m sure The Foundry would’ve done something about this if it were a bug.

And sure enough! I found the issue.

(more…)

Premiere Pro CC 2014 GPU accelerated previews on new cards

loocas | miscellaneous,software,technical | Sunday, August 10th, 2014

premiere_pro_cc_2014_splash

I’ve recently upgraded my GPU to a TITAN Black with 6GBs of RAM, which is awesome, however, Adobe does not “support” this card in its current CC 2014 version.

However, there is no reason this card should not be supported, it’s only that Adobe hasn’t tested the card yet and thus does not provide any support towards it. But, fear not, TITAN Black will render the GPU accelerated previews and everything just fine. You just have to force-enable it in Premiere (and the likes). Here’s how:

  • Go to your Premiere Pro CC 2014 installation folder, in my case: C:\Program Files\Adobe\Adobe Premiere Pro CC 2014
  • Shift + Right-Click in that folder in order to launch the Command Line, from the menu, starting in that folder (this tip is free of charge ;) )
  • Execute the gpusniffer.exe program and see what name of your card it lists at the top
  • Mine said “Renderer: GeForce GTX TITAN Black/PCIe/SSE2
  • In the very same folder, locate the “cuda_supported_cards.txt” file and open it for editing
  • Simply add your card at the end of the list. Do not include the “/PCIe/SSE2” parts, just the name of the card

Done. Now Premiere Pro CC 2014 recognizes the card for Mercury playback and uses the GPU for acceleration.

Note: If you rather own an OpenCL GPU, edit the “opencl_supported_cards.txt” file instead of the “cuda_supported_cards.txt”.

Migrating encoding presets from Premiere Pro CC to Premiere Pro CC 2014

loocas | miscellaneous,software | Tuesday, August 5th, 2014

premiere_presets

If you’re, like me, on the Creative Cloud subscription, you’ve most likely upgraded your applications to the CC 2014 version. Which is all fine and dandy, because your shortcuts and settings got migrated over or synced via the Adobe Sync feature, right? Wrong! For some, unknown, reason the media encoding presets in Premiere and Media Encoder did not get transferred over, so your most favourite and most used presets are just gone and you have to re-do them one by one again.

But fear not, my friends, there is a very simple way (not so obvious, unfortunately, because Adobe chooses NOT to share this info with anyone).

Simply go to your local user directory:

C:\Users\<username>\AppData\Roaming\Adobe\Common\AME\7.0\Presets

And copy everything from there to the new one:

C:\Users\<username>\AppData\Roaming\Adobe\Common\AME\8.0\Presets

Done, now your presets will show up in the Premiere Pro CC 2014 as well as in the Media Encoder CC 2014.

duberPython is available for download!

loocas | 3ds Max,dotNET,maxscript,Python,software,technical | Saturday, July 13th, 2013

duberPython banner

That’s right! duberPython is finally ready for it’s debut public release.

But that doesn’t mean it’s a fresh newb of a plugin. It has been used in high-end productions at studios such as Pixomondo or Orbit, etc. on feature films, commercials, full CG animations, etc.

duberPython came into life after a long search for a solution that’d allow us at duber studio have 3ds Max communicate and play nicely with other pipeline tools and DCC applications. duberPython was designed, mainly, to bridge 3ds Max and Shotgun (JSON API is fully supported!) and Tactic. I even wrote a dedicated Shotgun wrapper, so that you can call Shotgun methods directly from within MAXScript (available upon request), so that writing your studio pipeline tools is really, really easy and fun.

duberPython

The current version runs on the IronPython engine 2.7.3 and is compatible and has been thoroughly tested with CPython 2.7.3 (though, compiled Python modules are not accessible via IronPython).

Currently you can directly call Python code (via string parsing) from within MAXScript, or you can call Python scripts externally and pass it any number of variables for Python processing. The variables will get automatically translated to and from Python, so that strings are strings, booleans are booleans, arrays are arrays, etc. Even dictionary data types are supported in MAXScript (via Hastable dotNET objects)!

duberPython

So, do not hesitate, head over to python.duber.cz and give your full-featured 30day trial a go and if you find it useful, I’d be very happy if you purchase the full version for only $25 bucks, which is a bargain for what you get! (site licenses are available upon request).

By the way, the full documentation can be read here: python.duber.cz/documentation

Corona Renderer kicks ass!

loocas | 3ds Max,opinions,software | Tuesday, June 11th, 2013

Corona Banner

Have you thought that the market with renderers is full and thus there is probably nothing that could come up with something almost revolutionary to stir things up? So did I. But man, was I wrong!

Introducing Corona, the unbiased, CPU based renderer that will kick asses of even the most high-end and proven renderer on the market, such as VRay, finalRender or Arnold.

It’s still in its Alpha stage of development, but let me tell you, I’ve been using it for over a year and have done quite a few TV commercials with it without too much of a hassle.

Now, you can read more about the renderer on the official page, even download the full-functioning version and try it out for yourselves. So, I won’t go into how awesome, simple and brutally fast the renderer is, but instead, I’ll write a bit about how we used the renderer for a slightly different purpose than just final rendering.

SLS_RedCarPaint_Corona_02
(more…)

Repathing 3ds Max assets externally, command line utility

loocas | 3ds Max,software,technical | Sunday, March 3rd, 2013

Repath Max Assets cmd

Do you remember my post about repathing 3ds Max assets in the .max and .mat files without actually running 3ds Max? Well, I cooked up a little utility that can be run from the command line without any IronPython installed. You can use this simple exe file to repath or simply just list all your external asset paths inside your .max and .mat files, should you need to. And since it’s a command line utility you can run it from within your programs and catch the outputs or batch feed it data for processing etc…

Anyways, the syntax is pretty simple:

You need to call the program and then pass it a .max or .mat scene file. If you provide only that, it’ll list the file’s asset paths. But if you provide a -p parameter followed by a new path, it’ll re-path all the file’s external assets to the new location you provided. Unfortunately, there is no way for me (afaik) to distinguish what is an actual render output or RE output and what are texture or cache data inputs, so everything will be linked to the new directory at once.

Should you need any help, just call the program without any parameters, or with the parameter -h for help.

Download the program from here.

Next Page »

Powered by WordPress | Theme by Roy Tanck