Prolost

Realistic Lens Flares

When technology and art intersect, it's often the case that those who know how have no idea why, and those who know why have no idea how.

I can’t stop thinking about this SIGGRAPH video. It shows realistic lens flares being computed in real time using a sparse ray tracing technique. There are some lens artifacts shown here of a complexity and beauty that I’ve never seen faked convincingly before.

Lens flare is caused by light passing through a photographic lens system in an unintended way. Often considered a degrading artifact, it has become a crucial component for realistic imagery and an artistic means that can even lead to an increased perceived brightness.

“Increased perceived brightness?” That was the best sales pitch you could give on why being able to synthesize realistic lens flares is worthwhile?

What you meant to say was "increased awesomeness."

Lens flares are awesome because they are fricking crazy. They are organic, but completely unreal. They increase the veil of unreality between the audience and the movie. They are beautiful. They are tiny imperfections magnified by orders of magnitude. They are aliens. And scary buildings. And first kisses. We give them sound effects and music cues. They make movies bigger than life because they have nothing to do with life.

And I want yours, Hullin et al..

In the Vimeo comments the poster said:

Anamorphic optics are currently not supported, but this is not a principal limitation of the rendering scheme.

If they had put anamorphic examples in this video I think I’d be standing on their lawn with a boom box right now.

Physically-Based Real-Time Lens Flare Rendering — Hullin, Eisemann, Seidel, Lee

Screenplay Markdown Progress

The response to my Screenplay Markdown post has been wonderful. It’s a bit hard to follow the progress by reading the blog page, so here’s a brief recap.

I wrote about my recently discovered joy of working with plain text and Markdown, and that I’d concluded that a simple text file would not be such a bad way to begin work on a screenplay, given that Final Draft and many other screenwriting apps do a fine job of interpolating proper formatting from imported plain text documents.

Turned out I was not the only person to consider this, and some commenters called my attention to other plain-text-to-screenplay projects (post update 1).

This led to speculation about a simple syntax that would account for the few things not supported by plain text import/export, such as emphasis, dual dialog, title pages and and centered text.

This led to me going bananas and writing up a proposal for a plain-text screenplay format called SPMD (update 2), and creating a video mockup of how an app like Byword might soft-preview your screenplay formatting while you work (update 3).

The Byword guys tweeted about the video and got some excited responses from their followers.

Kent Tessman, creator of the Fade In screenwriting software (and its iOS companion, which I just learned of), wrote a detailed reply on his own blog. Other developers have emailed me privately and shared their valuable thoughts.

This has resulted in some changes to the spec, and to some real hope on my part that SPMD might becomes something useful someday. So if you’re at all interested, please take a look at the proposal, download the sample files, and let us know your thoughts.

Screenplay Markdown

Or: How I Fought The Battle With Usability and Lost, But Received Actual Productivity as a Consolation Prize

Thanks in no small part to the wise ramblings of Merlin Mann, I’m hooked on the portability and flexibility of doing as much of my creative work as possible using simple text files stored on Dropbox. Documents I’m working on are always accessible to me wherever I go. I can even apply useful formatting to these plain text files, regardless of which writing software I’m using, with the relatively intuitive syntax of Markdown. Markdown is, in the words of its creator John Gruber:

…a text-to-HTML conversion tool for web writers. Markdown allows you to write using an easy-to-read, easy-to-write plain text format, then convert it to structurally valid XHTML (or HTML).

Apps like WriteUp on iOS and Byword on the Mac show me what my Markdown-formated text will look like in HTML. Here’s this very blog post in Byword — first the raw markdown text:

And here’s the HTML preview:

Because the files are plain text, there’s no way to mess up their contents or formatting by opening them in an incompatible app. The value of this has been made evident to me recently as I tried to live the Apple dream and bounce some work back and forth between Apple’s own Pages app on iOS and Mac. The file became bloated with unnecessary crap, formatting was removed, comments were deleted, and use of niceties such as curly quotes was inconsistent. I won’t even mention the hassles of manually emailing the document back and forth between devices, since Apple is actively solving that issue with iCloud. But iCloud won’t be so hot for Pages documents if the iPad version persists in stripping out critical formatting and features from documents created on the Mac.

Markdown solves all these issues by eschewing WYSIWYG and instead prioritizing something that, I’ve come to realize, might be far more valuable: keeping your hands moving on the keyboard.

The putzing-free fluidity with which I edit Markdown documents across devices has made me even more grumpy about the sorry state of mobile screenwriting. On iOS, I use two screenplay writing apps that support the industry-standard .FDX format: ScriptsPro and ScriptWrite. In all honesty, both have tremendous potential, and tremendous bugs. I’ve been skittish about using either for real work. Celtx Script, which I wrote about when it launched, is stable and lovely, but does not support FDX. Like Merlin (roughly) said in a recent episode of Back to Work, “I’m not going to row out to your island.”

Out of desperation for a mobile screenwriting solution that would be as fluid and flexible as my Markdown text work, I engaged in some procrasductivity the other night and began researching ways of writing a screenplay in plain text. After much fiddling, I finally remembered that Final Draft actually has a heuristic for guessing the implied screenplay formatting in a plain text file. If you feed it something like this:

It will correctly import it as this:

So the ultimate mobile screenwriting solution may be, for the time being, your favorite among the many lovely Dropbox-based plaintext writing apps out there.

Are other screenwriters as dissatisfied with their workflow as I am? Is there a part of your workflow where you’d give up WYSIWYG and accurate pagination to just get words on the page in a way that freed you from a specific device, and specific software? Or do we expect that Final Draft, Inc.’s promised-but-delayed iPad app will be what we’ve been wanting? Or that one or more of the existing iPad apps will become awesome?

Screenwriting is challenging enough that I often catch myself “fiddling” (in the Merlin Mann definition: spending more time putzing with the tools than doing the work) with ways of making it more visual and intuitive. And now here I am fiddling with a way of making it less visual for the sake of more portability.

Maybe I should just shut up and write. Which is exactly what I did after I got this all figured out. I put all the toys away and wrote a six-page treatment for a feature I want to make.

I wrote it in Markdown. And yesterday, as I was out walking my dog, I got an idea for a small tweak. I sat down on a bench in the sun, pulled out my phone, and made the adjustment while it was still fresh in my mind.

Awesome.

Update

on 2011-08-09 22:59 by Stu

Apparently I’m either not crazy, or not the only crazy person out there. Turns out others have experimented with tools to enable plaintext screenwriting.

All seem to behave like Final Draft in interpreting plain text into a screenplay format. Which is nice, but it’s a one-way street. I’m thinking there might be a place for a plaintext screenplay format with markdown-like syntax, and a WYSIWYG desktop app that works with that format as easily as FDX.

The syntax would be necessary for special cases, such as forcing a Scene Heading element even when the first characters are not INT or EXT, simultaneous dialog, title pages, and centered text for the all-important “THE END.” Markdown syntax would be used for **bold** and *italics,* but being screenwriters, we need _underlining_ too, and the ability to _**combine**_ them.

This way we could have the niceties of a dedicated desktop WYSIWYG app combined with the edit-anywhere flexibility of plaintext.

Update

on 2012-01-28 05:34 by Stu

And now I really am crazy, because you can view the Screenplay Markdown sytnax proposal here.

Update

on 2011-08-12 18:14 by Stu

And now there’s a video.