Blender stories – learning to light

the beauty and intrigue of working in the world of 3D lies in being able to completely control every element of every scene.

unlike stills and film where your life can become anxious and deeply stressful when the weather won’t play along, in 3D, you are the weather, and the lighting, and the colour of every element, together with its placement, and your actors are never temperamental or unreliable, and you have infinite fuel and explosives, not to speak of the infinite options available to you in lighting and lenses, and even including anamorphic.

truth be told, i have an addictive personality and right now i am hooked.

so let’s dive into it.

one of the less thrilling aspects of the 3D world is that software houses prefer not to make their filetypes interchangeable, or shareable from one package (like Maya) to another (like Blender). as previously mentioned i have experience working in Google Sketchup (before it became Trimble Sketchup) and used it to design and engineer actual fire protection systems. i therefore have a library of old files to choose from with pre-built sites. After a few hits and misses i figured out the right settings when exporting OBJ files from Sketchup, to (1) stop the imported model from showing up with blotchy materials superimposed on one another, and (2), the right way up.

up until this project all of the lighting i had ever used in a scene was either 2 or more suns, or big overhead area or spot lights, and the occasional HDRI. so, having decided also to commit to volumetric lighting for this project, i then decided to get cute with the lighting…

[masterslider id=”2″]

there have been so many times when i have started out on a project with a vision, but not expected to get anything even remotely decent looking. i know my limitations and am acutely aware of my lack of experience.

but that doesn’t stop me.

i use a brute-force approach to life and learning.

and for the bubbles themselves, dialling in jusssst enough translucency into each bubble…but not too much. and just like in the real world, when you take a photo on your DSLR and the lighting and colours look beautiful on the LCD but look dull and lifeless on the big screen, so too a small-scale, low quality render looks nothing like high quality 4k output. this means you have to constantly generate cropped output at 4k size and medium quality to guide you accurately toward conclusion. …but, even a cropped render takes minutes when you’re operating 2019 software on a 2013 machine.

…oh and did i mention, it was only in month 3 that i learned how to select a portion of my camera view, and render only that cropped portion? Up until that point i had to save keyframes of how the camera was supposed to be, and then zoom all the way in to the detail i was working on and scale the output all the way down, then when satisfied with the detail, move the keyframes back into place again. (don’t worry if that was all greek to you…)

…what this means in the real-world is that it takes a tremendous amount of resolve and sacrifice to put in the hours needed to iteratively learn. when every small tweak takes hours to review, you must have a firm vision to work towards, and/or be willing to evolve within the creative limitations offered by the technology at hand.
there have been nights where i’ve set a timer for every 2 hours to wake up and run one physics “bake” after another for a series of fire sprinklers in a structure. to bake physics is first to, for example, create a hose pipe or tap with water drops that fall out of it and drop on the ground, secondly, to tell the water:
-how big its drops are,
-how heavy they are,
-how malleable and plastic-like they are – or
-how viscous the overall fluid is,
-how much they are influenced by forces like gravity and/or turbulence and/or wind, etc,
thirdly, to tell the ground:
-how solid it is,
-how permeable it is,
-how sticky it is,
-how much friction it has,
-etc
and lastly, to then let the computer run the simulation for the length of time specified, in the background, and calculate all the results of the geometry and the physics into big and daunting looking spreadsheets that are now “baked” and stored in a directory, and can become as big as 40gb for a scene.
the reason that you bake them is so that your computer doesn’t have to manually calculate each frame while you move back and forward in the timeline, as you work.
bakes can take time.

in a scene where a lot of geometry is present, such as a truck, getting your foam particles to randomly stick and/or bounce, but not look too neat and mathematical, or too plasticine-like – finding that delicate balance takes painstaking attention to detail, and a bucket load of time.

on a recent project i had foam cannons emitting 240,000 particles each x 9 of them, together with a high resolution fire, and a lot of trucks. hence, every 2 hours i was up to bake another cannon…

therefore these 5 months have been a super-human effort for me, but one i have gladly embraced because i am well and truly besotted with my vocation now.

my commitment is total, but so too is my machine’s.
my computer can do nothing else while it is calculating physics or when it is engaged with a render of a visualisation.

by now i think you’re starting to understand why this world can be so consuming to a creative personality with an already addictive nature – oh, and did i mention, somewhat of a control freak?…

it’s a truism of life that it is those little weeds we leave behind, those “i’ll get to it tomorrow” seemingly trivial problems, (or in my case) details, which grow and fester and keep you awake at night.
and maybe it’s a statement on the nature of my reality that the biggest problem i am consumed with is modelling in those lights that i know i should have done in the first place, a statement for which i am eternally grateful within the current paradigm of things…

…that willingness to undergo the repeated life-on-hold waiting as you iteratively work toward selling the realism. that’s not laziness. that’s anything but laziness

it’s probably also not sane…

i feel like i should add a title to my name.

“technical illustrator for the fire engineering industry”
that sounds about right…

that same curiosity drives me to explore unique perspectives and angles. this is partly why i love drone technology but only the proper, high-end stuff that has cable-like, buttery-smooth gimbal motion. the DJI’s and GoPro’s don’t impress me with their jerky, clunky, one-movement-at-a-time, camera motion.

by this stage i had learned how to introduce invisible geometry to make the flames “bend” around the tanker and wheels. i also added a second foam “cannon”, and got the physics of the “foam” particles to interact with the flames.

after ramping up and doubling the effective “foam” particle count, i discovered that the emission shader i had added, with which to help slightly illuminate each “bubble”of my “foam”, was causing a buildup and eventual overflow of too-much light into my scene, as the light-emitting “bubbles” were stacking up on top of each other…

rendering out a full HD (nevermind 4k) video at a decent quality (not like these low quality and low res images) is just not possible at this stage. On my computer it will take 45 minutes per frame for the (slightly over 10 seconds at 24 frames per second, or fps) 250 frames, or 7.8 days…

…which is why (and to circle back to adding a title to my name) i’m not quite ready to add “technical animator for the fire engineering industry” to my titles, just yet…
but watch this space.

and oh fuck, the geek in me just realised what day it is.

i’m completely in love with Blender, so if i was going to wish a happy valentine to something i would want to spend my life with, well, this is, tragically, it…

even in the real world.

happy valentines day everybody else.

and to you, my darling Blender, a happy valentines day and wishes for many more!