I thought it looked so clean and easy, then I selected the whitespace. =[ 2009/7/25 Spencer 'voogru' MacDonald <voo...@voogru.com>: > I like this one better. > > http://compsoc.dur.ac.uk/whitespace/ > > > > -----Original Message----- > From: hlcoders-boun...@list.valvesoftware.com > [mailto:hlcoders-boun...@list.valvesoftware.com] On Behalf Of Olly > Sent: Saturday, July 25, 2009 10:54 AM > To: Discussion of Half-Life Programming > Subject: Re: [hlcoders] whats happening with this engine > > Its a good job you used tinyurl, otherwise it wouldn't have fit on my > screen!... > > 2009/7/25 Harry Pidcock <haz...@tpg.com.au> > >> Valve contacted me yesterday to tell me they have successfully implemented >> a >> new feature. >> >> http://tinyurl.com/4f6mt >> >> I hope to see more of these innovations in the future. >> >> -------------------------------------------------- >> From: "Andrew Ritchie" <gotta...@gmail.com> >> Sent: Saturday, July 25, 2009 10:21 AM >> To: "Discussion of Half-Life Programming" <hlcoders@list.valvesoftware.com >> > >> Subject: Re: [hlcoders] whats happening with this engine >> >> > 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 >> > >> > >> >> >> >> > >> > No virus found in this incoming message. >> > Checked by AVG - www.avg.com >> > Version: 8.5.392 / Virus Database: 270.13.28/2259 - Release Date: >> 07/24/09 >> > 18:24:00 >> > >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlcoders >> >> > > > -- > Sent from Olly's SEGA Game Gear > _______________________________________________ > 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
