#42 posted by Qmaster on 2018/09/08 18:08:18
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
#43 posted by Qmaster on 2018/09/08 18:10:21
Still can't find anything other than blendshapes and even that is 't as powerful as the .mdl format.
Qmaster
#44 posted by Kinn on 2018/09/08 18:34:09
md3 is a vertex animation format too.
Model Formats
#45 posted by echos on 2018/09/08 18:46:15
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.
#46 posted by echos on 2018/09/08 18:53:42
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.
#47 posted by Qmaster on 2018/09/08 19:00:44
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
#48 posted by echos on 2018/09/08 19:13:18
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.
#49 posted by muk on 2018/09/08 19:22:47
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.
#50 posted by echos on 2018/09/08 19:26:47
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.
#51 posted by Kinn on 2018/09/08 19:32:00
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...
#52 posted by Redfield on 2018/09/08 19:33:35
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
#53 posted by echos on 2018/09/08 19:43:07
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.
#54 posted by muk on 2018/09/08 20:15:56
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?
#55 posted by Kinn on 2018/09/08 20:16:50
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.
#56 posted by echos on 2018/09/08 20:17:06
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
#57 posted by Kinn on 2018/09/08 20:19:32
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
#58 posted by muk on 2018/09/08 20:24:11
TREASON?
It Gets Better
#59 posted by echos on 2018/09/08 20:31:20
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.
#60 posted by muk on 2018/09/08 20:54:10
Spike also released FTE with literally no documentation making any desire to design for it null from the start.
#61 posted by mh on 2018/09/08 21:06:56
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.
#63 posted by echos on 2018/09/09 01:23:16
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!
#64 posted by muk on 2018/09/09 01:30:16
just out of curiosity, whats the last Q1SP youve played, echos?
#65 posted by echos on 2018/09/09 02:21:17
@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.
|