|
Topic:
|
Max. Games. Now and then. (10 of 10),
Read 82 times
|
|
Conf:
|
Discreet Take 5
|
|
From:
|
Chris Subagio
|
|
Date:
|
Sunday, July 20, 2003 04:59 AM
|
Well Michael, cutting edge goes way beyond just what you see, it's not just art I'm talking about. To be perfectly honest, I think even the best PS2 engines out there (arguably that would be the Rachet and Clank / Jack and Daxter family) have just begun to fight, and while impressive those still aren't doing anything particularly advanced, just refined. Let's not even talk of what the Xbox should be able to do, if only the daft thing would start selling properly and we could start spending attention on it.
It's really odd, but often times an idea is shot down not because of implementation time, but because of the difficulty in generating the bloody data for it. Implementation in fact very often even comes third after the difficulty involved in testing the result. Seriously. If you're an artist, chances are a dozen interesting texhniques have already been shot down in someone's head long before they even bother telling you.
From a programming point of view as well, what I make in Max, I need to know I can get into the engine meaningfully. Less and less to me this means just getting a vert/face/keyframe array. Yes, the talent overrides the tools any day, but in this instance, I'm actually refering to spending the talent building/maintaining/using the pipeline more than the talent generating that data. From an artist's POV (mine until recently), it's easy to be glib and self centered and just demand the programmers do whatever it takes to represent whatever we make, however we make it, in game, but honestly, it's so much more productive, adventurous, and just plain exciting when we honor each other's arts and actually collaborate.
Back to Max, no it's not entirely up to the task, imho. We use it exclusively, and we've invested a LOT of energy in customising it. Here's a breakdown of what we do use:
We have a nice hierarchy of material/bitmap plugins that allow us to build materials as each platform sees them (per pass/per stage/per bitmap settings, with commonality an per platform overrides), as well as apply the 'material modifiers' we use in engine for effects by dynamically disabling/adding to those controls. The modifiers also change how the mesh gets treated in the converter tool, post export, including membership in collision sets. This is the most advanced thing I've seen so far for gaming materials built directly into Max. Forget trying to map the standard material on export, we started over. We can even preview simple multistage (not multipass) materials in the viewport.
Custom Attribute controllers on objects to add per object animated controllers. In fact we export most tracks with an animated controller at the moment, so we use this to export collision primitives as well.
Note tracks to add string triggers to animated objects over time.
Scripted plugin lights to add the parameters our engine understands, and replace the normal light UI to remove redundant controls.
A few plugins that do things the max architecture is perfectly capable of, but has no interface for, like HSV/levels manipulation of vertex colors with soft selection. Also some error checking/mesh validation things.
A small army of scripts that condition data, export cutscene script files, and any try to deal with any miscelaneous problems that come up.
So you see, we're practically using everything there is to use, and it works perfectly fine for this level of technology, but what I'm talking about is the future. There is quite a bit missing from Max at the moment for our liking, and while we can bodge around it, there's only so much bodging you can do before the max SDK stops you, the bodge becomes far too inelegant to be efficient, or the effort spent is better spent elsewhere. Things like per face data. There's a half a dozen places you can embed data on a per face level, but then go and try and view it meaningfuly in the viewport. The more interesting stuff you do in Mac, the more you do start having to write external tools just to view, validate and debug the results.
As for Sorin's comment about writing an engine and the ratio of work that is the exporter, I think you'd be surprised. It's not that small a portion of your effort, especially when you consider that you'll need to understand Max before you can even hope to extract the data you need, let alone any of the extension stuff you want to build into Max. The return on interest when you consider the limitations you eventually hit make writing your own tools more and more enticing each time you have to do it again. And you're missing the other side of the coin. If you're writing your own engine anyway, you already have the capacity to view and change all the data you need in it's native format. Writing an editor then is a case of coming up with an UI for it, you already know how it all works, almost exactly the reverse of writing something in Max, where you know nothing about how it works, but you get a UI for free.
Bobo, that's an interesting and interestingly timed press release! Doesn't do that much for me though honestly. I'm not the biggest fan of Renderware to date (wish them all the best though!), but more importantly I don't see anything in there that fundementally changes the relationship of Max to Renderware. It's still data going through a black box translator/sampler from our point of view, and where does that leave their Renderware Studio level editor? How much will Max be allowed to encroach on that territory?
Scott, by the numbers, eh? :) I don't know if this is a common evolution, but I was there and I've moved onto a stage where what I really want is intuitive procedural hooks into a data driven stream. Just data driving a game is a nightmare for the virtual impossibility of debugging the giant state machine it all becomes. Just holding a single frame's state in your head starts to hurt, don't you find? But conversely, trying to do too many thing procedurally is too dull and unexpressive for my tastes. Need some middle ground. Imho, it starts with removing resampling from the pipeline. The data you make has GOT to be as close as possible to the final data, e.g. no animating willy nilly with fancy curves that get resampled on export only to look just ever so wonky on the other side. No arbitrary tasselation of geometry for scene management without some way of viewing the results outside of the game. And so on and so on. Things that would be trivial in your own environment, but bloody hard in Max.
Oh dear, long rambling again. Nice to be having a discussion though. Any more thoughts?
-Chris.
|
|
|
|
TOP
Post
Reply
Reply/Quote
Email Reply
Delete
...
Edit
Previous
Next
Previous Topic
Next Topic
Entire Topic