Tag: houdini

Commercial: Tip Top Popsicle Smoothie

faulknermanoLeave a comment

This one was a long, drawn-out schedule. In order to accommodate its numerically-challenged budget, it was thought that the schedule could be extended to several months so that we could put in other jobs in between this one. However, near the end of the schedule, we started picking it up again in earnest, and ended ironically with a quick tempo. Over-extended jobs like these invariably turn out to be rush jobs in the end. This wasn’t the case of procrastination, but the limiting of hours that could be spent on it. Consequently, we were set to do other jobs, and in the end, it could be argued that we had to spend more time on it due to the inefficiency of going back-and-forth different things.

My contribution to this ad was that I helped think out the render strategy, helped the render layer setups, modelled the base of the blender (yay!), troubleshooted character models as it relates to the rig, did the white mist effect using Maya fluids, did a breaking ice simulation that replaced by another simulation, helped shade a few of the elements, and assisted in the initial comping.

The render strategy was thought out early; we saw the character design as a final art for a poster, and Terry and I worked out the booby-traps in making this character work in 3d. It all boiled down to the refractive properties of the characters especially around the cavities (eg eyes, mouth). If modelled literally, the character would look wrong (and slightly horrific) in many angles, since the glass would refract the dark cavities.

The solution was to make render the glass as though the smoothie content was unbroken by the mouth or eye cavities. This way, the refraction was as seamless as possible.main_v010_BTY_blenderGlass.0039Then, it was a simple matter of comping, using masks, the mouth cavity and eyes, and the rest of the limbs.

main_v010_BTY_blenderBodyParts.0039

 

Apart from my usual responsibilities maintaining scene integrity throughout the whole project, one of my other main contribution, was rigging the characters, which I used AdvancedSkeleton with. The rig went through a lot of iterations in its cycle, mainly to do with consideration of the render elements that changed as we moved forward. Towards the end, collision objects were added into the rig to affect the ice that broke apart around the characters.

Because these two characters were identically in many respects, yet had considerable differences, too, I opted to create a generic rig was which featured elements from both characters. The most notable feature are the fruits sitting on top of the characters. A simple boolean switch handled the switch between the ‘pink’ and ‘purple’ characters.

In keeping with Sandline workflow the rigs had to be uniquely named, so I wrote a simple variant export. When a rig change had to be made, the generic rig was modified, and the variant export was done.

One of the workflow strategies we developed in the Mother Earth Pingos ad was using rigging low-resolution meshes into lattices in the rig itself, whose lattice points would be exported as vertex animation. Then we use the same lattice setup in the models file, and put the high-resolution meshes there. This is the approach we used for controlling the high-resolution fruit meshes on top of the character (though, on reflection, a lower resolution would have sufficed).

2016-02-10 12_40_21-Autodesk Maya 2015_ r__3d_2015_07_TipTop_Popsicle_Smoothie_3d_scenes_rigs_PINK_r

 

 

Janus Macros – Problem of Permutations

faulknermanoLeave a comment

Long live Janus. ;-)

 

I’ve been doing some custom development for an architectural visualisation company in Australia called 3DVIZ recently. During Janus’s commercial phase,  3DVIZ bought a licence. It is usually the case that I don’t know what Janus user actually do with Janus technically-speaking. Few users ask for feature requests, and even fewer ones explain their workflow and how to better improve it through Janus. That’s mainly why Janus developed the way it was: my own personal production needs, and my curiosity in proceduralism.

It is the proceduralism that seemed to draw 3DVIZ into Janus. When I wrote the FOR loop constructs in Janus, it was mostly out of admiration of Houdini and the curiosity of what proceduralism could look like in Janus. No had asked for it, I only had an inkling that I may, just possibly, need it if ever the chance I get into a large-scale project in LightWave. But, if I’m honest, I’ve never actually used FOR loops for any of my commercial projects; none of them were ever big enough to warrant to advantages of using the feature.

When 3DVIZ contacted me for support, I realised that they were using it in a far more advanced way than I personally used it as a TD in commercial work. It was gratifying to see that someone actually had some need to proceduralise their scene management and rendering to that level, and that Janus’s FOR loops actually made all the difference.

3DVIZ approached me again with a permutation problem. From the little I know about it so far, their asset hierarchy is well-organised (ie rigid). And this is the case because they need to be able to render more variants upon variants; from a house, they render parts of the house in varying configurations, each with their own types of materials, and so on so forth.

Part of 3DVIZ’s own request, since they know their problem more than I do, is to enable them to automate scene loading and Janus operations from a more ‘global’ script; as FOR loops handle the breakouts for any given scene, now they want to expand that capability across scenes. The concept is similar to LightWave’s own Render-Q script, where a script resides ‘persistently’ and orders LightWave to do tasks.

The most obvious idea to automate Janus is to allow it to accept macro commands. A ‘controller’ script handles the scene loading, then writes a macro to a file, which contains commands to breakout so-and-so render pass; then signals Janus to receive the macro; when Janus completes the macro, the ‘controller’ loads up another scene in its queue, then writes another macro, and repeats the procedure.

Thanks to the years put into Janus, the implementation of macros was clean, and with some limited testing, the concept works as well as imagined.

However, my main obstacle would be their expansive asset hierarchy. The real challenge is to make sense of it in my head, and design a ‘controller’ script that creates sensible macros that solve 3DVIZ’s particular problem of permutations.