Skip navigation

Monthly Archives: February 2013

There is this misleading marketing tactic used by coffee vendors, to sell you _dark_ roasted coffee as “stronger” coffee. Dark coffee is often labelled “robust”. The truth about “dark coffee”, which I’ll admit I didn’t know before:

1) DARK is a reference to HOW COOKED it is. Very dark coffee is very, very burnt.

(image from here)

2) There are tons of varieties of beans, but you can make dark and light coffee from the same original bag of beans. “Dark” coffee does not come from a “darker bean”. (In fact original coffee beans are always green).
3) You need higher quality beans to make and sell a light roast.

Companies like kicking horse coffee, seem to market dark roast as “more hardcore”. “454 horse power”, “Grizzly Claw”, “Hoodoo Jo”, and yes, even “KICK ASS!”, are all dark roasted coffees sold by them. More apt names would be names like “Volcanic”, “Pumice”, “Supernova”, and “Total Destruction”.

In fact, dark roasting burns away some of the caffeine (so there’s less caffeine in dark roasts, NOT more as “KICK ASS!” or “454 horse power” might have you think at first).

So the point is, there’s this misleading notion everywhere (with respect it’s not all coffee vendor’s faults.. but most people just don’t know)

Yes, in my opinion, dark roasting all but destroys the bean. I have started to believe coffee companies just want to sell more bean by selling off the crappy dark roast. Also DARK ROAST MAKES ME TIRED. I drink a lot of coffee and if I have 2 cups of dark roast, I won’t have nearly the same energy I will have if I drink 2 same “strength” cups of light roast.

Advertisements

So you wanna MEL script, do you?

But you don’t want to learn MEL scripting? And you don’t want to read about it??

Fortunately, MAYA is very cleverly built. It turns out that EVERY UI action you do with the mouse, turns into a MEL script command, which MAYA then executes.

So here’s how you can generate your own MEL script for your own tedious task.

1) Open the script editor

Now try something. Select an object with your mouse. You should see pop into that “script editing” dialog a line like:

select -r pSolid1 ;

That, sir, is the MEL script command to “select” an object. Namely, the object that you just clicked on with your mouse.

So, carefully click through ALL the actions that you need to do your tedious task. Copy and paste each MEL script action into your own MEL script.

You may need to tweak it a bit to get it to work in the end, but it is a quick and easy way to LEARN MEL scripting, as well as generate the correct MEL script for the task you want.

The basic steps are:

1) set up your model and textures / scene for baking
2) right click the object to bake, choose baking/assign new bake set…
3) set up the parameters for baking as you like. to re-edit them, right click the object, then select baking/edit attributes/texture…

Baking a texture out WITH alpha is hard. Even though maya lets you select HDR, TIF, and TGA as bake texture formats.. when you go to open the texture in photoshop, the alpha channel is black, not 0 alpha. Even though your resultant texture will have an alpha.. I think there is a flaw in the maya export process. Anyway, so to KEEP the alpha, you go RENDERING (menu) / Lighting/Shading / Batch Bake (mental ray).

The file will be output in whatever format you chose in the Baking Set options in C:\Users\YOURUSERNAME\Documents\maya\projects\default\renderData\mentalray\lightMap, but THAT file will have 0 alpha pixels as BLACK, not 0 alpha. So ignore that file, it is useless. Go to Hypershade/Textures tab, and find the texture starting with baked_.. That is your baked texture. RIGHT CLICK IT AND SELECT TEST TEXTURE. SAVE THAT as PNG.

And that is the only way I found to save the alpha channel in a Maya baked texture.

Just a link to this, probably the best one I’ve seen

This is a makeString() function that works like printf(). Gives you a std::string from a printf()’d one, so you can stop using sprintf() all the time and NEVER use ostringstream!

string makeString( const char *fmt, ... )
{
  va_list args ;
  va_start( args, fmt ) ;
  char msgBuffer[ 4096 ] ; // max len.  Can also use a strlen call to avoid over alloc
  vsprintf( msgBuffer, fmt, args ) ;
  return string( msgBuffer ) ;
}

I want to believe iteration style doesn’t make a difference as much as the next guy, but the fact is, it does.

In order, performance goes

For std::vector:
integer indexing FASTER THAN range based for FASTER THAN traditional iterators

For std::list:
range based for FASTER THAN traditional iterators

You can quote me on that. A test below proves it with a simple example.




#include <stdio.h>
#include <vector>
#include <list>
using namespace std ;

/////#include "Timer.h" // TIMER.h pasted below
#include <sys/time.h>

struct Timer
{
  timeval start ;
  
  Timer() { reset(); }
  
  void reset() {
    gettimeofday( &start, NULL ) ;
  }
  
  double getTime() const {
    timeval end ;
    gettimeofday( &end, NULL ) ;
    
    return end.tv_sec - start.tv_sec + (end.tv_usec - start.tv_usec)/1e6 ;
  }
  
} ;


struct O{
  int a ;
  float b;
  
  O( int ia, float ib ):a(ia),b(ib){}
  
  void print()
  {
    printf( "%d %f\n", a,b ) ;
  }
  
  void doIt()
  {
    a++;
    b++;
  }
} ;

int TESTS = 10000000 ;

int main(int argc, const char * argv[])
{
  vector os ;
  
  os.push_back( O(2, 2.2 ) ) ;
  os.push_back( O(3, 3.3 ) ) ;
  os.push_back( O(4, 4.4 ) ) ;
  
  Timer t ;
  
  t.reset() ;
  for( int i = 0 ; i < TESTS ; i++ )
  {
    for( vector::iterator iter = os.begin() ; iter != os.end(); ++iter )
    {
      iter->doIt();
    }
  }
  printf( "TRADITIONAL ITERATOR : %f\n", t.getTime() ) ; // 0.755 sec
  
  t.reset() ;
  for( int i = 0 ; i < TESTS ; i++ )
  {
    for( O& entry : os ) // note: if you pass by value, it's even faster
    {
      entry.doIt();
    }
  }
  printf( "NEWFANGLED RANGE BASED for : style Time %f\n", t.getTime() ) ; // 0.493 sec
  
  
  t.reset();
  for( int i = 0 ; i < TESTS ; i++ )
  {
    for( int j = 0 ; j < os.size() ; j++ )
    {
      os[j].doIt();
    }
  }
  printf( "INTEGER INDEXING Time %f\n", t.getTime() ) ; // 0.243 sec
  
  
  
  
  
  
  return 0;
}