logo_hypothetical_square_80px

Eric Mehl

About Eric Mehl

Posts by Eric Mehl:

Gaffer Deadline New Feature Roundup

Gaffer Deadline New Feature Roundup

0

Since first releasing GafferDeadline, Hypothetical’s extension for submitting Gaffer tasks to Deadline, I’ve added a number of new features to make it more flexible and powerful. Many of them came about from needing them for Hypothetical’s recent Welikia Recreated project.

That project also proved that our Gaffer Windows port and Gaffer Deadline work well in a cross platform environment. All of the production was done with the Windows fork of Gaffer, with rendering being done through Deadline on Amazon Web Services Linux instances. Deadline’s path mapping feature sorted out any differences in file naming requirements and away we went!

The latest releases are always available on Github. Let’s have a look at some of the new features and how they may be useful.

Include an arbitrary list of auxiliary files

Deadline allows the submitter to include what they call auxiliary files with each submission. These are files that are uploaded to the Deadline repository at the time of submission and downloaded to each Deadline Worker when it dequeues a job to render it. GafferDeadline always included the Gaffer script itself as an auxiliary file, and now it is easy to specify a list of additional files to include as auxiliary files.

When GafferDeadline renders the job, it sets an environment variable called “AUXFILESDIRECTORY” that can be used within Gaffer scripts to point file paths to the temporary directory where Deadline saves the auxiliary files.

This can be useful for files that would normally live on a server that you want to “freeze” at the time of submission in case they are likely to be changed before the job is rendered. It can also be handy for including files that are needed by a Gaffer script that are not included in path mapping rules.

Add custom environment variables for render jobs

Environment variables are a convenient way of customizing settings in Gaffer across the whole application. Studios often use them to preload settings specific to a studio location, show, shot and more to make it easy to keep data and settings organized.

Now you can specify any list of environment variables to be set by Deadline when the job is rendered. Especially when combined with GafferDeadline’s new string substitution (see below), this can be a great way of customizing a render job.

Gaffer allows you to use the “${name}” syntax to substitute variables into Gaffer plugs. For example if you normally launch Gaffer with an environment variable of SHOWNAME set, you can have a GafferDeadline SHOWNAME variable set to ${SHOWNAME}. On submission, the ${SHOWNAME} will be substituted with the SHOWNAME set in your workstation’s environment, and properly carried over to the Deadline Worker’s environment.

String substitution

Gaffer’s string substitution is a powerful method of using context variables, environment variables and frame numbers in string plugs. This feature is now included in all of the GafferDeadline string plugs, so you can easily set things like job groups based on an environment variable, job comment based on a context variable and much much more.

Custom Deadline settings

I’ve taken a selected set of commonly used Deadline settings to include in the main interface to GafferDeadline. But these are not always enough, especially considering how many settings Deadline offers. Now you can set any Deadline setting from a GafferDeadline submission. This means every setting can now be included in a submission!

Path mapping

As I described above, path mapping is sometimes a necessary requirement for rendering jobs across different operating systems or network layouts. Deadline’s path mapping is now supported in GafferDeadline, making it simple to submit jobs from one operating system to render on another. It’s also crucial for rendering with Deadline’s AWS integration to resolve file names from cloud-based Deadline Workers.

Coming up next…

There is more in store for our Gaffer + Deadline submitter, and if you are interested in contributing, find a bug or would like to see a particular feature implemented, head over to our Github repository .

How Hypothetical Recreated Welikia

How Hypothetical Recreated Welikia

, , 0

Hypothetical recently wrapped up the first phase of our digital recreation of Welikia and I’m excited to share some information about how it was done. This project is a collaboration with the Wildlife Conservation Society. Dr. Eric Sanderson and his team at the WCS spent years developing extensive ecological models of New York City before European settlement – when it was a diverse and rich array of ecosystems.

welikia_collect_pond_viewport_previewwelikia_collect_pond

Production Requirements

There were a number of requirements for the project in addition to the core need to create photorealistic images based on their data. In fact the images were meant to be the output of a system for interpreting the underlying data, not just a one-off set of scenes and images. For that system we wanted to accomplish a number of goals:

  • make it easy enough for a non-expert user to create images
  • allow viewpoints from anywhere, roughly categorized as nadir (satellite) views, aerial views and ground level views
  • allow for a user, or a scripted solution, to input latitude and longitude coordinates for the camera location
  • for the nadir views, be able to render the terrain in tiles to allow for the images to be used in multi-resolution map browsers like Open Street Map
  • represent a wide variety of ecosystems and their specific vegetation species
  • not be limited to only still images but also allow for animation and panoramic images
  • accommodate future updates to the data as more research is completed

These requirements, combined with the scope of the terrain – the data covered 230 square miles (596 square kilometers) of visible landscape and another 470 square miles (1217 square kilometers) of data underwater – and a need for detailed control over how the landscapes are generated meant a standard off-the-shelf solution wouldn’t be suitable.

Based on my experience working with Gaffer I thought it would be an excellent solution. Combined with some data preprocessing in Houdini, our Gaffer script was able to check all the boxes.

Data Preparation

The data I got from Dr. Sanderson’s team was in the form of raster and vector GIS (Geographic Information System) data. Raster data is an image where each pixel, or cell, encodes information for that grid point. Elevation data encodes height above sea level. Ecosystems are identified by a numeric code for the most likely ecosystem for that area based on Dr. Sanderson’s ecological modeling. Vector data described things like pond outlines and Lenape trails.

Some early experiments showed that the resolution of the elevation data held up great at long and medium view distances, but ground level views didn’t have as much detail as we wanted. To improve that I run the elevation data through Houdini’s terrain tools to add a mild erosion effect at an upsampled resolution of 1m per pixel instead of 5m per pixel. This is also where I bring in the vector data through a custom Houdini node for reading the supplied shapefile vector data to ensure ponds contained water. The same scheme is used to cut streams into the terrain by “dredging” a little bit of terrain and prepping Houdini to treat it as water.

Now I have a set of images with elevation and water depth encoded in the pixels. That, the ecosystem raster data and a variety of tree and plant models made with SpeedTree will bring Welikia to life.

Building the World

To keep all of the requirements above met, I decided to structure the overall model as a single world that can be viewed through cameras free to move anywhere in space. It is procedurally created and populated with vegetation, but there is only ever one definitive distribution of plants. This makes it possible to render seamless tiles that line up correctly for nadir views and explore the world with cameras without limitation.

Gaffer’s easy customization and open access to its source code makes creating new nodes in either c++ or Python accessible and greatly extends the ability to tailor just the right solution.

Terrain

At 1m resolution and approximately 58,000m x 55,000m dimensions (once the supplied raster data was squared off) the whole terrain doesn’t have a chance of fitting into memory for rendering. So I break it up into a set of 1024 tiles instead of one huge raster file.

Gaffer has a really great method for assembling scenes with its CollectScenes node. I give that node a list of tiles to include and the upstream tile assembly nodes result in a nice orderly scene graph. The list of tiles to assemble comes from a couple of nodes I created. One takes a scene consisting of bounding boxes for the whole set of terrain tiles and prunes the boxes that are outside of the camera frustum from the scene graph. A second node extracts the names of the scene locations that are still present and turns them into a simple string list that is sent to the CollectScenes node via an expression.

tile_collection
A schematic view of the bounding box to CollectScenes flow. The bounding boxes of all 1024 tiles are quick and easy to cull from the scene based on the camera frustum. A custom node extracts the names of the boxes that are left, which correspond to their tile number. An Expression node reformats the names into compatible format for the CollectScenes node (called CollectLandscapeTiles here). Upstream of the CollectLandcapeTiles, the tile number is used as a context variable to load the appropriate tile. The set of visible tiles is then passed downstream to the rest of the graph.

Upstream from the CollectScenes node is a plane with grid divisions of at least 1m spacing. I created a new Gaffer node for sampling image data onto a 3d mesh in order to transfer the height values from the raster images to the 3d grid points and an OSLObject node to displace the points vertically according to the elevation.

landscape_mesh_looking south
A subset of the landscape tiles used for a view looking south from the southern tip of Manhattan. Tile points outside of the view frustum are removed, leaving a much lighter mesh to render. The tile in blue is selected for editing. The resolution here is a preview resolution of 5m grid spacing.

The terrain is then duplicated for the water. The elevation data represents the height of the surface itself, so sampling the water depth and further displacing the terrain by that amount results in the water surface.

When I started rendering aerial views, a new problem came up. Aerial views can end up including a lot of tiles, often hundreds. For example, a camera 100m above the earth can see about 36km to the horizon. Memory restrictions at that point become a problem.

To solve that, I implemented a simple level of detail system to increase the spacing of grid points of the terrain for tiles farther and farther from the camera. The ImageSampler node works perfectly with this method because it will interpolate image samples for points that don’t lie exactly on a pixel. An expression connected to the plane’s “divisions” setting allows me to tune the detail level based on its distance to the camera and image resolution. Keeping about 2 screen space pixels per division turns out to be a good balance between visual quality and memory usage.

Future development will include a node to implement more sophisticated level of detail techniques to adapt the terrain even better. The water for example can be enormously simplified since it is flat right up until the last couple of triangles that start to overlap the dry land.

landcape_with_water
The water level is not a simple flat plane at height of zero. Instead it takes into account average tidal levels and the difference in elevation from roughly north to south as the Hudson and East rivers flow out to the Atlantic Ocean. Streams and ponds also have to account for their depth and the elevation of the underlying terrain.

Vegetation

With the landscape in place (but not shaded yet, that’s up next) it is time to give attention to the vegetation. There are about 60 different ecosystem types Dr. Sanderson and his team identified. Some are very similar to each other, and some are underwater, but there are still many to populate with plants.

SpeedTree is a great tool for creating vegetation models and it proves to be very useful for creating Welikia plants. They have an extensive library of pre-made models available that serve as a good starting point for further customization. One trait we want to make sure is conveyed is the old-growth nature of the forests. This means not only large trees, but also a wide variation in sizes to represent trees that are relatively younger, having filled in a hole in the forest where a past tree had fallen. I also create variations for the center and edges of the forest. Trees packed in next to each other don’t allow enough light to penetrate lower branches so leaves are concentrated at the top. Trees on the edge of a river bank or other forest edge can get more light down low, so their leaf canopy extends quite low and visually makes for a more impenetrable looking forest.

Although Houdini has good plant scattering capabilities, I ultimately decided to keep the plant distribution within Gaffer. This allows for faster iteration directly in the viewport, easy camera movement to preview different ecosystems, and rendering previews that are critical to getting good results.

Scattering plants in Gaffer is mostly straightforward. Each species is scattered individually using a Seeds node, starting with the dominant species of an ecosystem and working down to smaller scale species. For example, an oak / hickory forest has edge and middle oak tree models, edge and middle hickory models, sapling models for oak and hickory, a scattering of dogwood trees in the understory and a final layer of sparse grass on the ground.

Using a combination of OSLImage nodes, spline widgets, noise maps, blur nodes and image merge nodes, I convert the ecosystem raster data into a probability map for each model ranging from 0-1. The seeds’ elevations are set from an ImageSampler node. A custom node for calculating the gradient of the height map feeds data into Gaffer’s Orientation node for controlling how much the plant will point straight up vs. along the landscape slope.

seeds_demo
The sparsely scattered points represent a large tree like an oak, and the smaller points represent grass. Grass can only grow where there is enough sunlight, so it can’t get too close to the trees. The ClosestPoints node, combined with some OSLObject code and a DeletePoints, allows control over how close the grass can get to the oak trees.

Each seed also gets a unique ID based on its location so that it will be consistent on each scattering run. Like the terrain tiles, seeds are also culled out of the frustum using a custom node to reduce the data load on the renderer. Without a consistent ID, manual customizations are not possible for moving cameras and would be problematic even for a still camera that may be moved during exploration.

The final step is to cache out the seeds once the plant distributions are looking good. Scattering is fairly quick for a small area, but as with the terrain, aerial views can take prohibitively long to populate, especially for multi-frame animations.

Look Development

Terrain, water and vegetation are all in place now. It’s time to create some shaders! The shaders themselves are pretty straightforward. I chose to use VRay as the render engine. From past experience I know it can handle lots of instancing with low memory consumption. To get it working in Gaffer I needed to code the interface between Gaffer and the VRay AppSDK. I may have more information on that in the future.

A couple parts of the shading configuration are particularly interesting. Using Gaffer’s OSLObject node and a custom node for identifying connected faces, I add data to the tree meshes to vary the leaf colors slightly for each leaf. This adds a subtle but important variation to the trees so they don’t look repetitive.

For the ground, I use the ClosestPoints node again, this time measuring proximity of terrain points to vegetation, to determine what kind of ground texture to apply. Grid points within range of trees get fallen leaf litter textures depending on the species nearest to it. The rest of the points get blended textures based on their dominant ecosystem like mud flats, cliff faces or sandy beaches.

Final Details

Customizing the Scatter

For long aerial views, the procedural scatter does a great job of covering acres of terrain with believable looking vegetation. But when you bring the camera down to ground level, it’s important to be able to add an artistic touch to the layout. You also want to make sure your chosen camera spot isn’t in the middle of a tree.

To allow individual control over trees, a few extra items need to be in place. For one, I need to be able to address a specific tree, regardless of the order in which it was generated. This is because preview renders are often done with a shorter far clipping plane than production renders, and changing using the default Instancer node settings can result in the same tree getting a different name based on it’s placement in the sequence. To sort this, I used the “Id” parameter to add an unique Id, based on an OSLObject hash of the object’s world location, to each instance. Now the instances can be moved, deleted and more based on a constant Id.

Handling High Resolution Trees

Gaffer’s context variables came to the rescue for simplifying the viewport geometry for trees. With individual trees often having a few million polygons each, it would be a major bottleneck, if it’s possible at all, to load and display the full geometry at all times. But I also needed to make sure that any manual edits to the tree’s location were applied to the proxy and the full resolution tree. Lastly, I wanted to be able to select a tree in the viewport and not risk forgetting to navigate a level up in the hierarchy view before making tweaks.

The solution was to create a convex hull for each tree in Houdini, and read that into Gaffer as usual. The full resolution trees were then parented to the proxy. A context variable downstream switches between full resolution and proxy.

tree_reader_graph
The node graph for the tree loader. It handles switching between proxy and full resolution tree, and optionally an animated tree as well, all based on context variables set downstream.
maple_proxymaple_full
maple_hiearchy
The scene hierarchy for the tree proxy system. An Alembic file is read from disk. The top location, “maple_red_forest_03”, has the proxy geometry and the child locations hold the full resolution geometry. In preview mode the full resolution geometry is not loaded by using a Prune node. In full resolution mode, the top level geometry is removed using a DeleteGeometry node, leaving the transform intact in case there were manual changes to its location.

Camera Placement

The final piece of the Welikia puzzle is the latitude / longitude based camera locator. For this I use Gaffer’s Expression node to call an external open-source program called proj. Proj handles the intricacies of converting latitude and longitude coordinates to regular cartesian coordinates. It’s a surprisingly difficult problem and one that I’m very happy to delegate to the experts.

I hope you enjoyed that dive into the inner workings of the creation of our Welikia images!

welikia_bronx_new_york_botanic_garden
You can rest easy knowing that the beavers are happily at work damming up the virtual streams of Welikia.

GafferDeadline release #1

GafferDeadline release #1

0

Hypothetical is pleased to announce the first release of our open-source GafferDeadline extension, available on GitHub. Our continuing adoption of Gaffer has allowed us to iterate creative ideas faster than ever before and was instrumental in keeping our recent New York City 1609 animations moving forward.

Deadline has long been our render farm manager of choice. Its easy customization means very specific workflows can be accommodated. And its integration with Amazon Web Services gives us an extremely powerful render farm at the click of a button.

Now with the ability to dispatch node graphs directly from Gaffer to Deadline, you can keep all of your complex task dependencies intact for optimum rendering. GafferDeadline will automatically detect frame-to-frame and task-to-task dependencies in your node graphs. If your graph has more intricate dependencies than Deadline can represent natively, there is a dependency script that reads metadata attached to the Deadline job by GafferDeadline to ensure tasks are still released as soon as they can be.

If you are a Gaffer and Deadline user, or if you’ve been holding off on adopting either because they couldn’t communicate, we hope this will be just what you need to advance your own productions.

 

History Rendering: New York City circa 1609

History Rendering: New York City circa 1609

, 0

Four hundred years ago, New York City looked very different from today. Gone are the endless miles of pavement, skyscrapers of steel and glass and food carts on every corner. Instead it was a lush landscape of marshes, forests and swamps inhabited by an equally diverse collection of plant and animal species alongside the native people, the Lenape. The idea of New York City as a temperate paradise full of “sweet smells” inspired Hypothetical’s first history rendering project.

We set out to visualize New York City’s distant past according to the latest research available and historic descriptions by Henry Hudson, his crew and successors. It’s the first step of a journey to show the city as it evolved into the metropolis it is today.

New York City has an incredibly rich history. It was transferred multiple times between the Dutch and English. It became a leading American city after figuring prominently in the Revolutionary War. And it went on to become a world-leading center of culture and commerce.

The area shown in these history renderings was known as the Collect Pond and has a twisting story of its own.

foley_square_1609_forest_no_text

To create the animations and images shown in these digital recreations is a complex process. It starts with sculpting the terrain based on current research and historic records.

That landscape is digitally eroded to add detail, encoding metadata about the terrain along the way such as how much debris has piled up, how steep the landscape is and where the water would pool.

Then vegetation like Red Maple trees, Prairie Fleabane and Canadian Horseweed is added. These are placed according to how they would likely grow in real life – too steep and a tree can’t take root. Too shady and sun-loving plants won’t thrive.

Ground textures are added to give more detail to the landscape like tree roots, fallen leaves and mud.

Finally we add cameras and sunlight and the result is a lifelike, accurate depiction of how Lower Manhattan may well have looked 400 years ago.

The images below show a work-in-process of the forest as the trees and ground vegetation are being placed.

1609_marsh_screen_capture
1609_forest_screen_capture

 

Hypothetical has a lot more in store as we continue to create our collection of historic CGI recreations of New York City, stay tuned!

Linux + V-Ray 3.x Update

Linux + V-Ray 3.x Update

7

Updated June 20, 2016 – Brian from the V-Ray forum has a couple of additional features that are not supported in exporting vrscene files from Max which I’ve added to my list below.

My post about using VRay with a Linux render farm has turned out to be easily my post read post, so it’s obvious I wasn’t the only one trying to figure out this combination.  That post was written before V-Ray 3 came out, so it’s time for an update.More

3ds Max + VRay Standalone is not as terrifying as you think

3ds Max + VRay Standalone is not as terrifying as you think

8

Update 15 June 2016 –

I have a new post up that updates this information with the latest in VRay 3.0!

Update 12 November 2013 –

There’s a collection of settings in the VRay RT parameters tab (change renderer to ActiveShade mode first, which brings up the tab you need, then switch back to Production render when you’re done) that controls whether things like XRef scenes and proxies are exported.  Enabling these makes a huge difference in how useful this cross-platform rendering method can work.More

Maxscript to Show Speed of an Object: Speedometer+

Maxscript to Show Speed of an Object: Speedometer+

3

Download Speedometer+

I was adding motion blurred cars to a project recently and since I already had the camera shutter set, I figured it would be easiest to start with a car going a reasonable speed rather than just trial-and-error to get the blur right.

So here is a quick Maxscript to show you the speed of an object.  Optional units are miles-per-hour, kilometers-per-hour, feet-per-second, meters-per-second and knots.  It works with any system units you have set except “generic”.More

Maxwell Light Lister

Maxwell Light Lister

1

Download Maxwell Light Lister

2013-05-10: It looks like there was a typo where I duplicated a variable name and Max 2014 isn’t happy about that.

2012-04-16: I made a small bug fix that afflicted certain uses of multi-materials.  You can always download the latest at the link above.  If you already have the script installed, just run the new one and any buttons or menu items, etc. you set up before will use the new version.More

Let's Talk
66 West Broadway Suite 306, New York NY 10007
646.630.8812 • info@thinkhypothetical.com