Planet Tech Art
Last update: August 22, 2014 06:59 AM
August 21, 2014

Get macroscript hotkey

While working on my mScrub plugin to add new features and do some code cleanup I stumbled upon the need to get whatever hotkey the user assigns to the macro since in the current version it’s hard coded to use the Spacebar.

I did some research but couldn’t find a native way to do it with Maxscript so I ended up writing my own. I’ve tested it in 2014 and 2015 which use XML keyboard files. I’ve put .NET XML classes into play with a XPath query.

Since I’m also relying on .NET to check what keys are pressed, I’ve decided to return a System.Windows.Input.Key object instead of the virtual key (integer), but this is easy to convert back.

If you have any other way to do this, I would love to hear about it! Just leave it in the comments.

fn getMacroScriptHotkey macroName = (
	keyInterop  = dotNetClass "System.Windows.Input.KeyInterop"
	
	kbdFile = actionMan.getKeyboardFile()
	xmlDoc = dotNetObject "System.XML.XMLDocument" 
	xmlDoc.load kbdFile
	
	root = xmlDoc.selectNodes ("//shortcut[contains(@actionID,'" + macroName + "')]")
	if root.count == 1 then 
	(
		xmlNode = root.itemOf[0]
		virtualKey = xmlNode.Attributes.ItemOf["accleleratorKey"].Value as integer
		return (keyInterop.keyFromVirtualKey virtualKey)
	)
	else return undefined
)

And you can use it like this, also included is how to convert back to a virtual key using KeyInterop class.

hotKey = getMacroScriptHotkey "mScrub"

keyInterop  = dotNetClass "System.Windows.Input.KeyInterop"
keyInterop.VirtualKeyFromKey hotKey

 

by Artur Leao at August 21, 2014 08:06 PM


The low status of software engineers

A couple weeks ago I read an article by Michael Church titled “How the Other Half Works: an Adventure in the Low Status of Software Engineers“. It is the story of Bill, who had two very different experiences interviewing for two different positions at two different companies: one as a software engineer, and one as a VP-level manager. Bill’s experience is as you would expect from the title. The article is well worth reading.

It was difficult to process the article’s conclusions, because my interview experiences have not been like Bill’s. In fact, in some cases it has been the opposite. I once interviewed for a management-level position that I was woefully unqualified for. Once it was clear I wasn’t the person for the job, they changed the day’s schedule to allow some engineers to unnecessarily hammer me with technical questions. Likewise, I recently interviewed for a software engineer position at a healthcare company with a very small programming team, yet was treated extremely respectfully by everyone, including the CEO. Furthermore, I know I am not guilty of holding software engineers in low status, as anyone I have worked with will tell you.

A few days later, after thinking about the article some more, I started to get some flashbacks*.

I wanted to make changes to scrum teams, consolidating several smaller teams into fewer larger teams. I was told “if we do this, it must be secret. We cannot discuss team composition with developers. They just gossip and act like children.

I was discussing systematic problems with management structure with a sympathetic senior manager. I was told “I once put forward a proposal that employees should choose their own managers. I was laughed out of the room.

We were considering two senior developers for a second Technical Director position. I was told “you must leave this to me to handle, we do not want them to know the other is being considered.” Of course they were good friends, and eventually made the decision themselves.

I raised an objection to a workflow a tools team had put together, concerned it put a large and unnecessary burden on content creators. I was told, “if they don’t want to deal with it, they don’t need to work here.

A team griped frequently about their tools, which were both essential and horrific. Management felt they weren’t sufficiently appreciative when any minor fixes were made. Instead of fixing the tools, they and I were told “there will be no more discussion of these issues, except as initiated by management.

Until now, I thought of these events as incredibly stupid decisions made by unqualified and disconnected individuals. Unfortunately, that’s not the case. These are incredibly predictable decisions made by normal individuals who are produced by a totally unsurprising system. Once the engineers are no longer running the show, they are quick to lose social status. Engineers remaining in management will be assimilated, demoted, or their position removed entirely. There’s no way to reverse this, and I think it’s why culture can so quickly spiral from enjoyable to miserable.

Finally, it’s also interesting to think about this in the context of the Silicon Valley “anti poaching” conspiracy which depressed employee salaries. It demonstrates the systematically low status of software engineers better than anything. Management at Apple, Google, Adobe, Intel, and more, saw engineers as mere pawns, while simultaneously acknowledging how vital they were to the success of those companies. What a world!


* If you’ve worked with me before, you can probably guess who some of these nameless individuals are. I have not obfuscated things for the sake of protecting the innocent, because I don’t find these shitty managers innocent.

by Rob Galanakis at August 21, 2014 07:45 AM


SIGGRAPH 2014 Short Review

It's been crazy times at Undead Labs as we get ready for Pax.  I did sneak in a lightning visit to SIGGRAPH, since it drive-able in Vancouver, but I had to cut it pretty short.

The highlight of the show was the TA beer night at the Butcher and Bullock  -- hats off to +Robert Butterworth  for putting together -- but there was some other stuff going on as well. Here's a very partial and completely unscientific brain dump of what I saw. The important caveat here is that my limited schedule kept me on a very short leash:  I spent all day Monday in the Advances in Real Time Graphics course, which I'm pleased to say has become a SIGGRAPH institution (go Natasha!) and then all day Tuesday talking to vendors, so I'm 100% certain to have missed a lot of cool and interesting stuff. This was an all business visit, so most of what I have to report is general impressions rather than new cutting edge research.  My impressions are after the jump...


Have a PBR!

The trend towards physically based rendering is getting even more pronounced: I think there's no question this will be this year's buzzword of the year, at least in games.  I've been working with PBR renderers at work (mostly, but not only Marmoset) and it really is a better way to work, at least if your working with realistic subject matter.  I've got an article in the works for 3D World about exactly this - lost somewhere in the labyrinth that is print production - and the takeaway is that it's a good thing for anybody in game art to be boning up on.

 The standard textbook, Physically Based Rendering, Second Edition: From Theory To Implementation, is a bit of a slog. It has great info but very coder-centric. The Marmoset site linked above has some great intro level material.  For a deeper dive there's this post from Sebastian Lagarde. There's also a couple of decent video intros:
Hat tip : +Robert-Jan Brems
I think there's a near-future blog post in all this somewhere :)

One side note: the need for high quality specular light samples - usually cubemaps - in a PBR pipeline has the nice side-effect that you can usually count on a reflection map for lots of areas which might not have gotten one traditionally. Combine with depth buffer reflections for fun and profit!  There were good talks from the Killzone and Thief teams about real-time depth buffer reflections which I think are going to make a noticeable difference in tone from last gen graphics as it becomes more common.

Free samples


One of the side effects of the new console generation is that everybody is revisiting antialiasing and sampling.  From 720p to 1080p means pushing more than 2X the pixels. This makes MSAA a worrisome burden: you've to do a lot of sampling at that res.

Not surprisingly there was a lot of interest in alternatives to brute force antialiasing at this year's graphics course. I particularly liked the paper from Michel Drobot of Guerilla on 'Hybrid Reconstructive AA', which to my less-than-wizardly ears sounded like a variant of temporal AA (in which you accumulate AA over a few frames by varying the precise sampling point in the 3d world a little bit on each render) spiced up by oversampling just the coverage buffer of the graphics card to get enough data to do higher quality sample weighting on the AA for edges.  I know that's kind of a sketchy description, unfortunately the paper is not up yet for linking so I can't go through it more academically;  however it will eventually show up on the course website at advances.realtimerendering.com.

Fabric 50

What does it say about me in my old age that one of the pulse-pounders of the show was a change in licensing terms? The Fabric 50 program is a new idea from the makers of the Fabric Engine. Fabric is a high performance, highly parallel computing engine that is intended to be used inside DCC tools like Maya or as the core of a standalone app. The key goal is to put lots and lots of power in a package that is usable by mortals so you can write a pretty beefy tool without having to go back to school and learn all the dark arts of multiprocessing and parallelism. The 50 program allows studios up to 50 licenses for free in an effort to get more tool makers using and evangelising for the tech. I'm pretty sure I'll be dropping this one on my tech director's desk soon.

The Dismal Science

Business-wise this felt like a slow year to  me. Not sure how much of that comes from the size of the venue, how much comes from Hollywood types skipping out on the cross-border travel, and how much is the result of the slow implosion of the big-budget FX industry but the overall vibe among vendors was fairly mellow.

The advances in capture and acquisition tech are kind of like those in cell phones: we're so jaded that we don't even notice the miracles anymore. I saw a lot of mocap demos - it's the siggraph show floor, so ball suits abound - and I was struck by how clean and lag-less the captured images were all round; even the bargain stuff looks pretty damn good these days.

There's no big 3d application booths anymore - the market has gotten so mature (or monopolized, depending on your mood) that big stage shows and high power demos you used to see are gone - the Autodesk booth was literally a 10 foot cube featuring primarily  abstract artwork.

One 3d app demo I did catch was a Modo 801 animation demo. I've been ambivalent about Modo's efforts to compete head on with the Max/Maya juggernaught, but I was quite impressed by their animation workflow (here's a video from their site, which covers a lot of the ground I saw in a more bullet-pointy fashion:)


I'm usually a bit suspicious of efforts to port the pen-and-paper workflow to CG, since I don't see the point in mimicking the artifacts of one medium in another. However the timing chart workflow is a fresh take on an aspec of animation which has been badly overshadowed by the minutia of rigging, and I hope it inspires everybody to kickstart the moribund business of animation software. Speaking of which, I had an interesting talk with the founder of French startup Nukeygara, who was showing an interesting and unconventional standalone animation package called Akeytsu (no, I'm not sure how to pronounce it either. It's French. Just roll with it!) This vid gives a pretty good idea where this is going:
 

I'm very curious to see how this one works out: I'm still waiting for somebody -- please! -- to shake up animation the way Zbrush has (and continues to) shake up modelling. Like recent GDC's it seemed like schools and training programs took up as much floor space as vendors, which is a little scary: call me selfish but I kind of miss the days when  our skills were rare and esoteric.  Of course, the kids coming out of these programs are all waaaay more sophisticated technically and artistically than I was at the same point in my career, so it's good for the art form I suppose.

Not for my ego, though.

The Meet Market 

 The Job fair was a tad small this year -- like the show floor, it might just be the distance from LA, but I'd say there were only about two dozen booths.  Many of these seemed to be BC based VFX houses as well: the hurly burly of the old days with 4 hour lines at ILM and Pixar was not much in evidence, at least not while I was there. I saw a handful of game companies (biggies like Blizzard and smaller ones) but things seemed a bit subdued. Here's hoping that's just an artifact of the time and place of the show.  Maybe there was more action in private suites and hotel rooms, perhaps the internet has taken some of the flesh-pressing out of the process. Still, a bit worrisome.




by Steve Theodore (noreply@blogger.com) at August 21, 2014 01:19 AM


New Animation Reel

It’s been a long time since I cut a reel and I’ve been meaning to for a while. Well, I finally got around to it! Ironically the newest work on here is still already a year and a half old:

Morgan Loomis Animation Reel 2014 from Morgan Loomis on Vimeo.

For the breakdown you can check it out on Zerply. (If you haven’t tried doing a breakdown on Zerply, it’s pretty slick).

Next up I’ll try to put together a separate rigging reel, whenever I find the time to do this again.

by Morgan Loomis at August 21, 2014 12:23 AM


Adding Sublime ‘Build’ Support for KL

fabric_build_kl

I have been dabbling with KL and that Fabric guys have some great introduction videos [here]. They have worked hard on some Sublime integration/highlighting, which you can find on GitHub [here].

While following these intro tutorials, instead of popping back and forth to your command line, you can actually compile/run your code in Sublime and see the results. To do this go to Preferences>Browse Packages… Then open that Sublime-KL folder, and inside create a new file called ‘KL.sublime-build‘, the contents of which should be:

{
"cmd": ["kl", "$file"]
}

Then just select KL from the ‘Build System’ menu as shown above, now press CTRL+B and it will show results inside the Sublime console!

The post Adding Sublime ‘Build’ Support for KL appeared first on Stumbling Toward 'Awesomeness'.

by admin at August 21, 2014 12:13 AM


August 20, 2014

Let’s get 3ds Max UI revamped with Qt!

Okay, I’ll be starting my personal vendetta with 3ds Max UI!

What I aim is something like the Maya team did in 2011 for Maya when they converted their UI to Qt. This doesn’t mean that 3ds Max as we know it has to change, but the underlying technology would make a huge difference for users and developers! Not to mention that Qt is cross-platform *wink wink*

Anyway, this is definitely a long term project since something like this would definitely take time to implement, but hell, no pain no gain right! Just imagine being able to completly customize your UI or as a developer, to create your tools and seamless embed them in 3ds Max! If you want you can read a bit more about Qt on Wikipedia.

Long story short, how can you help!? Easy, check the link below, it’s for Autodesk UserVoice, if you are not registered please register and vote. Share the link, ask your friends and coworkers to support the idea.

On my side, I’ll make the best I can to raise awareness with Autodesk that their user base wants this and is up for the challenge. Let’s do this!

 

Vote here!

 

by Artur Leao at August 20, 2014 09:14 AM


Submit!

For any readers who are thinking about doing a GDC talk in 2015, it's time to get your submissions in! Talk abstracts should be submitted by August 28th!


Tech artists are an important part of GDC: sharing knowledge, inspring people to work smarter, and teaching better ways to get things done are what we do all the time -- doing a talk is just taking your day job on the road. So hurry up and get those proposals together!

After the jump I've reposted an article I did for Game Developer  back in 2008 which outlines some of the things I think make for a good GDC talk.  Update: I added a longish list of stuff that has changed since the original 2008 article in the comments - in particular, don't forget to read the new submission guidelines and don't forget 25 minute talks if you're getting your feet wet


Why it matters


GDC is important because it is one of the few institutions devoted to spreading that knowledge around, instead of hoarding it. Older business has have professional schools and academic wings that help to keep them vibrant, and though we are gradually evolving these sorts of things as well we are still, on the whole we still have to do the spade work ourselves.

Being a GDC speaker offers a nice boost to a resume. It gives you some visibility among your peers and also gives you a chance to demonstrate your chops in front of an audience that's likely to contain possible employers who are looking for skills like yours.  If all that weren’t enough, speaking at the GDC earns you a free conference pass, a free tote bag, and the chance to bump into Will Wright in the speakers lounge. Not surprisingly, a lot of folks would like to win that coveted speakers badge.  

 It’s a good thing that the rewards are so steep (did we mention the tote bag?),  because putting  together a good talk is a serious undertaking.  It requires serious planning, because talk proposals are submitted six months or more before the show. It takes a lot of preparation: creating a slide deck, putting together example art, and doing enough practice to be a confident presenter. And it’s also highly competive – only a fraction of the talks that are submitted to the conference website are approved for the show.

How it works

It helps to understand how the evaluation process works. Proposals are submitted to the GDC via the conference website at GDConf.com, usually over the summer of the preceding year. The proposals are vetted by an advisory board of developers . The conference management recruits advisors from a number of studios for the various “tracks” or disciplines. The advisory board looks all of the proposals and ranks them on the appeal of the topic, the quality of the proposed treatment, and the track record of the speaker.  
The board is also responsible for filtering out the large number of talk proposals that are basically sales pitches or user-group style sessions.  

While there’s nothing  inherently wrong with a talk on your fabulous new motion capture camera or your amazing new paint package,  the conference tries to steer clear of potential conflicts interest by routing these through a separate process . You’ll see these sorts of talks in the show catalog as “Sponsored” sessions, as in “Sponsored by Autodesk”. If you’re thinking about a topic that involves a lot of very particular attention to one product, service or vendor you might want to get in touch with the conference staff before submitting your proposal in order to get a little more guidance on the rules for distinguishing between the regular conference sessions and the sponsored variety.

The Keys to a good talk

When you start to develop your topic, you don’t need to be too academic.  That’s how the programmers amuse themselves. GDC talk aren’t classroom exercises, they are a chance to share practical knowledge. The unique value of the show is that it’s oriented around a professional community.  You can pick up the finer points of Zbrush at your local branch of Gnomon, and you can get a lot more help for your keyframing skills from a few months of Animation Mentor than you’ll ever get from a 50 minute lecture.  What you can’t get anywhere else is the combination of technical information and rubber-meets-road experience that comes from other devs, so a good talk combines technical or artistic command of a given subject with an understanding of production realities. 

The Takeaway

The first thing the advisory boards look for in a proposal is the “takeaway” – the key nugget of wisdom that the audience will (hopefully) get from the presentation.  From a selfish standpoint, the conference likes snappy takeaways because those are what you show your boss when trying to wangle yourself a junket to the show:  Good takeaways make for more conference goers.  More importantly, though, the takeaway is a the acid test of what you’re trying to say in your talk – if you can’t figure out the two or three sentence distillation of what you want to get across, the audience and the reviewers won’t either.

A good takeaway is concise and straightforward. “Attendees will learn the pros and cons of the major normal mapping techniques, with particular attention to choosing the right technique for your game genre” is a good example while “Attendees will learn the coolest normal mapping tricks EVAR!” is not.  

Scope

As we’ve said before, the unique value of a show like the GDC is the combination of technical and artistic knowledge with real world experience. You can learn as much, or more, from your presenter’s accounts of hassles and failures as from the theory they are trying to explicate.   Thus this year’s talk on The Illustrative World of Team Fortress 2could teach a lot about dealing with multiplayer-only title or working with the Source Engine material editor, as well as offering some general wisdom about stylized character art.  The best talks teach general principles using real world production as vivid examples, striking a balance between simple post-mortems on the one hand and pure theory on the other.

Trying to go very deep is very tough in the typical hour-long lecture format. If you focus too closely on the precise specifics of a particular technique or technology you’ll probably lose many of your listeners in the thickets of details.  And if you can’t provide a larger takeaway, you won’t be able to reach audience members who work in other genres or on other platforms.  A talk about how to use non-linear animation tools to crank out lots of animations for multiplayer games, using your online shooter as a case –in-point  is going to work a lot better than a talk about the six months you spent getting everybody to learn the Trax editor in Maya.

On the other hand, overly broad talks are also weak. It’s a notorious truth, for example, that every year produces a large number of talks about art direction.  Most of these are good proposals from serious professionals – but the more broadly these talks are pitched, the more they will tend to overlap, so inevitably the large number of proposals gets whittled down to only one or two talks – there’s only so much room on the program for Grand Unified Theories of Art, no matter how worthwhile.   

On the other hand,   a talk about creating art direction for international products, with special reference to a porting a popular Korean game to the US, a primer on doing historical costume research as shown in a Renaissance themed adventure game, and a third talk about the special challenges of creating a visual direction for DS games can all coexist happily.  

Focus

 Working in an esoteric business like ours can be lonely. Every veteran game artist has a closet full of favorite tactics and war stories to share, and an audience full of the only people in the world who have any idea what you’re talking about is a standing temptation to cram every tip and trick of your career into your Powerpoint.  Unfortunately, that grab-bag approach may make good fodder for a bull session on the suite party circuit (or maybe not, as many GDC afterparty vets can attest… but we digress) but it’s murder for a GDC talk. 

Verbal presentation  is a much less efficient medium than print or the web; to really reach an audience effectively you need to make sure that your points are clearly marshaled an mutually reinforcing, and that means your talk outline needs to be clearly structured , well thought out presentation of your points and not just a laundry list.  Talk proposals with good topics and interesting speakers often fail to make the grade if they come with fuzzy or incomplete outlines – just as in high school English, coming up with a strong outline is the key to success both in the submissions process and in crafting a popular talk. Fortunately, a good takeaway and the strong hook will both nudge the proposal towards a clear, well focused structure. 

Credentials


If you haven’t given a GDC talk before, landing a speaking gig is more challenging. First-time speakers confront the same catch-22 that maddens first-time job seekers:  without any experience, it’s hard to convince people to let you earn experience.  Unsurprisingly, audiences and reviewers are attracted by well known names and high profile titles.  If you have had the good luck to work on a high profile franchise (or better yet, a big hit from the last year) your proposal will have a big leg up over an equally good submission from an eager but obscure competitor.  This probably means some good talks don’t get accepted, but it does reflect the preferences of the audience.

Naturally, if you’ve given a successful talk at the GDC before it’s also much easier to get another chance. The GDC carefully tracks audience responses – fill out those cards, people! – so that earlier talk might not be such an advantage if the ratings were unimpressive. The ratings are done on a 5 point scale – if a previous session averaged 3 or under, it’ll be pretty tough to win a second chance.

If your resume isn’t studded with million sellers, you should make sure to burnish up any other credentials you may have. Presentations at other industry shows certainly help, as does experience as a teacher or writer.  If your fear you're at a disadvantage in the credentials department because you should think about developing your presentation skills and name recognition. A semester or two teaching at your local art school or community college game design program can be helpful, as can a guest spot in Game Developer or other industry publications.  In any event if you’re worried about breaking in the hallowed ranks of GDC presenters, you have all the more incentive to really hone your proposal into an irresistible pitch.

Why Bother?


If this sounds  like a lot of work, it is.  Landing a speakers badge for the GDC is an accomplishment in itself.  You’ll need a well crafted topic, some hard won personal expertise, and the willingness to get up in front of an audience of smart, skeptical peers who won’t hesitate to call BS.  Is it really worth it?

Well, the practical benefits for your career are obvious – if you make a name for yourself as a presenter you’re going to have a big leg up in future job searches.  As  a side benefit, you’ll become a Jedi master of whatever subject you set out to speak on – no matter how well you knew it when you clicked the “send” button on your proposal, a few months of slide-crafting and run-throughs will force you to know the subject far, far better than you thought possible.

Even with all purely personal benefits, pinning on the lav mic and facing the crowd is also a real service to the community.  Older professions have a pretty good sense of what it means to be a member of the club – if you’re a lawyer or an accountant, you have a pretty clear idea of how you can expect your work life career to go. In our young (not to say “infantile”) business those expectations are much more fluid and are still evolving . Stepping into the spotlight for a few minutes is helping to define those expectations for yourself and for your peers.  What does it mean to be a “game artist?” You’re helping us all to figure it out. If that comes with a tote bag, so much the better.

by Steve Theodore (noreply@blogger.com) at August 20, 2014 01:56 AM


August 19, 2014

Happy scientific accident.

I was in photoshop and intending to use the gradient map. (Image > Adjustment > Gradient Map)
I accidentally clicked an existing saved gradient and realized I had made sort of a scientific texture.

You know, like that sort of stuff:



 Here's my photoshop gradient:

And that's the result on my texture:

The real question is: what on earth did I create such a gradient for in the first place??

by mkalt0235 (noreply@blogger.com) at August 19, 2014 07:48 AM


Rigging Dojo’s Artist in Residence (AIR) : August – James Direen from Reel FX

August 2014 (AIR) With James Direen from Reel FX, Thursday August 21st We would love to have you join the conversation by subscribe here.  We are very excited to have …

The post Rigging Dojo’s Artist in Residence (AIR) : August – James Direen from Reel FX appeared first on Rigging Dojo.

by Rigging Dojo at August 19, 2014 05:59 AM


August 18, 2014

A short letter to a unit testing newcomer

One of my friends asked how to get started with unit testing and Test Driven Development and figured I could write a short post. I also mention TDD a few times in my book so I think it could use some more attention.

I got started with unit testing when I wrote a smallish Python project, and realized I couldn’t maintain large Python projects without tests*. So I wrote unit tests for my code. I then quickly got into TDD. I don’t remember what resources I used, but there are plenty.

I’d encourage you to start unit testing by writing your code first, then the tests. As soon as this becomes easy and is paying off, start writing the tests first (TDD). You will come to appreciate that this is a powerful way of thinking and working. Even if you don’t ultimately stick with this approach, it is worth becoming skilled with it. You will uncover many suboptimal areas in your coding process that are otherwise extremely difficult to find and fix.

Keep in mind that learning TDD isn’t like already knowing Mercurial, then reading a book about Git**, and then being skilled with Git because you are skilled with Mercurial. You are embarking on a long journey, and will need to refer to many tutorials, blogs, and books. You will do some TDD, and look back on that code and process in a year and be horrified, just like you were when you started programming. Do not think of unit testing and TDD like learning a new framework or library. Think of it like learning how to program all over again.

So I don’t know exactly where to get started, only that you must, and keep going once you do start.


* I’d soon realize that no project was really maintainable without tests.

** Pro Git is my favorite Git book, by the way.

by Rob Galanakis at August 18, 2014 07:29 AM


August 17, 2014

Open Dialogue

Open Dialogue is a free and open source tool I’m working on that makes it easy to create dialogue trees or quests in a node graph UI. Best part is it’s standalone and so can be used in any game engine. All you need to know is how to read JSON data.

I’m going to cheat and place a link to the blog post I created on my company (Atmos Interactive) development blog.

CHECK IT OUT HERE!

by mattanimation at August 17, 2014 10:06 PM


August 15, 2014

The Oculus Rift

I’ve had may Oculus Rift Dev kit now for a good 6+ months and I must say I was rather impressed with the results. Yes there is latency, and the screen was a little more aliased than I was expecting, but the screen resolution isn’t that detailed (about 1280×760 per eye) so I won’t complain.  Michael Abrash gave a great  talk  at the Valve 2014 Developer conference where he explained the work they had been doing in VR and how in order for it to be successful, the device needed to create “presence”. Since then most reviews of VR gear like Sony’s Project Morpheus and Oculus Rift have picked up on that vocabulary. Check out that link to find out more about what “presence” entails, but in a nutshell it just means immersion to the point that even though you know and are seeing something not real, you feel like you are literally somewhere else.

So far the DK1 cannot deliver this, and unfortunately I think I ‘m part of that small percent of people who get a little sick from the latency that currently exists with it, but that has not stopped me from developing with it. The thing about VR that will be a challenge is how UIs will need to change in order to provide a nice user experience, as well as how users will control a character when not being able to physically see their peripherals (keyboard, mouse, etc.). Some Kickstarter projects have launched that demo alternative control devices with sensors in the fingers to allow for detailed character articulation, but at a price point comparable to the VR headset themselves.  I’ve seen some people hook up the LEAP Motion controller to the headset and use that as an alternative method of tracking hand movement and gestures, but that is still subject to lighting conditions and environment.

We just got the DK2 at work and I’m looking forward to checking out the improvements and tackling some of these challenges. VR is not going away anytime soon, for John Carmack and Michael Abrash to both leave companies they founded to work on Oculus and then have Facebook funding the project, it can’t fail. The only thing now is to create content and find out the best ways to have the users experience “presence” in the worlds we create.

by mattanimation at August 15, 2014 05:46 AM


Going TDD: first steps...

Hi folks,

I have a confession to make: I've always looked at test driven development with envy and admiration, but I had never really tried it due to the strong dependencies of the code I usually write... but it's even worse, I had never put a fair amount of effort on testing due to the same reason (I know, shame on me).

Until one day I finally swallowed my excuses and decided to go TDD on a proper project (mauto, more on this in a future post)... and you know what? it worked great!

I'm taking my first steps on this and I have no authority to 'teach' TDD, but I'm sure there are many TDs/technical-artists with the same preconceptions on testing and hopefully some of my humble findings could be useful for them.


Why testing? I know it's a good practice but...

That was exactly my thought for a long time: "this code is not a core library so it doesn't matter", "I have so many dependencies, I can't test this", "it would be nice but maybe later", "write tests sucks" and so on.

The thruth is: writing tests leads you to write better code and enables you to refactor your stuff without breaking everything as you do it. Think of it as a tool to back you up as you progressively refine the project.

Whithout tests you can't really work this way, your first take has to be the good one (which is never the case) and any later modification comes with a huge penalty, breaking existing code is inevitable.

What about dependencies?

Most tools I write are meant to be executed within a DCC (maya, softimage, whatever) and there's a strong dependency on their APIs... So, how to test this stuff?

Encapsulate your dependencies! write testable code is up to you.

The first change I noticed on myself was the need to think about dependencies in order to test my code, I started to encapsulate stuff instead of call expensive resources all over the place (i.e. writing all calls to the filesystem in a particular module, DCC calls on other and so on).

I'm not saying you have to write a complex software-agnostic wrapper or anything like that, just do your best to keep things thight in order to know where your dependencies are, otherwise you won't be able to replace them when testing your code.

Forcing yourself to be aware of dependencies seems to be a win/win situation as it enforces a clear separation of concerns on your code (even if you are not going to write any test).


Sounds good, where to start?

Structure:

We need to define a structure for our project! I highly recommend stick to the standard structure for python projects/packages, here's a quickstart guide.

You can also create your base structure using something like coockiecutter or similar tools, most IDEs set a base project for you.

Testing frameworks:

In order to rely on your tests to develop is extremely important have a mechanism to systematicaly run the test suite, it sounds obvious but it's not.

Python include several ways to write/run tests, for really simple use cases you can go with doctest, but most of the time you will be better of writing your test in a separate module using somthing like unittest.

These modules works fine, but I personally feel more confortable using a boilerplate-free alternative as nose or pytest. Just choose your weapon and stick with it!

Mock:

Other important aspect of testing has to do with replacing the expensive resources during testing, this way you can run them faster and without affecting production assets in case something goes wrong (databases and what not).

For this situations there's a python library called mock. I won't cover how to use it, but it provides a nice placeholder that you can use to monkeypatch your dependencies during your tests. For further information refer to its documentation.


Everything is set, now what?

Short answer: start with the readme file!

This is not TDD per-se, but write down a high level snippet about how to use your code is really useful and gives you a nice starting point.

Let's say we want to develop a pose library (this comes from the top of my head, please do not take this example too seriously):

import pose_lib

# init rig from the scene
ROOT_NODE = "C_John_root_C_GRP" # node name
rig = pose_lib.Rig(ROOT_NODE)

# list john compatible poses
pose_lib.list_poses('John')

# apply a pose to John's rig
pose = pose_lib.get_pose('John', 'stand')
rig.set_pose(pose)

# add John's current pose to the library
pose = rig.current_pose()
pose_lib.add_pose('John', 'my_pose', pose)

# and so on...

Boom! We have just decided to interface with maya nodes through a class called Rig and access the library through a couple of functions (there's probably another class managing json-files/sqllite/any-kind-of-storage under the hood).

Just think how you would like interact with your finished project and write it down (wait a minute, we are also documenting!).

Let's write some code!

First, let's assume this structure for our project:

  • pose_lib/
    • pose_lib/
      • tests/
        • __init__.py
      • __init__.py
    • LICENSE.txt
    • README.txt
    • setup.py

The first test is the hardest! that's why the readme is so important.

1- Reading the readme snippet I would go writting a test as follow:

# file: pose_lib/pose_lib/tests/test_library.py
from nose import test_with
import pose_lib

def setup():
    pose_lib.add_set('test')

def tear_down():
    pose_lib.remove_set('test')

@test_with(setup, tear_down)
def test_list_poses()
    assert isinstance(pose_lib.list_poses('test'), (list, tuple))

setup and teardown functions are executed before and after the test function (the decorated function), other testing frameworks (this one is nose specific) should provide a similar way to do this.

2- ... which lead us to write this:

# file: pose_lib/pose_lib/__init__.py

def add_set(set_name)
    pass

def remove_set(set_name)
    pass

def list_poses(set_name):
    pass

3- ... and run the tests (from the root directory in a terminal):

python setup.py nosetests

Most IDEs and code editors have a built in function to run the test suite for you, if you're using an editor like sublime text you can take advantage of the build system to run the tests.

4- ... and refactor the code until all tests pass...

5- ... and write new tests...

6- ... and repeat until the project is completed.


Do you see where we're going with this?

Is that simple! of course there will be some work to do in modules with dependencies (take a look at mock's docs; there are ways to patch objects, simulate return values and so on). With not-so-much effort you should be able to run your tests outside maya/softimage/whatever as any other python developer (that means you can go faster and lighter on early stages of the project and hopefully write better code).

There's much more to say about testing and TDD, things like coverage and what not... but I think this is enough for a first contact.

Is it doable on the project you are working on? Do you have any experience working like this? Anything to share?

Would love to hear what you think about this, please leave me your comments below.

Cheers!

by Cesar Saez at August 15, 2014 04:00 AM


August 14, 2014

SIGGRAPH: Real-time lighting via Light Linked List

Abdul Bezrati (Senior Engine Programmer) presented “Real-time lighting via Light Linked List” as part of the Advances in Real-Time Rendering in 3D Graphics and Games at SIGGRAPH ’14. Description: This is a brief description of a new rendering technique developed at Insomniac Games called Light Linked List or simply LLL. The LLL technique stores dynamic […]

by macton at August 14, 2014 09:50 PM


A manager’s primary job is to build trust

While interviewing for my new position at Cozy, I was repeatedly asked what the job of an Engineering Manager is.* By the end of the day, I had decided (for myself, anyway) that the most important job of an Engineering Manager** is building trust.

  • Senior engineers must trust you. They can succeed without you, but you can’t succeed without them. Why does your job exist? It isn’t enough for you to trust them; that’s a prerequisite. If you don’t trust them, that needs to be rectified first. If they do not vehemently trust you, your role is not just worthless, but a net negative.
  • Junior engineers must trust you. They need to have a reason to stick around. They must trust that you are giving them opportunities, and they don’t need to leave to be treated better. They need to trust that they are learning, growing, advancing. Finally, they need to believe that if and when they leave to see what else the world has to offer, they will be welcomed back. If junior engineers do not trust you, they will leave, and take their ideas and passion with them.

  • Design must trust you. They must believe you when you present estimates or assessments from engineers. They must believe that they are getting good information from you, and you aren’t an out of touch middle manager. They must see continuous improvement and engagement from the engineers. They need to trust that you and the engineers are working towards the same goals as they are, with fire and passion. If design does not trust you, you are damaging engineers and company and should just get out of the way.

  • Management must trust you. This is generally an easy one, because if they don’t trust you, they should fix it or remove you.

  • Finally, one that cuts across roles: malcontents and metathinkers must trust you. Many people (especially engineers) just want to avoid politics and are happy to work on on their tasks and not ask questions. As long as you don’t actively screw up, these people will usually trust you. Much more difficult are the critics. They come in all shapes and sizes. It’s not that they need to agree with you, but they do need to trust you. These people often have big ideas and cultural influence. Distrust will drain your organization of talent. As a member of this category, I take this very seriously. When I’ve actively distrusted management, and subsequently left, there’s been a flight of talent afterwards as problems get worse. I’ve written about the importance of the malcontents on this blog before, and as a manager it’s always been a yardstick. If malcontents and metathinkers are leaving, something is going very wrong.

  • Trust is probably the most important metric for whether you’re doing a good job and your organization is healthy. It is a product of some actions, and a foundation of others. If it’s going up, your organization is getting stronger. If it’s going down, you need to get to work.


    * I really enjoy interviews, especially in-person interviews, because it really helps me clarify my beliefs. This can lead to a high bounce-rate, but generally I’m left with culturally compatible companies after that. I consider this a benefit but YMMV.
    ** Any manager, really.

    by Rob Galanakis at August 14, 2014 07:50 AM


    August 11, 2014

    “Do you expect too much from people?”

    Last year, a coworker asked me if perhaps I expect too much from other people. I thought about it a moment and said:

    No. I do not accept the argument that I’m somehow inherently superior to most others. In fact it is because I know I am not superior that I have high expectations of others.

    In the intervening year, I’ve come to see that this belief drives a lot of my management philosophy. In general, I assume the best of people I work with. If someone is not performing, I do not blame them; I blame myself (or whoever their manager is) and systematic problems that they are not in control of (but hopefully ones I am).

    Of course people have different innate abilities and experiences. Some people have a high aptitude for certain types of work, and some have chosen a path that may not be a good fit. But the realities of business are that these things can quickly change, and an asset one day can be a liability the next. When a company has grown past a dozen people, I believe its time to start favoring nurture over nature. If someone isn’t performing, it is management’s problem.

    This is true of not just employees, but other managers, and it was specifically about two other managers that this question was posed. The times were a-changin’, but these individuals were in roles they were ill suited for. They simply did not have the experience or competence to drive through the changes that needed to happen. It was up to their (our) management to take responsibility, but instead I heard apologies that “maybe they aren’t the best suited” and other meaningless explanations. I didn’t expect them to magically change; I expected management to do their job: get involved and well, manage!

    If I expect something, it’s that people can both teach and learn. If the ability of people to grow is not an organization’s chief expectation- if management is not set up to grow employees, or management is not prepared to mature itself- I can’t imagine what they think their long-term prospects are. Perhaps they aren’t expecting much.

    by Rob Galanakis at August 11, 2014 07:08 AM


    August 09, 2014

    RYSE AT SIGGRAPH 2014

    ryse_sigg

    Crytek has won the SIGGRAPH 2014 award for ‘Best Real-Time Graphics’ with Ryse: Son of Rome, check it out in the Electronic Theater or Computer Animation Festival this week at SIGGRAPH.

    We are also giving multiple talks:

    I will be speaking in the asset production talk, as well as Sascha Herfort and Lars Martinsson. It’s also the first course we have done at Crytek where the entire course is devoted to one of our projects and we have 50+ pages of coursenotes going into the ACM digital library.

    The post RYSE AT SIGGRAPH 2014 appeared first on Stumbling Toward 'Awesomeness'.

    by admin at August 09, 2014 10:54 PM


    August 08, 2014

    3ds Max and Maya API Survey – For developers

    If you are a developer for Max or Maya, you should definitely participate on this!

    3ds Max API Survey: https://www.surveymonkey.com/s/YKHSTTB

    Maya API Survey: https://www.surveymonkey.com/s/NR7Y3SS

    by Artur Leao at August 08, 2014 03:19 PM


    You must manage what you can’t measure

    We all know the quote:

    You can’t manage what you can’t measure.

    The quote is often incorrectly attributed to W. Edwards Deming. Thank goodness, because that sentiment is absolutely ridiculous, and Deming is one of my heroes. In fact, a more accurate Deming quote is:

    The most important figures that one needs for management are unknown or unknowable… but successful management must nevertheless take account of them.

    It’s very important to understand how absurd the “can’t manage what you can’t measure” idea is. It leads to articles like this:

    It is an old management adage that is accurate today. Unless you measure something you don’t know if it is getting better or worse.

    No, it wasn’t accurate when Peter Drucker promoted it, and it isn’t accurate today. This quote is so counter intuitive, I’m not sure it became popular. Are your managers idiots? Are your employees automatons? Do you believe you can measure everything about your business? That the more you measure, the more successful you will be?

    If you want to truly engage with employees as empowered and creative individuals, you must manage what you can’t measure. If you want to create a learning organization optimized for long-term health, you must manage what you can’t measure. To forget this is to engage in one of the great sins of management.

    An absolutely wonderful book on this topic is Measuring and Managing Performance in Organizations. I really encourage anyone who believes that measurement is a prerequisite for management read it. It explains, with anecdotes, statistics, and logic, how depending on measurement will lead to deep organizational problems.

    by Rob Galanakis at August 08, 2014 07:24 AM