Nathan Letwory explains the drop of QuickTime support in Windows Builds of 2.58 on BD conducted an interview with release-manager Natan Letwory on the drop of QuickTime support in windows builds of Blender 2.58:

Adding a pair of sentences to the announcement of the drop would have been sufficient to at least provide some rationale for the decision: QT is dropped because it is available only as a 32 bit library and PSD support is dropped because it is handled by QT library.

Still, I think the attitude about the replacement (write scripts to handle external tools, equivalent to go get lost, it is not our business) and the total lack of forewarning about the decision are highly objectionable.

So jpb06: if I got your post right, even though it is objectionable that it was dropped without warning, people with 64bit systems would not have been able to use it with a 64 bit version of Blender anyway?

If that’s the case, then the quicktime library would’ve been usable for less and less people using Blender because more are using 64 bit operating systems (either purchasing it, getting it with a new machine, or switching to Ubuntu), it may also mean they may be open to adding it back once a 64 bit version of the library is available.

People can have both the 32 and the 64 bit version of Blender installed, and therefore they can do most of the work with the 64 bit one and leave a few items done with the 32 bit one. Even with 2.5x out 2.49 has still its place for not-yet-ported functions. The situation is similar to the way I handle SketchUp -> Vue workflow: I use the 32 bit version of Vue to import SKPs into Vue VOBs and then switch to the 64 bit version of Vue for anything else (libraries for SketchUp import/export are 32 bit only).

The trouble is not to drop 32 bit functionality which is nowadays definitely legacy, the trouble is to do so without warning and without an assessment of the number of people affected to determine whether this stuff is to be implemented again with different tools.

The right way to handle this issue would have been to:
1 - post an official notice on that these functionalities were earmarked for removal and the rationale behind this decision;
2 - do some kind of poll to assess the number of affected users;
3 - schedule, according to the result of point 2, an appropriate development effort to reimplement stuff (or simply provide workarounds if the number of affected users was minimal).

I don’t think it would have been so difficult to handle stuff this way, I am somewhat astonished that nobody did so.

That’s not what was stated in the interview:-

For me the main reason was simply the incompatibility of the license of the SDK…
…Next to that, it was available only in 32bit versions of Blender…
…But the first reason simply outweighs any of the others.
It was dropped because the SDK license is incompatible with GPL, not because it is only available as 32 bit.

It is not really a big deal for me. I use Quicktime daily with Adobe products and when I render from Blender I render to image sequences anyway. Which is often recommended by many people on this board. Heck, Quicktime output from Blender on Windows never really worked right anyway until some very recent builds with 2.57-2.58.

Freedom… will it ever catch ?

I personally never worked with quicktime in Blender, even when I use the compositor and/or the sequence editor I always work with sequences. For final output to a container format I use Virtualdub, Avidemux and Adobe Media Encoder. I also use After Effects a lot for compositing and going to Quicktime from there is obviously very easy. Quicktime as a container format IMHO is not as usefull as for example Flash video or AVI so I wont lose any sleep over dropping it. I’ve made a habit of working with image sequences and only using video codecs / video container formats at the last step.

Never used PSD’s directly in Blender either, I always use PNG’s JPG’s or Targa’s. What is really the benefit in using PSD’s over any of the other file formats in Blender?

PSD is a very important file format in professional gamedev (for example)…
I always use PSDs…

Using Photoshop to create textures doesnt mean you need to support PSD directly. Photoshop can write to many file formats Blender supports. When I create textures in Photoshop my PSD files contain many different layers, adjustment layers, text, effects, etc. These features are not supported by Blenders import through Quicktime. You need to flatten / rasterize your PSD file and by doing that you’re better of using another file format that Blender supports.

for us on mac while qt works, I’m still wondering if 64bit version of the qtsdk is avail for public? or if the big corp are still hogging it.

As a source format, but never ever applied directly to the model! usually it gets changed to tga or png for applying to the model and then conversion to dds and mipmap settings are handled by the exporter (at least at Sony, EA and many smaller studios that I’ve worked with)

layered source(psd)—>flattened source(png/tga)—>modelling package/world editor—>game format (dds)

I don’t get the big deal anyway… quicktime container is still available from ffmpeg, Nathan said that finding an external lib to handle psd was on the cards though I really don’t get why anyone would want to use psd anyway… all it does is take up more ram and make your scene all bloated with all that layer data you can’t even access… A different story if you could use it as an output format with renderlayers -->psd layers, but that’s not what has been “lost” here…

I have to agree with abc on this one, I’m currently working on models for an Indy game, everything I’m doing is being done in Blender. The .PSD texture support is vital while painting textures externally in Photoshop.

To counter the argument “Use another file format such as [INSERT FILE FORMAT HERE]” just isn’t practical, Photoshop saves .PSD’s in 1-2 seconds for me at a 2048*2048 resolution without having to select any options. However if you try and save them in any other file format .PNG .TIFF etc you have to go through the options and then wait 20-30 seconds for it to save out (talking 100+ Layers here,) so I change a small detail on a texture and it takes about a minute to see the results…It’s NOT practical

You don’t have to flatten them, they do work.

In my experience, most people in Gamedev create actions for saving out TGA files that require multiple iterations and as such never use PSD files for anything other then a source file.
It then becomes a one click save or if you are feeling super efficient, you can assign it to an fkey too :slight_smile:

And how long does it take Blender to open the file with this huge PSD texture? Can you even run the game with such huge textures, and how do you evaluate the performance of the game assuming that you intend to use another format for the textures when you are done painting.

Are you talking about one or two textures in your entire game project that your working on this way? Because if not, maybe your way of working is NOT practical.

It seems like you move the problem to Blender. Still I would say that your case is more the exeption to the rule, if you make a habbit of creating 100+ layers in Photoshop perhaps you should try to optimize your workflow in Photoshop.

Please re-read the quote in regards to the time it takes to save these images out. If that WAS the case why does zBrush, Mudbox, 3D Coat, etc go out of their way to support .PSD’s? because its efficient during a texture development process.

I am wrong .TGA saving IS as quick as .PSD

When creating textures for games, most studios use PSD as a source file because it saves layers. For the final texture they use TGA or Tiff (in Crytek’s case), which are then imported into an engine and compressed (with dxt1 or dxt5). Regardless of if programs support PSD, they are rarely used as a final texture.
Setting up an action requires you to only to save manually once per texture type (which takes prob 1-2 mins for a whole set of Diffuse, Normal, Specular) after that its almost instant after click the action button. :slight_smile:


ahh, cool :slight_smile: (not cool that you were wrong, cool that you got a solution;))

As an alternative to Quicktime import it would be great if the windows builds of Blender would allow import of Avisynth scripts(by using Avisynth enabled FFmpeg builds), because with Avisynth scripting(+plugins) a number of great things can be done including importing Quicktime files. :slight_smile: