Know what i would like to see?

[Ranger366]

This is damn serious, im Quake modder for some time now, im modding Half-Life for like 2 years. You must know im a very young guy which loves to modify games and likes to play them.

When you make mods for Half-Life, everything is clean and easy, you can make Maps with Hammer, you can make models with Milkshape 3D - listen, im not a Milkshape FanBoy, im not using it all day and NOT FOR MY MODS, but it was created for Half-Life and is perfect low-poly models.
The Half-Life Formats are MUCH better than Quake ones, everyone knows that, im working with the Model Viewer all day. using HL Formats is not only easier, it looks better because textures dont use one f*cking global palette.
Every Quake mod look like Quake! (palette changing is damn time wasting) And the Maplight has only ONE damn color!
Half-Life formats like BSP30, HL MDL, SPR32 would MATCH PERFECTLY to Quake, Xash3D (GoldSrc Engine built "from Scratch" by Uncle Mike) got every Format right to work. im just freaking ask me why after 10 years no one thought of to make an engine with all those Filetype supports. We would have better mods. Make this thing happen guys.
Well, dont misunderstand me, i can do stuff by my own, i just wanna know here what do you think of it, i never saw HL MDL working correctly in Quake.

[mh]

Number of reasons.

Valve's licensing terms ain't exactly too friendly, and projects (like the old open source CS clone on QER) have been C&D'ed in the past. This on it's own is enough to kill any such plans stone dead, but there are a few others that are worth discussing too.

The formats aren't exactly that good. Take HL BSP 30 - most everything it's capable of has already been replicated in Q1 engine ports, but the one real jump ahead that's needed (switching unsigned short types to unsigned int in the format and thereby removing limits) doesn't exist. Neither do essential features for easing the map making burden like areaportals or (AFAIK) detail brushes. I don't know much about the HL MDL format, but what I do know is that comments about it being disgusting to code for have been made in the past.

Mod support. Baker has made a great point elsewhere that engines don't drive forward standards; mods do. Until a major mod comes out that's using (and is committed to using) HL formats all the way through the content pipeline, there is absolutely no way we're going to see HL formats getting any kinda widespread uptake.

I can't speak for everyone else, but another thought I have on this is that HL formats aren't nearly ambitious enough. I've touched on this a coupla paras back, but the point is worth bringing out on it's own. HL formats don't offer enough extra to justify the work investment required to build support for them. This is critical. Just because some of the formats are relatively close to Q1 formats doesn't mean that they're automatically easier to implement or a better choice.

I've said this last one before elsewhere myself. If you wanted to pick new "standard formats" to go forward with, then my belief is that you're better off picking the Q2 formats. We already have a GPL working reference example of an engine for loading and using these formats: the Quake II engine. We have GPL tools for building them. Overall they're a more sensible "next level up" than HL formats.

[Ranger366]

Quake 2 Formats arent supported in every Engine, most important thing is that the animations still suck up with this glibber effect. The important thing on half-Life MDL is that it uses Skeleton based Sequences and attachments for the muzzleflash, as example. The chrome effect on some textures arent really important - ah yes, multiple textures, MD3 has the same too, but this format is rarely supported, it also fix the animations. Funny thing on telejano Quake is that MD3 is totally useless, try it by yourself...

Quake 2 BSP? Never worked with that, i know that you can do with WorldCraft maps for it, but the map textures arent that good... (.wal, can be changed to TGA but this is one other chapter in the story of my problems)

[ceriux]

i think i have to agree with him not on a coders standpoint but as a content creator. making a half-life 1 .mdl is much easier than quake or any other format iv ever compiled/made. on top of that it uses groups, where each group (like attachments) can be changed and have different sub groups, not only that each having their own texture if you choose.

Half-life bsp, has a much nicer version of worldcraft that he mentioned is called hammer. with the latest version you can view your models that you place in a map directly with in the editor before its compiled and its much easier to use than any other world editor. so easy that i have taken the time to learn others and have failed miserably.

so for someone who creates content, these formats are much nicer and easier to use and make content for.

i would have to agree that it would be a benefit to have them in an engine together. its always been something iv wanted . but im no engine coder so i could never accomplish it on my own.

personally my favorite features would have to be things such as this :

- HL.bsp
- HL.mdl
- frik_file
- csqc
- any special limitation fixes and extensions

after those things. i could care less what was in the engine, as long as it was net quake =).

[Ranger366]

If there are really license problems the dream that HL MDL becomes an Quake Engine standard will never come true. But i think Valve dont cares about it, idk.

[Spike]

i could care less what was in the engine, as long as it was net quake =).

so near, yet so far.

[frag.machine]

If there are really license problems the dream that HL MDL becomes an Quake Engine standard will never come true. But i think Valve dont cares about it, idk.

Valve has tapped on the mod community for a while (TF2, Portal, Alien Swarm, DOTA, etc), I think it's just fair they give something back to this community for free like id did in the past. When I said in other thread you should ask them to release the Half Life 1 engine source code under GPL I wasn't joking. Why don't you guys start a public request and make sure that the game press know about this so Valve feel forced to take a position about the subject ?

[ceriux]

If there are really license problems the dream that HL MDL becomes an Quake Engine standard will never come true. But i think Valve dont cares about it, idk.

Valve hasn't attacked solitude yet.

[revelator]

id support asking valve for the hl1 source

also gives me a chance to pester them about hl2 episode 3

[mh]

If there are really license problems the dream that HL MDL becomes an Quake Engine standard will never come true. But i think Valve dont cares about it, idk.

Valve hasn't attacked solitude yet.

It depends how far along the path Solitude goes towards being potentially able to run HL content without needing the HL engine, but despite the fact that Valve may not have taken notice of it yet, it is still in breach of the HL SDK license to distribute content made with it that can run on anything other the HL engine:

Whereas, Licensee wishes to develop a modified game running only on the Half-Life engine (a "Mod") for free distribution in object code form only to licensed end users of Half-Life;

[Rich]

I think it's worth noting that IQM is superior to HL MDL in every conceivable way. The HL MDL format is a complete mess, although not nearly as much of a mess as the Source MDL format. IQM has a pretty small and concise spec, and implementing it should generally take a lot less time than you'd spend implementing HL MDL. It supports every data type you could need for skeletal animation, and a full range of data types for geometry so that you can use whatever type of precision you'd like. Most people should probably just stick to float32's.

You could convert any HL MDL to IQM without losing anything. I think the tools path for this already exists as well - just decompile the mdl using Valve's studiomdl tools, and export the resulting SMD(s) to IQM. Noesis can do this part, if nothing else can. Although I haven't actually tried it. I could implement HL MDL import in Noesis if this is a path people actually want to take, so that HL MDL->IQM becomes a one-step process with no manual intervention/tweaking required.

I think the only real downside to IQM is that it is not implemented in too many actual Quake engines! In fact, I believe DP is the only engine that supports it which is also meant to run Quake. Hardly seems appropriate for an "Inter-Quake Model" format.

But yeah, if you are gonna implement new model support in your engine, I would say go with IQM. Do not bother with HL MDL, as it offers nothing IQM does not and it's a far more horrible spec. (because Valve has molested it for so many years, extending it in wholly inhumane ways)

As far as BSP formats, I do know DP also supports q3bsp, although I don't know how well. q3bsp's native lightgrid data is pretty primitive, but given that you can also use deluxemaps, it should be pretty possible to produce a q3bsp for DP that looks just as good as (or better than) anything you would see running in Source, much less "Goldsource". (or "Quake with half-assed skeletal models" as I like to call it)

The main thing I see lacking is the ability to store additional per-surface-scale-and-biased "light distance" maps, so that correct specular highlights can be applied to pre-lit bsp surfaces. This is something that would require either a good bit of waste or a format convention change (I would go with storing deluxemaps as RGBA with light distance in the alpha) - plus you need a way to attach the scale-and-bias to each bsp surface, because raw 0-255 (even globally scale-and-biased) is just not enough precision for light distances. It might be neater to export this data (both the maps and the surface s+b vectors) to an external paired file, so as not to screw with the q3bsp format, and allow engines like DP to just check for and use that file if it's there. Export of this data would be relatively trivial to implement in q3map2 - at least in as much as swimming neck-deep in a pool of shit is ever trivial.

I also have a custom q3map2 somewhere that bakes out tangentspace light vectors, which is what the original implementation really should have done. Is there already another modified q3map2 in existence which can do this, or should I start digging through my old un-SVN'd code to find it?

[mh]

Q3 BSP doesn't do lightstyles though so it's not really the best option. It can fake them, and does so reasonably well in RTCW, but proper animated and switchable lightstyles are an essential element in letting content creators go bonkers (which is the whole point of the thing, otherwise it degrades to a tecnhical dick-measuring contest).

Otherwise I fully agree on IQM.

[Rich]

Q3 BSP doesn't do lightstyles though so it's not really the best option. It can fake them, and does so reasonably well in RTCW, but proper animated and switchable lightstyles are an essential element in letting content creators go bonkers (which is the whole point of the thing, otherwise it degrades to a tecnhical dick-measuring contest).

Otherwise I fully agree on IQM.

I actually don't really like the idea of re-uploading sub-regions of lightmaps as a way of implementing lightstyles (due to inconsistent performance across driver implementations, actual performance limits it imposes on lightmap resolution, and a small variety of less significant factors), and would generally prefer to eat the memory overhead of just calculating separate pages and/or LM texture coordinate sets to implement lightstyles. If you don't mind getting a bit more modern, you can smoothly animate between those lightstyles in a shader as well. Or just tell people to use realtime lights instead of lightmap light styles, when they need those kinds of visuals. We also had lightstyles in the Jedi Academy variant of q3bsp, though I thought it was implemented in a pretty wasteful manner.

I would say the lack of actual lightgrid is an instant loss for q1bsp, though. Unless there are already ways to use external lightgrids with q1bsp files.

Lightgrid support aside, I suppose there isn't really a fundamental reason to go with q3bsp over q1bsp, if all of the same visual niceties (deluxemaps, and light distances would have to be external for q3bsp anyway) can be afforded as part of the format spec.

[Boss429]

But Darkplaces can load halflife maps...
and Darkplaces DPM models are just compiled halflife .smds

There just better: no 512x512 texture limitation, full 32 bit colours, HL2 style vert weights...

The only thing thats really laking is solid documentation on these features but they're all there. with the possible exception of bone controllers and animation blending.

[Urre]

Rich: what about not being stuck to 3 hull sizes?