what about doing what metalliandy suggested in the first part of his post creating an action. and than instead of saving manually and having to reselect your options all the time you just use your action. Than its one click to save in Photoshop and blender will open faster and perform better as it won’t have to deal with huge psd files.
Just looking into that now, the macro’s are finicky and like to save filename_copy.tga randomly, but, I came across something called vTools which is a nice little set of scripts for dealing with .TGA files in Photoshop, I haven’t tested it yet but the scripts look very useful. http://home.insightbb.com/~jamestaylor/
vTools are great
Photoshop will add _copy because it automatically defaults to the PSD extension. To get around this, just change the format to TGA and then rename the file to something more specific, like Filename_Diffuse etc. The action will save the correct file name
They work really well yeah, just been trying them out and, tbh, this is no more of a faff than hunting around and finding out how you can get .PSD support in Blender, a good one for people on 64bit as well I guess. I’d still like .PSD support though, it is just easier to deal with but I’m not so paniced now though! :rolleyes:
Noooooooooo! I shall refrain from removing that
Here’s another game developer workflow that gets “crippled” (or at least disturbed):
The unity game engine can store and handle both .blend files and .psd files directly. It converts them internally to optimized formats and different sizes for different platforms. That way, you have the perfect workflow. Open the .psd files (which you have linked in the .blend file as the texture) directly from within unity, change something in photoshop while maintaining all layers and layermasks and layersettings, save, switch to Unity or Blender, done. Same goes with .blend files. Open, change, save, switch to Unity, done.
All the source files are stored in one place and are quickly accessible through Unity. No need to go to another folder and find the right psd file to edit and save a copy of it to another folder. Also, I can do easy backups of the whole project and don’t have to store/manage/backup psd source files externally from unity.
It was just pretty much perfect. Sure it will work without direct psd support, it’s just a step backward, so I guess I’ll keep working with 2.57 for as long as possible.
of course the PSD is not the final format…
but during the working there is a big slowdown to always flatten and save in other formats…
anyway, it is possible and very easy to read a PSD that has “compatibility” option on (so it contains the merged layers)… I think no need quicktime for this
Well… is not like the psd format is not documented anyways, altough the full documentation is only distributed with the full SDK (devs need to contact adobe directly).
There’s at least one GPL command line parser for the psd format and GPL converter to the xcf (read GIMP) v1 format, located at http://telegraphics.com.au/sw/
Maybe integrating these software to Blender can be a good starting project for some wannabe dev looking for a starter project… or maybe ask the original author can make some gears move… who knows.
I must agree with some comments about the PSD import usefulness.
For me PSD support would only make sense when rendering into layers / passes.
QuickTime as states is only a container system but one that works well on many systems unlike some windows formats.
Specifically some codecs are useful - so I am curious about how they want to make sure you can transfer files easily.
Not everybody wants to work with image sequences and share them - even when it has its advantage in some areas.
legal problems eh?
thank goodness i have a mac. i just need to upgrade it to 10.5 or get a 10.5 mac.
+1 Michael W, isn’t QT avail in ffmpeg? I often Mux my animations in Blender with a direct animation export instead of frame seq’s. so I would miss that (my edit suite doesn’t like frame seq’s.).
First, aren’t you on MAC?
Second, quicktime via the quicktime libraries was very half baked anyway… no audio, only a handful of codecs not to mention Apple’s artificial crippling of pro res to only be a decoder on anything but a MAC…(and not available in blender).
Third, quicktime, ogg/theora, avi and mpeg container formats are all still available in blender via ffmpeg, (though somewhat hidden in the UI behind theora)
And at least that way you get some audio support!
Open formats never get
much love lol!
Do you know how many useful features/patches fall by the wayside because of threads like this? Many features that would be shipped in commercial software don’t go in because they’re not good long-term solutions and await “proper” implementation of this or that…
Because of the enormous negative feedback when you try to remove (or no longer support) essentially buggy/broken stuff.
And it’s not like anyone actually made builds with QT anyway… it was always to hard/expensive.
I understand that communication upfront could have been better, the reason for me to answer a few questions on BlenderDiplom (since Gottfried thought of asking nicely). I kept the answer short and simple, so I thought it’d be easy and clear to understand.
What I don’t understand is what people don’t get in the part “the QT SDK license is incompatible with GPL”. Given as very first reason, so it’s easy to spot. We just simply can’t link, and shouldn’t have linked for all those years to the SDK.
What I also don’t understand is why people won’t accept that it is possible to write scripts (and thus have a very nice integration GUI-wise too) to do any necessary conversions. Isn’t the end result what matters here, and not what happens under the hood?
If, at this point of reading this reply, you still think I should re-enable Quicktime support, then I’ll be very sad. If you don’t get that, I suggest you reread the interview several more times and think about the answers and their meaning. Especially the first argument. I hope it will eventually sink in.
It’s understandable, of course. I think it’s more knee jerk reactions (myself included) when your workflow is being removed/altered, softer landing next time? The work arounds for this are fairly minor and after some digging it leaves little impact.
EDIT: Thinking about it, I’ll be happy to see the back of QT off my machine
QT here or there, I honestly dont really care what is being used as long as it can a cross platform format which has a lossless compression. We are working on OS X and Windows.
Ogg seems to support also a lossless video codec so this might be a good alternative to look into.
A lot of people swear by huffyuv for pc–>mac
I only used QuickTime very occasionally, but it is a very widely accepted format, and to drop it without any warning is going to tick people off.
Also, you have to take into account that a majority of users are not coders or scripters. I wouldn’t have the first inkling on where to start. They don’t know python, they don’t know scripting and they don’t know programming. Yes, if you are part of a team, you probably have someone who knows this stuff on-board and they can sort it out for you. A lot of people are working on thier own and they are going to be stuck. Just saying “Go code a script to fix it” is like saying to a Formula one driver “Go build yourself a new carburetor”.
If it is easy to fix, maybe you could drop a link to a tut or a work-around?