News | Forum | People | FAQ | Links | Search | Register | Log in
Modelling Help\Screenshots\Requests
It has always been difficult to get decent models for quake 1. So a thread where people can get advice on making models and post a work-in-progress for critiques is long overdue.

Any requests for models may well get met with silence. Specific requests will likely stand a better chance; "I'd really like a knight but carrying a shield" might be better received than "we need a mdler to join our mod remaking counter-strike for darkplaces".
First | Previous | Next | Last
Py Thon 
Thanks for your comment!

I've read somewhere PILL and PILLOW won't work together.
They're both in my Python32, but I can't uninstall one or the other.
Now I'm a bit confused between the next string and my totally lack of understanding the args. :P

>>> knight.load(r"C:\python32\Lib\site-packages\qmdl\vlak.mdl")
<qmdl.helper.Helper object at 0x00C2A550>
>>> knight.append_skin("avlak.bmp")
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\python32\lib\site-packages\qmdl\", line 310, in append_skin
from PIL import Image
ImportError: No module named PIL
No PIL Library 
That's the error you get if PIL isn't installed. Try following the instructions at the top of the question posted as

They should uninstall PIL and reinstall PILLOW, the person who posted the question eventually found that retrying the commands fixed his issue... 
Extract Skeleton Out Of QME 
Is it possible? I found some skeletal animations in mdl models in Navi seal mod and i would like to mess around with. 
Excuse me?
Skeletal anims in QME?
Are you sure?
Quake engine uses vertex doesn't have bones that move,it tracks the movement of all vertices (if this wording is correct). 
ijazz2019, Yes it is true, but it sesms QME writes joint track info after the regular data in the mdl. Go download navy seal and take a look at pdude.mdl 

>>> from qmdl.helper import Helper
>>> knight = Helper()
>>> knight.load(r"c:\python\Lib\site-packages\qmdl\vlak00.mdl")
<qmdl.helper.Helper object at 0x0051AA70>
>>> knight.append_skin(r"c:\python\Lib\site-packages\qmdl\avlak.bmp")
<qmdl.helper.Helper object at 0x0051AA70>

So far so good, but nothing has chanded the model.
Or am I looking to a repeat of the mdl command
and no append_skin excist? 
You need to put a command at the end to save the model again"c:\python\Lib\site-packages\qmdl\vlak01.mdl")

I tend to use a different filename for the input and the output of my scripts so I can see the difference (and so I have a backup if there's a bug in my script!). But you can use the same filename if you prefer. 
I helped myself out trying some kids tuts for python. Soon it looks as if my turtle.forward comes out square, but that's the end of the line. Every other way of statement ends up wined so my setup isn't right.

I did get a next mdl though. What I'm trying is to make a simpel square of four vertices, add a skinfile with an alpha and see if it comes out transparant in Quake. (If it would be that easy).

Now I end up with a new mdl file what I can't detect, as qmle nor noesis identifies it as a commen mdl. It must be the 32 bit bmp file what blocks. 
Could you upload the script, model and skin somewhere for me? It sounds like there's a bug in my code if its outputting an illegal model. 

Redfield, how did you manage that pinetrees?! 
A Fix And A Bug 
I quickly noticed the big issue here - your skin file doesn't have the correct width/height for the model. The script assumes that you supply a correctly sized skin, and doesn't attempt to resize it or even warn you.

However, once I tried adjusting your skin to match the model, I discovered there is a bug in qmdl I can't quite nail down. Even if the image dimensions matches the image, it seems that the skins don't load correctly if the dimensions are not multiples of 4. Can't nail down exactly what's causing that, so I recommend:

1) resize the model's skin to a size that's a multiple of 4 in each direction, e.g 128 by 64.
2) change the skin to match the dimensions of the model

I got the import to work with your script after those steps. I'll see if I can investigate the bug further now... 
No Bug 8bit Limit 
I adjusted the skin to 128 x 64 and it turns out a usefull mdl.
Nothing wrong with the code.
I think the reason it turns out with a scattered skinfile is because it is converted back to the 8bit quake.pal.

Here is my result. 
is there a q1/q2 export for Blender 2.8? 
See Example 
That doesn't work with Blender 2.8. 
Great, I use Blender v2.6
Take a look at endeavor's tutorial
Maybe you can use the export plugins. 
I remember being annoyed when I wrote a MDL export plugin for an earlier version of Blender, and the next version changed the APIs I was relying on. Puts you off maintaining it...

What I often recommend for creating MDL files is a two stage process - export from your model editor into a more commonly supported format, and then convert that to MDL. I have a tool that support conversion
from MD3 to MDL:
or from FBX to MDL:

Hopefully one of those routes is possible from the version of Blender you use. 
I made turning windmill as a static entity. And did some qc to make it turn. I wanted to make it toggable but not sure how to do it.
When I use two poses to make them turn and break I can use a button on them.

Now the strange effect is that although all windmills have the same targetname, only three of them turn. Toggling makes the other ones turn.

Not sure if the code is right, but only three mills while all size are the same targetnames?

turning walls

Here is the static code:

$frame 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
$frame 21 22 23 24 25 26 27 28 29

void() vibro1_stand1 =[ $0, vibro1_stand2 ] {};
void() vibro1_stand2 =[ $1, vibro1_stand3 ] {};
void() vibro1_stand3 =[ $2, vibro1_stand4 ] {};
void() vibro1_stand4 =[ $3, vibro1_stand5 ] {};
void() vibro1_stand5 =[ $4, vibro1_stand6 ] {};
void() vibro1_stand6 =[ $5, vibro1_stand7 ] {};
void() vibro1_stand7 =[ $6, vibro1_stand8 ] {};
void() vibro1_stand8 =[ $7, vibro1_stand9 ] {};
void() vibro1_stand9 =[ $8, vibro1_stand10 ] {};
void() vibro1_stand10 =[ $9, vibro1_stand11 ] {};
void() vibro1_stand11 =[ $10, vibro1_stand12 ] {};
void() vibro1_stand12 =[ $11, vibro1_stand13 ] {};
void() vibro1_stand13 =[ $12, vibro1_stand14 ] {};
void() vibro1_stand14 =[ $13, vibro1_stand15 ] {};
void() vibro1_stand15 =[ $14, vibro1_stand16 ] {};
void() vibro1_stand16 =[ $15, vibro1_stand17 ] {};
void() vibro1_stand17 =[ $16, vibro1_stand18 ] {};
void() vibro1_stand18 =[ $17, vibro1_stand19 ] {};
void() vibro1_stand19 =[ $18, vibro1_stand20 ] {};
void() vibro1_stand20 =[ $19, vibro1_stand21 ] {};
void() vibro1_stand21 =[ $20, vibro1_stand22 ] {};
void() vibro1_stand22 =[ $21, vibro1_stand23 ] {};
void() vibro1_stand23 =[ $22, vibro1_stand24 ] {};
void() vibro1_stand24 =[ $23, vibro1_stand25 ] {};
void() vibro1_stand25 =[ $24, vibro1_stand26 ] {};
void() vibro1_stand26 =[ $25, vibro1_stand27 ] {};
void() vibro1_stand27 =[ $26, vibro1_stand28 ] {};
void() vibro1_stand28 =[ $27, vibro1_stand29 ] {};
void() vibro1_stand29 =[ $28, vibro1_stand30 ] {};
void() vibro1_stand30 =[ $29, vibro1_stand1 ] {};

void() vibro1_broke1 =[ $0, vibro1_broke2 ] {};
void() vibro1_broke2 =[ $0, vibro1_broke1 ] {};

void() vibro1_start;

void() vibro1_start =

local float r;

if (self.pain_finished > time)

r = random ();

if (r < 0.5)

vibro1_stand1 ();
self.pain_finished = time + 1;

vibro1_broke1 ();
self.pain_finished = time + 1;


void() info_vibro =
precache_model ("progs/vibro04.mdl");
precache_sound ("vibro/vibrosount.wav");

self.solid = SOLID_BBOX;
self.movetype = MOVETYPE_NONE;

setmodel (self, "progs/vibro04.mdl");

setsize (self, '-4 -4 -4', '4 4 24');
self.use = vibro1_start;


vibro1_start randomly plays either "broke" or "stand" -- so, that's why some of them are not moving. If you want them all to start moving when triggered, don't have the random check in there. 
That seem to be the right solution, they all roll now.

void() vibro1_start;

void() vibro1_start =

local float r;

if (self.pain_finished > time)

vibro1_stand1 ();
self.pain_finished = time + 1;


void() info_vibro =
precache_model ("progs/vibro04.mdl");
precache_sound ("vibro/vibrosount.wav");

self.solid = SOLID_BBOX;
self.movetype = MOVETYPE_NONE;

setmodel (self, "progs/vibro04.mdl");

setsize (self, '-4 -4 -4', '4 4 24');
self.use = vibro1_start;

For my humble request, the same macro is used by the turnwall. But it needs to start and stop.
How can I make it toggable? 
create two functions vibro1_toggle_on, and vibro1_toggle_off

The "off" function needs to set nextthink to -1, and set "use" to vibro1_toggle_on

The "on" function needs to set nextthink to time + 0.1, and set "use" to vibro1_toggle_off

Finally, you need to add a line to vibro1_start which sets "use" to vibro1_toggle_off. 
Damn, you trying the recreate chasm levels inside quake? I don't think the chasm levels are that good, only thing worth salvaging are the monster and weapon models. 
I'm starting to believe my own lies, yes that's the way to do it.
Now I can spin down the fans at commands. Really thanks for the hint.
Usually I get cramped by warnings but this time the algebacary is on my site.

yeh1, the levels may not be that good, but what if I use the buttom to go under to furnish the refinary and jump in a fan tunnel?
Chasm monsters deserve a well arrayed terratory.

I wish I could lay my hand on that alfa_mask texture. I'm using static fences , as they are the only way for me to obtain transparancy. 
I like the theme behind Chasm maps, but they are too tiny (you don't have space to run/maneuver) and, like old doom maps, they aren't 3D (you don't have vertical action).

Would be better if you stick with the theme, but not with the old limitations/architecture. Think of it more like a remix than a remake. 
Stratos Attack 
I'm trying to give Stratos a quakey apearance with chasm effect.
So I attached the scrag attack to its needs and changed the w_spike into a circle sprite.

It is shooting round sprites now, but the positioning is a little out of centre.
Also it shoots them one after another, nor at the same time. 
If I recall correctly, that huge robot from AD fires two rockets at the same time, as does the centroid from mission pack 1, couldn't you look at their code? 
Fire Range 
I could take a look at the soa.qc.
For now I'm puzzled by the shooting range of the scrag which comes in a v shape from the scrag towards the player.
Stratos fires exact in the opposite way. 
V Shape 
The V shape is an illusion created by the particle effect on the scrag spit model. If you replace w_spike.mdl with the rocket model you'll see how the smoke particles give a clearer indication of the way the spike moves. It's really just a single object moving in a straight line from scrag to player. 
That's the same outcome when I use a sprite in stead of the w_spike.
My intention is to make it look more like the Stratos attack, ie. starting at the same time on both sides.

I've got the idea the sprite won't come up for nine frames, only the first one is used. That doesn't give it the facet look like a sequence of rings.

The railgun from dr shadowborg uses this sequence, I just don't know how to intergrate it. 
I'm trying to convert the Chasm weapons to quake.
For the shotgun I just used the w_rifle.mdl for the shotgun.
Now I'm trying the double shotgun and it works in the same way.

There is just one thing I can't understand, when I try to use the g_rifle in stead of the g_shot for static it falls just below the surface.
I can heighten the static in the map or in the origin of the mdl, the thing just falls in ground.

What can be the reason of it? 
I used v_shot in stead of g_shot. 
Kinda Rusty But 
check your bounding box's minimum? could be the min_z is 0 not -24. 
I solved the shooting vector by changing Wiz_Start_Fast statements :
missile.nextthink = time + 0.6;
0.6 and 0.8 into the same counts.
And in Wiz_FastFire
dst = self.enemy.origin - 13*self.movedir;
deleting into
dst = self.enemy.origin;

The two launch lasers come from both sides to the player without crossing.


Another thing is wondering me. While working on the Chasm_Rift models I keep the skin texture of 64x960. This odd format makes me play the mod only in Quakespasm. Fitzquake and other engines just won't start.

What would be the easiest way to convert this skin 64 x 960 to a more commen format?
Something with UV filters, I tried Noesis but I can't find a way to get to the skinfile. 
AFAIK there is no limit on skin width. If that's the case, the easiest way is to just swap U and V. Here's a quick'n'dirty script that should do the job. Make sure you test everything though, as it doesn't take stuff like on-seam offset into account at all.

It's also possible to move UVs around arbitrarily, then just re-project the skin texture, but it would be somewhat tricky to keep the pixels intact. 
My computer is incompatible with the program.
I could try yo use it in Python, but Python doesn't like me.P:
Thanks anyway. 
Holy Cow! 
Yes, thanks chedap.
That was just the thing I was looking for! 
now I have my skinfile from :
height=960 x width=64
height=64 x width = 960.

If I'm not mistaken the maximum height = 300, the size of the width isn't that important I'm told.

When I make a try-out of the resized skins in Fitzquake085 it just shuts down. Maybe Mark V will do, but I was wondering how to reorder the skinfile back to a commen quake format. 
Well yeah, that's what I said it'd do: switch width and height. Weird that it shuts down. I know Nehahra had 1500px+ width skins, but that's Nehahra.
I'll try things out myself, give me a couple of days. Previously I just tested if it loaded in QME. 
Skin Size 
First skinfile I know is 300x200. Later on it changed to other formats as engines become more advanced, but it seems to be a prior limit.

I know there is a way to hussle with the UV map, but I never succeeded in doing so. 
Probably Something Else 
So first off, h_gross.mdl is reported as invalid by most programs (regular Quakespasm, QME 3.0, Blender importer). The version is reported as 'RAPO' instead of 'IDPO' though that tells me little. Curiously, it opens fine in QME 3.1, but re-saving it doesn't fix the issue. It's probably easier for you to re-convert it properly than for me to poke blindly at it.

Now then, h_gross aside (replaced it with another h_grunt), the good news is that this actually runs just fine in regular Quakespasm, QSS, FTE, BJP and even in WinQuake. On DOSQuake it won't run on account of 200 height limit (fan.mdl skin is 616x252 and can't be packed tighter, short of remaking the thing from scratch).
So I don't think the issue's in the skins (or in my script).

FitzQuake and GLQuake both crash though. Well, the map does, can load to vanilla maps fine. Maybe there's some other weird limit it's hitting - I wouldn't know. Try a simpler map.

A slightly safer version of the script that now accepts entire folders. Still barebones, ignores on-seam etc - I went through the models and none of them seem negatively affected (for comparison try putting fan.mdl through this and check the resulting UVs). 
So I don't think the issue's in the skins
I can't see another reason.

The error of the h_gross comes in like a bug somewhere.
If I would have simply copied it I could see a reason for a hidden flag that gives that recall.
But I made the h_model myself, just like all the others.

When I have the one last stand frame of an entity and I clipp off all, except the head, where can be the flag that's says I come from Hexen2?

Another thing, the fan model I made myself so it's easy to clip that skin file back to 200x300.
I think it are that irratic 960 x 64 seize that make account. 
Sometimes, i make some edits in a model and quakespasm-spiked refuses to load it, and shows that message about it being in a hexen2 format.

To solve this, open the model in QME, go to "Utilities/Remove Dangling Vertices" and "Utilities/Remove Degenerate Triangles". Save the model.

It works for me. 
Alright, so:
- As of devkit2.27, it runs on DarkPlaces, DirectQ, FTE, QSS and QbismSuper8
- If I swap UV, it also runs on MarkV(DX), Quakespasm, TyrQuake(GL/SW), vkQuake and WinQuake
- If I then also crush the height of the fan skins, it runs on DOSQuake
- If I then replace joker.mdl, it also runs in FitzQuake and MarkV(SW)
- If I then replace fense.mdl, it also finally runs in GLQuake
- If I then recompile with 256x128 sky2, it will show up in DarkPlaces

I haven't done anything with h_gross (skin height 512), and it still runs even in DOSQuake. That means it's possibly not the only one waiting to cause problems.

joker.mdl has artifacts in QS and in vkQ. Looks fine in other ports. Probably some broken geometry.

fense.mdl just has too many vertices.

Sky textures have a specific size and both halves are supposed to tile independently. 
First | Previous | Next | Last
You must be logged in to post in this thread.
Website copyright © 2002-2020 John Fitzgibbons. All posts are copyright their respective authors.