A Lighting Desk

Explorations of a theatrical lighting designer

[adamlvachon]

Hope you're well. I came across your DMX profile and wanted to ask your opinion as I have little experience in using lighting desks. I'm currently creating VJ sets for a show and using resolume as my software. The software has a DMX mapping feature for lighting desks. As this will be a pre-recorded session, how can I write out a simple profile for the lampie to work with during the show? I can send links to the DMX channels used by the software and would really appriciate your guidance in this.

Hi! I'd be happy to take a look and help where I can. To be perfectly honest I've never used resolume, but I've heard great things about it.

Send me the links and I'll give you what ever advice I can! What are you using for lighting instruments?

Best,

Adam

[adamlvachon]

The guys over at Licht.Pfad doing some REALLY rad stuff in TouchDesigner with moving lights. Nice work guys!

[adamlvachon]

The Challenges of Realtime Performer Tracking for Moving Lights

Tracking a performer on stage in realtime is not something new. There are, in fact, a couple of companies that sell technology bundles that do this already for sound (StageTrackerFX and TiMax Tracker) using ultra-wide band RFID tagging. Many hospitals and shipping companies use similar set ups to track patients and packages, though both StageTrackerFX and TiMax Tracker use a few more receivers/communicators and some special algorithms to more quickly accurately tracker a person in motion. At first I thought I might be able to utilize such a system for Wonder Dome to track a performer or object with light, but after some research I came across a few problems. First, the price tag on a system like this (one geared specifically for theatre or otherwise) minimum $5,000-$10,000, far beyond affordable for the Dome an most others interested in realtime reactive lighting. Second, after talking with multiple companies, I discovered that this type of tracking is typically accurate only to within 6", and often have a 1-2 second tracking delay to adjust for accuracy within the algorithms.

That sort of thing might work for sound tracking (balancing a speaker system so that it appears that a performers voice is coming from wherever they are on stage), but the human eye is far less forgiving when it comes to light. Visually, if a performer is standing even a few inches off their mark, it is noticeable to an audience member; we are a bit more forgiving if a "sound" is a foot or two off to one side of a performer.

With this in mind I turned back visual tracking. Using a camera has it's own set of issues, however. In order to pick out a specific individual or object, the camera or an image processing software must be capable of either blob tracking or skeleton tracking. In addition, in order to accurately track a performer or object within Wonder Dome specifically, a camera would need a viewing angle of at least 90°. Blob tracking programs and protocols tend to be fairly resource intensive on a computer's processor, but some cameras have this built in already. The camera would also need to be able to remember or pick out specific individuals so as not to track random audience member, just a performer. This can be done is via color recognition or using special infrared filters, LEDs and/or special IR reflective materials.

Thanks in no small part to the video game and robotics industries, several cameras specifically made for interaction already exist on the market, namely Microsoft's Kinect, Sony's Playstation Eye, Nintendo's Wii Remote, and Charmed Lab's Pixy. The Kinect utilizes onboard skeleton tracking and a tunable infrared camera which allows for the camera to calculate depth information. Skeletal tracking provides excellent data from a front view perspective, but a top down view (which we are planning to use in  Wonder Dome) tends to confuse the Kinect skeletons. The Kinect also only has a camera angle of 57° horizontally and 43° vertically, which means I would need to matrix between 4 and 6 Kinect cameras to be able to track the entire Dome. As an added complication, each Kinect needs to be on separate USB bus to function properly; most desktop computers come equipped with at least two, so potentially 3 computers would need to be networked together for this method to work.

The Nintendo Wii Remote (Wiimote) has a tiny on board IR camera that does a couple of remarkable things; built in blob tracking, and data rate for 100Hz. The in board blob tracking is incredibly useful, as it frees up resources from processing computer, and the data speed makes the camera super responsive. There have been numerous hack-and-mod projects for them, so documentation is abundant on almost every aspect of the device. There are some extremely limiting factors to the Wiimote, however. In in it's most basic and unmodified form, the Wii Remote has a camera angle of 33° horizontal, 23° vertical requiring a matrix of 12 cameras to be effective in the Dome. Additionally, the remotes themselves are battery powered and communicate via Bluetooth to either computers or a Wii. This means a maximum of 4 Wiimotes can be connected to one computer before data clogging occurs, which means 3 computers for processing, and batteries need to be changed regularly. Osculator or Glovepie can both be used to read data from the Wii remote. As I mentioned previously, the Wiimote has been the subject of numerous modifications and hacks, and there is a lot of documentation on how to remove the camera itself from the Wiimote, and mount it as a standalone camera, or, in some cases, in a matrix for robotic vision. I have a separate post I am in the process of writing regarding the math and theory aimed specifically for the Dome and a matrix of 12 Wiimote cameras.

The Playstation Eye, all by itself, is more of a webcam than a motion tracking device. It has a frame rate of 60Hz, a maximum camera angle of 75°, and can only track objects in concert with a special Move controller. Peau Productions, a company specializing in custom and DIY touch surfaces, sells modified Eye cameras with swappable lenses, going up to a viewing angle of 122°. The most wide angle lenses are expensive (up to $440), but also are equipped with integrated distortion correction, making the image the sensor sees is not curved in a way that can effect tracking. These cameras modifications were developed to work along side a light weight, open source, blob tracking software called Creative Core Vision (CCV). CCV works on both Mac OSX and Windows, is incredibly customizable for blob tracking, works with many different cameras, and can send it's data with OSC protocols. This is likely the camera set up I will use with Wonder Dome, despite the price tag of around $550. That said, a matrix of 12 Wii remotes would cost $480 just for the remotes, not to mention more gear to get them all to work happily together and a development period for that as well, so $550, doesn't seem like such a bad price tag!

Last, but certainly not least is Pixy from Charmed Labs. Now, Pixy is my dream camera: and arduino based camera with a speed around 100Hz, swappable lenses, and built in blob tracking. Really smart blob tracking. Honestly, check out their Kickstarter page for all the details, but in a nutshell it can be trained to remember specific color signatures and track many objects simultaneously. The video is pretty killer. Price: $75 with a stock 75° lens. So what is my hold up? Well, unfortunately these incredible cameras won't start shipping until February for Kickstarter rewards, with an estimated arrival date of "well into March". Wonder Dome is presenting starting March 19th, so I'm hedging my bets that I wouldn't be able to work with a Pixy until the week before at best, which is way too late. In future iterations of the Dome I'll be very excited in seeing what a Pixy can do however!

I'll post some screen shots, videos and pictures of the Creative Core Vision and some camera/tracking work in the near future.

[adamlvachon]

Calculating appropriate Pan and Tilt DMX values for a moving light positioned at the peak of a Dome, controlled by custom software

Lighting performers in a Dome with 360° projections is a unique challenge. In many regards it is similar to theatre in the round; in order light a performer properly, Light has to hit the performer from all sides. At the same time, the angle of the light has to be steep/controlled enough to avoid hitting the surrounding projection surface. 

So, what does that mean? Well let's take a look at our current test moving light, the Vizi Wash LED 108 from American DJ. According to the manual, the instrument has a Pan of range 540° or 630° (you can choose with the internal program settings of the instrument, I am sticking to 540° for now), and a Tilt range of 265°. For testing purposes, I have placed the light at the peak of the Dome.

Thinking about a performer moving around inside the Dome, and the need to keep might lights from washing out projections, I know that both 265° of Tilt and 540° of Pan include ranges I simply do not want or need. The question then becomes, How do I determine what degree range I actually need for the space I need to light? The answer: some simple math!

Let's start with the Pan. In this particular instance, there is no need for more than 360° of panning for my moving light (circles are nice like that). So, it turns out we need 360 of the full 540°, two-thirds, or roughly the first 66% of 540°. So that means we also only need 66% of the 0-255 DMX values for the moving light, which is about DMX values 0-168.

The Tilt is a little trickier, but still some simple mathematics. The first question to answer is "What range of angles of light do I need?". In my case, I knew I needed only 90° of Tilt for the WonderDome. As you can see in the drawing below, the Dome is essentially a hemispherical projection surface on 7' risers; In order to not wash out the projections, i need to stay below the 7' mark. The diameter line of the Dome is at the same 7' mark.

Some basic geometry tells us that taking a measurement angle at the peak of the Dome to the radius points on either side of the dome is 90°. Great! We know we need 90° of the 265° of tilt available to us, which translate to about 34%, or approximately 87 DMX values. But how do we calculate which 34% of the 0-255 DMX values do we need? Well, there are a few ways, but here is what I did: 

We know 90° of 265° are accounted for, so 265-90 = 175°. Since the 90° I need are directly in the middle of the total possible 265°, I know I can simply divide 175° in half to get 87.5°. Using the same method as before, this means that the first 87.5° has DMX values 0-84, and therefore our 90°  is DMX values 85-171 of the moving light.

And there you have it! So how do we apply this? Let's say you are working in TouchDesigner with a system similar to the one I set up in this post. For my TouchOSC rotary dials, I would simply assign the Pan output value rage as 0-168 and the Tilt output value as 85-171. When the moving light profile reads the incoming OSC (Open Sound Control) data, it is already restricted to the values needed.

[adamlvachon]

Why do you not post photos of your work? Process is important, of course. But where is the result?

Hi,

Thanks for asking, the answer is two-fold. First, the project I am working on (WonderDome) is in its early stages; while I have made some progress (i.e. I can make a moving light react to movement with a program called TouchDesigner), I am pretty far off from my ultimate goal of having a moving light actually follow a person. When I am satisfied I have something worthy of sharing in that regard, I will share it.

Second, quite frankly my process is my work. Before this project, I had never worked in TouchDesigner. Just the fact that I have a working knowledge and can show screen captures of a working network of CHOPS in TouchDesigner is a huge success in my books. In the end, for me at least, I find that it is in the process of a work, the small failures and the even smaller success, is ultimately where I learn the most. Yes, results are important. For me, the most important result is that I am learning, and can share that knowledge with others.

Best Wishes,

Adam

[adamlvachon]

Lighting profiles, DMX, and TouchDesigner

Over the past couple of months I've had the opportunity to play around with TouchDesigner and test out it's capabilities in regards to programming moving lights. In this post I'll cover how to make a profile for  a simple moving light in TouchDesigner, how to output the profile data to DMX to communicate with the instrument, and how to control the light using a simple TouchOSC control set up.

One of my favorite things about TouchDesigner is that is that not only is it incredibly customizable, but the programming logic is fairly intuitive as long as you are willing to play around and not be afraid of making mistakes.

The ease of making a moving light profile in TouchDesigner was actually incredibly straight forward and easy. To start, I looked at the DMX chart for the moving light I was using, in this case an American DJ Vizi Wash LED 108

The light actually utilizes 12 DMX channel, despite the chart above having only 11 channels listed. With this in mind, I began by creating a simple network of 12 Select and Null CHOPs (one CHOP for each DMX channel that the moving light needs), one Merge CHOP, and one DMX Chop. The result looked a bit like this:

A quick note on TouchDesigner and DMX. On their wiki, Derivative says the DMX Out CHOP addresses in the following fashion:

"The first channel you send into the DMX Out will correspond to the first DMX address (DMX channel) As you add channels to the DMX Out, you will access the next DMX channels in order. For example, if you input 12 channels into the DMX out, you will be controlling DMX channels 1 thru 12." 

With this in mind, I decided a Merge CHOP was necessary to collect all of my DMX channels in the correct order for output before connecting to the DMX Out CHOP. This worked well for testing, however it might end up complicating things in the future, which I will come back to in a little bit.

DMX Out sends data through a USB to DMX adapter like the ENTTEC USB Pro that I used. When the drivers are installed properly, the adapter should show up as a Device in the parameter window for the DMX Out CHOP as long as you are set to FTDI Serial for your interface.

From here I needed some data to see if the profile would take data from an outside source, so I created a simple TouchOSC app to control intensity, color, pan and tilt.

This is where the DMX values from the ADJ Vizi Wash manual come in handy. For example, the manual I know that the moving light pans when it receives data between 0-255 in it's first DMX channel, so I made sure to have the rotary dial for Pan output values 0-255. I did this for all of the parameters I needed to control with this simple controller. For convenience, I also labeled all of my sliders and rotary controls in TouchOSC, so that their names would automatically popup up as a channel later in TouchDesigner. More information about TouchOSC can be found here. 

Jumping back into TouchDesigner, I needed to catch all the TouchOSC data from my controller to send to my DMX channels so created an OSC In CHOP, and set it up to receive data from my iPhone. Be sure that you are Sending from your controller (phone, tablet, etc) on the same Port as you Receive in TouchDesigner on the OSC In CHOP! I created an OSC In DAT as well, which allowed me to also look at the data streaming in from my phone.

From here it was a simple matter of connecting CHOPS, and using the Select CHOPS to grab the right channels. I organized my profile vertically, and, making sure to connect the Selects and Nulls to the Merge CHOP from top to bottom, or DMX 1-12. 

For this particular profile, the only channels I really needed data for were Channels 1, 3, 5, 6, 7, 8, and 9 (See chart above). One quick note regarding the Shutter function of most moving lights: It needs to be told to be Open. In this case, Channel 8 needed to have a constant value of 255, which I added as a Constant CHOP before the Null CHOP.

The rest of the DMX channels (2, 4, 10-12) were unimportant, but still needed values in order to be seen as "channels" by the Merge and DMX OUT Chops, so I added Constant CHOPS with 0 values before their Nulls as well.

The result as a very quick and responsive iPhone powered control system for a moving light. An addition I made later with the help of Matthew Ragan was a custom Kinect Tracker CHOP, which allowed us to get some rough data values (from a Kinect camera that was tracking a performer in real time) to connect to the Pan and Tilt Channels. That particular network and tracking solution needs some work, but the light reacted well to having realtime tracking input!

Regarding DMX assignments and TouchDesigner, a feature which almost all commercial, dedicated lighting control software/hardwares have is the ability to quickly and easily to Patch (assign/reassign) instruments to whatever DMX channel is the most logical for the design of the show. For example, as a designer I might patch a system of Front Light as DMX channels 1-20, skip 10 channels and proceed to assign my Back Light system as 31-40. In this fashion I can easily organize my channels to suit my needs. TouchDesigner can currently ONLY assign DMX in sequential order.

All that said, this may or may not be a problem, since I will be building the entire control system from the ground up, using fewer instruments (around 10), and TouchDesigner is super customizable. I might even be able to program a control to do exactly what I am talking about. It is definitely something to keep in mind for the future.

[adamlvachon]

TouchDesigner evaluation for WonderDome

The following rubric allows for 25 points, based on my needs of the WonderDome

Ease of 3D environment manipulation and navigation

1: worst thing ever, controls are complete poo

2: controls are annoying/frustrating, but I can get by if need be

3: Controls are a bit clunky, but definitely useable

4: Pretty easy to use, even if there are a few quirks I dislike

5: Dang, I could do this all day

Can you build in this program?

  4: The controls will take some getting use to, but over all they are fairly simple and intuitive. In terms of modeling with cameras and light, it is incredibly customizable, if a bit overly so. You can build and edit within Touch, or import from any CAD program.

  Instrument control

Neigh impossible, I can’t do what I need to do

This really isn’t meant to do what I need, but I can get by

Moderate programming challenges, and controls might be a little  clunky but it works

Moderate to easy programming, almost complete control/control of lights isn’t super frustrating or slow

I have complete control, and it’s easy to program

  3.5: Complete control over the programming, to the point where I’d essentially have to write moving light profiles from the ground up for my instruments, as well build my own instrument models (possibly? I might be able to just download the CAD versions form manufacturer websites and “animate” them accordingly). That said, given the flexibility of Touch designer, I can definitely program whatever parameters I need to.

UPDATE: After working in TouchDesigner for a while, I can confidently say that making Profiles for moving lights is super easy! There is a learning curve to learning TouchDesigner, for sure, and I have a very long way to go to be able to make my own control program on this platform, but it is certainly possible

Communication w/other programs

Does not communicate

Does not communicate across all desired protocols

Communicates, but is a royal pain to setup/communication drops out

Communicates  with other programs well, no real issues

Communicates perfectly and has all sorts of nifty auto features that make it all a cinch

  4: input/outputs in DMX, MIDI, OSC, etc. I do not know how well the communication flow works. Given how customizable TD is, the communication will probably take a bit of forethought, but will be very doable

UPDATE: The communication between TD and other programs, or even other computers also running TD (same or different editions) often requires a little playing around to make it work properly, but works quite well

  Cost

Not even a free trial version unless you have a super special dongle

Expensive, but there is a limited used trial version (trial version may or may not be useful)

Decent price point, trial versions for testing

Cheap and/or almost unlimited access trial version

Free or free version that will work wonders for this project

  3: I should be able to accomplish everything I need to in the free FTE/non commercial environment. The one exception to this is that TouchDesigner 088 non-commercial and TouchDesigner 077 Free Thinking Environment only allow for 32 DMX channels of output. This is a problem. Most of the lighting fixtures I will be using have at least 10 channels of DMX needed to be able to control them. In short, I will quickly run out of DMX channels for my lights. The commercial, professional and educational environments unlock the full 512 range for DMX, but do have a licensing fee. Educational license: $300 Commercial license: $599 Pro license: $2,200. 

Overall programming:

1: building everything from the ground up, and it’s going to be onerous and difficult

2: Have to build everything (or almost everything), but once it should be really stable and fairly straight forward once I get a hang of the programming

5: profiles are already made, I don’t have to do jack, AND there is an easy out for a “control” desk

  3: I do have to build everything from the ground up, but it is fairly easy, I'm getting some training from a professional, and it should all be pretty solid when the whole thing is done. Getting it all done before March, however, that will be the true challenge.

Total for now: 17.5/25 (70%)

   Conclusion:

TouchDesigner is incredibly powerful and flexible, but I’ll be building from the ground up, more or less. I’ll have to design and build a profile for every single light, and some sort of control desk/playback system to be able to program and run the show. Of the moving lights I’m looking at right now, some have as many as 47 channels of DMX to be used to operate them, which means I would have to program each DMX input/output individually in TD. That said, there will only be two or three different lighting fixtures and one lighting control system, and then I can just copy and paste the rest and re-patch as necessary. As mentioned previously, the limitation of 32 DMX channels in the non-commercial versions would severely limit the amount/type of lighting fixtures I could use, so I will eventually have to upgrade to a commercial or educational license for this project

So, TD would take a long time to program, but thanks to the fairly simple/logical interface, with a solid design plan and a little training to learn the program, TD is a viable option. A much more viable option if, say, I have more time (a full year?) or more time to dedicate to creating the interfaces, but an option none the less.

As of right now, TouchDesigner will be used for a large chunk, if not all of the programming for Lighting in the Wonder Dome project

[adamlvachon]

GrandMA2 3D evaluation for WonderDome

The following rubric allows for 25 points, based on my needs of the WonderDome

Ease of 3D environment manipulation and navigation

1: worst thing ever, controls are complete poo

2: controls are annoying/frustrating, but I can get by if need be

3: Controls are a bit clunky, but definitely useable

4: Pretty easy to use, even if there are a few quirks I dislike

5: Dang, I could do this all day

Can you build in this program?

  3: A fairly simple system of 3D navigation. One major downside is that you cannot build or modify shapes and objects in GrandMA2, you can only import models. While in theory this should be fine for Wonder Dome, it does involve an added step for any object we need to manipulate: It has to be created in a separate program and then imported into GrandMA2. Not the end of the world, but definitely an extra step.

  Instrument control

Neigh impossible, I can’t do what I need to do

This really isn’t meant to do what I need, but I can get by

Moderate programming challenges, and controls might be a little  clunky but it works

Moderate to easy programming, almost complete control/control of lights isn’t super frustrating or slow

I have complete control, and it’s easy to program

  1: GrandMA2 cannot input live tracking parameters from what I can tell. Maybe with MIDI, but the GrandMA2 manual is not terribly helpful on that front. That is a major issue.

  Communication w/other programs

Does not communicate

Does not communicate across all desired protocols

Communicates, but is a royal pain to setup/communication drops out

Communicates  with other programs well, no real issues

Communicates perfectly and has all sorts of nifty auto features that make it all a cinch

  2: Only inputs/outputs Midi from what I can tell.

  Cost

Not even a free trial version unless you have a super special dongle

Expensive, but there is a limited used trial version (trial version may or may not be useful)

Decent price point, trial versions for testing

Cheap and/or almost unlimited access trial version

Free or free version that will work wonders for this project

  5: Free GrandMA2 PC and GrandMA2 3D

Overall programming:

0: Cannot be programmed for my needs

1: building everything from the ground up, and it’s going to be onerous and difficult

2: Have to build everything (or almost everything), but once it should be really stable and fairly straight forward once I get a hang of the programming

5: profiles are already made, I don’t have to do jack, AND there is an easy out for a “control” desk

0: cannot be programmed for my needs

  Total for now: 11/25 (44%)

Conclusion:

 GrandMA2’s lack of ability for motion capture input data is deal breaker. When it comes down to it, I would have to pipe in data to do live tracking, and even then I won't really have the control to flip between pre-programmed and live "scenes".

[adamlvachon]

Control software evaluation for the Dome project

A few months ago I began planning for my applied project, Wonder Dome; an immersive theatrical performance for young audiences with interactive lighting, sound, and media. A large part of the research for this project has been invested in researching the appropriate control software. 

As various tests and workshops have gone on, a few things have become apparent for my needs for a control software:

1) Time-line based progression: Telling a story is still a narrative, and thus must have a somewhat linear progression. The ability to have a timeline is therefore paramount

2) Functional non-linear progression: As a part of my groups desire to provide an immersive and interactive environment in which the audience can, in theory, contribute to the story, I also need to be able to make some leaps. While this might seem in direct conflict for the need for time-line based progression, I believe a balance can be struck. Examples our group have come up with include having 4-5 different settings within our story (eg, underwater, in a giant's beanstalk/cloud kingdom, the woods, in a city, etc), and then having specific progressions and objectives for each environment. This set-up is not unlike storytelling many contemporary video games.

3) The ability to efficiently track the movements of a performer and/or audience member in realtime and be able to follow them with a moving light

4) Reinforce the environments created by the media on the surface of the Dome

5) DMX addressing

6) Data input/output: midi or OSC, to be able to talk between lighting, sound, and media controllers

7) Flexibility/customization: Sometimes I'll want to have pre-programmed cues/effects (the path of a moving light, intensity and color of light, etc), and at others, I will want lights to take their cues from a media or sound cue. In this sense, the control software must be flexible enough to be able to program many possible settings within one cue. Being able to program a new tool from scratch specifically for a unique moment may be a necessary demand

8) Pre-visualization: In the pre-equipment phase (ie I don't have the money to buy all my lights yet), pre-visualization has been an enormous help. Having some vague ideas about what exactly data is doing to a virtual light, without having access to the real thing has been critical for trouble shooting programming relating to building software.

As a part of these revelations I also evaluated two pieces of software early in the process. My reviews of GrandMA2 3D and TouchDesigner as possible control software will follow in additional posts

[adamlvachon]

Wonder Dome

For my MFA Applied Project (Thesis) at Arizona State University I have teamed up with a team of designers, performers, a writer, and programmers to create an immersive, interactive, theatrical experience for young audiences. The experience happens in a dome, similar to a planetarium, allowing for 360˚ projections. Using various sensor and motion tracking technologies the both the audience and the performer will be able to manipulate media, lights, and sounds in real time to interact with their environment and take an active role in the story.

As the lighting designer for Wonder Dome, I am responsible for crafting the audience's experience of interaction with light in a way which simultaneously improves their interactive experience within Wonder Dome, while also supporting the classic need to provide sufficient and most appropriate lighting to support the progression of the story.

Throughout the length of this project I will be investigating what it means to have a "interactive lighting system", how that differs from classic theatrical lighting, and why it is important to begin thinking of lighting as an interactive story telling element, rather than a pre-made timeline based design element.

In the next few weeks I will be taking some time to discuss the current uses of interactive lighting, what is out there for software and hardware. I will specifically be evaluating three programs (GrandMA2, TouchDesigner, D3) for their usefulness for my purposes within Wonder Dome, and decide which one to use as a control medium.

[adamlvachon]

Professional Aim

I am a young professional theatrical lighting designer in the beginning of the 21st century. It is simultaneously an exciting and unsettling time; regional theater companies are closing their doors for good every day, while shows like Punchdrunk's immersive experience Sleep No More is still running after two years in New York.

As a lighting designer in 2013, I intend to explore non-traditional modes of design. My own training started in non-traditional movement based performance, and the idea of thinking outside the boundaries of what has traditionally been considered "theater" seems come more naturally to me than most. Interactive, immersive, theatrical performance Dome? That's my graduate thesis. 

This blog will showcase not only my professional work, but explore the climate of  current "non-tradional" theatre models. What kind of theatre draws a crowd in the days of mobile computing devices? I hope to find out.

[adamlvachon]

A Shift of Focus

It's my final year of Grad school! With that comes a tiny shift in focus. From now on this blog will be focused primarily on my professional work as a lighting designer. See tiny shift. The blog was mostly geared that way anyway.

[adamlvachon]

Madness: The third of the three major tropes in Victorian Gothic Gothic Horror

[adamlvachon]

Death: another major trope for Victorian Gothic/Gothic Horror

[adamlvachon]

Aristocratic decay: on of the three major tropes of Victorian Gothic/Gothic Horror

[adamlvachon]

A selection of Kazanjian's work which looks like a combination of Escher, the House of Usher, and some physics thrown in for good measure

[adamlvachon]

Just some really cool work by a guy from Portland, Oregon.  That said I He is a photoshop master. Seriously, Adobe includes his work in their master class series.

I'm not sure if he was ever directly influenced by Escher, but some the similarity of some of their works is uncanny!