Tag: lightwave

Commercial: Vector Solar Green House

faulknermanoLeave a comment

Remember that this work thread is about the fact that cg projects are rarely straightforward; one artist might look he’s not doing anything, when, in fact, he’s doing everything, and vice-versa.

My contribution to this commercial is intermingled with the fact that it had been animated, and its look set up by someone else to be rendered in Octane, a GPU-based, unbiased renderer, presumably to make rendering faster and more beautiful. However, it wasn’t faster, and it wasn’t that much more beautiful, as the look was mainly AO-like. Time was running out. We have a renderfarm that can render mental ray, V-Ray, LightWave, and After Effects; but not Octane. So, it was passed on to me so I can render and comp it in time. Not surprisingly, it wasn’t just about hitting the render button in LightWave.

I took the original assets, replaced everything with LightWave shaders, tweaked the shadows and diffuse shading so that they matched, as close as possible, to the original test Octane renders, and had to fix many of the errors present in the scene, as well a number of broken models. I strategised on how much needs rendering based on the animatics; I used Janus, the ultimate LW ass-saver, to breakout lots of the necessary animated elements and mattes, and rendered them; Richard and I did the motion graphics, and I comped everything for the final product in After Effects.

This hot-potato workflow, in which a project is tossed completely to another person to be rescued, is out of my control; I simply have to do it. The main problem I have with it is that few recognises it as that: a pawning-off of accountability and yet accepting the full credit for it (as such, I’m not credited). And, again, this is why this work thread is being written: a project like this would not have seen the light of day if someone hadn’t objectively dealt with the details that were required to actually finish the job to the client’s standards. What you see isn’t what went on.

There are hard facts in professional workflows, which some are in denial of. Workflows that fly against simple reason will not get them where they want, no matter how much they cuss or growl at the monitor. There is a lesson to be learnt here, but are those who need to learn it actually get it?

Vignette: Forest Road

faulknermanoLeave a comment

About a year ago, a client connected with Toyota requested a bid from the company. Part of that request was a edited compilation of the commercial style they were looking for. It was slick; fast-moving, lots of stylised cinematography. We didn’t get it, and for reasons I never usually know. Yet, it was no surprise; nothing in our company reel resembled anything like it.

I thought — it was not a new idea for me — why not take some cuts from the compilation, and recreate it in 3d or something? The simple thought was that at the end of it, new slick material can be put on the reel. I attempted to do this by creating the road forest scene you see above; this was based on one of the scenes in the compilation, though I had put in more detail and brightened things up a bit.

To be honest, this piece is half-baked, as I was soon overrun with other work and didn’t bother to revisit it, mainly because no one else in the company was interested in making new in-house material.

The song is by Graham Hadfield, whose Carbon album I first heard in a Guardian online article on Arctic drilling. Pretty interesting stuff.

Commercial: James and Wells

faulknermanoLeave a comment
jaws_thumb_1
(Click to watch video)

I should say this is a “bit of an odd one”, but then I would sound like broken track record, wouldn’t I?

Yes, it’s another odd one, internally called JAWS, it was abandoned like a mutant, tossed like a hot potato into the hands of the poor soul who needed to resurrect this dying pig… or sheep.

Fortunately, I was not the poor soul, but Richard Falla. Pitying his sorry life dearly, I extended a finger — my pinky, to be precise — to assist his writhing body out of the the slings and arrows of outrageous fortune.

So I made racist kiwifruit drop from the sky and flags wave. Cool. In the meantime, Richard rescued the job from burning in hell.

Commercial: 5 Seeds

faulknermanoLeave a comment

This was another sub-contract from Australian vfx vendor. My contribution here was the extension of the trees at the beginning of the ad, which featured apples (real apples either weren’t on season at the time, or that they were apple trees to begin with). We bought some stock trees, I populated them with apples, shaded, lit, rendered in LightWave, and integrated them into the foreground and background areas of the matchmoved footage.

The trickiest bit, actually, was the Australian vfx company. They operated in Nuke, and required lensing data to be piped back to our renders. But while they knew their own process — which involved UV remapping, I hadn’t done it to other vendor’s specs before during post-production, but it turned out all right in the end, as it usually does.

Commercial: Hyundai ix35

faulknermanoLeave a comment

This was a sub-contract from an Australian vfx vendor. Terry, with an assistant intern (which was more trouble than help), built rickety structures on the bridge and gave it an gloomy look. My main contribution to this was the front-on car shot on the bridge; I tracked the shot in PFTrack, though it couldn’t completely solve it; I had to hand-track to start of the shot. I modelled and shaded broken old wood that the car was driving on, lit and rendered layers in LightWave using Janus, and test-comped it before sending it to OZ.

I admit that it’s nice to have been involved with an ad that simply looks nice, even though I had absolutely no control or even input on how the other scenes — and the ad as a whole — was going to look like. Implicitly taking credit for being associated with the ad’s look is as easy as simply letting others naturally assume it. Let that not be the case here.

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.

 

Retirement and Retrospect: Janus EOL

faulknermano5 Comments

After some thought last year, weighing in what I want to do for the future, I  decided that I should ‘clean my closet’ first. And one of the things that stood out in that closet was Janus development. There have been no new sales for Janus for quite a long time now, unsurprisingly, because I never really made any respectable effort in its marketing. Besides a few clients, its userbase has equally been quiet. And so I’ve decided to retire Janus from commercial development, and the main reason is that I can’t see myself guaranteeing the same kind of support that Janus users have enjoyed through the years for free.

It feels like a nominal thing to say that Janus is no longer being developed because Janus dev hasn’t been as active, and I’m pretty sure only a very few are concerned with its development anyway. If anything, announcing the fact will simply get me off that spectral hook of ‘developer obligation’ for EOL products. At least that’s what I hope.

I’ve always said in the past that Janus was never meant to be a mainstream tool. But over the course of the years, I learned one major reason why: many LWers didn’t try it. Part of me comprehends the rationale that the Janus video tutorials described a workflow that they didn’t like, or was confusing. But this is what I couldn’t understand: despite the complaints of the lack of a render layer system in LW, why people wouldn’t even attempt a free try in the hopes that they make something out of it.

Then there was the price point of 200 bucks (later 100 bucks) which might have made it totally incompatible with their idea of a layering system, no matter how well (or badly) designed. I kept hearing their demands to NT to put a layering system in there as part of their LW upgrade path, avoiding the need to invest in a 100-200 dollar plugin. Apparently, they’ve been waiting for a long time: at least 7 years.

What strikes me ironically, in retrospect, is that if they had invested in Janus from the beginning, it would have been a free Janus upgrade path from then on. Of course, I can’t say that I would have guaranteed it, though it seems likely since it was the case despite the minimal community support behind it. It would have been a very small price to pay to have such a tool that early on in LW9.5 — LW 2015 still does not have a functional equivalent of Janus or a render layer system. I say that in retrospect; a few Janus users have been saying it for years.

Most LWers have lived without a proper layering system, because the need is not truly pressing for most of them; I think despite their complaints, they can wait 7 more years if they have to.

Whether or not I would have stopped development regardless of its popularity is something I will never know myself. To me, Janus, as a commercial product, has run its course. I think it does a lot more than what was advertised, which is a good thing for me as a developer; I’m proud of what I’ve accomplished, but more grateful for the things I’ve learned developing this tool. Janus is still available to be bought, but no support will be given (unless I can actually afford to), and I will try my darnedest to ignore bug fix requests: it’s easy to get obsessed with them, and they eat up lots of my time.

This is not to say that I’m through with Janus: I use it daily, and I will continue to code it to solve problems that I encounter myself. I may yet support Janus in the context of a company as a technical consultant, which is a better use of my time, and I can be actually recompensed for my work. I may fork it, or create a derivative for other progs like Maya — who knows, really? The future unknown, and I’d rather not try to plan or predict. I’ve focused on tools for the most part of my vfx career, and left creative pursuits largely untravelled. And that’s where I’m headed next.

User functions FTW

faulknermanoLeave a comment

Here I am, few days later talking about user functions in Janus again. Why not? It’s been giving me results and it’s fun to play with — as a TD, I mean.

Back at work I wanted to output an RGB matte for multiple instanced object. LW doesn’t have a way to do a scene-based surface override on an object (perhaps shaderMeister?– though I don’t know if it the Spot Instance node will work with it). Basically, I wanted an easy way of assigning RGB colours to items in a particular group.

Before, Janus’s item processing was strictly group-oriented, where group settings were simply propagated to the items. There was no way to individually and programmatically affect certain items within the group. So in the latest rev, I changed that. But the important bit was that I tied it (again) to user functions, and I embedded a new context — the group item context — through populating two constant variables relating to the group item’s index and name. In this way, the user function can be created that references the group item’s index, and based on that value, the command parameters can be changed on that particular item as it is being processed. It’s basically a ‘last minute’ change in the render pass settings just before the group item is applied its parent group settings.

Since user functions are basically string replacements from within the cmd line, there’s a lot of flexibility (but can also end up a heaping mess if the Janus user doesn’t watch it), so that I can dynamically various bits of settings; I’m not limited to adding one parameter, for example, because I can just concatenate the new subcommands in the return string; so as along as the final resulting cmd line is syntactically valid, Janus will grok it.

Janus for Mac

faulknermanoLeave a comment

It’s a bit too early to shout out, so I’m whispering here in my little blog about Janus for Mac. I’ve restarted development for the Mac. It basically just took a weekend to hunker down and sort what was going with it.

The biggest issue that I came up with was the use of LScript’s store() and recall() functions, where in Windows it uses the registry to store the information. In the Mac, I’m not sure where it ends up, but apparently, calling it those functions multiple times seemed to put LW in a state where it could no longer stream more files into memory. It was as if the i/o was full.

I avoided this by redirecting the functions; this was already facilitated by the fact that they were already housed in custom functions, and all I had to do was make it everything cohesive. I also cleaned up the code so that the array that Janus uses to store settings were more consistent, and that the PC version should remain unaffected by the change.

At this point the Mac seems to be very workable, and I’m probably going to do a few iterations of tests in the coming weeks. And who knows? — it may come out officially soon after that.

User functions revisited

faulknermanoLeave a comment

User functions have come back, and what seemed to me at the time an excuse to implement a structure that’s both ambitious (because it wishes to liken itself to Houdini) and hacky (because it ain’t Houdini), seems now to have been vindicated.

Talking about user functions is like talking about… well, nothing analogous I can pick out: no one relates to it, not because it isn’t uncommon — cg ops use it all the time in other progs — but because it’s in Janus, and thus LW, and among the LW crowd, it’s weird.

But then I contact this person asking for some scripting help; he’s made his assets and scenes, and needs a way to break out passes; I learn about what he particularly wants, and think Janus fits the bill, albeit requires a bit of modification to get the exact workflow. I ponder how much modification is needed. Then I realise that I already have a system of user customisation in Janus: user functions. But user functions, prior to this new development, was only in the realm of the more broad render pass settings (eg subcommands, and the cmd line). What was needed was to expand the same functionality to partial surface overrides, which were contained in text files.

This modification — user functions implemented in partial surface overrides — was done in one night, because there wasn’t much fudging of code; the functions were all there, and all I needed to do was apply the right timings so that the parsing functions didn’t fall on top of one another, and that the proper variables were being populated first before passing it on to the user function. So now, using the very system I made for Janus users, I’m using that system to get unique results instead of hard-coding things in.

I’m very grateful, and again, feel vindicated, that by not taking the easy route, by sticking to the vision I had for Janus, I am seeing the result of the flexibility, which I had hoped would be more evident to LW users. While I still inwardly bemoan the fact that Janus is not a very popular tool, it’s hard to feel sorry for it when its proving itself up to task in more and more situations.