News | Forum | People | FAQ | Links | Search | Register | Log in
Quake 2018: How Maps And Engines Are Better Than Ever.
Considering the following:

1. We're getting more map releases than we've been getting in nearly 20 years, and they're all of decent quality at the very least, and superb (that which are rivaling the undisputable classics in quality) at most.

And...

2. In 2008, for every 5 demos for a map:
- 2 would be Fitz 0.85,
- 1 would be aguirRe's AGLquake,
- 1 would be DarkPlaces,
- 1 would be JoeQuake or some other QW engine (???).

Each and all of those with their own protocols and idiosyncracies.

These days almost everybody uses Quakespasm - an actively maintained and cross-platform engine - as a standard.

Conclusion:

After a slump in the early 2010's, Quake is finally doing better than ever, with the player and mapper base growing and the game itself slowly creeping back into mainstream attention.

Discuss... or not!!
First | Previous | Next | Last
 
MDL sucks except for where it doesn't which is morph animation and the ability to make polygons dissapear in certain frames such as some of Preach's effects models or as completely different poses such as mushrooms or candle models from AD.

I don't know of any other format that let's you make each individual frame as if it were a separate model except for source engine's .MDL which is pretty much the same thing but you can have skeletal animation and use a separate mesh for collision.

All else uses a skeletal armature as far as I know. 
Ya Nope 
Still can't find anything other than blendshapes and even that is 't as powerful as the .mdl format. 
Qmaster 
md3 is a vertex animation format too. 
Model Formats 
mdl, md2/3/4/5/6, and iqm are all a quake specific model format. that's both good and bad, but mostly bad as far as the modeller and animators are concerned.

i think without question the best model format would be either FBX or collada, these are the most common formats and modelers and animators will be able to export for it easily from many different tools.

as far as removing the barrier to modelling of quake: this might get more serious modellers interested to make models for quake since they don't have to work with ridiculous formats they've never heard of. fbx and collada are so common the exporter is installed by default on most modelling packages. this lets a modeller make models for quake without knowing anything about quake at all. also lets you download these very common files from the net and use them directly for people who can't model things.

https://en.wikipedia.org/wiki/FBX
https://en.wikipedia.org/wiki/COLLADA

these files could be parsed with a standalone utility to add flag data or any other data into the file itself, because it should support arbitrary data within.

might be possible to add this data in the model editor itself by hand. like to a blind data field or on a non-rendering polygroup in the model.

collada is a non-binary text file so it would even be possible to edit that file by hand.

iqm is not too horrible though, i've tested it out. supports fairly high polygon counts and skeletal animations, as well as multiple shaders. also works good as non-animated static mesh.

collada and fbx file formats though are basically futureproof and support an unlimited number of triangles, and etc. whatever limits your engine decides to support will not need to be adjusted in the file spec at all, just the engine. you'll want to allocate as high a limit as possible. 100k triangle mesh is almost considered low poly in some circumstances today. consider the high-res monitor resolutions when quake was released, everyone was playing 320x240 and yet it supported really high modes to future proof it. 
 
both collada and fbx support blendshapes, if the game engine will support parsing that data and using it. you can have blendshapes and skeletal animation in the same file so it's ideal.

it perfectly replicates the vertex animated behavior of the .mdl alias triangle models.

when doing blendshapes the winding order of the vertices is important, so keep it in mind when creating your file parser. 
 
My vote is on md3 (if it matters) as a standard extra format to support. DP and FTE already have this I believe.

Relevant Exporters here for everything:
https://www.katsbits.com/tools/

FBX is not bad but it can be a lot harder to fully support it. Unless someone has the time it prolly won't happen. 
Qmaster 
the .mdl files originated as .tri files from alias power animator. they only become a .mdl when they are compiled by a model tool that came in the original quake sdk. this compiler was named modelgen and in q2 it's called qdata.

the direct decendant today of that file would be blendshapes stored as an FBX file, exported from autodesk maya. so blendshapes are indeed as powerful as the .mdl file, it's identical.

alias was sold to autodesk in the 90s. power animator became maya.

blendshapes are able to be created by almost any program, so maya is not needed.

saving blendshapes as FBX or collada does the exact same thing. either file format works fine. 
 
Theres been over 200 single player maps made for Quake in the last 2 years. I think Quakes doing just fine without all this stuff you're asking for that's already implemented in other engines no one wants to use. 
 
some implementations of these model formats are only partial. for example in spikes version of quakespasm he doesn't support shaders or tags on the md3 file. so you have to be careful here what you're asking for.

it would be great to have one solid implementation of a model format that can do it all and be used across all the quake engines.

converting a md3 into collada or fbx would be easy, you could batch convert them over with no user interaction required i bet. 
 
Theres been over 200 single player maps made for Quake in the last 2 years. I think Quakes doing just fine without all this stuff you're asking for that's already implemented in other engines no one wants to use.

Indeed. This is the stark reality. I'd like to think there's all these incredible maps and mods that are just sitting idle, waiting for Quakespasm to implement md3 before they unleash themselves into the world, but I think in reality if quake content creators actually want to use other model formats, we'd have seen some content by now. 
Give Tim Willits A Call... 
Seriously who are you going to retain to perform the labour behind developing a new Quake engine that will support fbx format, static mesh with collision, and 'ray tracing'. Do you have a 7 figure budget?

Honestly just call up id and ask to license idtech 6. This is absurd. 
Lol I Know Tim Actually, Great Guy 
kinn, i noticed that you were asking when qs would support q3 map format in another thread... in this thread you said nobody wants this newfangled crap!

the reality is people do want these things, including you, but every time it gets brought up on here there's a huge backlash against whoever asked for X new thing. quake doesn't need this shit blablalba. i think people have just given up mentioning stuff like this because it might get into a flame war for no reason. but this thread was created specifically to talk about it so here we are!

anyways, lots of great information in here so far, and in case anyone wants to consider it we have lots of ideas for improvements to make maps and engines better than ever.

@Redfield, i don't think its absurd, we already have mesh with collision or you would fall through the floor of the brushes you stand upon. none of what i mentioned requires a 7 figure budget. 
 
kinn, i noticed that you were asking when qs would support q3 map format in another thread... in this thread you said nobody wants this newfangled crap!

this weird obligation people have to pull up old opinions(3 years old in this case) of people to use against their new, current, opinion is pretty absurd. 
Echos == Otp Confirmed? 
I'm taking about the actual reality of how and why things get implemented.

Of course I think it would be cool to have md3, q3bsp etc etc. Doesn't mean I can't drop a few sodding truth bombs every now and then does it?

I'm not saying we shouldn't have these things, I'm saying this is why we don't have these things, and this is why the programmers don't think it's worth their time supporting these things. 
One More Thing. 
i keep hearing stuff like "if people wanted it we'd see X by now", here and in other threads.

i don't think it's that easy to dismiss. for example why didn't we see many q3 format maps?

because darkplaces didn't support the full implementation of the q3 shader system. this basically killed it for me and probably everyone else. and FTE uses and ungodly complex glsl shader, i would have to convert all my shaders over to that after learning glsl.

as well, model/anim implementations vary so wildly and are partial at that. if it won't support what you want to do because it's partial, it's as good as no support at all.

if you don't agree it's fine, but this is my take on things. 
And It's Pretty Dumb 
considering how obvious it is that otp just pm'd you (or whatever) with that incredibly controversial info.

Oh my god I once said q3bsp is cool.

Oh shit I still think q3bsp is cool what now. 
@kinn 
TREASON? 
It Gets Better 
spike called qs crippleware in the qss readme. that's a solid burn. what's the verdict on that?

i won't dig up any more quotes to throw at you guys for now, it's making you paranoid hahaha. 
 
Spike also released FTE with literally no documentation making any desire to design for it null from the start. 
 
The best model format is a binary format that you can fread into a VBO. Plain text is fine for intermediate formats, but for the final thing that you're going to use in-game, load times are pretty damn important.

Spike described NQ as crippleware. Not specifically QS, any kind of NQ. But Spike has a QuakeWorld background and judges things by different criteria. 
My 2ยข 
If you want to make a quake 3 map why not just, you know, map for Q3 instead of making a Q3 map then turning around and trying to run it on a Q1 engine hacked up to play Q3 maps? If the lack of quake 1 enemies is a problem just download a quake 1 enemies mod then base your map on that.

As for models I think FBX would be a great idea too although there should be an FBX > MDL converter made so people can convert their model for use in more vanilla-ish engines that don't/won't support more modern advanced formats. I would also be kind of concerned about performance concerns of really high poly meshes (at least really high poly in quake terms anyway)on lower spec pcs, the way I see it quake is a great game for lower end pcs and laptops- and why wouldn't it be considering it is over 20 years old at this point- and the mdl format helps with that because it gives strict well defined limits on what you can do and those limits also happen to help keep the models lightweight and able to help maps run better, my lower spec laptop already apparently can't run quakespasm without -noglsl which makes no sense since the gpu SHOULD support that, it isn't particularly happy at the thought of quake having compatibility with a model format with unlimited vertex/face count texture resolution etc, surprisingly enough. Potato lives matter you know ;~; You know there will always be that one guy that spams free high poly models that they downloaded from sites like Model Resource in their maps just like how in Doom mapping you have some people that just decide it would be a great idea to make their map in the most advanced format just so they can copy and paste a bunch of random custom shit in it from Realm 667/. Then they will post it for people to play and shockingly to no one, it runs like shit even if it's vised unless you have a super epic high spec system which like I said makes no freaking sense for a 20+ year old game but oh well that's just how it is.

I get that I'm obviously kind of biased in that regard but still I think that's something that should be taken into consideration. 
 
i'm really just speaking as a modeller, animator, and mapper here. i can code a bit and know a few technical details. for example i know vbo is a vertex buffer object.

my suggestion is you could have the engine parse the collada at first use and save it out in its own native format in the userdir, that's what many games are doing.

blendshape anims should be allowed to deform along with the skeletal for doing facial anims on characters.

this would give the ideal solution for endusers, if they want it or not is another question. how many people wanted this and got ran off by an angry mob years ago, or how many want it now and are afraid to say so? lol

it shouldn't matter who wants what, if the engine is going to support models and animations it should do it in a smart way. coding the engine features by taking votes from an angry mob isn't a good way to go in my opinion!

so says the black sheep of the quake commune, baaa! 
 
just out of curiosity, whats the last Q1SP youve played, echos? 
 
@muk: it was one from sock, i really like his mapping style.

@therektafire you made some good points, i won't cover all of those but i will say most of your concerns are because of newbie mappers over-using triangles. there's nothing you can do about it, just don't play their map.

vis won't help unless it can seperate the map into smaller pvs sets. if a pvs is using too many triangles then you will have a slideshow. a good mapper knows there is overdraw on top of that, and performance takes a hit when moving between pvs's since more is visible from that spot.

i have tested an iqm mesh with 50K tris in fte and it worked fine for me with no slowdown, and that's using a midrange older gen graphics card.

newer gen cards would allow higher res meshes or more of them to be used in the same area. 
Echos 
Good luck with your project. Sounds like you have it all figured out. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.