Zlogger - Substance Boy

Some of the tools I've written allow a user to check out chains of files- like Maya files as well as any exported FBX files and their unity metadata etc, all in one nice pass. This is great, but it has one annoying side effect. If the user presses the button twice the files are added to another change list, but the one they were just in stays there, empty. Press it a number of times and suddenly you have an army of zombie phantom changelists whose only purpose is to clutter up your pending list and annoy you.  I have been using the P4Python API and found it to be... well... its kinda crap. It would be great if it had a 'delete all empty pending changelists' function, but it doesn't seem to. So I wrote one of my own.  Beware! If you don't like hacking output out of strings the following code will make you cringe...  There's my target... import subprocess """Get a list of changelists from the command line. Try to delete them (will delete if empty)...

Its been pretty well established that you can send a .jsx file to Photoshop using a subprocess call in Python. The tricky part is then getting Photoshop to send some information back. This is my awesome hacky method of passing information from Photoshop to Python. It relies on being able to write to a temporary text file from Photoshop and then reading that information back into Python. This method relies on actually being able to write data to disk... if that's a problem I suspect you could do the same to the console standard output and get the same results... somehow? Maybe? Because writing to the disk was not a problem in this situation, I went with a temp file solution. The only kinda tricky part was making my program wait for the return value to be passed. Subproces.call() returns a value of 1 or 0 from the shell, but this only indicates that the program successfully (or not) opened. Its highly likely that whatever script you passed to Photoshop as part of the Subprocess cal...

Stuff is happening... After a little while in the field it came to be pretty apparent that the win32com module  can't  be relied upon to consistently work on everyone's machines. I spent a good amount of time trying to work out why , but came up with no solution that worked consistently on everyone's workstations. Errors like ('Member not found, None, None) would constantly pop up in their debug feedback, but not on mine. Talk about frustrating. So I got pretty annoyed and just ripped the win32com components out.  This was a pretty big undertaking, because apart from the GUI, win32com stuff made up about 80% of the remaining code. The P4 functionality wasn't touched, because its operating through it's own native API.  The solution: Photoshop Automation without win32com! The solution I went with was to write a wrapper around the JavaScript equivalent of what I was using the win32com module for. Each of these commands would be put into a list, which is then compi...

Zbrush, one hour. Felt like doing something a little more natural looking. Kinda feel I could have pushed the character a little further... maybe I will later. Its a happy/bored bear...

It might not be the absolute best solution, but I have been able to put into practice my idea of storing the tool settings in the PSD metadata, and it actually works pretty well. The current setup works like this: On export, go through a dictionary of controls inside the GUI and check the settings.  Store each object name and it's setting as a text block with easily splittable characters. For this I chose to use ~ and | as neither of these are used for windows file or directory names.  Write this text block to the PSD metadata.  Meanwhile, in the export, use the GUI's current settings to determine output locations, formats and files to include.   To reload the settings: A background thread is constantly listening for any changes in the current active Photoshop document.  If the name of the document changes, it automatically kicks off a function that reads the metadata out of the active PSD and splits it into objectName, setting value pairs.  If no data is f...

We are now getting Perforce. Oh how I  missed thee Perforce! And what a fantastic opportunity to revisit my favorite pet project, Texture Monkey! Be be honest, I'm kinda sick of re-writing this tool, but I've got it to a point where it meets a couple of extra prerequisites that it was sucking at before, mainly: It's written at a point where I actually feel I can competently write functional and readable code.   It's UI uses the QT framework. Which it MUCH nicer to work with than the previous WX.  It's been built around the premise that it  should easily be portable across projects without having to change any of the source code- provided afew assumptions about project structure are met.  It does more than texture exporting, and now supports Perforce integration as well.  Most importantly, it is written in a modular fashion, and can be expanded upon or cut back without too much trouble.  Now with extra stuff! Behind the scenes: It stores and loads tool ...

I want to save some tool specific information about a PSD file, but I don't want to have another pesky metadata file floating about to bloat my source texture folder. Luckily, the PSD file format supports writing custom MetaData within it, which is perfect for what I want to do. In this particular example, I want my tool to be able to remember which folder the flattened image associated with this PSD will eventually be put into, the format the image will be in and the resolution. There are many fields you can write to, but I have chosen to write to the Instructions information, because that just makes the most sense. Usually in Photoshop, you can see this fields available by going to the file info panel and going to the advanced tab: In Python, we can access and write to the PSD's metadata very easily. import win32com.client.dynamic as w32dynamic w32 = w32dynamic.Dispatch psApp = w32('Photoshop.Application') doc = psApp.activeDocument # When I pull this info out of the ...