No I wasn't advocating an 3D app -> MDL path. Simply adding support for a more common/cross platform 3D format to those that StudioMDL supports.
The problem with the SMD format is that it's an old format from and old engine and requires plug-ins to be written for 3D apps to support it. This leaves it down to Valve to write them. Take Max for example - a plug-in for one version does not automatically work with another, it needs to be recompiled against the new versions SDK. A shop like Valve is probably only going to have one version and not upgrade every time a new one comes along. Therefore SMD plug-ins for other versions are going to have to be made by the 3D app users themselves. Now there are plenty of suitable cross-app 3D formats such as DAE, FBX, etc. that Valve could add support for to the StudioMDL compiler (and I've vocally expressed this to Valve many times) in *addition* to the SMD, OBJ and MRM formats it already supports. So why should they do it? - Common file format means more 3D apps that can produce content out-of-the-box or via publisher made plug-ins. For example DAE/FBX is supported by XSI, Maya, Max, Blender, Milkshape3D, etc, etc. - Gives modders/studios/licensees choice to use the 3D app of their choice to create content. - Valve doesn't need to produce plug-ins for apps, just support the format in the compiler. Simply put SMD format is binding end users to the few apps that write it and the generosity of community users such as myself, Prall, et al. to write these plug-ins for the 3D apps we want to use. Interesting case in point - a Canadian studio approached me once asking me when my plug-ins would be available for 3DS Max 2009 because that was their in-shop 3D content creation tool and they had invested a lot of money in software and training and didn't want to have to move to something else. Their apparent decision to purchase a Source license for their title was hanging on the availability of plug-ins for Max. My main issue with some of the SDK tool is that that it feels like Valve aren't being smart about it. Good tools means wider adoption which might result in more licensees and from a modders perspective, more people getting into it and maybe making the next CSS/TF2/Portal that Valve can snap up as their IP. I think Valve should have a dedicated tool guy (not me) turning out polished useful tools - not this rehashed crap that's hung over from Half-Life 1. - Start over with StudioMDL - make it a GUI app from the start (and adding batch/scripting to it wouldn't be hard) - Make HLMV a proper MFC of WPF app and get rid of the old buggy mxtk GUI from Mete's HLMV. - Add support form more 3D modern file formats and eventually phase out SMD, etc. - If for license/NDA reasons you can't release all the source code for apps, at least release parts of it. A lot can be learned from even partial code that could help us as modders make our own apps. - Add some SDK tool API stuff - for example code to render a 3D window like in HLMV. It can still require steam but make it accessible so that developers can add support for model rendering in other apps. - Polished tools will make the SDK/Engine more attractive to end users. Modding shouldn't be a right of passage but a warm welcoming experience to inspire the next great ideas. I could go on but you get the general idea... - Jed 2009/7/24 Jorge Rodriguez <bs.v...@gmail.com>: > On Fri, Jul 24, 2009 at 2:41 AM, Minh <minh...@telus.net> wrote: > >> The .smd format is extremely robust the way accomodates reference meshes, >> AND skeletal animation. So you want a method to go straight from 3d model / >> animation -> .mdl ? >> How is that going to work with parametric animation? where you can combine >> multiple .smds to make an animation? > > > Minh, while the capabilities of the studio compiler are formidable, it still > leaves much to be desired in terms of file format and syntax. Don't tell me > you've never struggled with the qc format. I am constantly having problems > with its limitations. It's a rather robust system that allows for combining > animations in many interesting ways, but the syntax still pisses me off > quite a bit, and the technicality of it leaves it out of reach of most > artists. I hear Valve wrote some simple tools around it, but I'm surprised > they haven't replaced it entirely. > > The SMD format is perhaps a bit clunky, but I don't have too many problems > with it, because it does exactly what is needed, even if it does it in a bit > of a backwards way. _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
