Sublime Text 2 is since some time my favorite code editor. I use it for everything these days, from Python and Amiga assembler to the code for this website. It’s polished, it’s elegant, and its API is dead easy to use for extending Sublime with custom functionality. I’m that geeky that I still fall in love with simple but beautiful applications.

Anyway, back to the subject, even though we are now getting a very robust and awesome Python implementation in LightWave 3D eleven, that goes above and beyond what we ever could do with LScript, I’ll probably still dabble around in LScript from time to time. At least when doing quick adjustments to older scripts that I don’t currently see any point in spending time to rewrite in Python.

So I’ve made my LScript Package that I created for Sublime Text some time ago available at GitHub for sharing. And by that also open it up for anyone else to add to and improve upon using GitHub’s social collaboration features for coding.

Check out this video for a quick demonstration:

So if you’re into LScript, and have wanted to give Sublime Text a spin, go ahead and grab my LScript package for it.

LScript Package for Sublime Text

Oh, and one more thing, by the time LightWave 3D eleven hits the shelves, I’ll get a lwsdk Python package for Sublime Text going.

Cheers!

First of all, Celtx is since long an important piece of the puzzle for my workflow. It’s a wonderful screenwriting app and its mobile app is top of the line for screenwriting on the go. So I was quite intrigued to learn that Celtx were about to expand their lineup of tools with a storyboarding mobile app as well.

As I’m an animator, storyboarding is tremendously important to me. So obviously I already have a workflow that I’m comfortable with, but I’m always open to try out new tools and possibly improve my existing routines.

Celtx Shots uses Celtx Sync, just like Celtx Scripts to bring the project from the desktop to the mobile device. Unlike Scripts, Shots is a one way sync though. Why Celtx don’t add Dropbox support to these apps is beyond me. That would add a tremendous amount of value and comfort.

Anyway, Shots matches up with how the storyboarding functionality in the desktop app works very well. Shots is, well, more beautiful though.

Celtx Shots vs Celtx Desktop

Just like the desktop version you can add storyboard images/photos and make companion sketches to block out the shot to each storyboard frame. You can also define the type of shot and write a description. And you can organize it in sequences. So if you have used the desktop version before you should quickly be quite comfortable working with the mobile app.

One neat feature, is that you can capture photos directly with the built-in iPad camera to the storyboard. Which makes it very easy to quickly build up something being on location on a live feature. As I’m using the first generation of iPads I don’t have a camera in mine, so I couldn’t test that one. On the other hand, as I’m working with animation, I use drawn storyboards and don’t need that feature in my line of work. It would be cool to try it out some day though.

I recorded a quick walk-through video of Celtx Shots. I have a few other personal iPad projects coming, so it was a nice exercise in getting a somewhat decent recording quality of a screen. It turned out to not being the easiest thing in the world. Anyway…

It’s a definitely a good and useful app, but it could be even better. Here is a few things that me personally would love to see in a future update.

• Dropbox support.
• Ability to reorganize the order of storyboard frames by simply dragging them around.
• Better sync. I’d like to be able to keep sending a storyboard back and forth between desktop and mobile.
• Really, we need Dropbox support.
• Possibility to add your own clip art for sketching. This one goes for the desktop app as well. I have a few custom items and characters that I’m going to use for many storyboards. That would be extremely useful for me to be able to add them to the clip art library.
• You can import from Celtx sync, but then you can’t export it back to desktop Celtx via sync, but have to go via iTunes. That’s not a good workflow at all. See above, Dropbox support would make this operation a breeze.
• And then there is the… lack of Dropbox support! Could some Celtx iOS Developer check this out? Pretty pretty please with sugar on top. (This one is for the Scripts app as well).

To sum it up. Even though this app is no game changer for my storyboarding workflow, it will provide me with some extra mileage. The obvious scenario of how I’ll use it is if I’m working with an idea away from my desktop. I might even be finishing a script in the lovely Celtx Scripts mobile app, which I then can sync over to Shots and start storyboarding right away. I already use the iPad for drawing storyboard frames away from my computer with Procreate and Sketchbook Pro combined with an iPad Wacom Pen. So bringing them into Shots to try it out right away will be handy indeed.

I can jump between Shots and Procreate. Draw new frames in Procreate, open them in Shots, make some additional notes, maybe add a blocking sketch, and then move on to the next shot. Good stuff!

If interested in the app, checkout Celtx Shots in the App Store.

Cheers!

In short, I’ve added a new control to release the camera’s focal point into world coordinate space and also organized the schematic view of the rig. Follow the link below to the original post and read the changelog for more details about the update.

More information
Download v1.1 of the rig

Cheers!

The other day I was setting up a few shots for a scene I’m working on and I started building a few basic camera rigs to get a better motion out of the shots. I had time to spare and was in the mood so I started polishing one of the rigs to be more generic and to replicate traditional analog rigs.

Check out this demonstration video for how to operate my camera rig:

Note: I’ve updated the rig since I recorded the video. The differences are lined out in the changelog at the bottom of this post.

The reason to somewhat try to replicate the controls from an analog camera rig with a stick, boom/crane, rails and so on with all the restrictions that come with it, are simply that the audience are used to the kind of camera moves those restrictions imposes. So it basically helps to sell the shot.

My camera rig comes with a few additional goodies though like a built in Camera Shaker as well as a blendable target for the camera to track.

Feel free to comment, or give me ideas and suggestions for adjustments that would improve the rig. Enjoy!

Download

• Download v1.1 – 7 Nov 2011
• Download v1.0 – 21 Oct 2011

Changelog

Version 1.1 – 7 Nov 2011

• Added a new control, “Release Focus”, which undocks the focal point from
  camera movements into world space. Example Usage: Releasing the focus from
  the camera motion, makes it easy to keep an object in focus while the
  camera moves.
  The focus distance connected to the camera is pickable in the OpenGL,
  CR_focus_distance. While the actual focus point, CR_focus, needs to be
  picked in the object list when released from the camera rig, or by
  unchecking the lock icon in the scene editor to be pickable in OpenGL.
• Changed the label “Use Noise” to “Shake Cam”.
• Organized the rig in the schematic view.

Version 1.0 – 21 Oct 2011

• Initial Release.

I’ve also started using my asset system while finishing these models. Dogfooding! Progress tracking was implemented so I can keep logging as I go along. Next week I’ll add the relationship handling between users and every action in the system. So everything done from that point on is logged in the history with the correct associations. I want to have that information recorded early on.

In my roadmap I’ve dedicated time for adding one major feature each week until the proof of concept film finished. The rest of the week I’ll keep using it while doing 3D work and just make minor fixes if needed. With my current schedule, the system will be more than ready to be taken to the second phase by the time I’m ready with this (very) short, which means it will be solid enough for more people to start using it.

I’ve started toying with names.

To fight that ending of my film, I’m making sure that I’m running a tight ship from the very beginning and I’ve been very careful to keep everything well organized up to this point. But as I’ve went into pre-production, the amount of tasks and assets connected to the project are rapidly growing so I’m now at a stage where I need to come up with a system that can handle the added load without collapsing.

I’ve spent a few days researching digital asset management systems, collaboration systems, task managers and the likes. Everything has been evaluated from linking Excel files together to combining services like Basecamp, Teambox, Redmine with file sharing systems. And I’ve also considered dedicated services for film production like Shotgun. My ideal choice would be something that works now while having the potential to scale without a hefty price tag.

Using a main Excel document with links to sub-documents was the low-hanging fruit option to get something going right away. I created a simple system like that to evaluate, which actually turned out okay. It would work perfect for now. But the minute someone else joins me on this journey and by that we’ll need painless collaboration, the Excel option would crash and burn immediately! I definitely need to come up with a pipeline that scales properly, and that excludes Excel, so I don’t hit a wall and fall down hard somewhere along the production.

Leaving the low-hanging fruit behind, I went to the next level and signed up for a few popular collaboration sites. Teambox was the one I really liked, simple GUI and easy to work with. But at the end of the day, it’s not designed for film production. I started to come up with ideas of how I could shoehorn my needs into these systems, but soon I realized that shoehorning would be an on-going task if I went this route, and by that, I deleted these generic systems from my list of options.

The remaining option was to consider using a dedicated film collaboration and tracking system, Shotgun being my preferred choice. While awesome and living up to all my requirements and needs, it would kill my shoestring budget. As long as it’s just me and if I went with the lite option, it’s a mere $19/month. That’s fine. But I’m pretty sure I’m going to need API access down the road considering how I want my pipeline to work, and then we’re talking about $89/month instead for the studio option. And that cost is per user and month. So when I get more people on board, that sum would rise to a level that is not sustainable for this project. So because of that, Shotgun is not something I can consider.

Back to square one, what should I go with? I had a fourth scenario in my original research notes. I had written a reminder next to it in capital bold letters, “Johan, don’t go down this road this time, use your time for production, and find something that works out of the box!”. But here I am, having decided to go down that road anyway, despite what the ~6-month-ago Johan told me. And that is baking my own asset tracking and collaboration system.

Dancing on my own

So after doing my homework on existing systems and solutions I’m now face to face with creating my own. Crazy, or not, before pursuing my life as an artist, I spent many years working as a coder, so maybe not that crazy after all, and also me still getting some mileage out of those years.

Again, I had to spend another half day making some new research, to decide how to best develop a solution covering my current and future film production needs. Once again I wanted to see if I could find any low hanging fruit, to save time, so I built a prototype on the WordPress system. Using Custom Post Types and extending the WordPress core by writing a model for many-to-many database relationships, I very quickly got something up and running that worked almost as intended, concerning having a web front-end. But that is the catch. It’s very tempting to go with a framework simply because you get some results right away that works almost like you want. Short development time tastes good. But then you keep fighting to tune that framework into exactly how you want it to be and keep running into dead ends, so in the long run, building it on top of something might not always be the best option depending on present and future requirements.

I came to the conclusion that going with that solution wouldn’t scale well and that it would add tons of work at the time I need to grow and connect it with other entities in the pipeline. I don’t want to risk painting myself into a corner, so I threw this prototype away.

This is were I decided that I’ll write the system from scratch. It will take me a bit longer, it will not show any cool results in the beginning, but it will give me a very solid foundation to add features on as the film progresses. And I get a system that works exactly like how I want it to work.

So after about a days worth of coding, I had a new prototype up and running. Here is a preview video of a working example. You have to excuse my tired voice. I recorded the video around 3:00 this morning after a whole day of marathon coding the different systems, so I probably sound a bit apathetic, especially towards the end. Anyhow, here it is…

This is a very simple test, but it validates the concept and the workings of the underlying server engine and its API, and demonstrates a working connection. It’s just a quick early glimpse of my first iteration. So far have almost all my efforts gone into writing the software for the server and designing the API and the database.

For the test in the video I pretty quickly wired together a simple and rough LightWave front-end plugin as well as a simple web front-end. Both are hooked up to the server via my API. The collaboration server is off-site and located in a virtual private cloud at Amazon (where incidentally I also run a render farm, you see, something might get hooked up there as well. Wink wink notch notch.)

Anyway, as simple as the preview was on a front-end level, I’m still quite satisfied of how far I got with this iteration of the system.

The plan now is not to start adding shiny, sexy, new front-end features. Instead I’ll continue working on the server software and API. To make sure I have a rock solid foundation to scale with the film production. As long as I have a solid framework that’s extendable combined with a powerful all-access API to safely store all data within, features to interact with it can be added when needed as the film progresses.

I’ve followed the most common conventions when designing the API to make it as easy to use as I possibly can. When authenticated it gives access to everything. Even though I did my test implementation with LightWave 3D, any application that has a SDK or a decent scripting engine can communicate with the API. The API is completely application neutral. Subversion for version control of assets is of course something that is on the top of my list to allow to take advantage of the API. I’ve previously written a SVN integration for LightWave that I’ll probably bake right into this.

In time I hope to make a few more integration plugins if needed for some of the other applications I use. modo and After Effects come first to mind. But maybe also a panel for Photoshop. Time is really the only limit of which apps I’ll hook directly in to the system. Perhaps Adobe Bridge could be a candidate. I haven’t checked out what you can do with the Bridge SDK, but maybe it can be made into a desktop client for the system. Concerning Bridge I don’t have a clue of what I’m talking about, I’m just making some brainstorming without knowing the limitations or possibilities of that particular application.

This is of course distracting me from the actual film production for a few more days, but once it’s, it’s done. And I believe that I’ll quickly get those days paid back in the terms of a more efficient and flexible workflow. Having a solid management and collaboration system for the film pipeline will with a bit of luck turn out to be worth its bytes in gold!

That’s it for this update.
Over and out!

I’ve been working on my own film on and off for some time. A bit too long even. But recently I got back into the groove, on most of my stuff actually, and things have started moving forward on all fronts. (Thank you, GTD).

Anyway, since I’ve been getting back into my film I’ve spent time updating my original plans. Change/tweak/trash/update/remake – all of them true for defining recent events.

My original plan included making a Proof of Concept film, and then move into real production with the experience gathered. That plan still stands. The Proof of concept film is a short sequence, less than a minute, to keep it realistic for a one man show. Even though I’ve film production experience, it’s quite a different beast to architect the entire pipeline from the early development stages to the final distributable film, compared to coming in to do your part on a production in an already established pipe.

And that’s the reason why I’m making a Proof of Concept film before the real deal. Pipeline wise the Proof of Concept is a full production, with a script, storyboard, animatics, previz, full production modeling/rigging/animating/texturing/lighting, post prod, sound design and so on. Only that everything is on a smaller scale.

By working myself through the pipeline with the Proof of Concept I’m hoping to

1. Define a working pipeline.
2. Find any critical problems with the workflow.
3. Keeping collaboration in mind when more people gets involved.

Well, to be honest, I don’t for a minute believe that me doing a Proof of Concept will ensure a smooth ride when engaging a full production. I’m quite sure that it will be a bumpy ride anyway. But by doing this I hope I will at least iron out the most critical problems that can occur and that means avoiding any showstopping black holes, that could make the real production vaporize.

So to get back to the initial reason for the existence of this entry in my journal »Writing about the progress». My previous decision was to make the Proof of Concept in silence, iron out all the details, and then keep a regular public production log for the real deal. But when I was going over the entire process I came to the conclusion that my journal is the perfect place for me to share this phase of the production. I shouldn’t be so anal about this process, this is after all a project I make for the pure pleasure and enjoyment I get out of it at the moment, so everything don’t have to be shiny and polished.

It will be straw-man proposals thrown out there by me. It will be some brainstorming and share of thoughts. I’ll probably more than once revise what I’ve stated in an earlier post. It will be rough drafts, concepts and early revisions. To have the project more in the public light will also be a motivator and an extra incentive for me to keep at it and make sure things happens in a timely manner.

At the same time I hope that me starting to write about my progress before I know exactly where I’m heading with this, or having every little detail worked out, could turn out to be interesting for others on the same path as mine, or who are on the fence to also jump down this rabbit hole. Also I hope there will be some usefulness in me sharing my bumps, running into walls, thoughts as well as revelations, highlights and solutions. And I’d love if I’d manage to create some discussions on the topics or receive feedback and suggestions.

Now, back to make some film happen! More to come soon…

I’ve used my fair share of tree generating apps over the years. Vue, Onyx and X-Frog comes to mind as well as LightWave plugins like Tree/Leaves generator and DP_Verdure. While all of them good in their own respect, TreeSketch brings something new to the table. Controlling the growth by sketching.

I didn’t expect that much from an iPad app, more than a bit of fun. It turned out that not only does it work, it works great! It’s actually one of the most intuitive ways I’ve found so far to create trees. The use of the touch screen is really well thought out by the developer so it feels very natural to simply draw out directions of how you want the tree to grow. And you feel that you are in control when designing your trees into any shape you can dream of. Lot’s of advanced options as well to tinker with and it came with a bunch of video tutorials to get you up and running in no time. And to add to the awesomeness, it’s free!

Here’s a bunch of trees I sketched on my iPad today, and then brought into LightWave 3D for rendering. I’m just playing around to get to know all the ins and outs and get a feel for the app.

I found it really cool how you simply can rotate the viewport while drawing and the tree naturally grows along with how you direct it, and then that you can grab branches and bend, move, resize or even redirect with oversketching. Freckin’ awesome control! And my iPad Stylus pen works great with this app as well. Then there is a bunch of fine tuning settings for how the growth of branches and leaves shall be calculated. And when exporting you get a FBX file, UV mapped, quads only, and ready to be brought into a renderer for texturing and shading.

I’m impressed by this app to say the least. I’m quite productive with my iPad in many different ways, but so far it’s been limited to sketching, drawing, writing, note taking, communication, reading, some music composing and so on, I didn’t think it was ready for any 3D production. I’ve previously played around with Autodesk’s 123d sculpt, which was fun and a hint of where we might be heading in a tablet generation or two, but that one is nothing but a novelty for now. TreeSketch on the other hand brings real usage to the table right now.

One thing I found myself wishing for though, was more options to get the trees out of the app. I don’t really like that you have to go via iTunes to get the FBX back to the computer. Instead I’d love to see exporting to Dropbox or even just being able to mail it. That would make the workflow much more comfortable and faster to get the trees out of the app into a desktop environment without any cables.

Anyway, to sum it up. I’m truly enjoying this app, and I can’t wait until I’ll need to make a scene with trees and take it for a real spin. Perhaps combining it with instancing, or taking it to Vue or modo, or even making a tailor made tree to fit for a scene taking place within the tree. Or why not using it as a basemesh for ZBrush.

If you have an iPad, check out TreeSketch in the AppStore

I’m currently spending as much time as I can spare on my own film project. I’m not really ready to go public yet with full details, ideas and where I want to take it, but it’s getting closer. At the moment I’m making a proof of concept, of my entire pipeline from script to final sequence. I’m currently in the previz phase in my proof of concept sequence. When the proof of concept is ready, I’ll go into the real production and then also start posting a lot more details and producing making-of entries.

Anyway, before files are starting to get way out of hand in my project storage, I’ve decided to try to come up with a solid file and folder structure to keep everything organized early on.

I’ve made a template structure based on my previous 3D animation experience as well as injecting a few new ideas of how I’d like to have it organized.

During my proof of concept production I’ll keep validating this structure and modify and refine it, so I’ll feel comfortable that it will work when going into the real production phase.

So have in mind that this is still a work in progress, and as I’m currently at the previsualization  phase, stages beyond that are not that detailed yet. I still wanted to share this at the current state as this is an entity that’s going through changes at the moment and I’d value external input.

Filmmaking folder and file structure

Version: beta 01

Each bullet point represents a folder, unless it ends with a file extension, then tada, it’s a file (of importance). Comments are in italics starting with //.

As this is currently a work in progress a bullet list will do, I hope, to represent the folder structure for now. A link to a Google Doc is available at the end of this post.

• development // The project development is performed in Celtx and then exported out as separate documents.
  • project.celtx
  • project – treatment.pdf
  • project – screenplay.pdf
  • project – summary.pdf
• pre-production
  • animatics // A Premiere Pro project where the storyboard images are cut together with audio.
    • images
    • audio
  • concept art // Collect reference images and then illustrate the concepts from the screenplay’s asset breakdown.
    • characters
    • props
    • locations
  • storyboard // PSD and related assets.
  • previsualization
    • assets // Library/Catalog of all assets. Rough, draft models. That will be used in the previz shots.
      • characters
      • locations
      • props
    • animation // Animated data sets for all scenes in the production. Rendered frames go to the root render folder.
      • sequence_##
        • scene_##
          • application_specific_folders
    • edit // A Premiere Pro project there the rendered previz scenes are cut together into a rough version of the final product.
      • audio
      • clips
  • production
    • assets // Library/catalog of all assets. Final version with proxy counter parts, to be lift into the scenes in production.
      • characters // An asset folder contains the final version, associated textures and any eventual rigs.
        • character_x
          • character_x_v001
          • character_x_v002
          • character_x (final version)
          • character_x_proxy (final version)
          • character_x.fbx (for i/o. Store with embedded rendered icon or with an fbxicon.tif)
        • character_y
      • locations
      • props
      • asset_catalog.csv (Or kept in Google Docs?). User friendly asset name, namespace, file path, icon path, reference weapons and props in other files.
    • animation // The animation data created in the previz can probably be brought over here and used as a starting point for the final animations.
      • sequence_##
        • scene_##
          • application_specific_folders
• post-production
  • audio
  • compositing
  • edit
• renders
  • previsualization
  • production
  • presentations
  • tests
  • wip

It’s a bit rough, it’s not that detailed yet beyond pre-production and it lacks full explanations of how I work with the different parts. But it’s a beginning, it’s something, and I’m currently using and verifying it as I’m moving forward in my proofing.

If you found it hard to get an overview of the bullet list above, I also stored this first draft in a Google Doc which probably might be easier to read.

View: Filmmaking File Structure, beta 01

If you’re on a similar path, and have another setup, or have ideas or inputs on my setup feel free to comment, contribute or discuss this with me. All conversions on this subject are more than welcome and much appreciated. I’ll of course post my final version when ready.

Cheers,
Johan

I had roughly blocked out a sculpt, the image to the right, from a ZSphere armature to get the proportions and overall shapes for the character I was working on in place. I came to the point were I started to feel that the geometry was getting in the way in some areas. In other words some areas had too little geometry while others too much.

At this stage I usually take a few minutes, before adding details and polish, to make a quick retopo to even out the geometry and get back better control in the sparse areas without having to bump the subdivision another level (Oh, how I long for ZBrush 4 R2, where you supposedly won’t have to consider this anymore, looks like they have added Sculptris technology).

I find ZBrush’ retopology tools quite intuitive and quick to work with and I have never shared the view that they should be cumbersome. I have a workflow where I paint the new topology I want on the mesh and then just lay out the new topology on top of that. Which have worked out fine for me in the past. Today I ran into something weird though.

I’ve tried to illustrate what happens in the image below. First we have the sculpture where I have painted a few lines to help me lay down the new topology. Then we have the sculpture with the new topology on top of it, and then just a shot of the topology lines without the sculpture in the background. The second row of images is the result when creating a new adaptive skin from the topology. The holes are highlighted in red in the last two images.

Holes when creating an adaptive skin from the new topology. Click image to enlarge.

The only part of this character that displays this problem is the foot, the rest of the skin works fine as usual. After having tried to figure out what was going on I simply erased the entire new topology on the foot and created it again. But still no go, I got the same holes the second time as I got the first time. Now I was frustrated, I truly hate it when I have to spend time fighting the software. Here is a turntable video to easier see the holes in question.

As I mentioned earlier, I’m one of those who actually don’t think that ZBrush own topology tools are that bad. I usually get the work done quite fast with them. But this time I’ve to declare myself defeated.

I guess ZBrush has a problem with all the ins and outs with the long, bony, claw like toes that somehow confuses the logic of how the skin is connected on this particular part. That’s my only guess of what’s going on, and I can kind of see where the engine could see two possible choices of where to cap the polygons. It looks like polygons have been created in some cases, but between the wrong edges. The thing is that I have created topology for similar parts in the past and it have worked fine. That was in ZBrush 3.x though, and the topology tools changed in ZBrush 4, so perhaps something changed along the way that causes trouble in this case. It could also be user error, but after having spent too much time with this I am starting to doubt that.

Anyway, I made a quick and easy workaround. I used GoZ to send the skin to modo, fixed the holes, and sent it back. And voila, everything works. I still get obsessed trying to understand why and how this occurs, as then it’s easier to avoid/work around in the future, without having to bounce to modo.

If anyone have any clue or knows more of how and when these holes appear I’d love to get enlightened. I kept searching ZBrushCentral for answers but no luck there either. I found the question, I found other workarounds, but no explanations.

Perhaps I should consider getting Topogun for my topology needs? I see people raving about it all the time. I’m not that keen to add new applications to my pipeline unless absolutely necessary or unless it adds a tremendous boost to my workflow. Topogun might fit into the latter alternative, speeding up my work. And it seems to be straightforward enough to get up and running without a long learning curve.