#1631 posted by adib on 2015/10/05 21:39:05
In modern vanilla like QuakeSpasm you can push level art way further than mdl characters. I believe this is the problem md3 would solve.
What About Fiends?!
#1632 posted by ijed on 2015/10/05 22:41:46
clear to anyone with eyes
#1633 posted by Spike on 2015/10/05 23:28:07
Stock Q1 monsters look like baloon animals.
I'm more worried about the guns - http://triptohell.info/moodles/junk/theblimpgun.png
#1634 posted by Spike on 2015/10/05 23:28:07
Stock Q1 monsters look like baloon animals.
I'm more worried about the guns - http://triptohell.info/moodles/junk/theblimpgun.png
#1633
#1635 posted by Kinn on 2015/10/05 23:35:00
I have no idea who's responsible for whatever's on that screen, but they should be banned from using a computer.
#1636 posted by necros on 2015/10/06 00:24:06
looks like someone put meshsmooth into the engine????
My Eyes!!
#1637 posted by mfx on 2015/10/06 00:25:06
#1638 posted by Kinn on 2015/10/06 01:14:01
Yeah that screenshot's like a bingo card of terrible programmer art "enhancements":
Ultra-hi-res replacement textures? Check.
Replacement textures look like they were made with Gaussian Noise?Check.
Parallax mapping on textures dialled to 11? Check.
And so on...
...
#1639 posted by Baker on 2015/10/06 06:56:51
JoeQuake 0.15 has an implementation of MD3 that mere mortal engine coders could work with. source
But the MD3 implementation in JoeQuake is different than DarkPlaces or FTE.
There are also several outstanding questions like how to communicate eye position?, spinning (unless you don't care if ground weapons work), blood trails, frame groups? and the other flags/info in .mdl not present .md3. And where the texture go, which should be the folder the model is in but I don't think DarkPlaces does that. And how will you colormap the textures or do you just say to hell with it.
Then you have the idea that the implementation should be compatible with DarkPlaces, which could be awkward because you might be talking effectsinfo.txt (name?) to have compatibility for the extra flags.
Then you have the the idea of what MD3 extra features will or won't be supported. Shaders? Alpha?
But JoeQuake has an implementation. Does it work with monsters? Tea Monster MD3 ogre
/Extra info.
If there is *serious* demand for MD3, someone should see if the MD3 implementation in JoeQuake works with monsters and find out how hard it is to make it work. Or even make a prototype for DarkPlaces. Did Spirit's engine inherit MD3 support from JoeQuake?
If people aren't willing to do that, the Quakespasm team has an empty bag of test case scenarios.
/One opinion maybe even wrong.
#1640 posted by Baker on 2015/10/06 06:59:37
Keep in mind, Quakespasm doesn't even support external textures for monsters! Which is more of pain than it should be in a FitzQuake engine because of gl_mesh.c
[Mark V does, another case of great code being available for the taking! Some of it being due to some great tips from MH.]
For Science I Say!
#1641 posted by Skiffy on 2015/10/06 16:31:42
I'll have to give that engine a look I guess. Never heard of it till now. Alpha Key would be a cool feature to support at least. I don't mind making textures look classic quake in palette or at least heavily reduced colors either to fit in with the games look. I would still be down with some shader support down the line like glow textures but for now MD3 on its own would be cool.
For model info like blood trails or spinning maybe include a text file with the same name as the MD3 with some prefix or suffix to include some flags? In the end I just want more vertex precision that is all or IQM for bones still running at 10fps so the game logic does not get borked.
Chunkiness
#1642 posted by Kinn on 2015/10/06 16:48:50
Yeah - I actually love the crunchily pixellated skins and chunkily low polycounts on the monsters; the vertex swimming is the only thing that could do with being corrected really, as there's no way that can be seen as a desirable artistic look by any sane person.
Eye-candy "creep" isn't really my thing, but fixing obviously bad things about the current look is cool.
#1643 posted by czg on 2015/10/06 16:58:11
Why not have the md3 act as an extension for the mdl?
If there's a flappy.mdl, get all metadata from that, and then load the actual data from the flappy.md3 if it exists.
Kinda how lit files work.
Progs.dat refers to the mdl.
Trying to load a md3 without a mdl being present should be an error.
As I understand it there are already tools that convert md3 to mdl, so for content that has been explicitly crafted as md3 it shouldn't be too much work to convert it to a craptastic mdl that people running a good engine won't see anyway.
Though I have zero knowledge of the md3 format, so I dunno if there's some obvious obstacle.
The progs will have to be able to treat whatever new format as if it was a mdl anyway.
Czg Is Spot On
I think if the md3 is present it should load that instead of the .mdl kind of like how texture replacements and lit files work.
But it should be a requirement for the .mdl to still be present.
Also Skiff, I hope you're aiming for the lo-fi cabnbubs implementation of your shambler model. It should still fit in with the Quake roster of monsters.
#1645 posted by necros on 2015/10/06 17:14:18
i like it, do it that way!
Yes I Like
#1646 posted by Kinn on 2015/10/06 17:30:12
what czg said
We'll See
#1647 posted by Skiffy on 2015/10/06 17:48:21
In the end the shambler I am making will be a more modern take on it. BUT if I do get this one done then I could make a more "true" to the original version for folks to enjoy... but seriously the old shambler is origami... its 200 triangles... the dog is almost 600 ha. I have no idea what went on in their heads when making that guy.
MDL Requirement
#1648 posted by Skiffy on 2015/10/06 17:49:12
Yea I like this implementation. MDL as a base with all the proper info and MD3 for more precise updated visuals...
#1649 posted by necros on 2015/10/06 17:57:47
# of triangles is irrelevant. there was enough there to convey the shape of the monster.
it's a very efficient model and well constructed.
#1650 posted by Kinn on 2015/10/06 18:25:11
I have no idea what went on in their heads when making that guy.
Every poly saved was a win back then. Also I imagine the 'bler was one of the early models, like the knight. Later on they had optimised the engine enough to allow for 400-600 poly characters like hellknights and dogs, but I guess no-one deemed it worth remaking the shambler.
Necros Come Now Seriously?
#1651 posted by Skiffy on 2015/10/06 18:36:15
I will let that one pass because I do this for a living. Quake got me hooked on modding and game development after all when it came out.
I do agree with Kinn that it was most likely one of the first things and never got updated. Any game with a consistent art standard would not give a tiny dog enemy over 500 triangles and then 200 triangles for what is effectively an end game boss monster.
We love the shambler for its size, soundscape and evilness. It could have done with better construction and for dang sure better rigging back then though :P
Quake originally ran in 8-bit and 320x200. At that resolution it truly makes no difference whether there are 200 or 2000 triangles on a model.
Yup
#1653 posted by Skiffy on 2015/10/06 18:44:22
But now we try to enjoy it with a little more detail... just a little bit.
Skiffy
#1654 posted by necros on 2015/10/06 19:07:48
is the implication in your reply that the shambler is a bad model? not sure how you can come to that conclusion. with 200 triangles, it would be difficult to make a convincing model like the shambler. i am judging the model based on 1997 as that is when it was made. i guess you are judging it on 2015 standards, which is not really fair.
#1655 posted by JneeraZ on 2015/10/06 19:26:57
There's also the disparity in triangle counts. The dog gets 600 while the shambler gets 200? I think it definitely smells like a case of the shambler got done first and the dog was done later ... and there was no time to re-visit the shambler.
|