Categories

Effective 3D Exporter Design: How to Make Artists Love You

I wrote an article for Gamasutra. Check it out.

4 comments to Effective 3D Exporter Design: How to Make Artists Love You

  • JoeWebSurfer

    Excellent article! I think it will become required reading for tool writers and their clients and managers. This article will make the game development world a better place!

    (I bet you’ll get job offers as a result of this article.)

  • Wonderful! Ganbatte!

    Hey Gregg,

    You are the hero of all game artist out there!!!

    ^:)^

    Very nice article and it has lots of wonderful philosophies that I hope I can apply to my development process!

    Cheers,

    YC

  • 3d hierarchies
    Here’s something that came to mind after the article was posted that maybe I should have gone into more detail.
     
    under the “don’t force the artist to collapse the hierarchy”.  I believe the ideal is something like this.  If you have a hierarchy like this 
    +-car  +-carbody  | +-body  | +-window  | +-hood  | +-fender  +-frontaxel  | +-left wheel  | | +-left tire  | | +-left rim  | +-right wheel  |   +-right tire  |   +-right rim  +-rearaxel  | +-left wheel  | | +-left tire  | | +-left rim  | +-right wheel  |   +-right tire  |   +-right rim  +-driver    +-waist      +-chest      | +-neck      | | +-head      | +-left upper arm      | | +-left arm      | |   +-left hand      | +-right upper arm      |   +-right arm      |     +-right hand      |       +-shotgun      +-left thigh      | +-left shin      |   +-left foot      +-right thigh        +-right shin          +-right foot
    In an ideal exporter you should be able to export that as 7 parts if you want to 
    • MODEL:The carbody (body + window + hood + fender)
    • MODEL:The front axel (front axil)
    • MODEL:The right front wheel (right wheel + right tire + right rim)
    • MODEL:The left front wheel (left wheel + left tire + left rim)
    • MODEL:The rear wheel assembly (rear axel + left wheel + left tire + left rim + right wheel + right tire + right rim)
    • SKIN:The driver (too long to list +)
    • MODEL:The shotgun 
    I bring that up because I’ve seen exporters that only take this issue one step deep in that they would handle only collapsing to a point. Meaning if you said you wanted the carbody as a model the front axel for example would be come part of the carbody and if you said you wanted the driver as a skin the shotgun would become part of his character instead of separate or you’d get an error or it would be ignored since it’s not part of the skin in the 3d package.
     
    This is the kind of issue that came up by making it the a goal to allow artists to make 3D cutscenes entirely in the 3D package.  Solving that problem (3D cutscenes) will make your exporter very flexible.
  • Omar
    Automating “one-step build process”

    Hi Gregg,

    Nice article. I felt that everything seemed obvious at first glance, but it is the kind of things we don’t necessary do, often due to lack of time given to these tools. As you pointed out, they are often made by a programmer as a first quick test to work with its data/engine, and not engineered enough toward real production usage.

    I have a question about automating “one-step build process”. What’s your whole data pipeline strategy to do that?

    For a current project, I wrote scripts checking date-based dependencies (ala Makefile) between source data on a server and locally converted data, and running commands to export everything that has changed. Theorically this seemed ok at first, but:

    - As the project gets bigger, checking all files dates is getting longer and longer, annoyingly reaching several minutes. We have a manual way of selecting files to convert (drag & drop file to an icon), but the problem still apply for other people who need your latest data.

    - We had plenty of problems due to non-synchronized computers (local PC has 2 minutes more than server. When new data is saved on server it uses server date, and thus comparaison with local dates are incorrect).

    Both problems were introduced at first because of the separation between server based source data and local output data. I originally did that because our target platform require embedding data on each compilation so it was much faster to grab them locally each time.

    I can probably find a solution (storing output data on the server to avoid date problems and the need to global output, then automatically copying an archive locally for programmers).

    But I’d be interested in hearing about your strategy to handle automatic conversion of data.

    Thanks.

Leave a Reply

 

 

 

You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>