Surely this topic could be split into several different points. Personally I see 4 different ones here.
1) Engine features 2) Tools Capabilities 3) Tools Availability 4) Tools Presentation The first is ignorable, Valve is clearly only going to add new features or change things, like BSP and displacement maps, when they think it's important. It's their engine and it needs to do what their games need doing. If you choose to use Source then you have to accept you are modding their engine. Sure TF, CS, DoD etc.. all were mods that made Valve a lot of money and brought huge success but they were also developed around the constraints of the engine rather than the engine being built FOR these mods to be made. If a technical limitation is big enough to warrent an engine change then do so rather than hanging about wanting Valve to add the feature, as big as the previous mentioned mods are you'd need to really prove you're up to their popularity before Valve would make a drastic change for you. So either accept the engine's features before you get underway or be prepared to encounter the fact you can't do certain things without a lot of work, if not at all. The Tools Capabilities I think is what Jed was really getting at, I don't mean like adding features to hammer and stuff but specifically allowing the chance for modders to by pass say model exporting to smd and just use a common format. The tool would need to have the importer and converter written but I personally think that approaching Valve with a specific and industry accepted intermediate format might be a good cause. Especially if it makes life easier for getting the raw assets into a format that the tool can then use. With the availability of tools, I mean those asking that they be open source. Specifically referring to a comment about hammer, look at Worldcraft and BSP ( Yahn's editor iirc ) they were originally personal projects. So you could take a leaf and have a bash at your own editor and open source it, you never know might turn out to be a better designed tool. However just having the source code to hammer, I doubt would be of any benefit, you'd have dozens of versions of the tool floating around and do you really think you could add something useful to it? It may have bugs but if you advocate open source then why not take the initiative and lead by example? The last one, has been brought up in regards to wrapping a tool with a UI or removing the need for QC files. With this I think the issue is balancing the technical knowledge and the capabilities of a tool. However I feel it again falls back to a situation where Valve are happy to use it the way it is, they understand it and can get any of their tools to do what they need. It's the new, non technical, or perhaps slightly lazy people who would need that more complex aspects automated for them. I'd refer this back to Hammer, the early days of mapping could often mean rooting around in a hex or text editor and as things progressed and art started needing the technical requirements to be simplified you found map editors hiding away the old formats. Worldcraft and Hammer essentially sit between the user and the BSP, VIS, RAD etc.. compilers. The format they accept might be, at this stage, more heavily tied into hammer but it's still a front end for those. Again perhaps Worldcraft was a special case with Valve gobbling it up, HLMV too, but I think if the community is adamant enough about simplifying and unifying the tool chain then perhaps a bit of proactive development could lead the way or at least prove to Valve that everyone is serious about rethinking the way we interact with the SDK. Ok, sorry bit of a ramble but mainly what I wanted to share was that specific things like adding FBX to the formats studiomdl can accept would be good ventures as they are specific and have an immediately obvious reason. The other stuff like creating a unified system might be something that is best approached with good old community spirit. If you're serious enough about wanting to use the engine but can genuinely improve the way users develop for it then get organized and see if it's a viable thing to tackle. Even if it's just to prove you were right. I know the later is a bit of a cop out but Jed, Nem and NS2 (prior to dropping Source ) are examples of those who have gone out of their way to do so with tools and Garrys mod is a prime example of taking what is available game code wise and adding the extensions (Specifically scriptint) you want. Plus it beats just falling back to the "Valve Needs to Support Mods" and "Valve do whats best for Valve games and mods need to deal with it" arguments that go no where. On Fri, Jul 24, 2009 at 11:17 PM, Ben Mears <benmea...@gmail.com> wrote: > As a 3D modeller, animator, and mapper, (and not a coder) I agree with what > Jed said 100%. > > Jed, can you please just go work for Valve? > > great, thanks! > > On Fri, Jul 24, 2009 at 12:23 PM, Jed <j...@wunderboy.org> wrote: > > > 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 > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
