D Major Studio
  • Demo Reel
  • Gallery
  • Blog
  • Contact/Resume

Archiving some scripts from work

8/23/2014

0 Comments

 
One of my assumed responsibilities from work was to write scripts for my own use and the use of members of my team. Now that things are winding down for me at this job, I'm going through my scripts and trying to salvage usable modular code.

A few thoughts while I'm doing this...
- Write things cleanly the first time and save some grey hairs trying to figure out what you did, why you did it, and whether you could use it on a new project later on.

- Think through logical iteration/algorithmic process before creating endless exceptions with "if <variable> == <value>:" statements...

- Raise descriptive errors if the code is executed in ways other than expected and just... dies.
(Prevents: "...uh... um... huh? <opens code, eyes glaze over>" scenario)

- Comments. What did you want to do with that function?

- Doing something more than once or twice in your function? Write a new function to handle it.
    - Add comments to explain dependencies...

- When writing tools, try to compile commonly imported self-written functions/modules to reduce the amount of gopher-tunneling.

- If there is some condition or situation needed when running script, comment on what it was.
("Oh... this doesn't work... why? Oh, because the curves selected need to be dynamic and their output has to be named with '<very specific suffix>' ...okaaaay, even though that script might have been useful, there are too many other things I need to look at to spend time setting up that situation to test the script.")

- For the love of God, comment and date updates to code in the header. Less of an issue if working with a release system or git repository or whatever which keeps track of changes. For little personal code which may be saved in more than one place, keep track of the dates and changes made. Can help prevent needing to solve the same problem/bug again.
0 Comments

Volume Shader setup

3/10/2014

0 Comments

 
Here's an example of something very screwed up in Maya...
Without going too far into it; MEL commands perform some checks when certain operations are performed. Things like... updating the available renderer UI or lists, etc. These feedbacks are done after all commands in a script are run and sometimes cause RuntimeErrors if you do not provide the MEL based check in your own script.
This is something I've wrestled with for a little while and found this morning. I'm still not convinced this is the best way to approach the problem, but here it is.

Oh, and this script takes polygon geometry and lights selected and creates/assigns a parti_volume shader, linking lights to the parti-volume to prevent errors, while changing renderer settings to work with a single click.
Volumetric shader setup
0 Comments

    Categories

    All
    Dynamics
    Fur
    Hair/Fur
    Scripting

    Archives

    September 2016
    April 2016
    June 2015
    August 2014
    March 2014
    September 2013
    January 2013
    March 2011

Copyright © 2016 - David Major | 778.886.8073 | major@dmajorstudio.com