View Full Version : OT: art production paths

04-21-2003, 10:40 AM
Just wondering how other programmers feel about general art production paths. In my last project I was responsible for writing the plugins for 3DSMax for our art assets. This had the advantage of allowing me fast access to the plugins to make changes to what is allowed in our character exporter or world builder. On the other hand, it was using MAXSDK, which is royal pain in the butt. For my next project I'm thinking of adopting a hybrid approach where one of our technical artist (read: artist who can program) is writing stuff in maxscript to spit out data to a text file which I will then compile into a binary asset for our engine. This has the advantage of being able to leverage MaxScript (which IMHO, gives you more useful information than MAXSDK) and it is far less of a headache for me to write an asset compilier than an asset exporter. The downside is that exporting is now a two step proccess, and until the first step is completed (the script) if I want a temp asset I have to bug an artist (insert cracks about artists hours here).

For those of you who are still working with inhouse technology that isn't quite mature yet, how do you deal with the pain of asset creation during the feature implementation phase of 3d engine creation?

[This message has been edited by rgreene (edited 04-21-2003).]

04-21-2003, 07:51 PM
There is no difference between what you can get in MaxScript, and what you can get using the SDK. If you really are more comfortable in MaxScript, then fine, but the SDK is not limited, and I've found it to be reasonably easy to use, once you read a book on how Max works from the artist's point of view.

I would recommend a programmer write art export functions, else you probably won't have the right "validate everything" mind set, and weird artifacts may plague you forever. If that programmer can also make art, that's fine, too :-) Really big meshes may run into performance problems in MaxScript.

If you can export "everything you'll ever need" to text, then you can define that artists deliver text files to the rest of the company, and the build process builds text files into post-processed product-ready binary files. If you can import the text files back into Max, then you can even let the artists manage their Max files however they will, without requiring source control other than for the text files. Depending on your internal politics, this may be a great win, or a non-sequiteur.

If you compile assets as part of build or build set-up, you probably want to "wink" in those assets from pre-built locations wherever possible, to save time when doing clean re-builds of everything. Having a script do it at night seems line it'd work.

Last, what will the artist->product preview and iterate path look like? If they find that something needs tuning, your goal should be to have them see their results as quickly as possible. This may mean having a separate path that runs inside Max to show in-Max previews, or a separate exporter that goes straight to binaries, or some scripted solution, or whatever.

Oh, and this probably should go to sweng-gamedev or something like it, as it has nothing to do with OpenGL.