 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
|
I tried to keep the title post nice and short in the hope that this thread is as long lived as the coding one. So here's a slightly longer one with more information (and also more of my opinions you've heard three times before)
The mdl format was one of the first 3D model formats for games, and naturally is a little less advanced than anything seen today. Here's a rundown of the most important mdl limits: 1000 vertices 2048 triangles 256 frames The other important limitation of the mdl format is that the vertices are stored with a precision of 8 bits per coordinate axis. The vertices are in effect "snapped" to a grid of 256x256x256 points. This means you can't create intricate detail in your model without it being lost when it moves. It is worth noting that the origin and spacing of this grid can be specified, so the level of detail which can be retained is relative to the overall size of the model. Editing One of the greatest barriers to making models for Quake 1 is the lack of good tools. The best tool which works with http://www.fpsbanana.com/tools/2544 and you can upgrade it to version 3.1 with the patch in http://www.xs4all.nl/~renep/quakeme/qme31_p2.zip Although QMe is useful for this reason, I'd personally recommend working with the mdl as little as possible. It is generally easier(in my opinion) to create your model in another format entirely, preferably one with a powerful editor which saves the vertices at high precision. Then just export the model to mdl each time you want to test it, much like you compile a new copy of the BSP each time you add to a map. QuArK ( http://quark.planetquake.gamespy.com/ ) also handles If you work in Maya, you are fortunate to have the most direct route to export to One package which handles everything directly! If you work in Blender, you can give a script for exporting to mdl directly a go: http://www.btinternet.com/~chapterhonour/mdl_export.py I wrote it a while ago, for blender 2.4.4, and I don't intend to ever revisit it. But it's written in python, so it should be straightforward for people to modify themselves. Alternatively, you can export your model to MD3, using either http://tremx.svn.sourceforge.net/viewvc/tremx/trunk/blender/ or http://cube.wikispaces.com/MD3+Export+From+Blender+Tutorial Once you have an MD3 of your model, you can run it through QuArK to convert it to mdl. Alternatively (blowing my own trumpet here) you can use "MD3 to MDL" http://www.btinternet.com/~chapterhonour/md3tomdl.zip This is my new work in progress, and I welcome any feedback on it. It's a simple command line tool, requiring only a short text file and an MD3 to work from. I'm planning on extending the control file format to include things like model flags, multiple skins, named frame ranges and stuff, so suggestions of what could be useful will not go ignored. Since MD3 is so well supported amongst editors, you can use the above to get to This thread is pretty much a continuation of http://www.celephais.net/board/view_thread.php?id=60262 , a thread I'd forgotten about until I started researching for this post. Hopefully putting all this information at the top of the thread justifies starting a new one. Finally, if the low polygon requirements of Q1 seem constraining, take a look at: http://boards.polycount.net/showthread.php?t=41232 The things some of those posters do with 500 polys are just amazing. Lunaren's mdl export is at http://lunaran.com/files/lunmodelgen.zip
I previewed to check which links worked, and then messed up actually fixing that one. Also, to get the ball rolling on actual models, here's a pair of screenshots of the ogre I made ages ago based off metlslime's drawing: http://www.btinternet.com/~chapterhonour/ogrescr1.jpg http://www.btinternet.com/~chapterhonour/ogrescr2.jpg Last time I posted it, it didn't have any blood splatters, and that criticism has been answered. One of the reasons the first version lacked them was that the entire skinmap was mirrored, and so any blood splatter on the chest ended up looking like a rorschach blot. So I carefully unmirrored a few polys here to do the chest. The other reason I hesitated to do it before is because quite a few of the original id models rely on excessive amounts of blood to mask horrible UV failures. I wanted to make sure this model didn't do that anywhere, which is why the blood is a bit restrained. Hopefully he still looks like a butcher! that ogre looks awesome,all it needs is a small amount of blood specks and splashes on its clean face and it will most likely be a widely used replacement
Thanks for the toppic.
After my own experience with quake models I must say you skinned the Orgue well. In the overall making of models I find the texture part the hardest. I must admit that if i hadn't had Quark4.07 I couldn't change the dimensions of the model, nor manipulate groups of vertices. One of my greatest concerns of QMLE is the texture part. What do I do with tex triangles that are mirrored after imported in Qmle? If I delete the triangle and patch the vertices again the triangle: comes back with the same texture, so it's useless work comes back with a extensive texture subdividing, so texturing can only be done by percisely following the lines untill they make squares. Here's how I avoid the problems with the mirrored textures in qme: I don't use qme for that model - at all!
Now this is something I'd like you to try MadFox. Have a go at making a quake model without using qme, and see how it goes. If you don't like it, then that's fair enough. But based on the problems you've posted, I think you will like it. feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking. ^^ I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon. And as it only goes with squads, all triangles get doubled. Then I'm confronted with importing the New Model from frame. Saving this first frame also makes my skin frame. Then I have the choise to turn this first 3DS frame by changing the skin adapture. According the import file it will be a front sight or a side one. So when a triangle gets mirrored I'm delivered to Qmle weary workarounds. I already tried other ways, but the thing that knocked me out was the import/export to Max3D. Everytime I seem to get two vertices more by exchanging. Do you mean Qmle or Max3d?
Here's a new version of my Granito monster. The first one was rather blocky. http://members.home.nl/gimli/granito.gif feels like asking how to learn riding a bike,
and then say don't use the bike. Start walking. But the bike keeps crashing, mostly because it has bent wheels, no handlebars and a loose chain. Under those circumstances anyone would recommend you try walking! I don't make the model with Qmle, I'm glad I can import them into Qmle with 3DS files. This goes with an animation programm which is more specificated. I have to change the export to one patch per polygon. And as it only goes with squads, all triangles get doubled. Yes! The point at which you start importing the frames into qme is the point where the problems arise. This is what I'm driving at. You can avoid that problem by creating an mdl with all the frames in first, and then open it in qme. I'm not saying it's impossible to make a model importing it frame by frame in qme. But if you import frame 1 into QMe, then change the original model, then try to import frame 2 from it, then it's very likely to fail. The import system from QMe just isn't designed well enough to do that(if indeed such a thing could be made). The only reliable method is to re-export all the frames from the latest version of the model, and import them into a fresh qme file. Since then you need to scale them all, reimport the texture each time, etc - EVERY TIME the source model changes, it becomes a huge hassle. But if you stick with just QMe for the conversion, it's what you must do. this has bit me in the ass twice, once a few years ago, and then it happened again until i realized what was going on:
If you are modelling something like a laser or fireball or something, the temptation is to just fill the entire skin with the color or pattern that you want to use as a texture. The problem is, glquake and most variants will flood fill black into whatever color is in the top left corner of your skin. So if your blue laser has blue all the way to the corner, that blue will turn black and you will be saying WTF when you see it in the engine. Fix: for solid-colored skins, put a single black pixel (or other un-used color) in the top left corner. Trinca, thanks, but explain me the need of fixes.
Preach, don't care my foolish waistblam, it was just the first thing that came up to me. Being modelling so long on my own way made me more curious to other ways. Hassling the first frame is because I want to have a good skin.bmp When the basemodel is imported it can be on different sides. At that point my model is already done. So I can import them as one load, and the only problem I reach is some verticemeshes. The way I described it was somehow confusing. My fault. Something else got my attention in trying to avoid the mirrored texture. When I delete a triangle in Qml and add a new one the original count gets different. This seems odd as logically this shouldn't be so. After that I can't add frames to the original. But when the model is full of frames, these changes don't seem to bother. The reason why you can change triangles like that is because the first frame you import to qme is given special treatment.
When the first frame is loaded, the program loads the triangles and the vertices. The vertices are assigned numbers as they are loaded, and the triangles are recorded as sets of three numbers, each number corresponding to one of the triangle's vertices. For all the subsequent frames, the triangle information is entirely ignored. All QMe does is load the first vertex from the file, and move vertex 1 to it's location, then load the next one, and so on. The list of triangles from the existing model is always used. You could import a frame from an entirely different model, as long as it had the same number of vertices. The obvious danger is that your modelling program might not always export the vertices in the same order, particularly if you change the model somehow between two exports. This is how triangles can start to go astray. There's no way to control this kind of thing, which is why the import process can get frustrating. As far as the exporting 3d package is concerned, one ordering of the vertices is as good as another. But for the import, it's the only important thing! You could import a frame from an entirely different model
This reminds me to the moment I had the last death frame of granito, and used the expand function in Milkshape to make all polyhedrons wide out as an explosion. It took me quiet some time to make sure I had the right count. The frame imported the well, but when I closed qmle and reopened the old death frame came back again. So it are the vertice count that need to match, not the triangles? In my search to new monsters I'm fixed upon the need of some danger in Quake waters. Only the hartbreaking code part stopped me from doing. This doesn't avoided me to try and I came up with this creature.
In Quake defs it outranges the limits as it goes up to 507 verts and 957 triangles. But I still see it appear in Quake so my greatest concern is to have it good skinned. http://members.home.nl/gimli/frogman.gif I restarted the frogman again because the base frame had a bad texture error. By doing so I got messed up with vertice errors that went so far that now on my x-th frame I became a little nerd.
I wondered. If I look at the dragon.mdl of DOE it seems they have cut the whole monster flat on the texture frame. If I look at my base frame I get the picture of the monster front and back. If I cut the monster into pieces (sure, one day) Qmle gives me the well known error: vertices and triangles are not the same. How do they do it? found it. it has something to do with cheating qmle import and export abbilty's.
yes, this makes the texturing a lot more acurate. I plunged myself adding a new weapon in Quake1 and have come to the point I could compare it with the SuperNailgun. I added an arrow and add it to this weapon. Sofar sogood.
Then my perfektionistic habbits turned up and thought: how can I make this arrow fall to the ground instead of vanishing in space? I'll stop because I want it's velocity not as fast as 1000 and I want it replaced by the axe and... so how make I fall it against a wall and it lies there for say a few seconds? And post with content so here I go... http://members.home.nl/gimli/cross.zip i did this for my stake gun a while back.
essentially, you're going to go into the projectile touch function and get rid of the the lines calling remove(self) or SUB_Remove(). now, it's a matter of changing the movetype, so where the remove lines were, you put it self.movetype = MOVETYPE_BOUNCE. now, you don't want the thing to stay there forever, so we're gonna put SUB_Remove() back in, but in a different way. put in self.nextthink = time + 4 and under that self.think = SUB_Remove. this will get rid of it 4 seconds after it hits. finally, you can add in some extra stuff like making it spin around randomly with setting self.avelocity to some random values or you could spawn a TE_GUNSHOT for sparks or something else. necros, I will try it out.
But I was thinking, what if the arrow doesn't hit a wall but a monster? Then it should disappear immediate. you're quite right.
luckily, it's very easy to do so. simply make a check: if (other.flags & FL_MONSTER) remove(self); this will check if other (whatever it hit) is a monster, and if so, remove itself. Yeah, I discovered that when fooling around with my model editor. Some cool stuff could be done like blinking lights on enforcer suits and blinking, glowing eyes on monsters.
I renewed the download with my additions.
Although I altered the weapons.qc with your advice on #22 the arrow seems to stick in the wall and slightly turn to left untill it meets the corner. Then it disappears. I also added the grenade tumble but it doesn't append. I only had one time it started raining arrows. You can cheque it on the same download. It was the first calling remove(self) in arrow_touch I came to.
I didn't realize it had to be the second one on the end of the script. It's working well now, thanks! But shouldn't just adding 'nextthink X' and leaving SUB_remove have this work?
The projectiles would still do damage while waiting to be removed, but not if their touch was changed / removed. Argh. The definition of complex - lots of simple. I followed the code of Dr.Shadowborgh to make a new weapon in Quake1. I added the Q2 g_rail gun and assigned it to the double shotgun.
So far so good. Now my concern is starting a game with the g_rail.mdl. Although this weapon is coded on the doubleshotgun (3) it loses its touch when I switch to the shotgun. So when I still have enough cells to shoot, the game only offers me the railgun again when I collect the DS. So stop shooting is gone gun. I am forced to add a double shotgun too before I can acces the railgun again. Is there a model-code to solve this?. example: http://members.home.nl/gimli/grail.zip normally, i would just do a dxf export from qme and import that into 3ds, but for what i want to do, i need a fully animated model (with all it's frames in order).
i have a am i sol for this? any utilities i'm unaware of? Don't you have the Q2MDLR9B, I searched for it but it's one old Q2 mdl converter with also Q1 models. It exports into 3DS very easily compatible toMax3D.
Here's a linkhttp://members.home.nl/gimli/q2mdlr9b.zip: i think maybe the solution is in 3dsmax and not the exporters... there might be some way to create a vertex animation out of multiple copies of a mesh as long as the vertex # are consistent.
the thing that jumps out immediately would be to use the morph modifier with 1 channel for each frame, and to incrementally toggle each one on and off on the appropriate frames, but that would be extremely annoying and there might be a limit to how many morph targets you can have. Morph would do it, but be very time consuming.
A nastier problem would be that each model would be its own object, and so have the verticies number individually - there's no way to manage this in max. Normally with morph you use instances of the same object so that the verts have the same numbers - different objects would most likely get interpolated all over the place. Bones is the way to go - but that means recreating all the monsters as such :P It wouldn't take much time really - what's needed is a decent morph plugin that allows more vert control - morphing via position as opposed to number.
Will be looking around. My usual route is to convert it to md2 format using QMe, and then importing that with an import script(this is gmax, but I'm pretty sure that the same script can be found for 3dsmax). I do worry that some animation quality is lost in the conversion. It is potentially avoidable, by choosing the scale to be the same in each frame of the md2 you can get a lossless conversion, however I suspect that QMe does not do that.
If the fidelity of the animation proves to be a problem, then I might be able to knock up a python script or something which does mdl->md2 lossless conversion(modulo the skin, which would just get mapped index for index). the gmax md2 importer script here: http://www.scriptspot.com/3ds-max/quake-ii-md2-importer works with 3ds max 9. i was able to import some stock q2 models in with full animations in.
next i'll try converting to q2 from q1 format. If it works with 9 and gmax then in theory it'll work with all versions since gmax was discontinued a few years ago (?) so it should be alongside the
I have come this far with my amphibian monster.
It stands on land and in water and starts its attack as soon as the player is in vieuw. The landmonster will start shooting and follows it into the water where it turns into swim behaviour. The watermonster will go into swim position vieuwing the player, but only starts its attack when agitated. Also it hardly shoots as its position is somehow dull. Point is I can't get it out of the water. I'm trying to see with my hard-egged qc cramp what's going on but must admit I'm a dumbass. Here's an example of the model: http://members.home.nl/gimli/harpio.zip didn't look at the code, but for the (uncompleted) monster that was supposed to do what you are describing, i settled on making special monster jump triggers.
essentially, you would make your trigger in the area you wanted the monster to jump out of the water and you'd just set speed and height just like a normal jump trigger. the only differences were that: 1. it didn't affect any other monsters 2. if it was a 'get out of water' trigger, it would do nothing if the monster was on land (and if it was in the water, 'get in the water' triggers would similarly do nothing). it makes coding it a lot easier, but it kind of takes away from the monster by making it dependent on the mapper. (imagine if fiends only jumped where mappers put triggers, for example). you could take a look at the code that makes the player jump out of the water. this could work but it could be troublesome. the player code is run every frame, so it doesn't miss chances to jump out of the water. but a monster not only is running it's code slower (0.1 seconds) because of movetogoal, it will never really be flush with walls unless it gets lucky. otoh, if all you mean is you can't get the monster to walk out of the water on, say, a ramp, the trick is to take off the FL_SWIM flag early. every frame of your swim function, run a test of the pointcontents over the monster's head (say 16 units over the monster's origin) and use that point to determine when to swim or walk. i wanted to ask you how you combined the legs, torso and head of the skeleton from quake3 when you converted it to quake1. i can't think of a way to do that in 3ds max while preserving the animation. :S
I must admit I have only converted one frame of the deathscene,
where it stands straight with all limbs in line. From there I made a 3ds file of it, which I used as baseframe. Then in am2000 it is possible to make the model act with sepperated limbs and export the 3ds. Then I bunched against the 1000 verts limits of Qmle, and had to substitute the torso with all the fine parts for a much simpeler one, and then I could import the 3ds into QMLE. It sounds simple, but I tried the knight in Max3d and must say the way it handles bones is much more specific I could give my patience. Which programm do you use to convert the model? I searched, as it was in answer of my question how to convert q3 maps to Q1. Something like Q3map2 : http://shaderlab.com/q3map2 after 2 days of trial and error, i figured out a way to do it.
http://necros.quaddicted.com/temp/hunterq1.jpg (hunter was always my favourite ^_^ ) the process is roundabout and exceedingly headache inducing. :P also, if you want to do this, read my whole post first. step 1: we need to get the 3 q3 md3 files (head, torso and legs) into 3ds max (in my case). for this, i used this script: http://www.scriptspot.com/3ds-max/quake-iii-md3-importer-public-beta surprisingly, it worked in 3ds max 9 (usually most scripts this old would never have worked). if you follow the instructions on that web page, it will work properly: use the script to import upper.md3 first, then lower, then head. this will make sure the tags link up with the body parts. (pre) step 2: involved transfering the animation key frames from the torso tag onto the torso mesh itself. the torso doesn't actually move, it only has vertex animation; it uses the tag to make sure the torso is properly oriented with the legs but in order to export the animation, both the translation and rotation must be on the torso mesh object. step 2: select your torso tag and go to file -> save animation. save the file with a name of your choosing some place convenient. now, select your torso mesh and unbind the mesh from the tag. go to file -> load animation and select the file you saved earlier. you will get a message box "No tracks are mapped. Create map file?" and click yes. you'll see 3 list boxes, two on the sides with the middle one empty. Ctrl+Click on both the sides the item that says "Exposed World Transform" then click the button with the arrow "<-" this tells max to use the world transform from the save file on the selected object. Click the "save mapping" button on the bottom and save it somewhere (not really important, it just doesn't let you load the animation without saving first) then click "load motion". if everything was successful, your torso should now be moving on it's own, without being linked to the torso tag. step 3: redo step2 except for the head. step 4: now you need to rearrange the uv mapping. originally, head textures take up the same spot on uv maps as the body does, but when you are combining all of this into 1 model, you will have overlapping uvs for the head on the body area. for a quake3 player model, the body is 256x256 and the head (in the case of hunter) comprised of 2 128x128 textures (the face + the feather hat). i chose to make a 512x256 texture, with the body on the left, and the face+hat stacked on top of each other right next to the body. this leaves a 128x256 empty area we can use for the weapon. step 5: before we can export, there is one final step to do. the thing that drove me crazy for the longest time was that the head would never export any frames, even though it had keyframes. the problem is that the tool i had to use to convert the 3ds max models back to md3s (http://www.quakeunity.com/file=481) only looks at *vertex* animation when deciding if there's a key frame there or not. so what you need to do is go into the head at vertex sub-object level and add a key frame to any 1 vertex at the end of the animation. (i just move a vertex an incredibly small amount). step 6: delete all the tags (they aren't needed) and export the whole model as an ase file. make sure you have it set to export keyframes every frame. step 7: open up npherno's md3 compiler (http://www.quakeunity.com/file=481). import the ase file but only select 1 component. export the single component back into md3. close, reopen the program and do the same for the torso and head. step 8: use preach's md3tomdl converter (http://www.btinternet.com/~chapterhonour/md3tomdl.zip) to convert the 3 pieces into mdls. step 9: (these next steps are the 'dumb' parts) open qme and open up the legs. then, using import object, import the torso. qme, annoyingly, has no options with what to do with incoming object's skin mapping, so although the nice uvw maps were preserved from the original md3 files, they will be placed next to each other. step 10: open quark 4.07 (yes, really). load your combined model. you'll notice your actual skin now is absolutely massive (i think it was 1536x256) because qme just kept adding stuff on the sides.
what you need to do in quark 4.07 is select the torso verts on the skin mapping editing window and slide them way over to the left (where the legs verts are). for the head verts, i wasn't able to slide them over next to the body verts because they were considered 'on the other side' and so werent' allowed past the mid-point of the skinmap. so i slide them just to the right of the mid-point. finally, (still in quark) go into the edit -> model properties menu. change the width to 512 (make sure the 'right' radio button is selected so it will remove stuff from the right side, not the left). this should place the head verts right next to the body verts and everything should be perfect. if not, the gods have not smiled uopn you and you are SOL, sorry. Save. step 11: now all that's left to do is to name your frames which you can do easily in qme. yay, you have a q3 player model in quake with uvw and animations preserved. :P note 1: i'm not sure if you could skip the 3dsmax process for the legs and torso, since the only real modification we had to do was with the head (regarding the uv mapping change). note 2: there may be a way to collapse all 3 components into a single mesh object. the problem is that simply attaching the mesh objects together discards their vertex animation with no way of reclaiming them. the other method involves using boolean with unify operations but you can't export frames that way because the key frames of the boolean operands don't count and the md3 compiler will only see 1 or 2 frames. (although this method does at least preserve the vertex animation) so yeah, anyway, in most ways, it's probably better to do it the way you did madfox, import a single frame, combine it all into a single mesh, re-weight the vertices with new bones and animate it again yourself. this is the more logical way, i suppose, but i really wanted the original animations as well. :P npherno's md3 compiler: http://www.quakeunity.com/file=481
preach's md3tomdl: http://www.btinternet.com/~chapterhonour/md3tomdl.zip I.m convinced necros you're aproach leads to the most pure way to extract a Q3monster to Q1!
In my case I more felt out of choice because I didn't expect three animations for one model. Then the fact Q3models contain much more verts than A Q1 model made my plan for converting a rather silly idea. As I have only Max3d 4.3 I'm furious looking to get the 9th version to check your method. Suburp model, hunter! I know necros is in agreement with me here, but thought I'd say this:
Autocombining skins can be done. Automatic combination which is nice - low skin wastage, power of 2 skin dimensions, scale preservation - is almost impossible except when it is trivial. If you have two 256x256 skins then putting them side by side is straightforward, but if you have a 128x128 head as well, you're in trouble. And I know that quake can take irregular skin dimensions, but the reasons no other games do that still apply to hardware quake rendering. On naming frames: it is something I'll probably include in the end, since the hardest part of coding that is writing c++ which will parse the list out of the text file. The reason it's low priority is that the engine doesn't use frame names for anything. Possibly when I add support for framegroups, there will be more reason to have this. You would define the frame sequence names, then have a second list of which of those frames should be framegroups. Wild though for the day: Since I'm the person so in love with the edicts command, I invented another feature for it. When you get edicts info for an entity with a model, the value listed in "frame" should be the name of the frame pulled from the model, with the actual frame number in brackets. I had a look at the code last night, and was a little surprised to see that the code already iterates over all of the components during the mdl export process, in the manner I suggested above (mapping everything to one skin and presuming the frames align). So far, so good.
The problem actually appears to be in the md3 loading code, which fails in the case of 3 or more components, although I believe it should work with 2. Hopefully I will be able to fix this very quickly and then release version 2 as a bug fix which enables many features... So I think I may have discovered one of the contributing factors to the bug. While reading the header for the MD3, I skip over the number of tags that the model has, since they aren't used in Q1. You can get away with ignoring some data when parsing an MD3, because it helpfully gives you offsets within the file to the various frame/tag/surface chunks. Unfortunately I forgot to do the corresponding code to skip the bytes representing the tags offset in the header, and so was reading that value into the surfaces_offset instead.
The only reason I ever got away with this is because usually I use the program on models with no tags, since there's no point adding them to models for Q1. Any time you try to import a model with tags, it chokes by trying to use tag data as vertex counts, which often end up being negative values. So hopefully with that fixed, I can close in on the bugs with multiple surfaces instead... http://www.btinternet.com/~chapterhonour/md3tomdl.zip
Version 0.2 with proper support for multiple surfaces. As it turned out, not one character was wrong with the mdl exporting code from v0.1 with regards to multiple surfaces. It was all errors in the md3 loader which I think are now squashed. Comments welcome! When I saw the serpent in the Qtest map I thought it looked like a bad imported dxf file. One that appears after bad im/exporting.
So I decided it could look better, but after my first attempts I realized how difficult it is to import a good dxf/3ds file into QMLE. Always the skinfile looks damaged with triangles appearing mirrored. When I finnaly had a good one I thought to be right. Obviously the skinfile tends to keep its mirrored habbit. What to do about it? http://members.home.nl/gimli/Base.jpg after replacing all distorted triangles I ended up with a meshed skinfile.
Then I loaded the model into q2mdlr9b and imported the skinfile in pcx. It loaded well in qmle after redrawing the verts on the skinfile. I had to know this before, after all the time I spend in QMLE correcting skinfiles. here's my result of the serpent.
I only construct the model, the skin is one of androidart.com I lately saw here on the board. Sure is a fine skin texture piece. http://members.home.nl/gimli/serp00.gif Madfox, that is very good stuff :) You should really use that as a new monster type. Would look awesome as a flock swirling around high above the player before attacking.
Thanks for your attend.
While I'm learning to understand what makes monster developement so hard I'm mostly surprised by the way I'm struggling with QMLE. I've spent months on Bones trying to correkt verticemeshes. Thing is: QMLE imports from the baseframe. If this baseframe is allready in the model.mdl the program tends to import dxf/3ds files corrupted. Me being glad to have the model in Qmle didn't mind to go frame by frame updating all corrupted vertices, with the habbit Qmle always picks up the wrong one. Untill I found out when importing the fresh baseframe and then at one stroke all frames importing delivered a clean model. My god... ! Then the skinproblem appeared. When an imported basefram is in QMLE, and not all trianles are visible (which is always the cause) the imported skinfile will be partly mirrored on the unseen triangles. It took me almost ten years to conclude this. Now looking back it comes to me as if the serpent model in Qtest is a kind of distorted imported model. Although they (ID) had to take of as less verts as possible they made some good models with these limits. The Qtest-serpent has 90 verts and 178 tris. Mine ended up with 95 verts and 190 tris. Can't help seeing the reminisence with the later dragon models. Anyone know if this was ever released?
basically I want to remove the 'helpful' auto-UV map feature that breaks my UV's and makes them shitty Quake front/back projection when importing non I realise having the source might not help me still so am going to try the model exporter from Spirit's bounty as well. Doubt that'll work either though since Qme only imports frames in so he can go on a rant on how all of quakes stuff should be open sourced, at least form this point forward.
and then ill be back later to agree with what he said to be part of Baker's army on that front.
Non-open is death. Even the most dedicated are only human. A binary is a slow death. What's a decent way to convert to the Quake palette from full colour in Photoshop?
Metslime, what are the changes that you'd make to TexMex? It seems to do pretty much everything needed, for me. Just curious. there's at least one crash bug that i hit periodically, plus it doesn't remember folder names from previous export/open/save operations, also, maybe some better fullbright handling.
ijed, are you asking what will yield the best conversion result?
the only thing i'd say is to check each of the different dithering options. some types of textures will look better with one type of dithering pattern, and others will look awful. also, unless you want fullbrights, make sure the palette you're using to convert has the fullbright colours blacked out. If you find the image you're converting has different "textures" within it, you may notices that a type of dithering works well on some parts but not others. In quake, this can be particularly apparent when converting an image with colours outside the usual range - often a less dithered conversion will alter the colours more significantly.
In this case, I've found it useful to do each type of dithering on copies of the original image, all moved to different layers. You can then use one as a base and create a hard-edged mask on the other layers. This way you can get the best of both conversions fairly quickly. hadn't run into a case where multiple dithering methods were needed, but this is a good thing to remember, thanks ^_^
limited to like 6 or 7 frames? i have a 12 frame skingroup but it seems to loop before playing the whole thing. T_T
option to manually animate is available, of course, but i finally found something to use that stupid skingroup thing and it's broken. :P DP has this bug fixed, or was it a limitation in the original glquake?
i can't run that engine to check. :S i'm using quakespasm. it's not an actual frame thing-- manually animating the 12 frames works fine. and might only accept 1, 2, or 4 skins in a framegroup. Or maybe even worse than that. I'm pretty sure 4 works.
Fun fact: fitzquake probably hasn't fixed this. Today I'm launching a bi-annual feature called "Model of the Week" where I offer a new quake model for use in maps. This week: waterfall.mdl
http://www.btinternet.com/~chapterhonour/waterfall.zip This model comes with a demonstration map, which uses quoth's mapobject_custom to add the model to the map*. Extract the map into quake\quoth\maps and the model into quake\quoth\progs. I recommend viewing in winquake first, and then in stock fitzquake to see the "progressive enhancement". Usage: waterfall.mdl is a 32 polygon model, measuring 64 units wide and ~192 units tall. The origin lies dead centre of the bottom of the waterfall. Place it in your map accordingly, with angles facing outwards, and set the frame to 6 for the loop animation. The model comes with 5 skins: Freshwater(0) Effluent(1) Molten(2) Blood(3) Toxichem(4) This covers the main fluids in quake maps, but if you need something unusual or a better match for your water texture, the model is easy to customise. Simply inserting the desired water texture as a skin will create a reasonable effect, although adding "waves" to the top and bottom is strongly recommended so that the flow can be read easily. Care has been taken to ensure that no visual artifacts can be seen behind the waterfall, but if you want to let players get behind the waterfall you may want to look at the flowflat sequence, which is not as tall as well as being flattened, so that it can be used for the back-face. Advanced usage: If you poke around the model you'll probably notice the spring and dryup sequences. These two animations were actually a happy accident, they were a byproduct of creating the main loop which I realised could be useful about half way through modelling. If you want to use them to create a waterfall that starts and/or stops you will need to tweak the model a little bit. The important thing to do is to ungroup the flow animation. This lets you line up the frames so that the interpolation and waves move consistantly. To make the animation smooth always transition from spring7 to flow1 and from either flow8 or flow16 to dryup1. So Preach, I don't want a 3 page diatribe on how you made this thing work but...would it be possible to make a custom-designed waterfall model with a more complex flow within a static model? We really shouldn't be talking here, but I know somewhere more private - e-mail me. *Just to note use of quoth is just me doing the laziest thing that would work - the quoth mod is not doing any clever behind-the-scenes stuff to enhance the effect. It simply precaches the model and displays it in the map. My last map has green water, so for a waterfall I exchanged all "+fall6" blue pix into green. A rather dull experience, thanks!
that is brilliant. do they stack easily? could one theoretically use lots of them together to create a kind of niagara falls type wall of water?
and yes, needs splash sprites! Yeah, I actually messed around using a func_togglewall with particles to create a spray effect at once point. It looked very cool, but I took it back out to keep the focus on what the new model can do and not the existing features of quoth(if used in a novel way). Certainly something for people to experiment with in proper maps.
I'm not sure that stacking horizontally would work too well for a few reasons, although tweaks to the model may overcome these. The first is that the random sync flag is set on the models so the waves would not come down together on adjacent falls. Even if they were in sync, the fact that the waves sweep diagonally means that they wouldn't align. Finally the texture itself does not tile in any direction so you'd see a seam without changing it. Stacking vertically would be ok, but I'd warn against anyone who was intending to carefully tile the flat waterfall effect end-to-end to build a long one. Firstly you'd again not be able to tile the waves correctly because they hit the bottom 2-3 frames before emerging at the top. Secondly the animation is supposed to have faster falling water at the base than the top. Tiling would create a stop-start effect. A better plan would be to create a stepped waterfall with simply two or three regular falls feeding one another. You could create height variation by having one intersect a second somewhat(although the wave-splash would be somewhat lost) or by duplicating and scaling the animation. Can I just add how nice it is to get feedback like ^^^^^. I've been tweaking the model on-and-off for a week to the point where it didn't do that for me, and I was worried I'd overworked it and lost what was so great about it at first. So thanks to all you guys for casting fresh eyes on it. Sounds like nobody's cracked out their model editor to find the easter egg though... that is surprisingly effective! i think i prefer that than fading in water falls like i did before. especially since it has a proper start/stop animation.
http://www.btinternet.com/~chapterhonour/flatnorms.pl
If you edit and save the model with QMe or similar you might notice that the model starts looking odd and flickery in-game. This is because the vertices are disconnected on the face edges, and so the normals don't always point the same way, even if the faces appear adjacent. The above perl script fixes this by setting all the vertex normals to the same direction in every frame. The script is lazy to the point of hard-coding the model name but it does work. Turning it into a better designed generic perl script is on the cards... just used standard blue particles, yeah. they looked kind of cute i guess, but would be much better if replaced with proper animated droplet sprites (they'd start as a single blue drop, then separate into multiple smaller droplets and eventually single pixels, fading to white) and then thrown out of an emitter entity in a similar fashion
to be fair it doesn't sound like a taxing task and is something i've been meaning to take a stab at for a while (although i have zero experience in sprite editing) as for the falls themselves, i'll see how i get on with stepping and whatnot; it might entail a slight design change. but there is a chance i may drop you an email at some point preach :) Hi all.
If you would like to create something that will be seen (and appreciated) every week by a bunch of TF maniacs, I have two requests: 1. A new animation for player.mdl, where he has his arms outstretched, kind of like this: http://images.sodahead.com/polls/000589539/polls_preacher_5854_705966_poll_xlarge.gif I need 1 Standing, 1 walking, and 1 pain. 2. A new player http://www.youtube.com/watch?v=4f77r-vu9xE He needs: giant_stand, giant_walk, giant_swing_a_club, giant_pain, and giant_die. I'm not sure how this forum works, it seems to be one long thread(?), please contact me at adonis_paradise@yahoo.com if you can help thanks, OneManClan ps, quick ad: BIG TF games every Sunday at 22:00 GMT, check it out: www.attackersgored.com where is that baron.mdl model that is in nehahra from? i seem to recall it was a converted q3 model or something? is there any way to get the original version to be re-converted? the nehahra version has massive amounts of vertex dancing; more than there should be.
and thanks for pointing me towards theforgottenone as well!
i can also see exactly why there's so much vertex dancing in the neh version: there's a sequence where he shoots a laser out of his eye which they probably deleted after it was converted. interestingly, i can see that the main improvement of md2 over mdl is that the vertex 'resolution' is per frame, not per model hence why evilbastard could get away with the eye laser animation in q2. its seems that the infantry dude from q2 and modified to bastion by kinn is extremely underrated . hes so awesome. and fits the base theme very well
looks like evilbastard did some extra frames for the nehahra mod as the original ddz baron model lacks those. hmmm not as useful as i had hoped....
it's too bad we didn't know as much about mdl format and vertex resolution that we know now. simply deleting the 'eye laser' frames before converting to theforgottenone (at leats the non-winged version) has the same torso as the ddz model. Although the animations may be diffeerent, might be worth looking into that md2.
i'm currently looking into what options i have atm...
i considering just re-rigging the q2 model and doing my own animations, since i enjoy doing that. first, it would allow me to just add a sword (which the q2 model is lacking) and do some proper melee swings and such. i figure i can just use the nice uv mapped q2 model and then try out preach's method of going through the md3 format on the way to mdl and if i can't figure that out, at least i can go to md2->mdl instead. i'm a little wary of trying to do theforgottenone since the wingspan of that model is fairly large at times. might result is pretty bad vertex dancing and i'd still need to add a melee weapon and melee animations. when i saw the baron model, i kind of assumed that the sword was part of the original model and that he just held it in his offhand like that q3 model that looks like a crazy hellknight. yeah, it's awesome. seems like no matter which model i choose, i'm still going to have to end up re-rigging and then re-animating them.
Has one or two tee models, so does soul of evil iirc. I think quoth might even come with a tree model, you might want to check the pack.
Rather intrigued by Preach I tried the waterfall model. I opened it in qmle and saw it were all film files. As it is a one patch line I couldn't use it in normal Quake. It just disappears.
So I decided to make one that turned round frames like a coil, so it can be used to simulate waterfalls or taintracks. The screenrecorder went chunky so I made a gif to illustrate the principle. http://members.home.nl/gimli/wfall.gif http://members.home.nl/gimli/rotaframe.zip :D Glad to see it getting used MadFox, certainly the watery realm in your map looks like the perfect home. To bind that model in with the perl stuff above, here's a quick script I just cooked up which offers another way to solve your problem.
http://www.btinternet.com/~chapterhonour/double.pl It takes an input model and makes all the polygons in it double-sided, so you can see it from front and back. Here's the output when you run it on waterfall.mdl: http://www.btinternet.com/~chapterhonour/waterfall2.zip Just remains to say that I didn't write the script just to help with the waterfall, it should also come in handy with the next model in the pipeline. You heard that right - this isn't even model of the week! (what an ugly tease...) It's time for Model Of The Week, only a day late. Or if you prefer, bright and early at the start of this week!
http://www.btinternet.com/~chapterhonour/vine.zip Time to plant some vegetation in your map! This model will decorate bare surfaces in your map, making your medieval walls look vibrant or your base maps overgrow and abandoned. And at just a shade over 40 triangles per model, why not add two! The model comes with 7 poses for the vine, and the following 4 skins: Tropical Vine Poison Ivy Desiccated Autumnal Tips The model is designed to tightly hug a wall in your map, and so the polygons only face in one direction. To get the right placement, position the origin of the model 8 units away from the wall it will be rooted to. In the case of the 'limp' frames, the origin should be 64 units from the ground, and in the case of the 'creep' frame 32 units from the second wall that it wraps around. The script in the previous handful of posts in this thread would also be useful here, if you would rather create free-hanging vines which you need to see from both sides. Bonus points if you can adapt the script to make it instead clone the triangles in the model and make a single vine model with multiple creepers. You'll save entities! Fine piece of artwork there, Preach. Wish I had these when making my venividifuzi level.
Roman art would like that, as well as the vine texture. I wanted to add some turbulence to the waterfall, as it is a bit strange to see so much water falling in a peacefull water. Also made the length somewhat longer. http://members.home.nl/gimli/hfall.gif I had worried about the bottom of the water in the same way, but decided to go in a different direction for the next models and return to it later, so I've been beaten there! I hope you plan to share the model once it's finished. It probably could stand to have some particles along with it in a map to add noise to it, but it certainly creates turbulence.
At the base of the splash you have a wave washing over, which makes me wonder if you could make the entire splash section loop around in the way that the main waterfall does, and so create a series of waves. The problem I can anticipate is that it forces the waves out in just one direction, but it might still be worth exploring. Glad you like it.
Not a case of beaten, just an idea involving by cherrishing it up! I also was thinking for a sprite with buble but that changes in view. Fog also would do, but that's kind of hazzard trying shaders. http://members.home.nl/gimli/waterfahl.zip Two models, the starting one as in the gif file, and another one I tried to make the wave bigger and more floating off. Funny to see the waterbulb go under the normal wayer surface. I already tried to make the vertices change directions, but you can make a try by dobbling the vertical one and change it in front of it. lol The idea just came up to me if it would be possible to use skip on model.mdl files?
The way it is done with mapping is clear to me. models and BSPs are totally different. i don't think there's any way to reconcile the two systems.
but metl's right, deleting the triangles is the only way to make faces not appear. Quoth had (iirc) 3 seperate models for the polyp stealth activation where Kell went and deleted successively more and more tris. Yes, I was suspecting something like that.
I understand deleting the triangle creates an opening, but there's no way to make it look transparent, than by texturing a blooming surface. Gradual transparency.
I don't think there exists a method for that in Quake, although DP has some stuff that does it. I was gonna ask some advice on using sprites in quake but instead I'm just gonna moan. Fitzquake really spoils you with it's proper support for sprites. I had a model-sprite combination working beautifully in fitz, and then tested it in a few classic engines just to be sure. GLquake doesn't support "facing upright" sprites and just uses the facing code. Winquake is equally unsupportive in a different direction, shrinking the unusually large sprite down to about half the desired size.
I'm pretty much betting that there is nothing that can be done but if anyone knows a fix for one or the other it's gladly heard. Otherwise back to the drawing board... the sprite offset stuff doesn't work at all in DP, so make sure, if your sprites animate, that they are centered in the image.
So yeah, not really putting out a model every week. Which isn't to say I've not been making them at that kinda rate. But I've made a few that I don't think are worth releasing, or are ready for show just yet, and had that tree project which got eaten up by technical hitches. After that I started making a series of models in a theme, more about that later.
Today though I took inspiration from the explosion effects in TF2 and tried my hand at making a particle effect, which was good practice in using all the gmax animation controls I'd learnt about for the aborted models above. http://www.btinternet.com/~chapterhonour/embers.zip The file contains the model and a quick test mod plus full details on how it works, but give it a quick spin and let me know what you think. So back to the series of models I mentioned at the top. I was thinking if the best way to handle a pack like that would be to post individual models here as soon as they are working - beta quality if you like. Then I can tweak them based on any feedback offered and release the pack with all the refined versions at the end. Sound alright? I noticed them only with the GL, but as closer to the wall the appearance get better.
This way it's easier to add emitters like the extra-mod. Are you making a new pakfile with monsters like I did in The Hangar? Are you use you don't mean the Rocket Launcher, the mod uses stock effects on the grenade! I'm not working on any new monsters right now, mostly my new models are mapobjects (and now special effects) that other people might want to incorporate into maps. Expect a few more particle systems soon because they're quite fun to make!
meant to comment earlier but forgot.
the effect looks quite good. hexen2 has a few good examples of ways to make effects out of models too, if you are looking for inspiration. Got the idea from ne_ruins mod, and blocked some models. Im not really sure how to setup a camera to simulate 1st person view.
http://i.imgur.com/p091p.jpg http://i.imgur.com/qlPcq.jpg One is just random, and another one based on this concept http://gamersblock.net/gamefluid/wp-content/uploads/2011/05/shotgun2a_001.jpg those are pretty cool man... should try to get them skinned and such.
for positioning, just grab one of the regular gun models and export it as a dxf file. then, in your editing software, just import the dxf and match your gun to it and then get rid of it when you've got the right position. something like this
http://i.imgur.com/MgS2q.jpg but wizmet never fails
http://i.imgur.com/HSHTZ.jpg that tri-barrel looks great! i'm not a fan of the skin though. i'd rather see it match with the other guns (brown and blue metal).
nice mesh though! What my comment was trying to get at is:
If you want to use it together with the vanilla weapons, there will be a visible difference in polycount. Maybe that is more understandable. I made a fuel chunk, and I'm a little surprised about it's behaviour. In Qmle it appears alright, but I'm doing something wrong I think. Although its returning state looks well damaged, I ment something like its last frame would participate on the first one.
So what in Qmle looks like: http://members.home.nl/gimli/plug.gif shouldn't behave like: http://members.home.nl/gimli/plog.wmv Maybe I'm not keen with qc. $frame 1 2 3 4 5 6 7 8 9 10 11 12 13 14 void() plug_stand1 =[ $1, plug_stand2 ]{}; void() plug_stand2 =[ $2, plug_stand3 ]{}; void() plug_stand3 =[ $3, plug_stand4 ]{}; void() plug_stand4 =[ $4, plug_stand5 ]{}; void() plug_stand5 =[ $5, plug_stand6 ]{}; void() plug_stand6 =[ $6, plug_stand7 ]{}; void() plug_stand7 =[ $7, plug_stand8 ]{}; void() plug_stand8 =[ $8, plug_stand9 ]{}; void() plug_stand9 =[ $9, plug_stand10 ]{}; void() plug_stand10 =[ $10, plug_stand1 ]{}; //void() plug_stand11 =[ $11, plug_stand12 ]{}; //void() plug_stand12 =[ $12, plug_stand13 ]{}; //void() plug_stand13 =[ $13, plug_stand1 ]{}; void() info_plug = { precache_model ("progs/plug.mdl"); self.solid = SOLID_BBOX; self.movetype = MOVETYPE_NONE; setmodel (self, "progs/plug.mdl"); setsize (self, '16 16 16', '24 24 24'); self.think = plug_stand1; self.nextthink = time + 0.1; }; first, i noticed you aliased the frames to numbers.
the point of aliasing is to assign a name to a frame number, so in this case, you don't need to do anything at all: void() plug_stand1 =[ $1, plug_stand2 ]{}; becomes: void() plug_stand1 =[ 1, plug_stand2 ]{}; but on to your actual question, this is the frame interpolation happening. to fix this, you will need to create an animation where the gears complete a full rotation in order to get around the problem. also, if you're just going to animate frames in a loop this way, you may find it easier to do this:
void() info_plug_think = { self.frame = self.frame + 1; if (self.frame > 9) self.frame = 0; self.nextthink = time + 0.1; }; void() info_plug = { precache_model ("progs/plug.mdl"); self.solid = SOLID_BBOX; self.movetype = MOVETYPE_NONE; setmodel (self, "progs/plug.mdl"); setsize (self, '16 16 16', '24 24 24'); self.think = info_plug_think; self.nextthink = time + 0.1; }; does the same thing without needing the big frame macros. if it's just going to loop forever with no state change or reaction to game events, then just make it a static entity and use a framegroup to cycle the frames.
I aliased the frames to numbers, because I have also a waterfall static entity.
Earlier I encountered problems when I had two of them with only framenumbers. The shorter script gave an error in proqcc. *** r0ta.qc:10:info_plug redeclared @metlslime- you said earlier on Inside 3D. Still I'm such a noob I would type staticentity in the console and ask myself how. Qmle or FimG don't support framegroups. Maybe I should take the oppertunity to leave it this way. Frame interpolation, learned something new. The shorter script gave an error in proqcc.
*** r0ta.qc:10:info_plug redeclared This error message means that the function info_plug has more than one definition. Look through your code and remove the original one, leaving just the one necros wrote. Also if you right click on an animation in Qme there's the option to "group frames for scene". This turns the animation into a framegroup. OK, so I downloaded QMe but I can't install it on Windows 7. The installer tells me it's not compatible with this version of windows and my dog is ugly and some other things.
I tried setting compatibility mode to Windows 95 but it sees through that ruse. How do you install QMe on a modern computer? To know that as well...
I've heard that you can install it on an older machine, then just copy across the files. that must be it, because i have qme working on win7 here.
here's qme pre-installed: http://necros.slipgateconstruct.com/temp/qME.7z This is the recipe for what you want:
void() info_plug = { precache_model ("progs/plug.mdl"); setmodel (self, "progs/plug.mdl"); makestatic (self); }; This will implicitly set it to frame "0", which, if you use a framegroup, will actually loop through all frames in the group on the client. The only downside to this is that the object is not solid, but you can put a clip brush there if you want. To make a framegroup in QME, right-click on the "scene" in the frame list, and choose "group frames for scene", The camcoreder icon will change and now be a camcorder with a tiny clock on it. This will now look like a single "frame" for quakec, and if it's the first thing in the file will be frame number 0. I had three scripts for models, but I'm surprised there are so many different ways to do it.
The second script indeed was my typo, as Preach suggested. But the last one from metslime really does the job. Thanks! I think my perception still tends to cinamatics than the maths of quakeframes. I made an new animation with the weels turning round, but I remain with the outcome of a returning, blocking wheel. Ah, my praxinosopic tention. even with the full revolution of the gear, it still jumps?
hm.. well, you can see about adding it to fitzquake's nolerp list (which i think all FQ variants have) but apart from that, not sure what else to do. :\ I already gave up, when I tried in Quark4.7 for a quick try in Quake, and then it runs on.
Have a look for yourself, I think I strayed. http://members.home.nl/gimli/plug.zip well, you didn't actually do what i said. you need to make the gears do a full rotation, that should fix the jumping problem.
A few moments later I realized I posted the wrong plug. Sorry for that, I corrected it, so the same link has now the round turning one.
As I see it in game, it looks as if it takes the first 9 frames, and then just jumps to 0, insyead if 10. that's the same thing as before..?
when i say 'full rotation', i mean 360 degrees around. you need to animate the gear so that it rotates 360 degrees. right now, you have it rotating only a few degrees. for future reference, you would want to do this even if you were not getting any problems with interpolating because you would see a very obvious jump on the skin of the gear as it reset to the first frame.
right now, it is not very apparent because it is still using the wireframe skin. Did it double wrong, indeed.
I kept trying untill I saw it was just the animation, not the qc. Now the link is right. I thought to be snappy and delete all even files which became a mesh. It rolls fine now, thanks for the hints! Now I expect the problem is just that you haven't updated your QC code to use frames 0-23, and so you're still resetting the animation when it gets to 10. Make that change in necros code and you'll be set.
Otherwise you could right click the animation in QMe and select "Group Frames for Scene", then use metlslime's code. Finally you might want to look for backwards faces on your model. The wheel rims, gas cylinder and some of the bolts are all inside out and need you to flip their triangles around. (Needless to say this is a really cool model which is I imagine while we're all so keen to pitch in about it!) I've got it rolling now.
Always with code, tempts to get so messy. How do I see those backwards facing. After importing I have to patch all vertices, otherwise they are empty space in game. Same goes for texture. A good thing is I can give a static entity angles, which before needed turning round the model. You can try to spot backfacing triangles by just rotating the model around lots and seeing which parts move strangely. But the easiest way to do it is select this option from the toolbar in QMe:
http://www.btinternet.com/~chapterhonour/backface.png When you turn on the "Triangle back sides shown" option, the model looks like this http://www.btinternet.com/~chapterhonour/backs2.png So it's easy to see which are backwards. Please think about using a modelling program that doesn't break your model so much when you export it! The learning cost of using something like gmax will easily be repaid by the amount of time saved on this type of glitch. Thanks Preach.
I have Gmax installed, but haven't use it much, as much further than converting I don't come. Models I design in AM2005, and from there I can export to *.3DS, *.PLY and *.AV2. So I usually take 3DS, and I don't know where the vertices count go when I import and export a Quake model. Let's say I take the quake player. Converting it to 3DS QMLE tells me it has 212 verts and 408 tris. If I import this 3DS in AM2005 and export it back, it has 203 verts and 704 tris. Rather chunky, and I have no idea what the cause is. I did the same with MAx3D but then the count stays the same. For some reason all vertices are almost twice as high, although I don't see more triangles. The version of QMLE I use is the lightversion 3. So I was looking for the radiobutton that wasn't there. Did you buy the commercial version? Or is the same one to be downloaded somewhere? http://members.home.nl/gimli/qmle.jpg Rather chunky, and I have no idea what the cause is.
I'm gonna say it until I sound like a broken record, it's AM2005 that's to blame for this and the backwards triangles, and the only fix is to stop using it. Right, but for what its worth, I won't compare programs.
Max3d I have on a ceracked version and it maybe more relayable than AM2005. On the other hand I bought last one and I am more familiar with. For other purposes it has a splendid outcome. Watch me in the early 99 internet searching for a program that uses Quake *.mdl files I bought the program. Then the extentions were not suitable, but behalve of that miscount I made fine things with it. All I did for Quake comes from it so stopping using it will stop my Quake model contribute. What is that Qmle version you use? Ok, i'm looking for Kenneth Scott's old quakeworld skins.
I found a page here: http://web.archive.org/web/20020213221847/http://www.planetquake.com/skinforge/sf_skinz.htm that has some of the skin images still loading but most are gone. Does anyone have the full collection? does quake render first-person weaponmodels at a slightly smaller scale than a normal model?
Looking at the nailgun model; in-game you can see the nails appearing outside the barrels of the weapon, as if they are being spawned too far to the left (or right) - this side offset is 4 units in the QuakeC - but when you check the nailgun model in QME - 4 units looks spot-on for the nails to be emitted from the correct place... anyone know what's going on? sounds like framerate. Quake only thinks every 0.1 seconds. Would say more but my phone's buttons are tiny.
sounds like framerate. Quake only thinks every 0.1 seconds. Would say more but my phone's buttons are tiny.
i can't see how it can be those things. Here is a nice picture illustrating exactly what i'm on about:
http://i.imgur.com/2DWjt.jpg It is a mystery. pretend in that picture of the model in QME that there is a helpful grid or something, but trust me it's 4 units to the side to the barrel centres, from the middle.
i don't think the scale of the weaponmodel and the world is the same at all.
turn on noclip and move into a wall. you have to be nearly inside the wall before your weapon starts clipping, but if you look at the model, it's quite large and should have started clipping almost immediately. the best you can hope for is to eyeball it. i did another test - i imported the spike mesh into the nailgun model in QME and put them side by side to compare their relative sizes in QME with their relative sizes ingame.
And yes, that seemed to prove that the weaponmodels ingame are scaled down compared to normal models. Can anyone who knows their way around the engine find out what the scaling factor is? That would be super helpful :) i think the weapons are the correct scale in the world, but they are drawn on top of everything else and don't clip into anything -- this means that, for example, you can get really close to a wall and the gun looks tiny because it sorts on top of the wall (even though physically it should be clipping through it.)
With the nails, i think the nails are actually closer than the gun, but they sort behind it so it looks like they are big and too far apart. If they were spawned lower and farther forward, they might look correct at the current lateral spread. dunno about that - like necros said, the gun will clip if you noclip into the world.
also, i changed the nail spawn points to be further forward and all that, but the side problem was still clear and present. I think it's possible that the misalignment is on the z axis, that the weapon model is actually several units lower than the nails are being spawned. What metl says about the weapon always being last in the draw order is what makes the image deceptive, it makes the model clip in front of the nails when the order ought to be reversed.
A good test of this theory would be to move the nailgun up by 22 units (the view offset) or launch the nails from 22 units below their current position and see if the alignment improves. yes metl and preach are right - the nails are actually too high above the gun, and the sort order totally threw me off.
Also I am a retard for not reading metl's post correctly. Although this is entirely unfair to Kinn:
http://www.youtube.com/watch?v=8vbd3E6tK2U I seem to be going round in circles and I not sure what which package I should be using. I want to make a small test Q1 monster with a couple of test animation frames and I am not sure which model package / conversion tools I should be using.
I download the Qme3_1 and it seems broken in so many ways. It is handy for extracting stuff and seeing how the mdl fit together but not much use for a good workflow on creating a model. I download gmax and preach's md3tomdl convertor and it seems like a good solution I can work with, but I have a ton of questions about what things go where. So bare with me while I ask lots of stupid questions! I can't import a md3 model into gmax? I want to look at the structure of the md3 in gmax (what stuff goes where) and the importer does not appear in the import menu? I have downloaded the file (q3-md3.ms) but I am not sure where it is suppose to go in the gmax file structure. I tried plugins but nothing changes on the import menu. The md3 format supports head/torso/feet layout (aka q3) but I assume q1 is a single format (all model) is this correct? Should I be building my models as one mesh? In Gmax I create the model/uv unwrap/etc then how do I setup the animations? Do I create bones and tweak each frame? How do I store the different frames? Do you work from a T pose model first and then tweak everything? (If I had an example in gmax I could see how it works, but I can't load preach's example ogre) Any help or pointers on what I should do would be awesome. Thanks The MD3 import is a pain to figure out, it's written in maxscript.
Put q3-md3.ms in D:\gmax\Scripts\Startup Then if you click the hammer icon in the right hand panel (tab 6), then press the MAXScript button. MD3 import should then appear in the Utilities dropdown. md3tomdl will combine multiple Q3 meshes into a single MDL file, but not very intelligently. The skin vertices of each mesh will be laid on top of each other in order to reduce down to a single skin. Similarly the animations are constructed by taking frame 1 from each mesh and combining those poses to make frame 1 of the mdl, all the frame 2s into frame 2, etc. I don't think I respected tags at all when combining either.* If you're building your own model it makes sense to keep everything in one mesh because that's what the end product will be. The standard way to animate in gmax is using the Skin modifier. You construct a set of bones for your mesh, then apply the skin modifier to the mesh. In the panel for the skin modifier you can add bones as controllers, assign vertices to them either by setting envelopes for the bones or by painting weights - google for "gmax skin modifier" and I'm sure a suitable tutorial will be there. I've packaged up the latest version of the ogre, along with all the other bits of the pipeline (the skin, the batch file, the script for md3tomdl, the md3 output). It's at http://www.btinternet.com/~chapterhonour/ogrepipe.zip If you can't get that to load, let me know what kind of error you get and I can try to diagnose it. I expect the skin won't work straight off because gmax stores an absolute path for it... *The problem is that you can't make the conversion more intelligent automatically. The number of decisions you need to send to the conversion tool is so great I'd spend most of the time writing a parser in C++ to read the config file. It seems smarter to write the tool in a scripting language, but I'm aborting my attempt with perl because even I find it awkward to work with and I wrote the damn thing. Python or Lua next... @Kinn, I don't have maya I only have LW9 which is too new for all the MD3 plugins to work. It does seem to connect well with Qme (3.1 version) but I prefer to try the max route for the moment.
@Preach, thanks :) That does make perfect sense now, I was wondering how you fit the ogre together. I will experiment with a single frame for the moment and see if I can the process working before attempting any proper monster model. Also is there a hotkey in gmax to bring up the UV edit screen? I can't find an easy way to get to the UV screen. I'm sure there's a shortcut for it, or a way to create one, there's a dialog box that lets you change all the shortcuts to your liking. Personally I just click the button on the modifier, it's not so bad.
I can't believe how anyone has the patience to create models for Q1. I created a model and UV mapped in LW 9 (I like the interface and tools) and cannot get it into Q1.
Qme (3.0 & 3.1) LWO import only takes mesh, totally ignores all UV data. DXF import, mesh only but format does not support UV. 3DS import, mesh only. I can't get the UV data to be accepted. It could be the shitty exporter in LW but I did get the 3DS file imported back into LW (not really a good proof format is right) I tried importing the 3ds file into gmax and mesh only. So I am totally stumped how anyone can get any UV stuff into Qme. The package and pipeline seem broken to me. Any hints on how other people create models with Qme? Is this why preach wrote the md3 route ignoring qme? ah ok, so this was the process you were talking about in your mail. :)
first, qme cannot accept standard uvw data. what you would need to do is to split the mesh up the same way it is split up in your uvw. if you could export a dxf with uvw and import it into gmax, then use a gmax md3 exporter to export an md3 which you can then use preach's converter on, you could create a mdl file with the single frame BUT with your uvw mapping preserved. after this, you could export the rest of the frames as lwos and IMPORT (not open) them into your existing model. sorry, first, i forgot dxf doesn't support uvw.
so you'd use 3ds format. the above long process is only needed for the initial frame to set up the skin mapping. once that's done, the rest will go in fairly easily. just write a script (lightwave can do this? i'm not sure, but i am assuming so since it's a high end 3d editing suite) to export all your frames as seperate lwo files. the only danger is that during all the importing and exporting, the vertex order could get rearranged which will prevent you from importing the rest of the frames. I did it! I got my model from LW to Q1! Now I can plan getting all the bones and animation sorted.
LW 3DS exporter Gmax Special 3DS importer (should be default) Save in MD3 format (special plugin again) Use preach md3tomdl (can't get Photoshop to save in the right PCX skin format for preach tool, have to replace in Qme) Open in QMe and it looks good :P FINALLY!!! :D:D Got several options for animations, DXF import into Qme or setup bones in Gmax not sure which at this point, will have to experiment. At least I can create all the meshes and UV stuff in LW. I don't have lightwave so I can't test it but this claims to be a md3 export plugin for lightwave. This would let you skip the gmax stages of that process.
http://members.bellatlantic.net/~mbristol/md3/index.html PS: if you export the skin from QMe you should be able to get it into the required 8 bit format for md3tomdl. PPS: if you can cut QMe out of the process you get to keep nice vertex normals for your model! PPS: if you can cut QMe out of the process you get to keep nice vertex normals for your model!
This is what was the final nail in the coffin for QME for me. Cool idea on the skin PCX format, I don't need to touch the package anymore. :)
The downside of the 3DS format is that the UV verts have to be un-welded before export. Is there an easy way in gmax to weld all UV verts together? I think the best you can do is apply the unwrap uvw modifier, select all the vertices manually and click the weld selected button. It's probably automatable with the maxscript stuff but it's not that much work by hand. Don't forget that the vertices do often get separated in the final mdl file as well, so do check if welding is helping the final output.
For some reason I have 1200 skin/frame verts in my model for something that started with @160 (used the standard ogre model as a test) Not sure why, maybe it is the export 3DS process not sure.
The LW->MD3 exporter plugin is too old, won't load in the current version. (typical for LW TBH) I did find a LW to MD3 external program converter but the documentation is gone (website link dead) Might experiment with it. The 3DS route seems to be causing problems. when you are exporting, make sure you only export the mesh, and not any bones, helpers or anything else.
bones (at least in max) count as mesh objects when exported in some formats. That is too many vertices, 1000 is the number you need to get models down to in order for them to load in glquake...
To check if you can fix it you may want to try a weld on the mesh vertices as well as the skin vertices in gmax. Obviously though if you can pin down what's splitting the vertices and avoid it that's best in the long run. actually yeah, thinking about it... that's sounds way too high for just bones/helpers. not sure what else it could be aside from what preach just said.
http://wiki.beyondunreal.com/Legacy:Lightwave/Exporting_3DS
"The reason is a limitation of the 3ds format not supporting discontinuous uv coordinants" Just got to weld all the stuff together in GMAX and now I have a model with 402 verts and 410 triangles :D My very first ogre, just got to test it in game, sort out animations, write ogre script and fix the skin and Don't forget about http://www.icculus.org/qshed/qwalk/
@necros, I was planning to animate the model with bones in gmax or maybe LW. This is something I have not done before and I am curious to see the process. I have not decided yet which route to take, I need to test which is easier. I tried a couple of frame imports with Qme and the mesh was all warped. I really want to avoid using Qme at all because of the vertex problems.
the nice thing about doing a model for quake is that when you animate it, you can use absolutely ANYTHING you want.
from basic IK to crazy scripted constraints/controllers. you can use any modifiers that don't change vertex# or order (ie: you couldn't use boolean operations). but you can use morphs (scripted morphs!), lookats, you can follow a specific vertex, etc... or you can just use biped and get everything you need for normal animation and add onto that. that after you import it into Q1 all the animation will be at 10fps and the vertices will be wobbling all over the place due to them being rounded to fixed point numbers, so even if you have plenty of flexibility, it doesn't exactly allow you to go to town :)
sure, but my point wasn't that you'd be making better looking animations than a AAA title, only that animating it is not a painful process at all (and, i find, quite fun).
There's no reason you have to keep animations at 10fps.
Well, there are a few things you have to consider. First is that 256 frames gives you 25 seconds of animation at 10fps. Can you get an entire monster into 12 seconds of animation? Perhaps the thing to do would be to keep slow movements like standing animations at low fps and keep the higher rates for the big/fast things. Secondly there's the QC support. There's a special instruction built into the QC instruction set for 10fps animation, with special notation and all. So to step outside that confers a minor performance penalty (though clearly it was significant in 1996) along with more verbose, messy code. Finally I'd worry about how interpolation is handled in all the engines out there. I know that fitzquake takes a lot of care to interpolate well in a variety of situations and ought to handle high fps, but I don't know that all engines do. Still, I'd like to see someone try! you must also halve
probably not a huge issue if you don't mind splitting your anims over multiple models if you need more frames, and swapping the models when appropriate.
On a related note it usually makes sense to spread anims over different models if the creature varies size substantially - i've seen models where the vertex accuracy is totally trashed because of just a few frames where the dimensions of the model is large compared to the rest of the frames - moving these "large frames" into a seperate yeah, that really pissed me off. :P
but tbh, i never considered splitting different bounds of a mdl into seperate files. that's a pretty good idea. @Preach, I am trying to understand what you did with your ogre model in Gmax. (workflow) The chainsaw and grenade launcher objects both have blue boxes. They look like some attachment tag, what are they? How did you create them? I assume this lines up with a bone in the hand?
The bone structure for your ogre has a tail bone, what was that for? When you were creating the bone structure, did you start with the spine? Did you mirror the left and right bones? The ogre is one complete mesh, is that done for a reason? animation etc Do you know of any good gmax bone/animation tutorials you used? Thanks for all your help So far I have only found this:
http://world-editor-tutorials.thehelper.net/magos.php Most forums seem to point at this. The bone arrangement in this article is a bit goofy plus the spine is not connected. The article does talk about helpers (your blue box attachment) I assuming this is the same system? i don't really know how much experience you have in this area, but this tutorial: http://www.3dtotal.com/ffa/tutorials/max/joanofarc/joanmenu.asp covers everything from start to finish. you'll want to check out the last section for rigging.
it was written for 3ds max, but a much older version, so likely there is very little (if any) information that can't be brought over to gmax. also, for more general information, 3dtotal is one of the best sites i know, with a higher concentration of max users than other places. Seems like you've got a handle on how it all works, but I thought I'd add that the blue boxes are a type of helper called a "dummy". They're just like a simpler version of a bone, which is all you really need for something like a gun. You make them animate with the model by applying a "follow constrain" from the dummy to the hand bone.
And loath as you may be to change the pipeline you got to Sock, give this a look:
http://oasis.xentax.com/index.php?content=downloads I post this about once every two weeks or so. Its a multi-multi platform / game model converter, very well maintained (found a problem in BMP format and it took a day or so to fix) and now supports IQM (boned models in Quake with proper UVs). I use 3dsMax but I know a couple of people go direct from Blender - Noesis - Quake without additional steps. So what they see in Blender is what they see in the engine. And, Blender is free and up to date as well, though it'll need learning. There are lots of youtube tuts etc.
And, Necros, I remember that tutorial from uni :) @Preach, thanks I was not sure if you used a dummy or point helper, it is hard to tell the difference. Gmax is not really helpful on showing what things are what.
One thing I would like to request of your md3 to md1 converter is the ability to specify a list of animation names. At the moment they are just a long list of (from 3dsmax). Can a list (comma delimited strings) be specified in the text file you use for the compiler? - Unfortunately I still need to use Qme to setup the animation names so they can work with the QC file. @necros, that is a very cool link, thank you. The English in that tutorial is strange, but I guess that is because it was translated. @ijed, I am close to finishing my model and the pipeline I have at the moment works! All the plugin and converters produce a result which works in Q1. If gmax bone animation drives me nuts, I will check out this other pipeline. Thanks for the link. you actually do not have to do that.
in your QC, when you alias the frames with $frame nameofframe1 nameofframe2 etc... they do not have to match at all. only the order matters. so if you have 'frame1' 'frame2' 'frame3' in your model, if frame1 and 2 are walk anims and frame3 is a run then you need to alias in order: $frame walk1 walk2 run1 all the qc compiler does it look at the order the aliases appear in and assign a number to them, so $walk1 = 0, $walk2 = 1. you can just reference the frame numbers directly in the function macros (and you can use the aliases in if checks and such (if (self.frame > $walk2)) also, check out my qc starter vb program. it will set up all your frame aliases along with the function macros after you enter the number of frames and such: http://necros.slipgateconstruct.com/utilities/ne_qcstarter/ Using max feels like I am editing a map and the editor is not drawing the links between entities!
Is there a way to show the object links in the viewports? I know you can see the tree structure with the selection (H) window, just wondered if there was something else more visual? not that i know of, sorry.
you can always set helpers/bones different colours to tell significant groups apart (like left/right side limbs so you can tell easily when viewing from the side). i suppose you could looking into connecting splines to objects with follow constraints to make your own visual representation of links, but that would mean doing it yourself. sorry, that's the best i've got. :S I thought it was me not being able to find the visual switch for displaying links between objects. It really makes understanding bone structures difficult, I am surprised there is no visuals.
It is a bit annoying, it is supposed to be an option which you can enable on a per object basis (so you could choose to just display the links for the chainsaw but not the bones). The option you're meant to tick is in the display panel, which is the 5th panel along on the right hand side. Down at the bottom is a "Link Display" rollout with a tickbox called "Display Links".
It doesn't seem to work though, so unless you can fiddle with it and get something, I think it's a feature of 3ds max that is broken in gmax and nobody ever tested... I was trying to enable the option on my ogre and that didn't work, but creating a simple test scene I was able to create two boxes, enable the option, then link them and see the link. So give that a try.
Thanks, I found the option and it certainly works on some bones and meshes.
I am at the final hurdle exporting all my frames and mesh into MD3 format and the Gmax exporter wants to UV map all the bones and place them in all the frames. Does not make any sense as usual. I also tried preach's ogre model and gmax exported all those bones as well. Any suggestions why the exporter wants to UV map bones? loath as you may be to change the pipeline you got to Sock, I know a couple of people go direct from Blender - Noesis - Quake without additional steps.
If I was to try and create a model in blender, animate it and then convert with Noesis to Q1 format, what versions and plugins do you recommend for blender? To get exports to work you have to use the Only Objects Whose Names Starts With option to filter out the bones from the mesh. Bit of a pain, but as long as the mesh starts with a letter other than 'b' it's only one keystroke. I am going to get round to replying to your e-mail as well...
Noesis supports lots of stuff, so any 3d package can output files to it, which then get passed to any game format you like, including
Personally I'm still using Max, and exporting to Collada. I can't remember which version off the top of my head (at the office just now) but in the past I've used various other formats such as FBX. Should really document the process and put it up on the site when I get time - your comments here got me thinking along those lines the other day. sock: try out blender first to make sure you don't mind it.
if you are familiar with mainstream editing packages, it could be painful. I keep saying Finally too much, but I think I have my first rough (extremely crap) ogre model animated. Probably the most painful thing I have done in my games life and I after playing red777 yesterday I can't believe the monsters in quoth and how much effort it must of taken to animate them.
http://www.simonoc.com/images/design/sp/ogre2.gif My ogre is suppose to be a similar (style wise) to the Hell Knight. These ogres make the armour for the Hell Knights and they like it so much they have adapted parts to their own needs. Process: 1. Create model in LW and skin in PS 2. Skin/UV in LW 3. Break model down into mesh/uv triangles 4. Export 3DS format 5. Import to Gmax 6. Weld all mesh/uv triangles 7. Setup bones and weights (borrowed heavily from preach model) 8. Export to MD3 (with object name filter) 9. Compiled it with utility from Preach. 10. Fixed skin with Qme @Preach, thank you for all the help, I am sure I asked too many stupid questions. No worries on email, I assumed you were busy. @ijed, that utility you linked is amazing! I just did a quick test from LW scene manager, exported with FBX format and straight to MDL format! one step for animations, mesh and UVs! My next trip into Q1 modelling is to try a pure LW pipeline with Noesis. I am sure something is bound to go wrong but at least I will get the chance to learn another modelling package animation system. @necros, at this point I only know bits of different packages and every application is new to me. I have never done animation stuff before, always done static mesh. The whole process is just one big painful learning curve, but it will get better. I sort of understand animation/bone systems (Max version) now I am going to torture myself by learning LW animation system next!
About Quake animation is that it's practically pose to pose, you don't have to worry as much about timing.
I'm pretty useless at animation, but a lot of cell animation tutorials have helped - like this one http://www.idleworm.com/how/anm/02w/walk1.shtml Nothing special, although I wouldn't want to do it outside my comfort zone of 3dsMax :) thanks for posting that ijed. i was going to mentioned traditional animation because it's very relevant (probably even more with quake due to 10fps).
it can even help to do the movements yourself in a mirror to get an idea of where you want your keyframes to be (close your blinds so you neighbours don't think you're insane). it's about expressiveness. speaking about quoth, the drole was the first monster i animated, and i find his movements are not expressive enough. it's hard to tell what he is doing between running and swinging for melee attacks. also, regarding death animations, make sure that when they die, they keel over immediatly. again, the drole's death animation is cool, but slow and when watching demos, i almost always see players continue to shoot at droles that are playing their death animations. it's important to communicate that the monster is dead as quickly as possible. be expressive, but don't go overboard. if you can communicate what you want in 4 frames, don't take 12 to do it. The thing I like about Quake animation is that it does not need to be perfect AAA quality and can have some goofy poses and body movements. The monsters also don't have to follow exact anatomy guidelines and have some funny shapes like crazy fat arms.
The hardest thing about modelling Q1 monsters for me is knowing how to setup the skeleton. Example layouts of bone structures was something I struggled with for a long while and had to do a bit of research with gmax tutorial examples. I also can't believe after all this time how little information or tutorials exists on the whole pipeline for creating a monster in quake. I know writing articles is time consuming and painful but there is so much cool information people here know and it is not easy to access. Is kind of cartoony at its core. The art is excellent for its time, and many studios now don't have that kind of focus when doing assets.
For example I showed the fiend to someone in the office and they were very impressed at how precise every single vertex was - no waste in the movements, even though looking at it in a 3d package makes it look like a deforming box kite, or even more apt, a papercraft: http://www.youtube.com/watch?v=mi3fy3IVA-M And good advice about the death - I'd add that make sure the monster has a unique death scream sound, that is fired in its first frame of death animation and not easily confused with its other sounds. Going nonsolid in the same frame is desirable as well. As to dev documentation, its almost a lost art because of the age of a lot of the processes. I will get round to writing something sooner or later - every now and again I have to bang out a few pages on something just to keep the goals and backstory in mind, might as well be some how-to's for the next one. At least tools like Noesis open things up a bit and give various routes to getting things right, as opposed to a single one that only works after hours of trial and error. A link to the rest of the guy's paper models:
http://cow.mooh.org/paper/ All taken from the original meshes of the monsters. I think this is called nerdcore :) or anyone else (stupid enough) modelling q1 monsters in gmax!
Problem 1 - Stationary objects having strange movement between frames Solution - Double frames Frame / Description -2 T Pose -1 Duplicate of Frame -2 (This extra frame makes sure no 'loose' object movement 0 Standing Pose 1 Duplicate of Frame 0 All frames are affected by previous frames and the double static frame prevents previous movement from affecting new frames. This may well be fixed in modern day versions of max, but gmax is v4 (very old) Problem 2 - Objects do random 360 rotations between frames example - http://www.simonoc.com/images/design/sp/ogre1_stupid1.gif Solution - Use local rotation ONLY This one had me going round in circles for ages, the default in gmax is view rotation which screws *most* animations. I thought I had some bones rotated/setup wrong and re-created them several times in different ways and it made no difference. It was just the default rotation mode is fuckin useless. (wasted days of time on this stupid default) Once I used local rotation mode, the animations worked perfectly. There's a common problem in regular max when flipping bones, usually to make the right/left side arms/legs.
The flipped versions get a negative scale which breaks most exporters. This can be fixed by using animation/bone tools/mirror mode from the panel. No idea if Gmax has this panel :) I still get the rotation bug almost every time I rotate a bone with gmax. I have rebuilt all the bones every way I can think of, not used mirror and still get constant rotation lock problem. There must be a way to prevent this, otherwise I will never finish animating anything.
After two weeks I finally have an idle animation, I feel like I want to jump up and down with glee, but I know it is just an idle animation, probably the easiest thing to make! (it should be) http://www.simonoc.com/images/design/sp/ogre3.gif http://www.simonoc.com/images/design/sp/ogre3b.gif (Alternative) There are ways to avoid using the double frame trick, by setting the tangent type to linear or step. This link is a brief outline, better resources are probably out there:
http://billysalisbury.com/Learn_Max/chapters/lecture6d.htm The way I try and avoid the random 360 degree rotations is where possible to never rotate the bones! Instead if you move the bone below the target bone in the heirarchy then the IK seems to always perform the shortest rotation. The track viewer is also sometimes useful to diagnose weird problems, although it's quite overwhelming at first. @Preach, thanks for the link, that is very cool explanation of the transitions. I will save that off to my MD. I looked at your ogre and I could not see any IK bone setup? How did you move all the bones while avoiding rotation? It is hard to tell at this point if it is my setup of the bones that is the problem or gmax! :P
There's no IK or angle constraints because I'm lazy about that kind of thing. However, the bones are connected parent-to-child in the default way, which creates a constraint. When you move a child bone, the parent bone rotates to match it it, but the generated motion is more friendly to rotation interpolation (I assume that it's calculating the relative motion in the keys automatically).
The main difference between this and IK is that it only extends to the immmediate parent, and so the child is locked to the radius of the parent bone. If it was IK then you could move the hand away from the torso and both the forearm and upper-arm bones would straighten to allow the motion. Without IK only the forearm would move, so to get the hand further away you'd have to move the forearm first, then the hand. As a last tip, sometimes you do need to rotate things directly. In those cases I've found that what usually provokes the wild backwards rotations is inserting a rotation between two existing rotations. Wish I knew how to fix it, but better to know what to avoid than nothing at all... @Preach, I can't believe you animated your ogre model without any IK solvers or constraints! The rotation issues on bones are extreme without any rotation helpers and not using rotation is not really an option.
I think I found a workable solution for Gmax (3dMax people get biped auto-magic bone setup, so this post is pointless to them). I setup legs, arms, neck, back and chainsaw with IK solvers, added constraints to top arms/legs and tweaked various inherit rotation blockers to shoulders, pelvis and hand/weapons. In order to maintain rotation on hands and feet I added a dummy_helper into the chain and linked the IK solver to the helper instead of the end bone. The helper is linked to the end bone and the IK solver still thinks it is a valid connection. To make sure the solver bends the bones in the correct direction I added a slight bone twist to the middle joint. As far as I can tell most rotation issues come from bone inheritance, with child bones doing full 360 rotation to re-sync with parent bones. Probably the sadest thing about this whole gmax route is that I found out yesterday that I can download the latest version of 3dmax (ex pro/student license deal) and use the auto-magic biped bone system instead. I am assuming I can use Noesis to export to q1 model format? The silver lining to this whole Q1 model process, I sort of know my way around 3dmax now! :) You're usually better off rigging yourself than using Biped, and it's fun to learn! ;)
You should look into the swivel angle stuff if you have any problems with your knees rotating weirdly. Also, not quite sure if it's what you described, but if you want your feet bone to stay in the proper bone hierarchy, and not have it rotate when you lift the IK controller, you can create a second IK from the ankle to the end of the foot, and parent it to your foot controller (the dummy), so when you lift the dummy your foot will stay aligned to the floor. This should give you the same result as what you described (if I understood it right), but it's cleaner cause you're not mixing your bone hierarchy and your controller hierarchy (which is good, cause ideally you're only placing animation keys on the controllers, so you can always change your skeleton, and as long as the controllers are the same your animations will always be good). bal, i think i know what you're saying about biped vs your own rig.
i learnt originally from building my own rigs too, but i remember the first time i used biped and how much it takes care of on it's own. i guess the real barrier to using biped is just the massive amount of stuff you get, some of it not at all useful for quake animation. otoh, using an up to date max means there will be lots of relevant tutorials. @Bal, I did that for the back and neck, two IK solvers in a row. I did not realize it could be done and create my wacky foot setup first. Then when I realized you got to use controllers on bones otherwise you get crazy rotation time, I experimented more and saw you could chain the solvers together. It is very cool what you can do, I just wish there was a way to play with the joint between the two bones, like it had a handle you could drag around as well.
I imagine the biped magic button in 3dmax 10+ has its own problems with setup, but at least it is a good starting point. I just wish I found more help earlier on when I was creating the bone setup for gmax. From all the internet searching I did, not many people talk about it. When you create a walk or run animation do you create it in layers? like move feet first, then torso and finally arms? Or try to move all of it at once frame by frame?
are you talking about animation layers, which is making animations in layers like in photoshop (allowing very similar things to what you can do with layers in photoshop) and combining them after?
or just which parts to animate first? for the former, i don't know :P for the latter, i like to start with feet/legs first. once i have the rhythm i'm happy with, i start in on the hips and the continue working up. at the same time, i don't do feet/legs 100% then hips 100% etc... i like to iteratively tweak it because it's hard to judge what's a good movement if you can't see the whole thing at once. I mean passes, like which bits to work on first and what to do next. Working on the model from the feet up makes sense, just was not sure if I was doing it right or not.
I am assuming it is feet, hips, torso, shoulders, head and finally swinging arms? (layers of stuff to do during a walk animation) yeah, i usually do arms last because they're basically secondary movement (movement as a result of).
hips and spine i do all at once, i found the upper spine depends on the hips (how much they sway vs how much upper body is compensating for the sway). step by step...
basically i start out and do my leg movements. this is very rough, little more than the foot going up, then down and pushing backwards. then, (with IK), i get a little bobbing motion going with the entire body. at this point, the bobbing up and down is pretty silly and exaggerated. now i'll try to position the spine in a static pose (for now) in how i generally want the upper body positioned. so if it's a full tilt running, then i bend the spine way forward, otherwise, i mostly just get it into a decent walking position. (maybe hunched over if it's an evil ogre) at this point, i start to smooth out the feet so that they look as good as i can make it. with IK, hips won't affect it, and i can always tweak later if i have to anyway. next up will be to get to side to side motion of the COG/center of gravity done and to make the up and down motion more realistic as well. the side to side motion is important. without it, the animation can look wooden but not immediately obvious why. now that the COG movement is done, i do the hip tilting and then the spine sway/compensation stuff. afterwards, assuming everything looks ok, i'll do the upper body rotation (lots for running, very little/none for walking) finally, i do the arms. i do the arms last because otherwise, i'll have to keep going back and tweaking them every time i change something in the torso, or anything that affects the torso. (i rarely do IK on hands, although biped has the option to toggle it on and off). if you have ne_ruins, open up pak0.pak and open the zombie2.mdl in qme.
i left the oldrun animation sequence in there for some reason. compare oldrun and run for hips/COG swaying. I don't have a method of my own, but I do remember learning quite a bit from a tutorial by Paul Steed. Although Paul is probably most fondly remembered for being the driving force behind the Start-To-Crate rating system, archive.org hosts the tutorial:
http://web.archive.org/web/20030621121346/http://www.loonygames.com/content/1.22/totb/index2.shtml It's a shame the videos are missing but all the images are preservered that's pretty cool. shame about the missing animations as i imagine they would really illustrate his points.
i didn't mention it, but his tutorial does on page2: make sure the feet (when on the ground) are on the center line of motion, not just moving forward and back. the overall motion of the foot is more of a very wide arc instead of a line. Having a skeletal rig is a good tool for animating models. Takes some time to construckt though.
Made some dynamic turbulence in the waterfall. http://members.home.nl/gimli/farl.gif that looks better than i thought it would with the texture; even the bottom scrolls. good job.
The water fall is indeed really nice ! Good job !
And the latest one: I'd like to see it textured too ;) I remember writing the last exporter for blender, but abandoned it after the first release as breaking changes left it inoperative in a later version. I suppose abandoned software has stability as it's sole advantage...
I am trying something like a cell generator, that implies empty cell packs going in and out a machine after having an energy injection.
Fact is I need to translate the cell dimensions, which was 32x32 I thought. The way qmle translates units looks like cm. Energycells are removeable, while these are solid, which means they have to stay out of reach of the player. Shame for the lost triverse in the cell pack.
I have to change the scale anyway. http://members.home.nl/gimli/clue.gif If you want a mdl with scale reference for a cell, dig into the pak2.pak file from quoth and open the pickup.mdl file. It is build to scale.
I have an example I had from Lunaran, but I lost it somewhere. Thanks for pointing the direction.
I was measuring the frame of qmle into my animation editor, and found that the units compared to centimeters. So for taking 64 x 64 I had my format. When I import a model though it is a giant. I have to scale it ten times before it is usable. When I modelled the monster in the wall I met the same difficulty. It's worth noting that 1 unit in the map editor always corresponds to 1 unit in the QMe editor, which corresponds to 1 unit in the QC, if that is any help for scaling. Most conversion tools just translate one unit in their editor to 1 unit in quake as well, for example the gmax->md3->mdl pathway preserves 1 unit scale at each step.
Good to know, preach.
I often tried a cube into qmle, but it always fails ingames. I made a whirlpool, or something in the way. It could also be udsed as tornado. http://members.home.nl/gimli/tornad.gif Is it possible to make a static entity move?
I have a sphere as a mdl, used as static entity and I want to make it turn slowly. I remember the spikemines., but my aim is more something like a turning sky. Calculating on framerates of 0.1 sec it isn't difficult to make it roll once in a second, but turning it slowly, like a rotal movement of 60 sec may be something beyond model dimensions. I thought I can use 256 frames, so that would be 25.6 sec to go. That isn't a skybox turning, so I wondered if it would be possible with qc, or a hiher frame maximum. What's the limit? can only move two ways:
1. they can have the rotate flag set in the model, like weapon/armor models do. 2. they can have a framegroup which contains the animation, and the client will automatically cycle frames at 10Hz. QuakeC cannot do anything with a static entity, once it is static it is purely a client-side object with no physics and no think functions. if you mean an entity that has had the makestatic() function run on it, then no.
of course, just remove that function call and you can move it as much as you want. you can use this will look like shit unless you are using an engine with high precision angles. Right.
So when I want to move a globe I can only make it roll like a grenadelauncher, or add as many frames as the engine can load. How far can I match? 256 frames ~ 512? well, know, my example was like the weapon rotation, but you can rotate it however you want...
'1 0 0' is rotation around x axis, and '0 0 1' is z axis. and you can use any number you want. even decimals. 256 frames is the max in protocol 15. Other network protocols (which require custom engines) support more.
Thanks, mertlslime that's what I was looking for! Then it will be 256 frames ~ 25.6 sec ~ comes to me like 1.5 minute a cycle.
I didn't see your post ,necros. Also thanks for the info. Why do you think it would look strange? 1.5 degree cycling with high resolution tex would make it look acceptable. I don't know, maybe I'm just the next stupid noob who wants to make a turning skybox in Quake1. :P Well, I succeeded to blow up Qmle, as I suspected.
After splitting the 240 frames into parts of 40 it worked out after kicking the expected error. I won't add a gif file as my homepage gets truncked, so here's the file. http://members.home.nl/gimli/azimuth.zip My zipfile came back corrupted. Hope this one will do. How can I use high resolution texture on models?
I placed them in the id directory with the others but it don't appear in game. Brush texture are 256x256, but how does it go for the skinfile for a model? I tried model.mdl_0.tga on 256x256 but it hust glidges. Is there a desired format for the dimension of a Q1 MDL skin? Are they suppose to be powers of 2? I looked through some of the ID skins and they are all strange sizes, does it matter the size of the skin?
What Qmle concerns the skinfile compares to the first imported file from base. Sometimes it is square or rectangle. General is the with that considders to go to limits like 308 x 264.
I always scale this up to a factor 480 x (>480), as this is the maximum skinsize before Fitzquake stops the game. There are other ways to obtain a larger file, which is just the same problem I'm struggling with. I'm accostumed to qmle, and sadly this has bad UV wrappers, in fact not. So as long as you use 480 x (the desired compare) you are safe. The ID skins are bad examples to follow, as they were created before graphics accelerators existed. Graphics cards expect power-of-2 skin sizes. The way that GLquake copes with this is to rescale all the skins to the nearest power-of-2 size first, which causes some distortion/smearing.
Fitzquake does the more sensible thing and pads the skin with blank space to increase its size to the next power-of-2, but that's still a waste of texture memory you could have used for your own skin. So stick to the standard powers-of-2 approach for best quality. Footnote: DOSquake has an extra restriction on skins, that they can't be more than 200 pixels high (although they can be as wide as you like). Since that would constrain you to 128 height, I'd advise just not caring that DOSquake can't load the file, I don't think it's bothered anyone else this side of the millenium... external model textures go in the progs directory. make sure the engine you use supports external model textures, of course.
If you are using noesis for model conversion, I found that if you have UV points on the edge of the skin they are corrupted when converting to Q1 MDL format. I have tried to contact the author to see if the program can be changed but not much luck.
speaking of edges on the skin, and someone please correct me if i'm wrong:
make sure the top left pixel of the skin texture is not a colour that is used on the visible parts of the skin itself or black. some engines replace the colour of the pixel in the top left corner with black and every other pixel that shared that colour. or something like that. It's like a bucket fill in 'paint', replaces the top left corner and all the pixels of the same colour which form a contiguous block. This has caused me a great deal of pain trying to figure out why a model I rendered with a single-colour skin was coming out solid black...
I can't make it fit. I have the HR texture pak in ID1/textures and the brushes appear well in Fitzquake085.
Now I have the model.mdl that I want to give a high resolution texture. First of all the skinfile in QMLE is bound to 480x126 and 256 colours and named model.bmp. I'm looking for a way to add the HR skinfile. Placing the same skinfile on 16M colours in the texture directory won't help as I keep getting the old 256 skinfile. I can change the name to model.mdl_0.tga with no effect I can't change that as my knowhow of Max Gmax doesn't supply. RTFM won't help a lot as I tried all I could. What am I dong wrong? read post 304 again, model replacement textures go in the progs directory.
model.mdl_0.tga is the correct naming convention. Let's explain more,
C:\Quake\ID1\textures is my HR dir, I changed it into C:\Quake\ID1\progs\model.mdl_0.tga with all other HR tex. My model.mdl is in C:\Quake\TmpQuark\progs with the progs.dat In Quark6.3 I can go into game with the normal HR brushes but the model itself stays in the same 256 mode. I know I'm going astray somewhere, but this problem holds me for a long time now. first, if you're working in a mod directory, you should put all your assets into that directory. you should never be adding mod assets into the id1 directory.
that said, what engine are you using? i know FQ and QS do not support external model textures. How do I obtain that?
DarkPlaces, JoeQuake, or what engine then? No complain about Fitzquake, but I thought there might be a hack. Thanks for your explain, it was usefull.
Me big ever smoking bluf for working in RemakeQuake and oversee that last one. I asked the Noesis author:
UV points aren't "corrupted" on the edge of the skin The format just doesn't support wrapping Incidently, quake mdl format supports wrapping as long as you are willing to forego support for the winquake version! In winquake you get lots of random noise anywhere that the skin UVs leave the bounds, presumably because it's dumping random memory onto the screen. Probably if you abused it enough you would segfault the whole thing. So not the best of ideas but certainly possible...
Wow thanks, I tried to contact the author of noesis but I could not find any email address (none with documentation or website). I eventually found a forum site he uses but that is never speedy for responses. It certainly makes sense now that I know the MDL does not really like UV points on the edge, I just wish Noesis said something instead of just creating a mess!
ijed, or anyone else using it: how are you exporting to fbx format? i'm trying to get it going with max9 ->
Some new ammo pickup models I created because my new map is a medieval theme and I do not want tech style stuff hanging around. I know I am stepping on holy ground by redesigning the original models but I wanted something different.
Each pickup has an unique design profile so it can be recognized easily and I tried to keep the original colours as much as possible. The new models certainly have a higher triangle count, but I kept the original texture density. (I like the old style pixel way best) http://www.simonoc.com/images/design/sp/q1_ammo_models_v1.jpg Any likes or dislikes? I typically hate "new stuff" to Quake's look like that, but I oddly enough rather like those ammo pickups sock. I enjoy the use of the id1 textures as part of what is encasing them, makes them feel like more a part of the game world rather than items simply inserted by the mapper.
Changing quake's ammos from the fullbright bsp boxes to mdls that take level lighting, is one of the few changes that I would actually make to quake's original look.
I'd probably add some tasteful fullbright elements to the textures though, so that you can place them in dark areas and they don't get lost. Easier to do that with tech-themed stuff though... @Necros, yeah good point. The original texture design was a stone box but I switched to wood later on. I will convert it all to wood.
@Kinn, oh yeah! I love it, you know it is all your fault that I now make assets designed for the original pixel resolution! :) mdl ammo boxes is a feature in quoth, although it's done there to save on model precaches instead!
Things are going a bit faster now that I have a working pipeline for creating models. So here is my attempt at replacing the medipacks with something more medieval. I have maintained the original footprint/height and tried to create something different in profile shape.
Original pixel vision thanks to Kinn! http://www.simonoc.com/images/design/sp/q1_health_models_v1.jpg Any dislikes? hadn't thought about the relative heights vs heights in isolation, but i'd also like to see the cross symbol return.
that said, i kinda just don't like the way they look... like a jar of blood. sorry man, i much prefer the original kits over your new ones. :( i think i'd rather see the original health kits but with the metal replaced with wood. @Preach, yeah I like those ideas, I will add a green/brown tint to the rotten health (15) and stamp a cross symbol on the top of the corks. I can certainly add some fake shadows on the bottom of the jars and some glint at the top.
@necros, I know you are not keen on me redesigning the original stuff, but I really want to get away from tech style boxes. I checked the existing q1 levels with my new items and they fit really well. The items don't look out of place and now have some character/style about them. I might create the originals as a separate pak file so people can have a choice if they are really against my items. Take the highlights on the edges of the bottles, and colour (only) the adjacent borders of the bottle with dark orange fullbright colour. The intended effect is that in bright lighting this fullbright appears just a natural part of the shaded bottle face. In dark lighting these new edges appear fullbright, as if they were dimmer but still visible edge highlights, while the original highlights disappear in the dark.
Not sure about this. I'd probably think it was just bad texturing, rather than a design choice to have fullbrights integrated like that. I only see fullbrights making sense when they create an obviously seperate glowy light element, like a rune or a gem. As for the health packs - I like the shape, I think that's cool. I think it's "too red" though - i'd be inclined to make it a combination of metal and glass, rather than entirely glass - like a mostly metal frame with glass "windows" in. Here's a few examples of the super-secret twinkle shader that's been hidden in quake for the past 16 years.
http://www.btinternet.com/~chapterhonour/gem.zip You need to view then in game, QMe will not render the effect. I'd suggest whacking them in a progs directory and renaming each one g_rock2.mdl in turn. You can then look at a rocket launcher pickup in game to view them (use the flush console command to update after each file is renamed). Start with the flat one so you know what to expect. Cookie for whoever can explain it! Someone took a bite already : -(
I think with a bit less laziness it would be possible to make something that looks a bit smoother as well. In the zip the effects are produced by 1) Randomising each vertex from the whole range of 162 2) Randomising over the first 15 vertex normals on a per vertex basis 3) Randomly selecting one vertex normal per frame and applying it to all vertices 4) Randomly selecting one of the first 15 vertex normals for all the vertices in a frame They all rely on essentially random selection of vertices because I was too lazy to import the table and start doing dot product calculations. With a bit more work you could create effects that vary continuously through space and across frames. dude, that's awesome!
how are you randomising the normals like that? can it be applied to anything? i'd love to get that effect going on an fx model i'm using. way better than just flickering alpha! I've uploaded one of the 4 perlscripts I used to make these models at
http://www.btinternet.com/~chapterhonour/randnorms.pl It's a hacky thing I wrote when I was learning perl, there's at least one thing I do which is not best practice. It also hardcodes the filename it operates on(currently gem.mdl) because at the time I didn't know how to parse command lines. On the plus side it doesn't need the perl library I wrote for operating on models, it's stand-alone. Soon I'll be recreating that library in python because it turns out that perl syntax isn't very readable. When that happens I'll try and create a more readable python script to do the same thing. Just a quick thought, when I see any container of red liquid which refills health, I myself tend to think of it as a potion and thus would be rather potent. With my mind coming from that angle, even the smallest healthkit looks like it would have the impact of a megahealth (with the largest looking like it could heal an entire party in coop like a mega). Essentially, all of these look like they would deliver a lot more health than they would running stock qc.
hmm yes, i think i agree with that /\
what if the rotten and normal kits were closer to the size of the Hx2 flask? (this one: http://lparchive.org/Hexen-II/Images/16-hexen2-items_flask.gif ) also: preach, that script works perfectly! should be noted (and in retrospect i should have realized) that you can't use fullbright colours on the skin otherwise the lighting effect isn't applied. still, works well and looks very cool. thanks! :) That gem looks good n game, Preach although it's a mystery how you obtain the effekt.
Here is the tessla coil. http://members.home.nl/gimli/tessla.zip Don't get burned. If you are using darkplaces then you will also notice the effect appears to cease working. Now we are sort-of performing a hack here so it isn't that surprising that response is mixed. It's also worth noting that what darkplaces is doing is not entirely terrible(tm).
Lets break down why in most quake engine we get varying brightness by changing vertex normals. I believe this is accurate but correct me if you know better...Quake has effectively a hack to make vertex normals work, by rendering as if there is a single bright source of light coming from a fixed direction. You get brightest light levels by having a normal directly facing that direction, and darkest by facing away from it. You can observe this by rotating 360 degrees on the spot and watching the shading vary on the viewmodel. Darkplaces rejects this and instead uses all sources of dynamic light in the scene as origins for vertex normals to be evaluated against. This means that the twinkle effects are not visible most of the time, but if you run the quad cheat you can get them to render. yeah, that was the first thing i checked after seeing it work in QS. :)
of course, if you're running in DP, it's not much extra work to include a q3 shader script to take the place of the flickering vertices. don't know if everyone knows this already; this is mainly useful if you're just modding an already made model:
if you convert a from there you can add to the uv map with normal max tools and then export following the md3 -> mdl route. nice not to have to start from scratch. Missed 30 odd posts there.
Did you get an FBX exporter or workaround Necros? As far as I can remember I'm using the default one from Max2010. Those pickup models look great - we also did this, but ours are fairly un-artistic :( nah, couldn't figure it out.
i've since gotten an alternative method which works fine using npherno's md3 importer and preach's md3->mdl converter. After adding the robot arm in my map I see this strange overlapping effekt of the cellbox.
In the framegroup there's nowhere a cellbox sliding diagonal, but in game there is. http://members.home.nl/gimli/Cclaw.gif http://members.home.nl/gimli/cclaw.jpg Whayt is it that makes the cellbox warp? This example shows the effect, now the solution if there is.
http://members.home.nl/gimli/celbox.wmv That looks like interpolation. :) Try turning interpolation off in your Quake engine and see what it looks like.
looks fine to me? what am i missing? it picks the box up and moves it over, then drops it again. also looks cool.
i see it in the video. How to fix it depends on how this animation will be integrated into the level -- obviously right now you have one box vanishing an another magically appearing, so this isn't a complete thing yet.
oh the playback must be broken as it freezes half way for me.
you could try adding two frames, one at the end of the sequence where the boxes shrinks into itself into a single point, and one at the start where it grows from a single point. this way, it would lerp the movement of an invisible single point. it'll still look goofy because you'll see the box grow and shrink really fast though. The animation is a 30 frame static entity, that is a part of two combining conveyor belts.
In the middle there would be another one with an injector uploading the cellboxes. For one animation the frames are too complicated so I make them in three parts. The bad point is that I have to make them fit to eachother in place and time. So the interpolation willem directed to is the cause. I tried to add interpolation 0 at the console but that's wrong ofcourse. I keep hearing the word lerping. In the gif file the last frame is the cellbox at the end. There will be a counterpoint both boxes are on the same place, but I thought I could catch that by letting them drop down into a solid brush while they are moving backwards. I found the fitzhack version to temper my intention to make the interpolation for the static entity. I just didn't knew it was the engine that had this limit.
The animation rolls much more shaky, but fills in the exact rotation. The original fitzquake rolls much smoother, but then I keep the hazy frameshades. I think I keep on to original Fitzquake, as for now only the wheels get creepy. http://members.home.nl/gimli/vey00.jpg http://members.home.nl/gimli/vey01.jpg It soon became clear to me that tuning two static entities is a real framejerk, so I combined them.
Reduced the interpolation effect of the conveybelt to the wheels, and then noticed the swing in the middle. It had become a jolly cellbox. In Qmle it won't show but in game it's hardly a count. http://members.home.nl/gimli/conveyc.gif http://youtu.be/OAi_Sj74BP4 The limits for verts is 2000 almost everywhere, including dos/winquake. The original glquake binary had a reduced vertex limit of 1000, but the released glquake source had this limit restored to 2000. Consequently every source-port has a limit of at least 2000, and there's no reason at all to keep models at 1000.
Just thought I'd mention this: preach's md3 converter is awesome. Thanks for making that thing. :)
I am sure most new content would never see the light of day without the various coder utilities that work away in the background. I am sure preach would love to see what you have been up to with his model converter! :P
I'm glad it's proving useful, and I'm sure you'll be glad to hear that the next generation of the md3 converter is almost half-done! By which I mean that I've written a module in python which loads and saves mdl format models. I'm just working on a few example models to go with it and then I'll put it out here.
Once that's done, all that remains is to clone the code, adapt it to load md3 files instead, then make the glue code for the conversion. The purpose of all this reinventing-the-wheel is that the glue code will hopefully be clear and easy to adapt, allowing for finer control of the md3 to mdl conversion. For example, if you're making a map object which needs to be aligned on the grid to meet the geometry in the map, you might want to specify the scale used in the conversion of the model coordinates. I was wondering if you don't mind adding some more features:
* BMP skin support (8 bit) I can't get Photoshop to save in that wacky PCX format you use. * Multiple skins (via the normal text file) * Update special mdl keys (rotate etc) * specify names and groups to animation sets (via the normal text file, a comma delimited list) It is awkward viewing stuff in Qme with just a huge list of numbers for frame names. @preach, that would be awesome to have those features. It is the last things I use Qme for (multiple skins and model flags) and not having Qme in the pipeline will be awesome.
The config file flag of mymdl.flags is fine with me, is this parameter available in the current version? I totally understand why the skin / animation names option is missing from the current version. Writing a config file parser is always time consuming. @Preach, unfortunately I don't have python installed, but I can wait, honestly there is no hurry. :) Plus I am busy creating new skins at the moment, so it will be a while before I am back to exporting models again.
rawr
Sock's mesh, uv and skin and I rigged and posed it. Thanks again for the converter, preach. Wouldn't have bothered with this stuff without it. wow, really nice.
Quake's monster skins tend to have a bit more blood and grime splattered on them; yours looks relatively clean by comparison. All this new medieval stuff looks like taken from an alternate reality that also happened to just have Q1, it's that good.
I like the way is has that humor on his face, while its shield looks so nasty.
Great model face lift! It reminds me of John Blanche' illustrations:
http://taran.pagesperso-orange.fr/images/4khorne.jpg Especially those from Sorcery! Something I found on polycount today, linked from the low-poly-models thread
http://wiki.polycount.com/SphereTopology It's a guide on how to save polys on spheres by collapsing edges that don't improve the silhouette of the shape. It's interesting in itself, but also as a starting point for how to optimise curved models generally. Okay, it's only a double post.
http://www.btinternet.com/~chapterhonour/quadtrick.zip Whack it in progs and load a map with a quad. It's basically a similar trick to the gem, but because I can write the scripts in python now, I can cope with doing directional calculations on normals. This means you can get coherent effects rather than the random ones seen earlier. I see the difference. Is it engine dependent?
And yeah, a well presented article. I'd be interested in one a bit more high level though. How the silhouette is all important and the visual acuity of the ones in Quake is pretty damn good. Yes, that looks good!
I just remade the squad.mdl, giving it a flat skinfile. It doesn't change much to the already excisting, as if smaller objects get reduced in game. This scripted print really glows. It relies on the normal effects, so it's very hard to see in darkplaces for the reasons mentioned earlier in the thread (back where sock posted the health vials). Fitzquake is recommended because it has motion interpolation without vertex lighting, but it's also worth seeing that it renders in winquake.
I know I'm recalling the subject again, but now that I have the tessla coil I can't add a sound to its sparkle.
I'm allready glad I can use mh's version of progsref to make the thing go. But now it seems as if an electric wav is hard to add to a info_notnull as all sounds are precached. So here is a map with an example, maybe there is a simple solution for it. Or I'll strip the toppic and read it again. http://members.home.nl/gimli/tessla.zip It seems like the easiest way to play the sound would be to add code that precaches it to info_tessla. You can look at the code for ambient_drone to get you started. The way that ambient_drone works does mean that you can never turn the sound off, so let me know if this is a problem.
The main problem you will have is that the sound file you have does not loop. To make it look you need to: Download wavosaur from www.wavosaur.com and install it. Open the wav file in wavosaur From the tools menu select markers->create marker. You can then move the marker around, place it at the point where you want the loop to start playing after the sound reaches the end. Finally, save the file and it should loop in-game. Thanks for the headsup about wavosaur... been looking for a good straight forward sound editing program. I can't stand audacity. :P
Right, Preach.
The sound of the constant tessla is already added with some ambient_fuz. I ment a sound that wakes at the moment the player gets touched by the tessla. So I don't need the sound looped, only for the flash of the bold. Reason why I thought it would fit more in the trigger_multiple from with the lightnihg is excecuted. Or in the info_notnull. But the sounds there are all precached. And I wonder as this func is used as teaching old progs new tricks. A couple of shots of a work-in-progress computer terminal model in idbase style.
http://www.btinternet.com/~chapterhonour/console1.jpg http://www.btinternet.com/~chapterhonour/console2.jpg How many colours does the quake palette contain? And why does it hurt so much?
When I start 64, when I'm working 256, and when I stop 625.
Must be the afterimage that hurts. Do I get John Bean Sunglasses now? http://members.home.nl/gimli/generator.jpg I'm trying to understand the basics of models in qmle, so I'm try turning triangles into cubes without losing skin texture.
The model above is one of the low poly model site I found on the board elsewhere. Reading the liscense and GNU it is freeware, but it's more a challence to make one of yourself. I'd not recommend learning basics from QME because you might end up thinking that things are just hard to do, when in fact they are only hard to to in QME. It's a specialist tool for quake models, general purpose modelling programs like blender or gmax are easier for the basics, despite being more complex overall.
Blender is to heavy for me, so i asked myself, if there is any other freeware next to gmax which is of good use for quake-modelling.
The program that I've always found easiest to actually create 3d geometry in is called "Wings 3d". It isn't a full package - you can't do skinmapping or animation in it, but it makes sculpting very intuitive. I also haven't tried to get a version of it for years so I don't know if it's still developed or even easy to find...
I was chasing the strange object bear pointed in the inspiration thread.
http://members.home.nl/gimli/moeb4.gif preach, what causes md3tomdl to ignore the input skin and (auto generate??) an orange/brown striped skin?
I exported a skin from qme into pcx and everything seems fine (model frames are all there as is skin mapping). The model is a convertion of the HalfLife2 low poly site whith free models. So I thought to respect the owner with a screenshot.
Most of the time these subposes don't reach ingame. http://members.home.nl/gimli/heavy.jpg Here's another one that hopefully will become playworth. Already big for milepasses and jumping on rockets. http://members.home.nl/gimli/bigles2.gif More of a texturing question I guess but this seemed the most relevant thread to post in:
Are there any Gimp users here? I'm trying to make some skins but I keep getting errant full brights, even when my palette is not supposed to have them. I never had this problem with Photoshop, so I'm guessing I'm just doing something wrong. Is there a proper way to set up a palette without any fullbrights? The way I have my fullbright-free palette set up in gimp is to start with the full 256 colour palette, then replace the last 16 colours with black. Since there's already a black colour at the top of the palette, the remaining 16 colours never get used.
how do you make your palette? I load up a palette image texture (has the 256 colours in large blocks) and then make the bottom two rows black.
But I still see fullbrights on some reds. I don't know if it reapplies the palette when you edit it, have you tried saving the palette, changing the colour depth to RGB, and then changing it back to indexed with your saved, fullbright-free palette?
Otherwise there's always QMe... Well, what it seems like is that there are two identical reds, but only depending on the index in the palette is it determined to be fullbright or not.
It's weird because in PS, the palette would show up in the same order it was in when I created it from the palette image. In Gimp, the colours are just all random in the palette. Otherwise there's always QMe... What do you mean? Try grabbing the file from http://www.btinternet.com/~chapterhonour/notbright.pcx and importing the palette from there. If you still have trouble, is it possible that some other tool is interfering? There is a shade of fullbright red with the same RGB values as a regular palette entry, so anything that converts skins from palette index to RGB and then back to palette index will inevitably lose information on some files.
re: QMe, you can use it as a cheap fullbright remover by importing the texture in question as a skin, then using the QMe palette filter tools (which are quite good actually, being custom built for quake itself) Thanks, I will try that out with the pcx file directly.
QMe palette filter tools Which tools are those? I've honestly never touched that part of the program. The skin editing in QMe is probably the most polished part of the program. You can even undo edits that you make while drawing on the skin using ctrl-z! (*)
http://www.btinternet.com/~chapterhonour/qme-pal.png highlights the button (top right) and shows off the dialog. You can remap colours one by one if you double-click them, then pick the replacement colour from the pop-up. It's pretty laborious to do that though. The quicker way to replace colours all at once is to untick the boxes to the left of the row. This replaces all the colours in that row with the closest match in the remaining checked rows. That last bit is important - if you have lots of fullbright oranges and reds you want to remove from your skin, make sure that all the non-fullbright orange and red rows are ticked first. Otherwise you will get poor results! (*) 3d view only Ah ok, I saw that dialog but couldn't figure out at a glance what the heck it did.
Seems like a cool way to do some quick palette swaps, thanks for cluing me in on it! Hm... I think I have found why
OBJs (for example) allow a face to contain it's own s/t tex coords, but MDLs have the s/t coords bound to the vertices themselves... Oy... I guess I will need to figure out how to split up the OBJ mesh so that skin verts and mesh verts are split the same. OBJ files store verts in clockwise order, but (I guess because of OpenGL?) they need to be in counter clockwise order to draw properly.
It's called 'ne_modelEditor' but all it can really do right now is edit UV mapping on models. :P
File->Open to open a model (.mdl but will load RMB Drag on the 3d view rotates MMB Drag on the 3d view pans Click the "Show UV Mapping" button at the top. Click and drag to move UV verts around. Dark Blue verts are normal skin verts. Light Blue verts are verts that share front/back tris. Moving a light blue vert moves the two together. File->Save to save a new model. Don't overwrite your models... who knows what this program could do?! Oh right.. me. Just keep some backups of your models. - There's no undo (there will be) - You can't split/merge skin verts (you will eventually be able to) - Can't select verts/tris in 3d view (you will eventually be able to) - Can't edit 3d mesh at all (don't know if I bother with this, there are better modelling programs out there) ne_modelEditor 0.01 Made out of java, so you can just unzip this into a folder and double click ne_modelEditor.jar If double clicking doesn't work, you probably don't have java or it's not set up right. Also, this requires OpenGL 1.1 compatible card... which should be like every card out there. Specialising in UV maps is probably a good niche to aim for, as all the existing mdl format editors are lacking in that department. I already prefer using this tool to QMe, which doesn't even select the vertex under your cursor correctly. Quick wish-list in that department:
* Drag select * Select adjacent vertices command * Select entire component (all vertices connected to the current selection) * Rotate tool * Scale tool * Mirror tool That ought to be enough to let people create efficient skins. Also one nitpicking detail: Quake actually places vertices in the middle of the pixel at the given skin coordinates, not in the top left corner of that pixel. It's a kind of unhelpful design because it means you can't get even borders on the edges of carefully aligned polygons. But it's the design we have been given so the editors have to follow it. Quake actually places vertices in the middle of the pixel at the given skin coordinates, not in the top left corner of that pixel.
Oh shit! I actually uncorrected this because I thought it was due to integer casting somewhere along the line! As for your wishlist: yup. :) Other things: - selecting tris and being able to detach them as one piece - being able to "relax" tris in UVs to match their shape on the mesh. -displaying coordinates and allowing editing of UV vertices by typing in http://necros.slipgateconstruct.com/downloads/ne_modelEditor002.zip
v0.02 ESC now closes UV Editor. This is mainly just a convenience shortcut. Shift-selecting multiple frames in the sidebar of the 3d window will auto animate the frames in the selection... Just a lame way to preview animations for now until I make some proper representation of the frames... maybe with JTrees or something. Box selection is in. Holding Ctrl while selecting will add new verts while just box selecting will clear the previous selection, as per usual windows UI standards. Alt+Box selection to deselect vertices within the box is NOT implemented yet. (it will be) There's no 'select element' function, but something almost as good... I emulated 3dsmax's Grow/Shrink Selection functionality. With a single vertex selected, pressing the grow selection button will select all vertices surrounding it (that are connected). Shrink selection works in reverse. So you can select a whole element just by repeatedly hitting the + button. A very rudimentary Undo action is implemented for UV vertex edits only. (Which is fine considering it's the only thing you can do anyway!) Of everything, I'm the least happy with the undo implementation. I've never coded an undo system before and I realize I should have been making it along side everything else. As it is, I seem to be working around my classes which is never a good thing. You still can't select stuff from the 3d view... Sorry, I'm just not sure how to do the traces. I realized when I sat down to code it I had no idea how a "traceline" actually works! All I could think of was doing a search in a sphere along a vector in small increments and hope to find a vertex within the radius... but that seems lame. :P Next will be some basic functionality like rotating and scaling verts and at least edge and face selection/movement. You still can't select stuff from the 3d view... Sorry, I'm just not sure how to do the traces. I realized when I sat down to code it I had no idea how a "traceline" actually works! All I could think of was doing a search in a sphere along a vector in small increments and hope to find a vertex within the radius... but that seems lame. :P
There's a better way based on this fact: The closest approach of a point to a line is where the vector between the point and the line is perpendicular to the line You can create some linear equations which can be solved simply to give you the correct point on the line. Then calculate the length of the difference and reject the vertex if that distance is too great. I can expound on the maths later today Ok, so here we go. In the following maths any variable in bold is a vector, non-bold are scalars:
We can define a line in 3d space using two vectors, origin and direction. The origin a can be any fixed point on the line. The direction r is a vector parallel to the line. The equation of the line is: x = a + k r where x is any point on the line, and k is a scalar which can vary. For fixed a and r we can choose k to find any point on the line. In this specific case the natural choice of a is the viewpoint of the 3d render. In quake we would find the vector r using makevectors(self.v_angle), in your java thing you're on your own... If we let b be the coordinate of a particular vertex we are testing we get (from the post above) r . (a + k r - b) = 0 We solve for k: k = (b - a) . r / (r . r) In a third post I'll bash through some algebra which uses this value of k to calculate the (squared) distance on b from the line. Thanks for taking the time to outline the whole process, Preach. I was going to reply yesterday, but it seems I can't even get my 3D Picker working to translate on-screen clicks into world coords.
I'm sure I just messed something simple up but I got frustrated with the damn thing and just went and mapped instead. :P Finally straightened out the screen coords -> world coords shenanigans and thanks to your posts, I now have vertex selection in the 3d view! :)
For edge selection, I'm thinking make a plane perpendicular to the camera, find the point where the trace hits the plane, then use the same stuff you posted above except in reverse-- find a perpendicular line of shortest distance to the edge from that point. Face selection, again with a plane, this time of the triangle. Find the point where the line intersects the plane, then check if that point is inside all 3 edges of the plane. (make sure the intercept point is on the same side of all 3 edges as opposite triangle point of the edges). Good that all of that stuff is working. I thought of one need little optimisation for selecting the best vertex when multiple vertices meet the criteria and forgot to mention it. If many vertices are within n units of the line you are probably best off choosing the vertex which is nearest the camera (rather than just taking the first result on the list which might be on the back of the model and confusing). The neat thing is that in (5) we already calculate (x . x), so we can save that value for the best point so far, then compare it to any subsequent point which is near enough to the line.
Your plan for the edge selection seems sound but one warning - you will need to special-case the situation where the edge is already perpendicular to the camera, because when you project the line into the 2d subspace it will collapse into a point, meaning r goes to (0, 0, 0). The danger is that you will then attempt to divide by the length of that line's r value and crash because it's a divide by zero. Check for the zero length, in that case you need only measure distance between two points - easy! A couple more models coming from further experiments with gmax animation: a force-field effect and a smoke plume. Download from:
http://www.btinternet.com/~chapterhonour/effects.zip There's a test map included, extract the whole thing to your quoth folder - the models themselves are in a folder called test (in the hope you'll remember to delete it once you've had a look around the map). As with the waterfall effect from a while ago, the models work in engines as far back as winquake but are better in something with interpolation and alpha support. JPL: the only reason quoth is used is because you need some kind of mod to display custom models, and quoth has an entity which does it and most people have it installed. Rumour squashed!
I am not trying to create a rumor, I was rather expecting a brand new update from the awesome mod to shake my inspiration that is today almost inexistent... :/
and now I am really really disappointed :P While I'm enjoying having a wizzy new website, I don't want to feel like I'm just linking to it instead of posting stuff here. So I'm going to share a motivating story and then link to a new article which relates to it:
I remember on several occasions running into an annoyance when creating a model. I would spend some time working in gmax on the model, sculpting and skinning it, until I reached the moment when it was finally done, and it was time to export to mdl format. Once I'd cursed and sworn my way through making the fragile conversion succeed, I'd begin the work in QME of getting the model finished off - scaling, rotating and positioning it correctly, adding animations, importing the skins. The annoyance came when half way through this work in QME, I'd suddenly realise how much better the model would be if this part of the skin wasn't mirrored, or if I'd turned some of the edges the other way. The dilemma was choosing between foregoing these improvements, or throwing away all the work in QME so far to export a new version from gmax. If you have ever had the same experience, or just want to learn how you might create a quake model without using QME, please come read the long article I just posted at http://tomeofpreach.wordpress.com/2012/11/24/a-modelling-pipeline/ The idea is to generate mdl files from a series of compiling tools, rather like bsp files are made. Also in the modelling category is an expanded article on "progressive enhancement" expanding on what I've posted about it here, and restored downloads of my two modelling tools qmdl and md3tomdl. The latter is an exciting new version of the tool, v0.2! It offers better vertex rounding, proper vertex normals and support for multiple surfaces in the source md3 file. To be honest I've been using 0.2 for years and never realised I'd kept it to myself. That's not to mention the model category where I've been uploading stuff the past week. It's a roughly even mix of models from the old site, newer models which I've shared in this thread, and entirely new models which nobody has seen yet! In particular the "Map objects" category has the best of the goods. Gmax md3 and soooo many things too learn. After using Hammer for so long Gmax is a bitch. Just getting things to grid. I keep moving things I don't intend to. A whole new set of terminology
Stick with it though, and don't forget to walk before you can run. There are thousands of wooden barrel models out there, but one which was made just for quake(and so presents no legal worries) would still be nice! It's pretty simple to model, interesting to unwrap the skin for, and then doesn't need any animation (which is the hardest thing in gmax).
I really should take that old gmax tutorial I had on one of the qexpo sites, and revamp it on the blog someday... New model time (although I posted previews of it years ago so it's only newly finished)
http://tomeofpreach.wordpress.com/2012/12/15/ogre/ It's a replacement ogre (which along with In The Shadows makes two in the past week, I know...) with all the usual skin map stuff. It's based off the ogre drawing metlslme did, which I was looking for in the screenshots thread earlier. Bonus fun fact: this model uses less texture memory than the id ogre in 3d accelerated engines! The original ogre texture is 264x194, which gets rounded up to 512x256 - twice as much as the 256x256 of this model. And another model, one which might even be more interesting, although it was much less effort to make. It's a mapobject for adding fences and wooden logs to a map, with 4 skins which cover the main ID wood textures. Go take a peek and download it from http://tomeofpreach.wordpress.com/2012/12/16/fence/
Here's a little bug, it won't attack unless you change its sting.qc.
bug I wanted something that just flattered around, but as it awakes it is fixed to a player. Not what I expected as it attack routine isn't used. Maybe make it a bit smaller to lower the bouncing box. Odd when it isn't possible to jump over it. download i haven't looked at the code, but movetogoal will home in on whatever entity is stored in the
if you adapted the sting.qc from a normal monster, then you probably have ai_stand() in the idle frames which will set the player to goalentity when it sees them. then you probably have ai_run(#) which uses movetogoal which is what makes it run to the player. I guess I should have elaborated more:
what you need to do is remove ai_stand and ai_runs. you will need to make a new movement function to replace the ai_run. then you will need to find a way to make it choose when to move and when to stand. btw, the model is cool. :) You're aiming at the point I lost my intention, necros.
In the mdl is a subroutine that turns, so it must be possible to make it just fly around, and take a place to sit down, after continuing flying. It's just that I'm not so familiar with monsters that won't get hostile. The subroutine to make it only wandering around don't come with an example to reach it. The tumble when it dies accordant to a scrag explains a bit of the way to go. Maybe the code I used for birds will be helpful?
http://mobile.sheridanc.on.ca/~jonescor/temp/ne_bird(07.12.12).qc check out the ai_bird() function at line 373 The bird doesn't move on it's own. The mapper places bird_anchorPoint entities with flags set for either food or rest. Birds get hungry and tired when flying and have to go to rest areas to remove tiredness and food areas to remove hunger. This is basically how they decide where to go. Also, birds don't use movetogoal or walkmove, they directly set I searched in the AI.QC the
I thought it would be possible to make the entity not getting hostile with an exclusion, but there is more involoved. Still I don't get it why I can't jump over it. I made the so seize small and still it acts like a pillar. Thanks for the util, will see it through. That's awesome. I did a bird mesh, but just fired it via an emission without coding anything up.
Poor bird mesh, to be vanished to fire without code!
necros - handsome sript! I try to rip off what comes in as usefull. I suppose strings like "ai_monsterDead" and "ai_bird_modifyHunger" are the parts my compiler doesn't know to deal with. But for a rough overview I must say you have a fine quake bird there. sorry about that.
ai_monsterDead is just a function that makes bodies fade away. You can just remove that. ai_bird_modifyHunger is on line 188. You can simplify it a lot by removing hunger and tiredness though. Those things are not really necessary. Ok, it's not a totally new model, I think I posted an early version of the dome right before my old site departed. But it's got a bunch of new skins, and it's now designed to align with the grid and brushes correctly.
http://tomeofpreach.wordpress.com/2012/12/20/dome/ Here's a special model for this festive occasion - although it's not really seasonal, just a little bit silly. It's a custom shambler model with some very special animations. Might even be useful if you're looking for an easter egg for your mod.
http://tomeofpreach.wordpress.com/2012/12/24/shambler-dance/ I reckon the underlying model has potential too. It would need a bit of work on the skin, give the fur convincing texture. Shaping on the arms needs some work. And obviously some sensible animations... I'm scrapping the map itself, but those columns look familiar http://www.suspenlute.com/stuff/columns.jpg
with 17 years of quake history someone somewhere MUST have created a model of a human heart - preferably animated. Anybody know?
But it's just a blob of meat - you can probably make one in under an hour, even if you just use ye olde QME on its own :)
I spose it's possible that there was something like that in Hexen. And the HL1 gibs were pretty detailed. But hunting one down will probably take more time than making one. The finest heart model which comes in under 50 polygons and takes less than an hour to make.
http://www.quaketastic.com/upload/files/models/heart.zip Half-life certainly had a model as well, it was probably a but better than this... Heartbeat sounds if you want them:
https://www.dropbox.com/s/y6779j28cc0619d/heartbeats.7z They're from a variety of projects; all should work in Quake. Just to say that if you do have any more vital organ requests, or indeed other ideas for models that could be created in just one hour, do post them. I'll see how many I can do between now and the new year. Reference images are very helpful.
Since the scope is just one hour, animation is probably out of the question. I did consider adding a beating heart effect to the model, but I couldn't see how to do it both quickly and well. Not sure how complex any of these could be, or become in terms of time. This list is probably something akin to what the naughty children received over christmas instead of presents...
Gravestones http://anakhacoman.com/wp-content/uploads/2012/04/celtic.jpg Ladders Cluster of mushrooms https://mycotopia.net/forums/attachments/photo-gallery-grow-logs/204332d1294432390-luminous-mushrooms-untitled.png Hanging Lantern (Nehahra but nicer) Twisted Trees http://3.bp.blogspot.com/-5rAklDg9gh4/Ta-GMkT6rtI/AAAAAAAAAjo/ikp7PrcSdGE/s1600/tree.jpg Gibbet with corpse http://images.wikia.com/uncyclopedia/images/1/1b/Gibbet.jpg Old Skeleton / Bones http://www.colourbox.com/preview/2991878-530102-very-old-human-skull-from-the-historical-place.jpg Wall of skulls http://3.bp.blogspot.com/_4b706UrnAoc/SesxNmn3CII/AAAAAAAABWM/7VJgsZSJMtY/s200/brnobones.jpg Decorative bones / mummies http://www.shopcurious.com/Images/Editor/Crypt%20of%20the%20Capuchins.jpg Cobwebs (for corners etc) Sacrificial Altar Loads of torture shit http://www.medievalwarfare.info/torture.htm That heart looks awesome, especially with the extra red skin I had lying around. Thanks! :D
http://www.quaketastic.com/upload/files/models/mushroom.zip
Took a few minutes extra to upload. Probably gonna look at the gravestones next (but not straight away). On some of the other models: The twisted tree would be really cool, I'd like to make it, but I think I'd spend longer than an hour on it, get the whispy bits animated properly etc. The hanging lantern would be doable, but without a flame inside - adding that would take longer but probably would bring the model together. Some skull/bones type things would probably be doable, the trick is probably to make skulls that are very low poly so you can have lots, and also to make the skins match the pile of skulls/bones textures in maps - so you could have models to top off a pile of skulls brush with a bit of extra detail. Piles of books would be fine to do, the trick would be striking a balance between detail and polygons. I guess all the mechtech torture models had to be removed from his pack then? They'd be static at least...I have no idea how you'd make a cobweb which would work in standard quake, I've thought about it before. Finally, I have a grass patch model on the back-burner right now, so watch this space... I asked for mushrooms to use in my rmx map that has the poison / drunken basement area, so expect to see those used there - thanks.
Torture models included. Has source skins so you can reskin from a large full color image. Also has some tombstone models.
http://www.celephais.net/board/view_thread.php?id=3&start=8889&end=8889 I have a few questions. Do hi rez textures for knave.wad exist? Anyone have a hi rez texture for the Quoth long wall torch? or a similar model with HD skin. Preach nice mushrooms. ijed You could have multiple models share the same origin in a map. That might overcome the limits. this collection is incredible and I'm definitely going to use at least one model in it so THANKS. ;)
Thanks for those MechTech - thats a highly comprehensive set of models to a high quality as well.
Very nice model pack. I've got a model where it's really easy to see that all of the animations are synchronised, and the flag does nothing in glquake or winquake. Has any engine ever added the feature back? Given the poor showing among original engines that could possibly be a breaking change!
Did it work in software quake? (I can't run that engine)
Because I do seem to remember suddenly realizing it was broken later. just reading that quakeone thread about the open source quake...
it would be pretty cool to see a real fast moving dog. Winquake is a software renderer and doesn't work. I don't know about DOSQuake because that doesn't run on my computer. I might just add a couple of extra framegroups with the same animation loop starting from different points.
I've been tinkering with the Q3 Orb for converting it to Quake1.
I did it earlier with Skeleton, but then I broke the skinfile and had to make my own. I used Q3map2Toolz to extract the three md3 files upper, legs and head.Then I use Noesis to convert to md3. From there I used Gmax and the combine tool to get the model into one with a skinfile of 512x512. I had some rigging as I could only export one frame out of Gmax, not the whole framegroup. I think I missed the keyframe setting, but I was already glad I had the model in one piece in QMLE with the right UVskinfile. Now I want to add the grenadelauncher, but everytime I merge it into the qmle model my skinfile splits to a size of 782x240. Also it wrenches up the model itself so I tried a launcher of myself but it breaks up. Then I tried again in Gmax to import the model with grenadelauncher and use the uvwrapper but it won't add the skinfile in the proper way. Is there a way to add a skinfile to a 512x512 one, as far as I can see I still have a corner left. Then I tried again in Gmax to import the model with grenadelauncher and use the uvwrapper but it won't add the skinfile in the proper way.
Can you elaborate on this, it's the way to go. QMe doesn't understand the kind of skinmap you create from MD3 well enough to edit them. That sounds like the right method, but how doesn't it add the skin file?
As much as I'd like to leave Qme behind and move to IQM, it's still practically a requirement for tweaking the last details of MDL. There's alot of good models in that mapmdl.pak. I noticed some bugs in the jetfighter (z fighting), helecopter (half a wing blade stuck in - gaps), and the garbled texture parts in pilaar.mdl. So I tried Qme for the first time and was able to fix these things. Some one must of swung the texture map vertices around in pilaar for the fun of it!
I tried the missle model tut and that went ok as well, except for the skin. Qme put some of the texture mapped faces on the shaft where no texture exists(top and bottom). So I guess I got to move the vertices manualy to make them look like how it was done for the pilaar one? Still haven't worked that one out yet but the rest is ok. A little off topic, but i'd like to know for when I get a chance to get back to work on my model editor thingy...
Which features do you need the most in QME and which the least? I'm not planning on putting any vertex manipulation stuff in my editor and was planning on keeping it purely for skin mapping and moving frames around (copying, deleting, naming...). I'd add;
editing model flags (blood etc) skin import + export (for convenience) direct fbx import Not fucking the verticies on resave asset library (see all models in folder)(wishlist) Not limited to qme features... What I've just written there will most likely destroy your sanity if done, but I make no apologies :) Adding/replacing skins
- I often have multiple skins on objects - Noesis does not support multiple skins which is frustrating Setting up animation groups - extremely useful for debugging models afterward Adding frames - via CAD files! I would love to be able to import frames easily. At the moment I export to FBX from LW, use Noesis to convert to MDL, open in QME and export the model to CAD and then open my base MDL and import all the CAD frames together. I would use preach importer but it does not work with the files exported from LW. I am stuck with : FBX->MDL->CAD->MDL process. Hey Sock, is the breakdown that you can export to MD3 from LW but the converter refuses to handle it? If so, e-mail me an example MD3 and I'll try to fix the converter.
Have you told the Noesis author about the multiple skins issue? He is nice and often super quick to fix things.
I keep forgetting to ask for error messages.
It just fails silently, which is a kick in the balls. And yeah, I do the same exporter dance to get something into the engine. Haven't tried your exporter Preach, will give it a go. The LW MD3 exporter is not up to date and I can't load it with the version I am using. This is the biggest problem with any modelling package, once a new version comes out all the user made exporters break. The MD3 format is so old that no one is supporting it anymore.
I use FBX because LW maintains the exporter and it works flawlessly and even all the skin UV co-ordinates are correct. If I could merge a series of FBX files into a MDL it would be pure heaven for me! I would need to check if the FBX format keeps the triangle/verts the same but in theory it should. I also don't need to keep triangulating my model every time I export but if I could merge FBX files together I would gladly triangulate my exported files. @preach, I know you use MD3 format but I can't get all my frames to merge into one MD3 files. This is why I have a huge directory of CAD files and luckily QME does directory frame loading, another cool feature. I know why you use MD3 format but I can't use it, hence my crazy conversion process. @preach, I would still need to go into QME because of the multiple skins, your converter program only supports one skin and in a strange PCX format that even PS has trouble exporting too. Don't get me wrong, the converter you wrote is cool, but it can't help at the moment. @spirit, there are tons of user interface issues with Noesis, but I doubt the creator is going to do much with the interface. * Can't select/display multiple skins on models * Can't goto certain animation frames, only got fast forward and reverse. * Each time I export the interface resets, it should remember each export file settings or allow a template/default to be setup. * I would love to export a batch of files but the command lines dialogue box does not work for me. When I specify parameters it ignores some of them, eventually I gave up trying because it did not make any sense. Sadly the model format/process for Quake is still a nightmare and is top of my list of things that drive me nuts about modding for Quake. I sometimes wonder why I fight so much to get models into Quake, but when I finally do get them loading in Quake it feels awesome! @spirit, One other thing, if the author of Noesis had a donate button on his site I would gladly give him money! His convertor program is amazing, I would have not had created so many models for my MOD if Noesis did not exist.
@ijed, also big thank you for letting me know about Noesis in the first place, it did make a big difference to the creation of my MOD. Noesis goodness: FBX->MDL (perfect for static models) MDL->OBJ (How I import into LW) FBX details: http://en.wikipedia.org/wiki/FBX Supported by Max, Blender, LW, Maya I use FBX as well, it's about as close to a universal format as you can get, apart from
Hey sock, I've managed to convert a FBX to MDL via MD3 using NOESIS. Can you send me a FBX which won't convert so I can take a look?
Noesis will convert all of my FBX files to MD3 but how would I merge several MD3 files into one MDL file? I thinking about animations, I store all frames separately at the moment. I remember you used GMAX to export a MD3 with multiple frames, I am missing that stage at the moment.
Does your convertor cope with multiple skins in BMP/PCX format? If I can avoid using QME for skins and model parameters that would be awesome. Also I don't mind using dos command line stuff to use your convertor, I can create batch files to supply parameters if necessary. To add extra skins and set flags and rename things, I have another tool:
http://tomeofpreach.wordpress.com/qmdl/ You basically write a little python script and run it on your model. The example script from http://tomeofpreach.wordpress.com/2012/11/24/a-modelling-pipeline/ is hopefully easy to adapt for that kind of housekeeping. And yeah, what you really need is a fbx file which contains the whole animation sequence at once (it's possible in general, don't know how LW copes). Then again the qmdl module could take a bunch of I exported every animation frame in Gmax as a *.mdl file (218x), loaded every single mdl file in QMLE and exported the *.dxf, then imported all dxf files from the first animated frame of the framegroup.
Then I had all frames in one mdl file. Don't think it is the usually way, but the reason I feel like a madfox. Before I can use the tools of Gmax for the purpose I need ( combining all animation frames in one model) I first need to start making simple models for it, or RTFM. Madfox I'm about to cry.
1. Download http://www.quaketastic.com/upload/files/tools/windows/madfox-care-package.zip 2. Extract the whole thing to a directory 3. Export your model from gmax as an MD3, making sure that when you see this screen: http://www.katsbits.com/images/tutorials/gmax-export-import/exporting-models-from-gmax-to-md3.jpg you type "0-217" in the "Following Frames" box 4. Rename the md3 to "model.md3" and put it in the directory all the other files are in 5. Run the "model.bat" batch file in that directory One Thanks for your concern, Preach!
I forgot the 0-217, just entered 217 which is the reason for my oneframe attempt. Good hint, It spares a lot of time! But I think there is something else I overlooked. #494 state for the unwrapUVW in Gmax is a mystery to me. I merged the v_launch.mdl into the Orb.md3. When I try to add this skin to the UVMmap and I select the legs there is no head in the skin file. Other way selecting the head and using the unwrapUVW to add the launcher vertices then the leg skin is gone. I can't join the parts together. The batchfile is fantastic, works great. Only QMLE crashes on the pcx file, as qmdl92b does. For now I'd just add the skin as a separate step, rather than try and make the batch file do that part of the work, import and replacing using QME is the easiest way.
For your problem with the missing segments on the skin, you might need to join the different segments of the model into a single gmax object. To do this, before you apply the uvw unwrap modifier, select one of the segments, then look for the button on the mesh edit control marked "Attach"(it's in the "Edit Geometry" part). Click it, then click the other parts of the model in the 3D view. You should now see all three parts appear when you apply the uvw modifier. You might also find that some or all of the animation disappears if you do this. Either way, post back if the first bit works, at least it'll be some progress... Spirit just linked me to this thread. I'm the author of Noesis. Hi!
@sock, it imports multiple skins, but doesn't export at the moment. I can give you a commandline switch or something to import additional skin pages to stuff into the mdl export, if that's what you're looking for. Noesis also supports concatenating skeletal animations via commandline, but the only path for doing that sort of thing with vertex anims involves having to export to a modeling suite first. I can stick that on the todo as well. As for your interface issues: "Can't select/display multiple skins on models" - You can - Tools->Data viewer->Model #, then select the textures in the model to display them. "Can't goto certain animation frames, only got fast forward and reverse." - You can do this too. Newer versions of Noesis have an animation slider, but just like textures as well, you can select them in the data viewer to display them. "Each time I export the interface resets, it should remember each export file settings or allow a template/default to be setup." - If you want to do repeated exports with the same setup, I recommend the commandline using ?cmode. See the readme.txt for details on using console mode. "I would love to export a batch of files but the command lines dialogue box does not work for me. When I specify parameters it ignores some of them, eventually I gave up trying because it did not make any sense." - I'm not sure what's going wrong for you here, I use commandline mode all the time. Can you give me the commandline you're trying to use, and the data you're trying to use it with? Also, the Noesis page doesn't have a donate link, but my personal web site does. :) http://www.richwhitehouse.com/index.php?content=inc_about.php @ijed, Noesis will generally spit errors out when something goes wrong. If it isn't, something's gone really wrong. Can you send me the files you're working with and tell me what you're doing to make Noesis fail silently? You can both send stuff as needed to the e-mail on the contact link. (from the richwhitehouse.com link above) @Rich, hey thanks for registering here.
it imports multiple skins, but doesn't export at the moment. I often have models with multiple skins, at the moment I use another package to add them. Tools->Data viewer->Model # That certainly shows me the multiple skins in the MDL file but I want to see them on the model. This simple displays them as flat textures in the view window. Newer versions of Noesis have an animation slider That would be extremely handy, as often I want to check certain frames with different skins. I don't suppose you could add a loop function (frame X->Y) for the play? Can you give me the command line you're trying to use, and the data you're trying to use it with? I will have to go back and try the again. I did spent a long time trying to working out what each command line parameter did, but found it frustrating because I wanted to automate converting 50+ models at once and the command line seem to only work through the export window. the Noesis page doesn't have a donate link I will sort out a donation this week. Amazing program, it has saved me loads of time trying to get models into Quake 1. We've talked before - I was having the problem with the Q1/BMP format that time.
This time it was a mis-applied texture from 3dsMax. Basically the material wasn't applied properly, so when importing the FBX it looked fine, but then exporting to IQM caused the UVs/texture to be removed. Unfortunately I've since fixed it so don't have a decent repro case to show. I'll be more precise and sure to send you bugs as they surface :) You can use iamthedick at gmail dot com. Feel free to send stuff along whenever you run into anything that isn't working right.
@sock, if you want to apply the texture to the model in the preview, you can go to Model #->Meshes->Mesh #->Material index. Double-click that to modify it to the value of the material you want. You can also go to Model #->Materials->Material # and modify the texture index for the material instead, if you'd like. I can look into multi-select functionality or something for the data viewer to allow you to loop arbitrary frame sets. Feel free to send along your batch export content/commandline to my e-mail whenever you get a chance, too. Thanks a lot for the donation. I'm presently seeking a new job and am close to broke, so everything helps. :) I tried all I could to attach the the grenade launcher to the other three modelparts but they won't collect to one model.
For some reason I can't follow the button traject and end up with a skinfile of 784x240. If I select an object I can't find the Attach button. Quake1 Orb http://tomeofpreach.files.wordpress.com/2013/01/attach.png
Take a look at this. If this doesn't work Tell me what you see instead of "editable mesh" http://tomeofpreach.files.wordpress.com/2013/01/attach.png
Take a look at this. If this doesn't work Tell me what you see instead of "editable mesh" What happens if you right click the legs and do "convert to editable mesh"? This ought to let you attach it, but it might damage the animation.
Yes, it freezes animation.
As far I can go is wondering how I got the skinfile of the rocketlauncher into the three other ones. First the eye got damaged, then I followed necro's hint of moving the mesh in Quark47. Only thing I couldn't avoid is the 782x240 size. A bit torned up I decided to reinvent the rocketlauncher and made it out of a flat basefile. Doesn't help much as I don't understand how to get a half sized UVW map out of them, just like the Q3 models. How do they do it? You can use entirely separate skins for different parts of models in Q3, it's not really comparable to Q1, where everything has to be on one skin.
I retraced the grenadelauncher from a flat vertice mesh in the hope it would get the UVWrappers attention.
Doesn't make a lot difference in detail though. And gmax handels it as a sepperate file so I have to search on. Thanks for the reply though! I wondered, is it possible to place the verts behind eachother, sparing skinsize? v_launch I wondered, is it possible to place the verts behind eachother, sparing skinsize?
Should be (it's common practice), unless Quake has some funky limitation. Are typically generated by Qme, which does back/front mapping without any controls for stacking or packing the UVs.
Not sure what the original models were made it, but they set the precedent. Yes, the quake model format does support this, but like ijed says, the main editor that handles
http://tomeofpreach.wordpress.com/2012/12/20/dome/ While I'm throwing out links to my blog... http://tomeofpreach.wordpress.com/2012/11/24/a-modelling-pipeline/ ijed et al, what is the preferred format to export uvw maps?
3dsmax's is a binary format and I guess proprietary... :\ that wouldn't be much fun to decode... @spiney - I placed the verts behind eachother and it worked. First skinsize had 194x220 and this one gets 184x195 smaller.
Three objects won't layer I suppose as one gets stick in the middle. @preach - I managed to get the object attached in Gmax now. And it also collides exact to the torso, more than I could animate myself. Only bad point is that the attached model don't want to export. It keeps asking about modifiers. I honestly don't know - I just export to whichever format works. I prefer not to use proprietary formats since it just closes doors on collaboration. And you never know when they'll change the format.
I know that the However it doesn't support animation, so typically I use FBX, which supports everything and is well supported and stable. It seems popular with everyone here as well. As to what UVW format it uses internally... IDK sorry. Let me know if you need any testing done. I also have another request... IQM format. Skeletal as opposed to vertex animation just looks better. Strangely enough was only implemented in the 4th version of MDL / idtech as well. You can get dev kits from Autodesk for the format, just need to plug the code into your codebase and it should work.
http://usa.autodesk.com/adsk/servlet/index?siteID=123112&id=7478532 Also FBX is not limited to triangles, you can store stuff in quads which is a lot easier for modelling when everything is not a huge mess of triangles. oh so you guys import UVs by importing a whole model then? ok, that works too.
I already have OBJ and FBX is plain text too, so not too bad to figure out how to deal with it. I know sock has trouble with OBJ in lightwave so it's probably a good idea to get FBX in anyway. Is IQM plain text? I doubt I will touch skeletal modelling, at least for a while. there's a lot of new stuff to take into account there. It's binary. Here's the site: http://lee.fov120.com/iqm/
But yeah, probably something for (current version + 1). An inherent flaw in how Quake treats animation I was fighting with the last night.
Having all the animation lumped together is a big cause of the dodgy frames issue. You know the one, where the animation continues fine but at the end or start of the loop one additional frame makes the monster (or whatever) pop into some unwanted pose. Qme had fairly good tools for naming and ordering the frames, and hunting down errant ones. 3dsMax at least doesn't have anything, so I end up counting the frames manually. Having said that, there probably is a plugin somewhere... I can export the model from Gmax to md3 and Noesis can convert it to a mdl. An mdl file in Noesid exported to md3 Gmax won't capture.
So far so good. There is only the thing of attaching the launcher to the model. When I import the launch.dxf and try to attach it to the legs my animation gets lost. Whwn I attach it to the torso, the uvw file also gets attached to the torsos-kin and ends up in a distorted skinfile I can scale this part th fit into the already excisting skinfile, but the loss of texture also scrambles the launcher Also think I had to skip some double objects while exporting as the vert/tris count gets much too high. So it is a case of a proper attachement of the launcher to the original file without the loss of the uvw skinfile. I tried the othe way around by just merging the launcher.mdl into the converted md3 model in QMLE. That way I also get a skinfile, but at least the proportions are in a usable manner I loose all my animation so I have to stretch 218 launchers to make the file fit. Didn't expect it to be such a hussle! Don't do that! Once you've correctly organised your UVs on the rocket launcher, delete all the non-rocket-launcher parts from than object, and import the rest of the model as a new object. You can export multiple objects to the same md3 file, so there's no need for them to be combined any more.
I come sofar, every attempt to attach it will scramble the skinfile of the corresponding file.
http://members.home.nl/gimli/norb.jpg Having all the animation lumped together is a big cause of the dodgy frames issue. You know the one, where the animation continues fine but at the end or start of the loop one additional frame makes the monster (or whatever) pop into some unwanted pose.
Qme had fairly good tools for naming and ordering the frames, and hunting down errant ones. Yeah, that's annoying. When I was making the models for Sock, I would have to manually go into the model and rename frames each time otherwise he had no way of knowing what was what. Ideally, I'd like to eliminate that. My original intent was to import seperate OBJs as 1 frame each. This lets you name files and give the frames names inside the model. FBX looks like it's more geared toward storing a whole animation in one file though. Yeah, I guess I can see how it's not ideal either.
All the monsters in Quoth were exported manually frame by frame... that was painful. With Sock's monsters, I wrote some maxscripts for myself that automates everything but I can appreciate that it's not always an option if you don't know how or your 3d package doesn't have scripting. I just don't see a solution outside of individual files per frame. I'm glad I have Gmax as my version of max3d 4.1 won't help me out with this skin problem. Forcing the torso part to attach the launcher distorted the skin file. Then I realized I could use the material editor to add the launcher skin again.
idle Thanks Preach, I really would have added the launcher animation manual, but the way it now collides is perfekt! While playing I wondered.., the rocketlauncher has three puffpipes.
In game the player sees them in front, so it looks as if the launcher is turned back. The v_model shows it with the pipes behind. Is it mirrored or am I shooting with the wrong way out? who shoot's who
fn export3DSFrames path name start end prefix =
( counter = 1; for i = start to end do ( sliderTime = i; ExportFile (path + prefix + "_" + name + counter + ".3ds") #noPrompt selectedonly:true; counter += 1; ) sleep 0.1; ) here's the function I use to export a single sequence. "path" string to specify output folder "name" string for animation name "start/end" these are frame numbers in max "prefix" can be anything, i give it a number starting at 0 and increment for each additional sequence. it's to preserve the order of the sequences in windows so when I import them all in a batch, the order is still correct. then I call it like this: export3DSFrames workingDir "stand" 2 13 count; count += 1; export3DSFrames workingDir "walk" 539 552 count; count += 1; etc... from a different script that is specifically for a monster. you can add in extra stuff like a switch to choose from different variations of a monster so that it automatically enables/disables layers or adds/removes bits from the mesh like for example removing shoulder armor or adding horns... maxscript is annoying to learn but it is extremely useful. :) Here's a work-in-progress python script for importing that kind of fbx batch of frames into a mdl file.
http://tomeofpreach.wordpress.com/2013/01/31/work-in-progress-fbxtomdl-script/ Anyone who's good with python know what the easiest way to handle installing libraries your script depends on? The set-up needed for this script is a barrier to use... If the script in the last post was a bit too much, then give the standalone package a try:
http://tomeofpreach.wordpress.com/2013/02/03/standalone-fbxtomdl/ It's got command line switches and everything! Plasmagun ground and view model drop-in replacement for Quoth (put
screenshot download more info and pictures Your shotgun and triple barrel version look really good, any plans to release them like the plasma rifle? Do you plan to make the double barrel in between?
Would be really nice upgrade path, 1->2->3 barrels. Actually, on the topic of both weaker weapons and base style things, I reckon a player version of the enforcer blaster would be another good "low-powered" weapon to give to players in the early stages of a base map. If it used one cell to fire exactly what the enforcer puts out (a pair of shots at 15 damage each) it would be on par with the thunderbolt on damage per unit of ammo. Firing a two shot burst would differentiate it from other weapons, and it would let players use cells from enforcers early, without giving them the lightning gun.
The weapon models are nice - but this looks absolutely incredible:
http://imgur.com/a/cMad2/#0 What is it? How did you make it? Single shotgun is in the zip, tripple uhmm still need to make a quake-quality skin and reloading anims, which is painfull with no proper preview (I spent 2 hrs repositioning the model and reloading quake just to get plasmagun look ok), next week mayhaps.
DBS you already have in the game and can find replacement models if you want a better looking one. The tentacle mess is made with splines. Its a world of Nyarlathotep, the Crawling Chaos. Quick tip for previewing and updating models. Run quake in a window, then use the flush command in the console to reload the models from disk. That way you can make a change, save it, and get it to appear in-game instantly.
One of the better received models I made on my old site was the waterfall, but it never made it onto the new one. The reason was that I actually wanted to redo the whole thing, and version two is finally done.
http://tomeofpreach.wordpress.com/2013/03/30/waterfall/ I was actually hoping to release this in a pair with a related model, but that one still doesn't look right so it's being held back. Anyway, this one ought to be nice and handy on its own. So a little break from all these coding posts. A few days ago I took the skip/detail window trick which I posted here and wrote it up for my blog. No new content, just a extra diagram, and a hint that you needed some visual cues to make a window like that work.
Well, that was a precursor to the next few models I'm gonna post, which are all attempts to highlight a window in quake, in such a way that it doesn't require alpha support (although often the models will be enhanced by alpha support in engines). Today is an example of a progressive enhancement model: http://tomeofpreach.wordpress.com/2013/04/09/glass-panes/ There's a couple of screenshots, one with and one without alpha. Hopefully the one without looks passable by winquake standards, and the nicer one from fitzquake sells the model. If you worry that the window still isn't yet well-defined enough, there will be more models to come very soon... I'm fairly sure that you can stop all waving effects in most engines these days, couple this with transparency and you could probably get a decent effect going with a nice texture (rather than use a solid colour to mask the fact that it's a water volume), quoth even allows you to run the correct cvar's on map load.
It's interesting that you can now make glass without adding entities to the map.
I have some cool tricks in my new map that are kind of neat and made possible with skip (but nothing cool with detail yet...) Well, you can use the water trick, if you don't mind your glass having no pattern (you disguise the ripple effect by having a flat texture), and imposing the same wateralpha value on all your lava and slime. But that's kind of beside the point of the challenge, like saying you can make 100-brush maps bigger by just adding some more :-p
The models are still nice as a compliment to more conventional windows. If you add a translucent brush which removes itself from engines without the alpha checkextension value you get this effect: http://tomeofpreach.files.wordpress.com/2013/04/panes3.jpg Then in engines which support alpha but don't report it you get: http://tomeofpreach.files.wordpress.com/2013/04/panes2.jpg and in engines with no alpha you get: http://tomeofpreach.files.wordpress.com/2013/04/panes.jpg which is quite a nice progression from getting the most from fully-featured engines, while staying functional everywhere. In keeping with this, today's models are some decals to apply to windows. http://tomeofpreach.wordpress.com/2013/04/10/decals/ The models received some last minute tweaks so that they play well with a semi-transparent brush behind them. I'm sure there is a command variable to turn off the water ripple effect completely (animation and all)... Maybe I was mistaken?
it's r_waterwarp 0 in fitz (most engines?)
Doesn't turn off the texture ripple effect though, if that's what you are talking about. The glass trick I used requires a plain texture in order to make sure that the ripple is not noticeable. The polygon distortion effect that is used by glquake and some other engines still affects maps using the glass trick unless the effect is disabled. Bringing back some old idea of breaking-the-grid for textures. I know RMQe does it for the waterwarp...
http://img194.imageshack.us/img194/7909/dudvdetail.png http://img835.imageshack.us/img835/4481/dudvdetail2.png Anyone know if it can be done in some Quake engine. I don't know how to code so... :'C (i also wonder if using a custom dudv map on bilinear could give you the equivalent of bicubic filtering)
but does it work on 64x64 textures? those examples are quite high resolution. (relative to quake anyway)
You do have have a point with that.
Resolution doesn't really matter, but might not be appropriate for all kinds of textures, it's all about getting rid of the perfect squares by distorting with a higher res dudv map. You can have the detail texture roughly correspond to 1px boundaries (glorified dithering scheme?), but I found it tends to look better when using 2*2 blocks since with 1 px there's still some leftover blockyness. You lose some of the definition of the original that way though. I'm not sure if Quake textures are a good candidate for this since the textures tend to have very defined features. It's just about getting a less perfect cg look, something more tailored to NPR probably. Could be interesting for something like Rage to obscure some compression artifacts maybe. Those images are just done with Photoshop's glass filter by the way, just to illustrate the point. I actually like the 'perfect squares'. I always play with nearest neighbour now, so this is definitely a 'to taste' thing.
I can remember there was this fat round bimbo in Shrak, that used deathframes with the transparant colour.
It was a very strange apearance of splitting open from the centre to expand the little side it had in the middle with that colour. In game it looked as if the monster exploded, but in the last instance it just disapeared fading in the background. Can anyone rember this, or is it just me making it up? About time for another model I think. I knocked this whole thing up today, so it's not that complex or in-depth. It's a monitor for a base themed map with a nice wave animation on the screen.
http://tomeofpreach.wordpress.com/2013/06/16/oscillator-screen/ all your models were bundled into something like Quoth for ease of use. It would be nice for some maps to use them :)
The thought had crossed my mind. I hesitate though, because once they get added to the pak they're difficult to update. Coming up with another skin or adding extra animations is possible, but you need another patch and the old files lurk about. The waterfall is an obvious candidate for mappers to customise with a skin to fit their map - and having a standard model might discourage that in favour of making-do with the stock skins.
It gets worse if a model has a problem like a badly placed origin - as you usually can't fix that in a backwards compatible way. Seeing the models in use would allay some fears, not just these technical worries but also how useful the models are. Of course, now we are back where we started... I will admit that lots of the models would benefit from a combined code-and-model solution, which is the kind of thing that Quoth is meat to deliver. Maybe in the short term the interesting models could be deployed in the pak, to be revisited in a later patch. to my point I'm fairly sure that Quoth also has the ability to deploy any model for use as a decorative mesh along with any particular key frame...
I think my fanboyism for Quoth is showing through (though I haven't made a map specifically for it yet I probably will soon). I decided to make a follow-up model to the oscilloscope about an hour ago. Here's the result:
http://tomeofpreach.wordpress.com/2013/06/29/levels-monitor/ Essentially it's the same monitor model with a different animation on the front. Still, it's a nice complement to the oscilloscope - a lone animated screen might stand out as too weird. If anyone has any other suggestions for screens that would be easy to animate only using polygons then post 'em so I can take a look at making them. the sefiroth tree.
http://upload.wikimedia.org/wikipedia/commons/4/44/Tree_of_Life_(Sephiroth).svg somehow animated... Just wiped out a post with ideas.
As I was saying... I made some screen textures like this but the animation quality suffered thanks to the frame limit. So here's some ideas; Mathematical graphs that update in real time. Concentric c shapes that rotate. A 3d plane that's displayed on a 2d screen. Star field windows screen saver. Real time render of a vat filling / emptying. Particles moving through a schematic of pipes. Just wiped out a post with ideas.
As I was saying... I made some screen textures like this but the animation quality suffered thanks to the frame limit. So here's some ideas; Mathematical graphs that update in real time. Concentric c shapes that rotate. A 3d plane that's displayed on a 2d screen. Star field windows screen saver. Real time render of a vat filling / emptying. Particles moving through a schematic of pipes. Also, I'm already using a few of your meshes in an upcoming map, including the oscillator screen, so more screen is good for me :)
And I know it's a bit cheeky but I don't suppose you've got any hanging or wall climbing vines? The level is a rubicon thing so plays heavily on red and green. Can't wait dude, let me know if I can provide cumbersome testing.
How far along do you think? Yes, I do have a vine model, it was up on my old site before that died. I'd been thinking about revisiting it with more poses and maybe multiple vines per model. It seems silly to hold it back over nebulous plans like that when it would be useful immediately, so here's the post:
http://tomeofpreach.wordpress.com/2013/06/29/vines Ooh, another question. I try to tag the tech related models on the blog with "base", so you can use the tags to filter for the kinds of model that suit your map. What would be a good tag for things like: http://tomeofpreach.wordpress.com/2012/11/21/oval-window/ "Medieval" kind of works, but lots of things would equally suit elder-world maps, or even other non-base themes like runic metal. "Fantasy" seems a bit airy and inapt. Can anyone suggest a descriptive, punchy tag to include all quake maps which don't have a base setting? I suppose that at least maps to the existing classification system of maps - which kind of keys they have!
any key ranging from used textures (cr8), to like say puzzle, as the 768 map by negke.
quaddicted has lots of tags. They're exactly what I was looking for.
In terms of tags, I think themes is good. Whilst some things do share, we all know what 'base' is. Elder is a bit more loose, but we all know more or less what belongs there. And tags are tags, as mentioned :) Oh, and if anyone tried to download the vines but found the link was broken, it is now fixed.
I was impressed by Preach's monitor.
In fact so much I reframed it and made it a three channel one. The vertcount is not the same and this one has a larger resolution. The simplicity of the verts changing is fun to see. http://members.home.nl/gimli/oscill1.zip I also made the Star field windows screen saver based on Ijed id. But then I realized the max frames for animated texture is much lower than what I had in mind. I thought it was 24 frames. Cool stuff, MadFox! It made me think a bit of those old Doctor Who serials where the evil computer would be giving a voiceover, and you'd see a monitor with sound waves syncing up with the audio. If you had a map with an evil, omnipresent machine like Shodan or GLaDOS, you could probably connect that model with all the different animation patterns to go with the audio.
As for the starfield, I think it's another one best done with animated polygons instead. I think I can see how to do it now, gonna take a shot... At the time I was also thinking of a game of solitaire - even the quake base monsters like to slack off now and again.
I made a flipcard animation to see how much frames related to the skinfile could be worthwhile. A slide of seven frames that switch after eachother.
I could make more frames, but then the resolution of the skinn becomes smaller. For simple forms it works, but anims like a surveillance camera it is lame. The winscreensaver monitor I expanded several spots before a screen and flattened them. Maybe a bit too small for viewing. http://members.home.nl/gimli/winscrn.zip :P Here's another shot at the starfield:
http://tomeofpreach.wordpress.com/2013/07/05/starfield-screen/ I spent ages trying to get round an awkward gmax issue. If you mirror an object, then the vertices end up in clockwise order rather than anticlockwise, and so the triangles on that object came out backwards in the model. Also I finally added the mushrooms from December to the blog, but I'd already posted them here, so nothing new... Does it have the reset xform option?
In the latest versions it appears as both a utility and a modifier. Not 100% that it'd fix the issue you mention though. Thanks for the starfield :) The shrooms I requested a while ago for my RMQ map where the player gets poisoned by spores and has to stagger around drunk... i really like how you're building animations with polygons like that. gives much better results than animated skins!
mfx: The mushroom can be found in the model archive, or on the front page for the next few days.
ijed: I don't have a backup version to test reset xform on, but thanks for the tip - I'll give it a shot next time. necros: Yeah, although the interpolation you get in modern engines is a double edged sword. It makes nicer visuals, but you can introduce glitches if you aren't careful. On the starfield it was important to keep the stars at 0% scale when they move from the edge of the screen back to the centre. Otherwise interpolation would give away the magic trick; you'd get away with it on simpler engines. I may be taking it too far though, I was planning how to make an LCD digit display using just polygons. That's probably much better done as a sprite instead, no interpolation needed or wanted. So yeah, maybe time to take a break from all this base-tech content and make something other-worldly... does gmax have maxscript? cause it could probably be done with a bit of scripting and some funky rigging.
Yeah, there's maxscript. The way I'd do it is model a plane with each lcd segment carved into it. Then inset a duplicate polygon into each segment. You can then scale this inner copy to 100% when the light is on, or 0% when it's off. It's just that's a lot of fuss and a lot of polygons to create something that appears to switch from on to off. A sprite would be 2 triangles, and actually switches on and off instantly, which might be more appropriate.
Last time I posted about QME I included a teaser of a model, and I am aware I still haven't delivered on it. I'm gonna post a teaser for another model today, but I have a three-step plan for making it up to you guys:
Step 1: post the teaser along with a useful article on palette swapping your skins. Step 2: release the newly teased model just as soon as a few more skins are done Step 3 will be coming a bit later... Here's the article and teaser: http://tomeofpreach.wordpress.com/2013/07/13/palette-swapping-with-qme/ So as teased, here is the button model:
http://tomeofpreach.wordpress.com/2013/07/17/button/ It's a attempt to do the kinds of tricks seen on the monitor models, but in a way that non-base maps can use instead. I have a much more esoteric model which also satisfies that goal, I just need to resurrect it a bit... It would have been great to add an extra layer, but changing normals don't have any effect on fullbright pixels as they don't have any shading you can change! A variant model which uses different colours on the Q would benefit though, and it would be pretty easy to script because the vertices you want to affect are easily located on the skin...
Wow that is really nice, I am glad to see you do some medieval themed models. The only thing that bothers me is the light pattern on the buttons, I would prefer it to glow, the rotating feels odd because the button front lacks depth.
The same method could be used for cracks with fire in them, for a trippy dimensional rip effect.
Sock: Yeah, I was trying to go with two different animations to convey the different states - the back-and-forth pulsing animation is meant to be saying "I'm tapping my foot here - shoot me!", while the rotating animation says "I'm doing some work right now, try later". If you don't like the rotation then the pulsing animation should hold up by itself. If you do need a version which lets you switch between two different coloured pulsing effects, I could probably knock that up pretty quick...
Ive once played a map/mod/game containing ogres with nail-shotguns + nice sprite-based animated explosions, any idea what mod is that? thanks
The problem with your three state button is that players assume it works like a light switch, it is either on or off. Having a third state is just confusing because the buttons in quake are two state devices. I can certainly understand the frustration of wanting to show more visual information but the states really do have to be different. A glow or rotate effect are too similar and will be lost on most people.
I do like the design of the Q on the front panel, it look cool. :) I especially like the bottom two versions on your page where the Q is linked to seam edges across the front surface. would probably best be visualized with a lever, because you can immediately see that it has more than two states if touching it only moves it to the middle.
If you want to communicate that the button is unavailable for a certain time after it has been pressed, you should also keep it in the depressed state until it is available again. That is pretty clear I would think. Unpowered is a state that you don't get in standard quake, yeah. I think the tristates would be more understandable in practice though, because you'd see a reaction (or not). The unpowered button would be inert until some external force turns it on, it doesn't move when you press it (you might need a text message when they try to push it like "Looks like you need to activate this first...").
Once it's been switched on, the brighter colour and animation should attract your attention back to it, and now it just works like any other quake button. You'd learn what the final colour mean by using it, the colour at the same time that the button moves - in response to the player using it. It then returns to the middle colour once it has moved back out, which is a convention players already recognise. If you were using it as a direct substitute for quake buttons you'd probably just choose two of the frames you like and swap between them, so you might go with unpowered and ready (a la "+1mtlsw" buttons) or ready and activated (a la "+1base" but in medieval). That stuff about the animations was more thought-process waffle than actual expectation of how the player would understand the visuals.... If you only need two colours, you can also use the combination of "unpowered" and "activated" - the interpolation between them will not pass through the colour inbetween. Then again at that point you might also just edit the skin, and get the more preferable pulse animation. I said I was going to make up for teasing with models I hadn't released in three parts. Here's part 3: get you guys to finish the model instead! Kinda...
I teased a model of a torn poster a while ago: http://tomeofpreach.files.wordpress.com/2012/12/qme-pal.png One of the reasons I haven't released this model is that I'd like to have a good selection of skins to go with it - it's a pretty flexible model with lots of scope, and once you've released it you've missed the chance to add more. Also, my skins aren't always the best part of the models. So I thought I'd try an experiment today, see if I get a response. I'm gonna link the model here on func_ but not put it on the blog just yet. If you want to play around with the model and try making your own poster, dive in and grab it. If you make a skin you'd like to offer for the final release, then please e-mail it to me. http://www.quaketastic.com/upload/files/models/poster-prerelease.zip Few quick notes: The model comes with two frames, the torn pose pictured above, and the plain poster below: http://tomeofpreach.files.wordpress.com/2013/07/mutation.png It is possible to create a skin which works for both poses, but don't feel obliged to, creating a dedicated clean/torn skin often works better. The top 2/3 of the skin is taken up by the front of the poster, and the back of the poster takes up the remainder, rotated 90 degrees. The backside of the poster is there because this model is part of the window-kit pack, you can paste it on an invisible window to give it some presence, like in "tangerine dream". The first skin on the model is a bit bright and weird, but there's a good reason. It's been painted with the colour of the player's trousers. This lets you use the trick from http://tomeofpreach.wordpress.com/2013/07/13/palette-swapping-with-qme/ to quickly create a base texture with the colours from any palette row. Don't feel obliged to use my template though, in fact wildly different skins are what this is all about. Mine have a tech lab/base feel but if you can create some lovely medieval wanted posters, or elder runes on human skin, more power to you! I love that poster model. I was going to have a torn poster secret ala Duke 3D on my base map but I decided 7 secrets was enough (plus I will probably revisit the homage at some point)
https://www.dropbox.com/s/925h5udfr0xxmvb/ijed_posters.zip
Lovecraft Biohazard Explosive Tin Tin Flat Earth Prodigy Quake Each has a _torn version. It's possible that fullbrights will rear their ugly head on a couple since I haven't tried them out in engine yet - I tried to avoid this issue but it might have got past me. I'd suggest including a 'on floor' frame and possibly a 'big' one as well. Awesome man, just what I was after. I've added them to the build, and there weren't any problems shaking the last few fullbrights out. I've got a few more ideas for skins off the back of those, so I'll try not to take too long getting them together.
When you say a pose for on the floor, are you thinking one where the page doesn't curl off the floor? If it wasn't for that I'd see no problem with just rotating it to rest on the ground. Larger sizes would be fairly easy to do, and I also want to create a few more frames with variations on the torn poster. That way you could have two or three torn ones on the same wall and not make it too obvious. While I get working on that, I've got another model coming out soon. Was about to post it but last minute fixes need doing, so hopefully tonight... Nice one madfox, that looks ace, didn't see it when I posted last. The more I check it out the more detail I find, like all the modeled rivets and the threading on the copper-coloured bit.
That is very cool MadFox, I like how you got the rotation of the wheels working correctly. My only concern is the baked shadows on the wheels and the background not integrating with the wheel positions but that is a skin issue not animation.
Glad you like them, they were quite fun to do as well.
Is there a way you could make the torn parts out of ploys instead of a modified skin? That would make it much quicker and cheaper to have more variation although it could get a bit more angular looking. For the floor pose yeah I just meant rotated flat on the floor- I was actually thinking of dropped vox populi posters in bioshock (a poster that didn't make the cut actually, along with 'a man chooses, a slave obeys'). Madfox cogs - those are awesome. It's great linking buttons to their doors, it gives a level a physical presence and a visual clue to how it works. In base maps you can just put a cable in. But medieval maps are trickier since its always machinery. I printed the original tex on the wkey02 model, and in that way the shaded origin produces the odd behaviour.
I tried a slightly larger texture and kept on the vertice lines, but the skinfile needs a rather irratic treatment. I'v spent some time on it but how more I try how more dazzeled I get. For some reason I ain't have the patience for the texturing, while I know it can result in great outcome. Another weird model today. Like the buttons it's part of the "more medieval models" effort; in this case it takes a previous base-style model, the forcefield, and creates a mystical version.
http://tomeofpreach.wordpress.com/2013/07/26/runic-barrier/ The screenshot doesn't really do the model justice, as it's all about the animation. However, the animation itself is too long to make a gif for... Another post from Preach, this time not a model but a tool update. It's v0.2 of the python module qmdl.
http://tomeofpreach.wordpress.com/qmdl/ There are some little tweaks to the mdl module, proper docstrings and breaking up a few methods to be more reusable. The biggest change is the addition of a "helper" object which disguises some of the complexity of working with the module. An example script which adds skins to the model would look like: from qmdl.helper import Helper poster = Helper() poster.load ("poster.mdl") poster.append_skin ("tintin.bmp") poster.save() It's basically something that's accreted from using the module for a while; I kept copy-pasting these functions into every file, then realised I needed to fix a bug in all of them and it was time to make a module... By starting an article in July and finishing it on August 1st, the article gets a publication date of 1st July!
http://tomeofpreach.wordpress.com/2013/07/01/skin-maps-for-mdl-format/ Oh, yeah, the article. This is a little history of how skin maps for Really enjoyed this one preach, I plan on making some custom quake models so this info will be of great help!
If only I could get my brain around coding... I've asked for this before, but my previous version got broken and I lost the backup.
I can't install Qme 3.1 (.mdo support) on my 64 bit system - can someone zip their already installed version and upload it somewhere? Sock sent me his version, here's a link to it for anyone else who want s a copy (from my dropbox):
https://www.dropbox.com/s/l9d1t3p81q3v4yb/q1qme_3xdirectory.zip Yeah, the long awaited poster model is finally released properly:
http://tomeofpreach.wordpress.com/2013/08/10/poster/ Thanks to Ijed for contributing all those skins! So during the time that func_ was down, I got round to a spot of writing, and finally finished off that article on how normals work in Quake:
http://tomeofpreach.wordpress.com/2013/08/19/normals-in-mdl-format/ While doing this, I also discovered there is a bug in the md3tomdl converter, where it's incorrectly calculating the normal vectors of the MD3 file, and so is only using half the range of vectors. This explains why models like the ogre have appeared brighter in game than you'd expect. If you ignore the model on the right of each image http://tomeofpreach.files.wordpress.com/2013/08/sidexside.jpg shows the ogre's shading with the bug, and http://tomeofpreach.files.wordpress.com/2013/08/sidebyside.jpg shows the correct shading once the bug is fixed. Once the shub-hub comes back up, I'll be uploading a new version of md3tomdl, and reupload all the affected models. So you'll probably want to download any models you're using again once that's done, and you should definitely get the new version of md3tomdl if you use it. Hi guys. Does anyone have a complete copy of the modelling tutorial I wrote back for Qexpo 2006? Archive.org has parts of it:
http://web.archive.org/web/20070925005759/http://www.quakeexpo.com/booth.php?id=32&page=181 Sadly some of the pages are missing, although weirdly all of the tutorial images were archived. I didn't keep a local copy of the text, and thought it'd be nice to restore a copy to the live web. So that this post isn't just a contentless appeal for help, I discovered a new thing involving QME and normals. You can turn on the lights in QME with the lightbulb icon, and then activate the torch to swing the light around, which lets you visualise how the shading is applied. You might remember from the above blog post that QME overwrites the normals on a model. It looks like the moment that the normals change is when the file gets saved, so you can preview your smoothing in QME before that happens. I think I might have an archive but I can only check in 3 days. Remind me if I forget and don't get your hopes too high.
Thanks for the help MadFox, it's great to have the tutorial back! I will try and nudge Spirit about his copy, just to see if I can escape having to retype everything as well. Knowing that it's not gone forever is a great relief, and I'll get it on the blog soon.
I was enthousiast from the moment I saw it at Q10booth.
Thinking it still would be there on the Q10th booth later, was enough for me to copy all to my hard disk. And althought it's not pdf, I'm already glad to have some access to the most basics. It is a valued tutorial for Quake1 modelling that has helped me a lot. Waiting for page8. Even if madfox hadn't been able to help me out with a zip of all the images from the tutorial, my dredging mission on archive.org would still have been a waste of time...On a search through my modelling folder for other things, I found a complete set of the original images! No text though, so it's the moment of truth now. Spirit: do I need to type the missing tutorials from the images?
So time for a little run of models to celebrate the return of the Shub-Hub! I've prepared a little stockpile, but quite a few of them aren't much use to mappers, and this first one is one such model. It's a grenade launcher variant which has issues in engines with interpolation (although fitzquake neatly avoids the glitches in this case). So I guess it might be valuable as a lesson of what not to do!
http://tomeofpreach.wordpress.com/2013/09/10/grenade-launcher/ I was so excited to post a useless model that I forgot the best part of the post. The model comes with a qmdl script that you can use to fix the normals on models with complex skin maps which you have edited in QME. It uses some heuristics to determine which vertices are "meant" to be joined together, then unifies the vertices' normals. Cutting QME out and preserving the genuine normals is still prefereable, but this gives decent results and keeps things simple!
Yeah, the drum's quite heavy compared to the rest of the model, which makes the thing look a bit unwieldy to say the least. It's too long ago to pretend I remember what I was thinking when I designed it...
Although I'm going to try and spread the models out over the course of days, I will put up a tool update while I'm at it. Here is the version of md3tomdl which correctly decodes the vertex normals on md3 files, and so gets rid of the overly-bright looking models the previous version created. http://tomeofpreach.wordpress.com/md3tomdl/ I'm gonna work through my models, reexporting them with this new version, and I'll share a link to the list of changed models once I'm done. Time for another model and another update to one of the tools. Today we have a stake launcher (a la Painkiller). It's a bit of a weird design, but on the plus side it has a neat animation and a skin which kinda fits in with the palette of the classic quake weapons. Maybe if you've got a map with wide open spaces, you could swap the lightning gun out and include it as a sniping weapon.
http://tomeofpreach.wordpress.com/2013/09/11/stake-launcher/ Today's updated tool is the qmdl module: http://tomeofpreach.wordpress.com/qmdl Firstly the page has finally been fleshed out with a changelog and a proper examples page to get you started. Also v0.3 of the module is released, which has a very special extra function added to the Helper class: merge_vertices. As the name suggests, it tries to merge as many vertices on the model as it can without changing the visuals (although it can be instructed that vertices with different normals are still mergeable). The feature I'm particularly proud of is that it will create seam vertices in order to perform a merge, if you have the correct front-and-back skinmap from a classic quake model. It sounds like it wouldn't be useful very often but here's an example: Imagine you start with a classic quake mdl, and you convert it and import it into a modelling package. You add some animations to it then export it and convert it back to No updates for tools today, I'm working on something but it needs more testing. As a change of pace from all these refurbished weapon models, here's a refurbished Helijet instead.
http://tomeofpreach.wordpress.com/2013/09/12/helijet/ It kinda feels like the helijet really belongs to it's own mod, but I think it might be handy as a random mapobject as well. Can that model be anyhow attached to a Path_corner, or turned into a func_?
At least in quoth? Btw that yesterday launcher freaked me out! Cheers! the heck man, that thing is awesome! the only problem is that i can't think of where i'd want to use a vehicle like that. it would have to be some serious open terrain otherwise you'd just bump into sky brushes. :(
ohhh well, maybe if you put a grunt or enforcer in it... and then put on guns. lots of guns. would be a cool unique monster.
ohhh well, maybe if you put a grunt or enforcer in it... and then put on guns. lots of guns. would be a cool unique monster.
Yeah, I'd never given thought to using it as an enemy but I think there's potential. You could probably adapt the skin into a Rubicon style thing fairly easy, if you rusted all the gunmetal bits brown and muddied the paint with more texture and the correct shade of green. Then it could compliment those enforcers on the hoverpads, ether as transport or gunship.
And yeah, it's possible to do Q2 style flypast animations in Quoth with one. Since func_rotate_train entities are non-solid, you can use a So, on to today's stuff. I posted a fair bit about it in this thread recently, so it'll come as no surprise that I'm about to post the Qexpo tutorial: http://tomeofpreach.wordpress.com/2013/09/14/the-return-of-the-qexpo-tutorial/ Well...I've still got 4 more to type up or recreate, but the first ones are restored. Thanks again to Madfox! And what better model to go with it than the Fusion Cannon from tutorials 3 and 4, which I finally got round to finishing off during the downtime! http://tomeofpreach.wordpress.com/2013/09/14/fusion-cannon/ The pace is maintained, another day, another model:
http://tomeofpreach.wordpress.com/2013/09/14/blinds/ This time you can create some beautiful windows, and give the illusion that you aren't blocking vis through them. Amaze your friends with the obviously fake HDR effect they create. Also the final four parts from the tutorial are up if you want to brush up on your animation technique or the essentials of the mdl format. http://tomeofpreach.wordpress.com/qexpo-tutorial/ I posted a new version of qmdl earlier this week. It turns out the merge_vertices function is worth running even on models that have come straight out of the md3tomdl converter. I ran it on my ogre model and it went from 692 vertices to 666. Not only is that a really cool number of vertices to have, but it's a pretty good saving to make. md3tomdl follows the topology of the md3 model exactly, so I'm guessing that there are places where vertices are separated due to subtle difference in smoothing groups. Once we get down to mdl format the fine distinctions are erased, and there's no reason not to merge the vertices.
I also discovered a bug in merge_vertices - it doesn't cope with framegroups correctly. So if you are going to add framegroups, for now you need to run merge_vertices first! No new model today, but I've gone through and updated all the old models that had weird normals created by the old version of md3tomdl. The list of updated models is at: http://tomeofpreach.wordpress.com/2013/09/15/new-md3tomdl-qmdl-fbxtomdl-and-updated-models/ If you use any of the models in this post you should pick up the new version. Also today sees a new version of fbxtomdl released which handles indexed skins in a simpler and more intuitive way(the same way that the helper in qmdl does). It's also got its own page now: http://tomeofpreach.wordpress.com/qmdl/fbxtomdl Yeah, here's some more. Quite a few of the model this week have undeniably been random odds-and-ends that I just got round to polishing up and releasing. Today we've got a red-hot new model, created entirely this week.
It's a door pull mapobject for adding detail to your medieval and metal maps: http://tomeofpreach.wordpress.com/2013/09/16/door-pull/ Nothing complicated going on, just a static model to make a plain door interesting. On the tools front, I've got a slightly weird exclusive to func_ deal going: http://www.quaketastic.com/files/tools/windows/model-compiler.zip This is the little package I use to jump-start my model making. When I embark on a new model, I create a clean directory for it, and then drop these 4 files into the directory. If I export the new model with the filename "model.md3", running the batch file compiles it to a basic mdl with no other input required. The files also have all the scaffolding needed to build the model properly as I go. For example, once I have the first skin on the go, I overwrite the "dummy" model.pcx file with it. If I need to add extra skins, there's an empty array called "skinlist" in model.py I can add the filenames to. Similarly as I add various animation to the file, I can add to the list of (name, length) pairs in the rename_frames list. I can even amend the last line of the batch file to give the model file a less generic name. So to make use of it, you need to extract the files somewhere safe, and then make one very important change. Open the batch file and modify the first line to specify the full path to the location of your copy of md3tomdl (advanced users could instead add md3tomdl to their path). Anyway, I hope this helps someone out there get things done with a little less fuss. door pull model is very cool and can be very useful. i'd love to see more things like this-- subtle details that are not meant to be the center of attention; the hallmark of a good map object.
Yeah, so I've about run out of tools and utilities to post about, but I will continue with a trickle of models to use. Today we've got a gas cylinder which I originally made for a top-down zombie shooting mod. So the idea was to try and make a model which looked interesting from above. Luckily I did skin the whole model so it can be used in 3D maps as well.
http://tomeofpreach.wordpress.com/2013/09/17/gas-cylinder/ Also, quick note on the republished vine model. Before this morning the "fixed" vine was missing the extra skins that the original came with. So you might need to re-download that one yet again... I have heard so much about beez.
Yet I never saw them in Quake1. I have heard about a swarm entity, but it is beyond my grasp. Here I have some beez in beta state. Thing izz... I can't kill them. I even can't hurt them. Help! They hurt me, and kill me. any ideas for the model are welcome.
I can't loop the sound, although I ripped it with cooledit to loop mode. I have managed to kill the swarm. My hint is that to run your mod in fitzquake, and run the console command "r_showbboxes 1". You should then see where to aim, and it'll give you a clue what's gone wrong in your code.
Incidentally, I spotted a mismatch in the code at the moment. In the QC the pain animation is defined all the way to pain14, but the model only has 8 pain frames. This means the death animation glitches half way through. Can't check out what you've got there...
The RMQ swarm were distinct enemies, basically each bee was thinking in its own right. In theory with a collision they'd be kill able but this would ruin the shotguns - the code would only allow you to kill one bee of the swarm at once.... Unless you made an invisible explosion happen on the killed bee when hit by a shotgun. You should be able to grab the swarm.qc from the RMQ SVN - it is almost completely nuclear as I remember, just needing a defs reference. There's also a small qc maggot mod from idgames2 which could be useful, which is a micro enemy based off the Flesh Grub (I think). That's hillaric!
I thought I was a bad-aimer, but this cheats me.:P Yes Preach, the bbox is out of order. It has to be in the center. The $painframe a typo. I'm surprised I can easily walk through the bbox. That gave me the feeling I had to shoot one bee. How does that bbox come up so left lifted? @Ijed- always something new with that monster entity. When I started the swarm, I was afraid I couldn't make them too large because of that bbox. Now it seems it is just a tiny thing. Compare your line:
setsize (self, '16 16 16', '24 24 24'); to the setsize line of other monsters. I changed it into setsize (self, '-12 -12 -12', '12 12 12'); and that seems to work.
If the swarm gets killed the bbox hangs in the air, as the swarm is. This looks rather odd. How come the bbox hangs in the air after the deathframes? check the wizard qc for this, specifically the death frames. you need to change the movetype to toss.
So even though I haven't posted things on here for the past few days, I have managed to keep up "one model a day" through today. What you might have missed:
A model with the qualities necros looks for in a map object - but only useful if your map has a nautical flavour... http://tomeofpreach.wordpress.com/2013/09/18/mooring/ On the opposite end of things, a section of river you'd need to design the whole area around, although it does have some interesting techniques to demonstrate... http://tomeofpreach.wordpress.com/2013/09/19/rapids/ Finally, a length of bright warning tape for base maps, gimmicky but fun... http://tomeofpreach.wordpress.com/2013/09/20/warning-tape/ Can't help it.., seen too much futurama
He's more an update from metroid.
I modelled it so, it can open its mouth and animate smiley's. I wanted to add the abbility of lipsync. Qmle screws a lot while importing. ...and then they will all bend for me!
and kizz my shiny ass! ...and then a new model!
So a while ago I was having a problem with gmax where the triangles got flipped when I exported. I have discovered today that the cause of this is applying the mirror operation to the model you intend to export. Use a mirror modifier instead. If you did mirror the model incorrectly, you can make the flipped triangles apparent in gmax by going to the Utilities tray on the right, and using the "Reset XForm" command. Now the editor and exported model are synced, and you can flip the polys in gmax to fix it. Anyway, new model time. This was a request by MFX, but I had some ideas stashed away for this kind of thing that made it a fun model to make. It's a mapmodel for adding cables, wires and ropes to a map. Although it's most natural for base maps, there's a rope skin so you can use it in medieval maps too. http://tomeofpreach.wordpress.com/2013/09/29/cable/ There's a good selection of skins, poses and animations to make use of, plus I'm gonna put up a tutorial based around the model, featuring a new way to organise your animations in gmax. Just need to find the time, might be a few days still... Sure I'll find a place for those!
Also, the mirror issue has another bug which could have you tearing your hair out if you don't catch it - when creating a skeletal rig mirroring the bones will give them a negative scale, which can cause all sorts of headaches. To solve it you need to find the 'bone tools' panel (can't remember which menu it's under) which has a mirror bones option that won't produce visibly correct but functionally broken bones. If you've ever had to bin an entirely rigged and animated model because of this then this should be a useful tip. In theory such a model could be rescued by creating a second skeleton and then attaching it bone by bone to the broken one, but that's a pretty ugly way of resolving it. Seeing as quake doesn't depend on skeletal animation this is kind of pointless, but anyone working on other engines might find it handy information. Thanks for that ijed, I've been manually creating both halves of the skeleton before due to that. It's not so bad since my skeletons are generally very lazy, no constraints or anything that might help with IK. When I get round to doing some better skeletal work that's gonna be a lifesaver.
Hey guys, I'm looking for a duck model... A walking and swimming (but not flying).
I've googled and looking in pub/idgames2 folders You guys have any idea where I might be able to find one? cheers, Ben Although there is a quake 2 mod that is a duckhunt mod, but they are flying ducks.
I'm thinking a 3rd person POV mod where you (mother duck) have to navigate your ducklings though a maze with lots of dogs and have to swim past rottfish. and yes the ducks will be quacking. then will the ducks able to use tricks to squash the dogs and fishes ? Mines, rockets, grenades,
i was thinking just a strategy against patrolling monsters.
the ducklings don't always follow logically and will run off and do something stupid. mother duck has to quack to get them back in line and following. I'm thinking a 3rd person POV mod where you (mother duck) have to navigate your ducklings though a maze with lots of dogs and have to swim past rottfish.
Awesome, I had a very similar idea at some point. Good luck with it! In the meantime you could be a shambler herding your rottweiler puppies towards the exit, or something. A grimdark Happyland Adventures.
i've always wanted to do a harvest moon mod for quake except your farm gets attacked by shamblers and they trample your crops.
@enliten
can you make your mother duck to mutate into a huge Shambler, if a dog kills a duckling ? Could be fun to watch the dogs chased by a wild and furious Shambler... what portmanteau is the best?
I was thinking that it could just give you a score at the end of the level, but I guess that this could work just as well. Crossover Quake!
Reminds me of a quake / Minecraft texture set I did. But it looked shite and I lost interest. You can't duck in Quake
There's a splendid Dragonite from someone, dunnoh now, who made a Q3 model I recompiled to Quake1. A cheet of a dragon baby! @enliten- I could animate the first (or second one) if you like.:P but I'll pass... before I get the model up I should have some sort of prototype up and running...
Uni assignments first... so many things to do... such little time. What tool do you guys use for modelling in Q1? Mostly I use an animation studio for creating the model.
Others use Milkshape, Blender or Max3D. From there ist is easy to export the model to a 3DS or dxf. Then one can import them in QMLE, Noeisus or Gmax and compile them. Quark47 has a handy prog to try them out in game. Preach site has a lot info how to start and which progs to use. Anyway, I made the duck model, so here's your prototype. holy crap man, that is both fast and quality workmanship. It's perfect for the prototype,
I'll need to get onto it :) Cheers i use an old copy of 3ds max 9 and npherno's MD3 compiler to export
Hi all, got a little model for the weekend here. It's a reworking of the nailgun model, where I was aiming to change three things:
1) Make the model interpolation friendly 2) Make the skin have power-of-2 dimensions 3) Nothing else Grab it from here and let me know what you think. So yeah, after seeing the warning tape in MFX's map, I thought it was probably worth creating a more generic texture for the model. So here's a version which has standard yellow/black hazard stripes.
http://tomeofpreach.wordpress.com/2013/12/10/hazard-tape/ To get the skin to look cleaner, I had to modify the way the skinmap works compared to the old model, so they can't be combined as a single file. In this way I justify a whole new blog post for a small cosmetic update : - ) I'd like to give the helijet a Rubicon 2 reskin, but the exported skin from qme is in pretty poor quality, and I can't even tell where an edge of the skin ends and the blank space begins. Do you perhaps have a better one laying around?
I'd like to give the helijet a Rubicon 2 reskin, but the exported skin from qme is in pretty poor quality, and I can't even tell where an edge of the skin ends and the blank space begins. Do you perhaps have a better one laying around?
use Qme to paint the triangles on the skin when exporting it.
Theres a button there in the UI. Quickest way to create a mask in QME is create a new skin (which makes it all black), paint white triangles as ijed says, and then export that skin. Bucket-filling the triangle interiors white is optional, you can usually just magic select the outside space at that point. Incidentally, not doing that is good for avoiding seams on your model, it's better to have a sensible colour - but don't forget to paint the pixel at (0,0) a different colour or it's all for naught!
quark407 also has a method:
- open the model in quark407 - in the skins area, right click in the white area - select copy - right click again -> paste - you get a new skin map skin - right click the new skin and export That post yesterday reminded me of an article I had planned but never finished. It's a trick in QME which makes the Cut Away Unused Skin option more useful:
http://tomeofpreach.wordpress.com/2014/01/25/qme-skin-reduction-trick/ Preach! Tried to email you but btinternet apparently blows.
I'm working on a drop-in replacement for knight.mdl - one with the same anim lengths and moveforward offsets, but not a terrible mesh with terrible animation, so you can just put it in id1/progs and have a knight that looks as good as the Hell Knight without any progs code. It means I've had to replicate even the weird stuff like the groaty 5-frame kneel where his feet lift up off the ground, because there are already mods that use those frames with their own built-in workarounds. My trouble (you might already have guessed what it is): id1 knight.mdl has 97 frames, but if you count the $frame definitions in knight.qc, there are only 96. attackb1 is duplicated as frames 43 and 44 - same name, same data. I'd expect this to screw up all the animations because of the one-frame offset it would introduce, causing incorrect frames to flash at the beginning of all the anims after it (walk and the two deaths), but it doesn't, so somehow Quake digests the model correctly. My knight.mdl behaves fine in game when it doesn't replicate this bug, but it's then broken in demo playback (exhibiting the aforementioned phantom frames). When I do try to replicate it, exporting the same frame twice into the You've spent quite a bit longer than me noodling around with the format. Any idea what makes the knight's stealth-duped frame special, and how to replicate the specialness? I don't know exactly what's going on there, it looks from a preliminary glance that it's the same pose repeating as attackb1 and attackb2 (although of course the frame names can be anything as the engine ignores them). So if you've tried making a 10 frame sequence and just repeating the first one to make it 11 long, then I'll have to investigate a little further. Leave it with me.
This guy will be thrilled to hear about a new knight model.
Thanks, Preach! :beer:
I'm not going overboard with the knight - it uses the old skin, and doesn't go any farther than good Quake level of detail lest it look out of place, so he's still got one flat quad for a face, but, you know, at least he has an entire quad for his face now :) Sock was disappointed I didn't give him a nose though. Whatever e-mail glitch there is between us operates both ways, it seems.
I've had a little bit more of a poke around with the knight model and some tools. I took a look at the binary output for the first two frames of attackb, and also ran the model through my python loader so I could inspect how the parsed data turned out. I can't see anything too weird going on with the attackb sequence though - it looks like it's just a length 10 animation sequence, with the first pose duplicated to make the sequence 11 frames long. The engine doesn't actually care what you call the frames, either in demos or live gameplay, it just references them by numbers, so the only important thing is getting them in exactly the same sequence as the original. Since I can't find anything weird going on, I'm worried that I've misunderstood the problem. Is it possible you can send me some attempted models to take a look at, and see if I can spot what's happening with them? It turns out I'm just a dumb idiot.
(short version: I was testing the knight out of /lunsp2/, since that's where all my model export stuff was already pointed and I am lazy, and at some point years ago I must have seen the duplicate $frame in knight.qc and "fixed" it, because I am proactive. The odd behavior was just a mismatch between gameplay in lunsp2 and demos recorded in id1, and had nothing to do with the model.) Thanks, Preach! I made a decision to plunge into the wonderful world of 3D modelling.
http://i.imgur.com/R5G56tM.png Thanks.
Speaking about Chasm, I think I ripped off its energy crossbow, though I didn't realise it at the time. I'm having some problems with UVs, by the way. I'm using QuakeForge Blender plugin and it seems to shift around coordinates in a certain way. At first I thought that it was a format-related precision problem, but when I tried to move affected coordinates in the opposite directions before exporting, I got ideal UVs on output. http://lunaran.com/pics/lunsp2/knight2.gif
This stupid run attack, man. The knight calls ai_charge_side on every frame of his run attack, which calls walkmove(20). That's 20 in units. Trying to animate this guy doing a full-strength baseball swing while somehow moving his legs in a way that covers 200 units in 10 frames without the feet sliding is That's the second pass and it still could be better. First pass I tried four strides of 50u each, which was a good length, but with only 11 frames to move his feet to all those positions, his legs were teleporting between very disparate poses and it was breaking persistence of vision, so he just looked crazy-Flintstones-bongo-legs. Two strides of 100u each is way too long, and he just barely doesn't look like a flying ballerina if I turn his hips all the way to the side and have him twist and push off the very toe, but at least it reads properly as an animation this way, especially from the front where you'll usually be seeing it. Plus, anything's better than the original knight, who as you can see hardly shuffles his feet forward at all in this anim and skates the whole distance instead. Also for a frame or two his head almost comes off. Also his feet are actually about four units off the ground for the majority of the anim. and so on. It's close, though. I need to add some blend shapes to the rig to puff out the knees and elbows when they bend deeply, since they collapse pretty badly at extremes, but at that point I might call it done. I'm trying to gather relevant skins also. So far I have stock, the Quoth beigeknight, and those two weird skins from ARWOP that make him look like a superhero. Any other prominent mods have prominent knight skins? Yeah, under the constraints I think you've done a fine job with the animation, makes it into a proper lunge. Also props for fixing the texture map on the sword, it always bugs me how much detail is lost from the knight texture through misalignment.
For skins, did Operation Urth Magik have tech-knights with lightsabres in it? Or was that just the hell knight model? I assume red epaulets interfered with the strong red-equals-rockets color scheme they were going for, and they wanted him to look more like the hell knight. Does make him pretty bland.
OUM technosupervillains added. I couldn't stand the chunky swimplayer, so I made a new one.
It's still in repair because of my experiences with the amphebian. I'm a singleplayer, so purpose lies more in the dm scene, but anyway it's a start . If you want your models to work in winquake, be careful where you put your seams! Models that have seam vertices on the rightmost column of pixels on the skin experience terrible corruption, with triangles that stretch to infinity at some angles, and random pixels on the skinmap. I've not looked for reasons in the code here, it's just experimental results.
I seem to have experienced some fortune in my models afflicted by this - all of them appear to not use the leftmost column on the skin and start their skin coordinates at 1. So I can apply the simple fix of translating all skin vertices left by one pixel. That however makes me worry that perhaps there's a bug in md3tomdl which means zero coordinates are never (or too rarely) generated... So, maybe not, now it's looking more like there's a bug in either qmdl or md3tomdl that creates mdl files winquake doesn't like. Saving with QME fixes whatever it is, the translation left by 1 unit was a red herring. More later...
OK, so here's the actual deal. It does relate to onseam vertices. Winquake is picky about the flag in a way glquake isn't. You MUST use the value 32 to indicate a vertex is onseam. Setting this value to 1 works fine in glquake but glitches out in software. I'm guessing there's a mixture of code in winquake between
if(v.onseam) //checks for any non-zero value and if(v.onseam == 32) //checks for 32 only So if you aren't careful you get half-onseam rendering, which is a big mess. Lesson learnt. GLquake probably just uses the former test everywhere which explains how I could get away with being sloppy so far... just to be clear, while onseam is treated as a boolean, in order for it to work in winquake, it must be set to 32?
good to know. The two valid values for onseam are
0: Internal vertex and 32: Onseam vertex GLQuake (appears to) treat all non-zero values as Onseam, but WinQuake displays graphical glitches for models that use any other value. I've narrowed the problem in my tools to helper.py in the python qmdl module. md3tomdl doesn't ever set onseam, because it uses the MD3 style skinmaps where separate vertices on the skin are separated on the 3d model as well. One of the new features in helper.py is stitching a classic front-back skinmap model back together if it's been through md3tomdl. It looks for pairs of vertices that could be merged to make a single onseam vertex. But when it does this, it set the value of onseam as boolean True, which got converted to 1 when the model was exported. PS: The stitching back together trick is actually fairly robust. You can create a model from scratch and carefully lay out seams half a skin width apart to create classic-style skins from an md3. You can even construct otherwise impossible skin mappings, like a cylinder with a single seam that spans across the middle of the skin, although they are for the most part interesting only academically. cool, thanks for that bit of info! i changed the setOnSeam method in my model editor to just set 32 all the time.
I guess I can safely say that I won't resume my tinkering with Quake models any time soon, so I'll just share the only thing that's somewhat finished.
https://drive.google.com/file/d/0B9DxOfPvG2G1Sk41OEpBYlhTZGM/edit?usp=sharing Old shot: http://i.imgur.com/R5G56tM.png Animation is interpolation-friendly. I was going to ask for that model so i can look into why glquake is messing up the texture coord vs winquake :-)
of pixel shells (lid is optional extra)
You know what'd be cool? If ammo could detect map types, that way you could have runic, medieval and base type boxes! :)
You know what'd be cool? If ammo could detect map types, that way you could have runic, medieval and base type boxes! :)
@Preach: I'm trying to create a model and it looks ok in darkplaces if I simply use the md3 file, but whenever I "compile" the mdl file from the md3 file it comes out all poly garbled, like the faces are pointing the wrong ways and small faces get stretched or combined and folded inwards on itself. I suspect it's the exporter that I'm using with blender because the skin works and the model is visible so I think md3tomdl is working fine.
Preach, what md3 exporter are you using? and what blender version? I have 2.71 and am using katsbits md3 exporter version 1.6.3 (for blender 2.63a from this page: http://www.katsbits.com/tools/ Maybe this might be useful: http://www.quakeunity.com/file=481
I use it when importing md3s exported from max, but you could try just importing the blender md3 and see if anything looks wrong then saving from that application before using preach's converter. I use GMAX and the md3 export which comes with that - by pop'n'fresh I think... If darkplaces loads the md3 fine then it's more likely a bug in md3tomdl, probably some edge case that the parser I wrote gets wrong. Can you e-mail me a copy of the file so I can take a look.
Don't forget about http://www.icculus.org/qshed/qwalk/
Hi Qmaster. I've got your e-mail and taken a look, but I don't have a complete fix yet. I can reproduce the bug - when I compile with md3tomdl I also get a corrupted model. It's not all bad news with the model though. It seems correct topologically - the triangles are all connected to the correct vertices, it's just those vertices which are out of place.
Specifically for this model, if you translate the right sets of vertices about the place you can get it looking normal. The place where the conversion suffers most is the right arm of the robot - half of the vertices have been displaced to the robot's far left. Then the head vertices have been moved to the bottom, and a few vertices from the front have been displaced to the back. It's almost like lots of the vertex coordinates are overflowing and wrapping round to the other side of the model. That might be possible if md3tomdl miscalculates the bounding box for the original model. Having multiple surfaces in the model might be the issue here - can you combine the whole model into one and re-export to md3? Since you can't get multiple surfaces in a mdl file, I tend to only use one and that code may be under-tested... I might be completely wrong, but this sounds like a bug with the skeleton. If it is rigged, and half the rig is simply flipped (arms legs) then the flipped bones can have a negative scale, which fucks up the position of the verts, which try to maintain their true position despite the negative scale transform.
Wild shot in the dark. I checked that this morning and found that to be the case for the left arm mesh object, the scale was negative, but even after fixing it still didnt work, and I sent that 2nd one to preach as well. I don't have any armiture/bone/skeleton for the mesh. I like to animate each frame by hand, it lends better to the original style I'm going for better.
@Preach, I'll give that a wack. In the editor, there are 3 objects, the 2 arms and the 1 body. I'll combine them as one and reexport and give that a whirl. Might be something to do with the way the blender exporter combines mesh data from multiple objects, or rather doesnt. I hope it works! I have a lot more npc's to maje after this one. do you mean you are moving vertices manually for each frame? That's hardcore man... but honestly, you should look into animating with bones. You can't get good proper movement without expending 10x as much work.
You don't need any fancy thing like max's Biped or anything. Just using primitive boxes as bones can save you hours and hours or work. I think I figured it out. Its to do with local origin placement. The object's local origin needs to be equal to global coord 0 0 0, the world origin in the editor. Any deviation from 0 0 0 will cause an issue when converted to mdl. Multiple mesh objects doesnt affect it. It all converts fine so long as I have an object origin of '0 0 0'.
Perhaps md3tomdl should check that the md3 origin value is equal to 0 0 0 and if not adjust each vertex by the origin amount to zero out the md3's origin before converting. I spent a long time looking at the code that was working out the bounding box for the model, thinking that's where the wrapping was occuring. MD3 files can have a different origin in each frame (but rarely bother), so when you mentioned non-zero origin, I thought it might relate to that. But the bounding box code accounts for that already.
Then I realised that it wasn't an overflow, but an underflow! The bounding box was accounting for the frame origins, but the code that actually exports the vertices does not. I need to get a compiler installed on this new computer, then I'll try and bash out a fix... Yeah i do and I dont use skeletal animation. It really depends on the model. For a very simplistic robot it doesnt make much difference. For a floating blob of goo: http://www.spriters-resource.com/resources/sheets/28/30623.png Theres really no better way. Anyways, it helps me keep to the original style by having fewer frames.
I'm gonna put a proper post on the blog later on, but for now grab the patched version
http://www.quaketastic.com/files/tools/windows/misc/md3tomdl-0.4.zip The mesh itself is healthy, but the offset from the origin is getting doubled. If the md3 is 16 units from the origin the mdl will be 32 units away (regardless of axis).
I noticed you added in " + f.org[0]" in mdlexport.cpp (line 215) which I'm assuming is what fixed the origin mix-up. See line 7 in md3import.cpp where you already added this to the frame.mins and frame.maxs... so is this doubling it? Psst...if I don't actually even have any line for a skinfile in the compile txt then it crashes (yes I know I'm a basket case). I'm thinking that writedummyskin(mdlfile) doesn't actually get called if skinfile == "". I guess it's something to do with !q1skin.height not being true in mdlexport.cpp->export_to_mdl{} (see Line 147)? I'd try compiling it myself with some trial and error, but I haven't bothered to install any c++ IDE at the moment. Thanks by the way! It's awesome to get such quick feedback. You're a real coding guru around here, it means a lot that you can do all of this. You're the best!
I'll try and fix all these things before I put 0.4 up. got a favour to ask first though: my tools don't ever create MD3s with an origin key to test, and I could really use a specific pair of models here. Could you send me two MD3 models, which are identical except for having different offsets? Like maybe 32 units from the origin on one, and 50 units on the other. It will make it easier to spot the doubling taking place. Thanks!
The skin issue is due to me failing to initialise some values properly, looks like it works in my local copy now! the 'q3_frame.org' field in the frame info is strictly a culling origin. apparently it can also be used for fog. It will not move the mesh up/down, unlike mdl.
using it to determine either the bounding box or the verticies is a bug. probably you should ignore it completely (in theory, you'll find a decent model has it set to the center of the frame's bounding box). That would explain everything, the correct fix (deleting the org stuff from the bounding box, not adding it to the vertices) is in place and the robot now hits a minimum of -24, which I assume was the intention. Here's a link to the new 0.4 download, once I hear a thumbs up from Qmaster I'll update the blog.
http://www.quaketastic.com/files/tools/windows/misc/md3tomdl-0.4.zip I'm not getting any different results? Maybe you uploaded the wrong exe or something? I deleted all md3tomdl's on my end and redownloaded again, but it still doubles away from the origin, and there's still the wierd crash without a skinfile line (not that it matters much, I have skinned it now, but it's nice to have for robustness). I checked the source code that you provided and it looks like you fixed it for both cases, but the actual exe doesn't seem to have the changes?
Dunno what's up. I'm going to the source. I think Preach's program works fine enough for his workflow...it's blender's exporter that doesnt provide a similar md3 file. From what I've read, Pop'n'Fresh's md3 exporter for gmax determines the bounding box for each frame. I found the source code for it here: http://forums.duke4.net/topic/1065-md3-exporter-for-3ds-max-2010-x86-and-x64/ I'll check it out when I get a chance and compare it with the katsbits exporter for blender. I might have to modify the blender exporter to match the gmax one. Translating from c++ to python here so wish me luck.
I think the uploads might havegot mixed up, yes, try this one.
http://www.quaketastic.com/files/tools/windows/misc/md3tomdl-0.4.zip So what's the easiest path for someone who wants to make a static prop to get it built and into Quake in MDL format? I saw, to my surprise, that Milkshape is still selling full licenses (wtf?) and I'd like to stay legit if at all possible.
http://quakeforge.net/ has a Blender plugin, taniwha is super nice and helpful in case it should not work.
If you have Maya at home I've written some python doodads. They go through a hacked modelgen.exe atm but I'm planning on merging it with Preach's pymdl so it all works within Maya.
The blender route seems the most sane at the moment
Of course I'm totally biased toward blender but I'm biased for a reason, it's awesome. I was considering looking at creating a blender addon using Preach's qmdl python package since all of blender's addon's are scripted in python, but it currently has an md3 exporter which works nicely with Preach's md3tomdl, especially for static props (don't forget to unwrap them before using blender's md3 exporter! got my goat several times for that one)
Exporting directly to it just feels so... liberating. No annoying conversion pipelines in between, no messing with qME to import a skin, etc.
There's a MD3 script too, but it has a horrible 'auto-scale' which makes my models too big by default having to input the manual scale to 1.00001 every time to turn that off. There's also a nice ASE exporter script for q3map2 use, however it shits the UV on certain turned edges. Trial and error for that You know I started trying it and I'm hooked on direct export to mdl. The only thing I haven't figured out is how to get it to export in a different palette. No matter though since darkplaces has a skin override feature: mymodel.mdl_skin0.pcx
I'm hoping to avoid the time to trial and error....what axis should weapon view models look down?
And how should the view model be positioned relative to the origin? For anyone who's using the fbxtomdl converter to get their model fix on, there's a new version out at:
http://tomeofpreach.wordpress.com/qmdl/fbxtomdl/ Like the past few updates to md3tomdl, the changes are minor refinements rather than new features. The main bug this one nails is inaccuracy when converting skins - the UV coordinates are now always snapped to the centre of the pixel they lie within. The other changes relate to the latest version of the fbx library - the code has been made compatible and the pre-compiled version has been upgraded to include it. Does this
Damn it. I'm terrible at this stuff. I think I installed stuff correctly but I get this error when running it:
https://dl.dropboxusercontent.com/u/161473/Misc/Bugs/FBXToMDL.jpg Here's the FBX file but I don't think it's related https://dl.dropboxusercontent.com/u/161473/Misc/Bugs/Q_Plaque.fbx Annnnd it's because I didn't have a skin file in the folder. Never mind, I have an output.mdl created! Continuing to play...
Sorry for spam. It's actually a useful touch of feedback, not just to hear that someone's making use of it, but it might actually be an indication that something needs fixing. There's meant to be code that handles the case when no skin file is present by adding a dummy skin, but it looks like it's not working. Possibly the bug is isolated to the pre-built version, and maybe it's the warning message that's triggering things. I'll test a bit and see if I can fix that...
If you ever need a kidney or something, preach, let me know. Damn...
https://dl.dropboxusercontent.com/u/161473/SeptQuake/CustomModels.jpg I never thought it would be this easy. I was procrastinating because the thought of Blender plugins and such was turning me off. But this... THIS... So I'm messing around with model skins and I'll be damned if I can figure this out
I can't get the right colors to show up inside of Quake. I don't have a custom palette in any of my WAD files https://dl.dropboxusercontent.com/u/161473/SeptQuake/palette.jpg I either get black models or the colors seem shifted off by one row Is Photoshop not the right tool for painting Quake skins? It has to work, right? I'm exporting an 8-bit, indexed PCX file... See, it's weird
Fuuuuck. Maybe there's something helpful in this tutorial? http://ccorner.duke4.net/conversion-to-8-bit-palette/
Check the "image -> mode -> color table" window looks the same as the quake palette? Are you just flood filling skins with a single colour to test them? Some engines respond badly to that... They try to replace the bright blue backgrounds on some models with black to get rid of blue seams. However, they do this by flood-filling in black from the pixel in the top left of the skin to all adjacent same coloured pixels. Best to always make sure that pixel is a different colour to the rest of the skin.
Photoshop has a dodgy PCX support, it seems. When you open Doom or Quake screenshots in it, they're greycale and with aspect ratio correction applied for some reason.
Exporting PCX images incompatible with Quake would make sense in this light. Thanks for the info guys, that's all useful!
So if Photoshop is dodgy, what's the recommended program to use for skinning models? What has good, solid PCX support? Or is PCX even the way to go? Image-wise, fbxtomdl supports 3 formats: pcx, tga and bmp. It is limited however by which variants of these formats the Python Image Library can load - I know that it doesn't cope well with 8-bit bmp files. You can use 24-bit skins and let the tool convert them, but there are times when, even if you've only used colours from the palette, that conversion can do undesirable things with fullbrights. So I'd recommend trying to get an 8-bit format working; if you want to stick with Photoshop maybe tga will work out well, if you want pcx support I've found GIMP works fine.
On the trail of the default skin bug, it's a bloody weird one. The bug doesn't occur in the python version, it's a side effect of the OK, neat. A 24-bit TGA converts accurately so maybe I'll roll with that for now. It will at least get me started...
the pcx format that is used only has the bare minimum information contained in it. it does not contain the actual colour information of the indices used for each pixel so photoshop takes a guess and loads them as greyscale with 0 being black and 255 being white.
not sure about the aspect ratio, but likely something similar. So, QME won't even install on Windows8. Windows just refuses to even try. What can I use to open up an MDL and look at the innards?
I want to figure out how to auto-animate my mesh, for example. Like the walltorch does... won't install or won't run?
http://mobile.sheridanc.on.ca/~jonescor/temp/qME.zip I think the issue is that QMe won't install on 64 bit processor machines, because the program is 32 bit but the installer is 16 bit. This was a common technique in the mid 90s, so you could at least display a message to people in the 16 bit world that the program wasn't compatible.
Probably my last noob question
The QuakeC doesn't seem to initiate it so https://dl.dropboxusercontent.com/u/161473/Misc/TorchQuestion.jpg Well, other programs can view these shots just fine, so the palette is stored in there somehow.
Yeah, I had been thinking that was the one bit of support missing. Here's a version with support for them (but literally zero error checking if you do something stupid like overlapping ranges, backwards pairs, invalid syntax, etc)
http://www.quaketastic.com/files/tools/fbxtomdl-0.4.zip The switch is -g, used like fbxtomdl -g 1-6,17-25,40-45 Groups have to be constructed from contiguous frame ranges, and animation speed is automatically 0.1. If you want anything fancier you need to install python and check out qmdl. Test it out and if you don't run into bugs I'll make the release proper. Ugh
This may be blindingly obvious, but how do I get the 3D viewports back? I can't seem to make it happen: https://dl.dropboxusercontent.com/u/161473/Misc/QMEWTF.jpg My version here is a bit wonky so I can't test properly right now, but it should just be clicking the camera button up there in the top left.
That's the frame editor view, and there's the same inside the view menu. Not sure about version differences, but it looks like you're missing the buttons to reset the viewports to default. One in particular is an eye, which centers the camera on the model itself. Just tried opening another version I have and thanks to not being able to modify my own (work) PC I cannot close it down.
90's software XD well, if anyone wants something to start with for a model editor: https://github.com/necros0/ne_modelEditor
Blarg
Preach, can you look at this? https://dl.dropboxusercontent.com/u/161473/MDLBugs/base.fbx https://dl.dropboxusercontent.com/u/161473/MDLBugs/skin0.tga That model gives me this error when converting: Traceback (most recent call last): File "fbxtomdl.py", line 189, in <module> File "C:\Python33\lib\site-packages\qmdl\helper.py", line 22, in save File "C:\Python33\lib\site-packages\qmdl\mdl.py", line 828, in write File "C:\Python33\lib\site-packages\qmdl\mdl.py", line 413, in write_vertices File "C:\Python33\lib\site-packages\qmdl\mdl.py", line 394, in write struct.error: argument out of range It's only 144 triangles When you get errors in the vertices stage of the export, that points to being problems in the UV coordinates. According to the output of the fbx module, you have some extreme UV coordinates in your input file like
3.882966888774369e+17 47382.390625 1709638.625 0.9035763144493103 -244233.234375 0.9035763740539551 qmdl doesn't actually mind UVs outside the usual range of 0...1. If you want to say "fuck software quake! I want a tiling skin" and have coordinates outside the skinwidth then the program will do what you ask and not raise an error. At some point I will get round to giving the helper module a couple of "clamping" functions to bring all uvs into the range of 0...skinwidth but they'd be optional and fbxtomdl would skip them to retain the potentially useful flexibility. So why the crash? Well, some of those coordinates are literally so large as to overflow a 32 bit integer. Python, retaining it's title as Awesome Language 2014, handles these arbitrarily large numbers without actually breaking. But at the end of the day they have to be packed into a 32 bit field for the binary format quake reads, and at this stage Python signals an error rather than truncate them. Long and the short of it, fiddle with your UVs and get the program which is exporting fbx to double-check what it's doing... Oh ok. Yeah, it doesn't have any UVs that I've fussed with at all. That would explain it! Thanks for the quick response!!
Just to wind up the person who downloaded it last week, a new version of qmdl just went up.
http://tomeofpreach.wordpress.com/2014/10/26/qmdl-v0-4/ Main feature is support for the Md3 format, weirdly enough. Along with a module to load Md3 files there's a script that recreates md3tomdl in python. That latter bit's not in a user-friendly way at all right now - even the paths to the source files are hard-coded. Think of it as a proof of concept. It is probably the bit I'm gonna rework for the next release though, as it'll provide lots of flexibility that md3tomdl.exe can't deliver. Stuff like being able to change the way coordinates are mapped (perhaps to keep integer vertex coordinates), or to combine the separate UV maps of different surfaces in a creative way, will be made possible. The kind of stuff that's simpler to express in code than any amount of command line switches. Also there's a few other nice bits of polish for the mdl side of things. The Mdl class has two new generators basic_frames and basic_skins. These let you iterate over all the "poses" in a model, treating framegroups as a succession of individual frames. This fixed the issue that the Helper module's merge_vertices method failed on a model with a framegroup. Up on the blog today is a texture to use as a placeholder while you make your model. It has features so you can see where your UV map is distorted, and check the pixel density is consistent (or at least being used as intended). What makes it different to the hundreds of similar textures already available? It's in the Quake palette, of course!
Check it out in action and download it from https://tomeofpreach.wordpress.com/2015/01/15/placeholder-checks-texture/ Hello, i work on adaptation texture pack Minecraft for quake.
http://image.noelshack.com/fichiers/2015/05/1422384719-2015-01-27-00001.jpg http://image.noelshack.com/fichiers/2015/05/1422384716-2015-01-27-00002.jpg Comment if u like or dislike. I tried the opposite of that, porting the quake textures onto the minecraft png.
But got distracted by other stuff. MAJ texture
http://www.noelshack.com/2015-05-1422478799-2015-01-28-00003.jpg http://www.noelshack.com/2015-05-1422478801-2015-01-28-00004.jpg http://www.noelshack.com/2015-05-1422478797-2015-01-28-00005.jpg http://www.noelshack.com/2015-05-1422478798-2015-01-28-00006.jpg http://www.noelshack.com/2015-05-1422478798-2015-01-28-00007.jpg Comment Like Unlike First i finish this pack texture but good idear. Why not :).
I have for project to create models ennemies minecraft in quake "creeper, skelletor, enderdragon for boss..." And why not model axe to minecraft sword. I see that later. For Minecraft, but I like those. I'm guessing the wood near the lava isn't really wood.
The images also point out the problem I had - Minecraft is material based stone = stone floor. For quake, there are lots of floors made from stone. So choosing which to use was what made me give up / do something else. Also, metl - I clicked the like link above but it didn't work? Should I post in Site Help? I mustard mitt that a map jam along the lines of "set grid to 32, and no non-orthogonal angles allowed" could be quite the lol.
Hii i have a litle problem.
If i turn off RT World my lighting Map is too bright And if i turn on its ok. http://www.noelshack.com/2015-05-1422718655-2015-01-31-00001.jpg http://www.noelshack.com/2015-05-1422718653-2015-01-31-00002.jpg http://www.noelshack.com/2015-05-1422718653-2015-01-31-00003.jpg http://www.noelshack.com/2015-05-1422718656-2015-01-31-00004.jpg How to revise that. Thanks ok, I'm guessing those are external textures and way brighter than quake textures, so they looked all burned out under normal quake lighting?
Looks like the same textures in both shots
Fitz/ QS don't even have rtlights so maybe it's a problem with the actual light maps versus the rt approximation not matching. What is the purpose of modelheader->size in the
The engine multiplies it by this:
#define ALIAS_BASE_SIZE_RATIO (1.0 / 11.0) // normalizing factor so player model works out to about // 1 pixel per triangle GLQuake doesn't seem to use the resulting value at all; Quakespasm definitely doesn't. Software uses it in R_AliasCheckBBox: https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c#L238 Maybe someone who knows the software renderer can tell what's going on there, I can't make any sense out of it! software rendering has two ways to draw a model.
1: either using spans 2: just subdividing each triangle and drawing a singleish point in the middle of it. method 1 is more correct. method 2 is faster when its further away. method 2 has the side effect of rounding the model outwards resulting in (most noticably players) being larger when distant. this makes them easier to spot than in gl (when running at the same res), and is imho one of the two reasons that people used software rendering over gl in quakeworld for so long. The engine needs some easy way to determine which method to use, hence that header field. I know synctype is almost entirely unsupported, and any static entities with an autoplayed framegroup will be visibly synchronized.
If you were to use a model with framegroups on a thinking entity, would the group cycle start at 0 when yes, I am actually wondering how viable it is to pack extra frames into an mdl, how did you know My next attempt to convert Q3 mdl files to Quake1.
This time I took the Dragonite model of Pior, a french artist that made the model. The hard part is to combine the three parts of the model back to one and import the base dxf into an editor. From there the trick is to give the model bones and animate them to the basic Quake1 frames. Only thing left is to give it a good flame throwing breach to attack the player, which I can only append to the Quoth mod. Wish I could expand the s_explode.spr better in qc. dragonit Okay this is wierd
Some times ago I was able to Import the nailgun moel into Blender thanks to that mdl script Now I want to mess with Q2's chaingun model, so I saved it as a Anyone got a solution to this? you could try using another model editor such as QuArK. Open the
RAPO says you saved it in hexen2mp's (aka: portals, or pop) model format. There should be some option to switch back to quake's model format instead somewhere (disclaimer: its been a looong time since I used qme). And then you can open it with qme and reexport to quake's format instead.
Find yourself this little prog,
load your beloved dxf model, get some glue and scissors, paint them up.., and they're yours! It's possible.., although making the flatten layout of the dxf model results into a scattered field of forms.
I tried to fill in the player's skinn into it, but with all fields in diverse angles my printer got blurred. not sure if the link works, I got a troubled server. <img src="http://i59.tinypic.com/10wtm4x.jpg" border="0" alt="Image and video hosting by TinyPic"> I wanna see some 28mm models of quake monsters made in the style of 3rd edition warhammer minis (not the new rubbish), and painted by Shambler.
"You are in a dark castle controlled by the evil minions of Quake!"
"I shoot a rocket" "There's nothing here" "I want to check for secrets!" "It's too dark, you can't see any hints on the wall. There's nothing for you to aim at." "I attack the darkness!" "Ok fine. You shoot a rocket. It hits a Shambler you hadn't noticed and does basically no damage and you are instantly hit with a 4d20 LightningBolt and turn into a fine gooey paste" "I quickload!" If I remember right, I think Descent: Journeys in the Dark had extra life tokens (maybe it was just health potions? there were a fuck load of tokens in that game) you could buy in town because sometimes the overlord player was a dick and would save up 'threat'so as to spawn a ton of extra monsters along with a dragon and murder the heroes over and over again. (Players won by completing the dungeons, Overlord won by collecting enough 'conquest' tokens via killing the players)
Not that critical but out of curiosity does anyone know why this happens in radiant:
https://www.flickr.com/photos/129414687@N03/16287396643/ The models show up fine in game, the original models also show up fine in the editor. is that a special version of the ammo box? I notice there's an inset area where the shells are. Maybe there's a cached version in the editor that is the original one?? no clue though, just guessing...
Nothing to do with caching as you have to point to what model to use... I'm guessing it's on radiant's side on how it reads the format as it reads fine in Qme and Quark.
While working on new quake models I came to a stuborn problem I can't avoid.
It all centers on the standard *.mdl para's of the vertices-triangle compatibility. If Quake uses a player.mdl it has 212 verts and 408 tris. If I make a new model, extracted to a *.3DS or*.DXF from Qmle, use it in my own animation studio to reanimate, and export it again it contains 213verts-729tris. This won't compair with the original file in qmle and caused me a lot of wondering. Then when viewing the imported dxf file I saw that all joints of the model have 2 intersections on the triangle, that the quake1 model hasn't. So for example the wrist suddenly has four extra vertices inside. It is due to the rule of *.dxf to convert all tris into two vertices. That's what makes the outer limit of 729 in stead of 408. Only way I can se now is, how can I delete these intersections. I don't need them. I could make my own model and then wrench qmle out of the intersections on the base model, so the poses will follow. But that makes no sense to me, it would be much simpler to keep hold of the original dxf. odd, i never had those problems when i worked with dxf and 3ds max... are you sure your settings aren't messed up in some way?
I've been trying Gmax and Noeisis, but fot some reason I can't get grip on it. Although it is a bit queer to explain in my ducktalk, but here is what happens.
After I have exported a model in quake, let's say player.mdl - pose axpain1. This dxf is the first picture, it shows a part of the knee with open squares. I import the model into my model studio and it appears as the same dxf as qmle. When I export it back again as dxf or any other extentions, it is filled with intersections. I won't care that much, but for making a good pose for a quake model it becomes incompatible with the original file. I once modelled an enforcer in Gmax, that kept the original tris/vert count, but Iremember I had a hard time with it. Dunno, all I can say is check what you're doing during import and export as well as what modifiers you are using. Extra faces like that don't happen randomly.
I've tried to use Gmax for Q1 at some point, but I could never make it work. Even if I'd figure out what I was doing wrong, it didn't seem like a vey good choice, workflow-wise - too much hackiness.
I've always to ask questions regarding modelling and animating in Blender and exporting it to Quake.
I've been known recently about Shape Keys (https://www.blender.org/manual/animation/techs/shape/shape_keys.html) for animations, and importing 1/What is the method to export shape key frames as 2/How can I deal with frame interpolation with Darkplaces? For example, the Super Nailgun rotates fine while shooting, but Zerstorer's Chaingun just distorts like crazy while shooting. 3/Kind of off-topic (but still relevent on the whole export models in quake subject) but how do I prevent Photoshop to turn textures that have the quake palette applied on into noisy pictures? I'm not sure, but the last one might be about automatic dithering, which indeed makes a lot of noise. Deliberately, but it's not always for the better.
I'd advice turning it off by default. Color conversion menu should have all necessary options. Oh, and I don't think that pixel art guidelines are appropriate for Quake graphics. Unless I missed something. I'm asking how I can make animations/animation frames in Blender and make sure the exported mdl file has them too, or if I need to export each frame as their own model and make sure I can import them as frames in QME.
And dwere don't worry, when I try to texture I try my best to replicate the quake aesthetics ;) And thanks for the tip about automatic dithering, that should do it since even if I try to make a simple texture that uses quake colors it still comes out as grainy. I'm asking how I can make animations/animation frames in Blender and make sure the exported mdl file has them too, or if I need to export each frame as their own model and make sure I can import them as frames in QME.
So at the moment, you are able to create models with more than one pose, and you are able to export them from Blender, but when they are exported they only have a single frame? And you have a way of changing which pose that frame is? I'm not very familiar with this blender plugin, but I had a quick try and I was able to import a model, then export it again, and the exported model had all the frames. So it is possible to get it to export animations all in one go, it's just a matter of finding out where it's going wrong and what can be done... It might be good if you can upload one of your blender files so I can have a look at what you have, and try to play around with it.
I think the amount of frames exported depends on which frame is currently selected. Or something. I forgot.
I'm max there was an issue once where I couldn't export all frames and I found I had to add a keyframe at the end that, maybe this is something similar?
Just saw that the timeline at the bottom of Blender's window actually stands for animations, as I discovered by importing an mdl file containing frames and fucking around with the timeline cursor.
Life's good, and I'm off doing models for Quake now! Doing a double post, but:
I'm currently doing texture work for my machine gun, and the only way I found out to work with quake's palette limitation and making the texture look like quake is to use MS Paint, taking parts of the quake weapons' textures and working pixels by pixels. Of course that's extremely tedious and eats a lot of time. But since I have Photoshop CS6, is there a way to optimize texture work through it? We had a big discussion on suitable editors for quake textures about a week ago in mapping help, see the following posts for the bulk of it:
http://celephais.net/board/view_thread.php?id=4&start=15380&end=15429 Daya: You can make 256 color palette in PS or GIMP, so you can convert your texture to color spectrum from this palette. You must copy Quake colors manually to PS Color Table and save it for later use.
Here take a look: http://graphicdesign.stackexchange.com/questions/654/convert-a-pattern-photo-to-a-given-palette For your convienence I just uploaded the good old program Wally up to Quaketastic.
It is one of the good wad editors that were on the WadFather back in 2001 and can be very usefull if you're doing things with quake's texture. It has a lot of feathers you can use, and is more specific than texmex. My download confirms it is a dangerous program. If it is more dangerous than the squad be aware, so download on your own risk. wally Wally was already at Quaketastic and is also available at Quaddicted.
https://www.quaddicted.com/files/tools/wally_155b.exe http://quaketastic.com/files/tools/windows/wad_editors/Wally-155B.zip I only knew because I went looking for it earlier this year. http://image.noelshack.com/fichiers/2015/39/1442965830-infantrygun.png
Keep in mind, this is the first time I'm doing actual texture work, and even after applying Quake's palette, it doesn't feel that "quake-y" enough. Any tips on accomplishing that if that's not the case here? Tend to use mainly the darker half of the palette lines and don't have many bright bits. It's usually textures being too bright that make things look unquakey.
But I think the checkerboard ork pattern on the muzzle is a bit odd. Maybe make it more transparent so you can see the metal texture underneath. That might not fix it though, since the UV cut to front is pretty harsh compared to the soft nature of the rest of the texture - created by the low res.
Maybe even remove / move it? Nah, it's something I wanted to make since day 1. Maybe doing transparency will fix it and a subtle halo surrounding the cylinder's face.
But then I've got another problem. When I export it as an http://image.noelshack.com/fichiers/2015/39/1443025682-infantrygun3.png
I'm asking again, has anyone had UV-reset related problems when exporting a model to I'm asking again, has anyone had UV-reset related problems when exporting a model to
What's your conversion process - which program do you make the models in, and what do you use to export it? It is possible to make quake models with nice UV maps with the correct process, e.g. https://tomeofpreach.wordpress.com/2012/12/15/ogre/ However, Quake itself had very simple back-front UVs and lots of tools don't support anything more. RE: v3 of the skin, it's improved a lot as you've taken the feedback on board. Have you tried overlaying scuffs and scratches onto the metal to make it a bit less "clean"? It's easy to go too far the other way with that stuff but I think it's worth a try, particularly on the browner metal bits. You mean it deletes your UVs?
I've had all sorts of problems, even it twisting the UVs round the model in a swirl. Really it just depends on what your tool chain is with these old formats and what tyou're rying to do. Not long ago it wasn't even possible to properly Uv a model. With some trickery in Noesis you can now get around the front back limitation, but I can't even remember what the method for that was. I'm using Blender 2.65 and using a Quake importer/exporter plug-in that is said to be "not even in alpha". I also have QuArk, but I only use it to convert quake 2 model files into
And if you're interested, here's the texture map of the Infantry Gun (or Nailbuster? I still hesitate between the two names) : http://image.noelshack.com/fichiers/2015/39/1443030916-g-infglowblue.png It's looking good now from the screenies. The real test will be what it looks like in-game :}
Yeah, try grabbing the MD3 exporter for Blender, and then use this "compiler"
https://tomeofpreach.wordpress.com/md3tomdl/ to make an mdl file. See if that's a bit more reliable - if it's not then it may be something that Blender does and we'd need to find a Blender expert. The error message is as follow:
http://pastebin.com/saMveW4p And I downloaded the exporter from here: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/MD3 It seems to have something about the normals, but I don't think that's the case. The function calc_normals_split was not present in Blender 2.65a, are you able to upgrade to 2.6.9 (which the MD3 plugin is rated for) or perhaps some more recent version?
So I did just that (2.75), the md3 exporter worked fine, as well as Preach's tool, but when I open it up in QME, the model's all yellow and it has a shitload of nameless frames (even though the second time I tried that I made sure to put the timeline cursor at the very beginning).
I've seen in the InsideQC forums you have to make texture assignment, but I have NO IDEA how to do so. The post itself didn't help (and the noob-smashing tone definitively didn't help...), and even the Blender wiki itself doesn't tell you where the texture pannel is, or where the mapping tab is... https://www.blender.org/manual/render/blender_render/textures/mapping/uv/applying_image.html It's so frustrating ;-; not very experienced with this, but try to isolate which step is going wrong. Maybe use noesis or another md3 viewer to confirm the md3 export went 100% correct, then go from there.. http://richwhitehouse.com/index.php?content=inc_projects.php#prjmp91
My md3 converter tool doesn't know anything about the texture you applied in blender, it sounds like you've just got the default texture. One thing to try initially is using QMe to import your skin "by hand". Go to the model properties screen, and rescale the skin to match the dimensions of your texture. Then import it and check it looks correct.
If that looks right, we just need to adjust your text file that md3tomdl is using. Your file must be an 8 bit pcx file in the quake palette, and you need to specify it with a line skinfile filename.pcx If it's still wrong in QME, then I expect the UVs are getting corrupted somewhere. I'd go with ericw's suggestion of checking the MD3 with noesis. Then we know which step has failed. Don't give up, this bit is really frustrating the first time - but once you've made it work it ought to be much smoother next time. I am using some static entities in my map that I scaled up very large, about 512x512 units.
Problem is that they have a skin file that is 312x156, maximum qmle has. So in game they look rather coarsened. Is there a way to use a high resolution in the same way the normal textures are upsized? Downloaded Noesis and the md3's texture is all white. It says there's a material but no texture.
This is literally the only thing that I can't fix, because everyone is just so fucking vague about proper texture assignment on Blender! Also I fixed the "export with 250 frames" problem, and it was just a matter of going to the timeline and putting "start : 1" and "end : 1". Can you upload the MDL file, and maybe the MD3 file as well, somewhere so I can take a look? It might be that it's working well enough to make a valid MDL even if the paths on the MD3 are wrong.
http://www.mediafire.com/download/l6ij34q3576s8v5/infantry_gun_-_nailbuster.zip
The zip file also includes the 2.75 blender file if you're curious, as well as 2 directories, the one being the first try, and the second one where somehow the md3 exporter produced a file 100 times smaller than the first time, but the result was still the same. The material in Blender is irrelevant to what is put on the model.
Also, preach 's tool does not name frames, but they aren't that important anyway, it's just annoying when previewing. Make sure not to save in qme as you will loose some vertex resolution. The material in Blender can be completely divorced from the material you end up applying, but it turns out that the MD3 exporter wants you to set up your material in a very particular way:
1) Go into edit mode on your mesh, and on the properties section click the button with a sphere (Materials) 2) Click the + button near the top to create a new material, then click the assign button to apply it to your mesh. 3) Still in properties, click the checkerboard button next to the sphere (Textures), and scroll the control back up to the top. 4) Click the + New button to add a new texture to your material. 5) Scroll down to Image, and click the picture image. A list of images appears, pick your g_infg.bmp image from the list. 6) Scroll even further down to Mapping, and click the button right of "Map:", then select your mesh to import its UV map. Then export the MD3 and it should work correctly. I hope... http://image.noelshack.com/fichiers/2015/39/1443347869-infantry-gun-done.png
Now thing is, at the start the texture came messy, and in Photoshop, the way I saved the texture is as follow: I saved it as an 8-bit bmp image and then saved is as Also, the front side of the cylinder's texture is off by 2/3 pixels and some texture edges (that looks like the UV) seems like they're a little bit torn if I look closer. Is it QME or should I worry about this, likewise for the texture that could be as messy IG(because I've been told to not save under QME or I'll have vertex problems)? If you have to Ave in qme, it's not the end of the world, but when you go direct from preach's converter, you get better vertex fodelity
Here's a possible explanation of some of the UV distortions. Quake uses integer UV coordinates, so the UVs are effective snapped to the centre of the pixel. This is a feature of the format, not QME, so the only real solution is to design your UV map around that. I end up zooming to pixel level on the skin in my model editor and moving the UVs to the centre of the pixels when I'm trying to get sharp edges exactly right. Of course, this knowledge is not near as helpful after the fact!
The original software versions of Quake (as well as some source ports) assume UV coordinates to be between pixels. GLQuake and derivatives move them to the pixel centers. I wouldn't recommend making any pixel-perfect detailing - it will always look like crap in some engines.
Blender plugin adds another problem: it places UVs between pixels when importing models, but (apparently) tries to align them to the pixel centers when exporting. If you snap your UVs to the pixel corners, small distortions are inevitable because of round-off errors or something. It's not really about distortion, but more about how some edges leave a very thin transparency line, no matter how much I try taking UV points to pixel centers. Is it related to how even models have to respect a grid too? Because I don't think Blender can do that.
If it is nothing, I can finally do the viewmodel! Speaking of which, I've been thinking of something: Instead of doing the usual fire mesh when the weapon fires, I thought about doing a Q3-like muzzleflash effect but with Powerslave's M60's muzzleflash ( http://www.spriters-resource.com/pc_computer/exhumedpowerslave/sheet/30756/ ). Will it work if I make a flat mesh with said muzzleflash surrounded by the transparency color? So I just did the viewmodel of the Infantry Gun/Nailbuster, complete with animations, 17 in total: without counting the standstill frame, it has 1 rise-up frame with the muzzleflash appearing, the next frame has the weapon getting down a little bit, only for the next frame to kick it again with another muzzleflash appearence, and the animation goes 0-1-2-3-2-1-2-3...
It looks great in Blender, I export it as a md3 file. I open it up in Neosis and the frames play flawlessly. Now I use Preach's tool, and that's when things get wierd. I open QME to see if things went right, but when I choose every frame except 0 and 2s QME says "Access violation at adress 00499BDF in module "qme.exe". Read of address 0000004C.", the frame doesn't show up (but frames 0 and all the 2s show up just fine) and the mouse is spazzing out until I click. What's the problem here, and how do I fix it? Also, this is still on subject but not for this issue, for color #255 to be properly transparent, you have to add { before the texture's name, right? Because QME doesn't seem to register that, and the pruple color is still shown. And sais former problem happens even without that { thing. Fifth is right, you can't do transparent on a mdl in standard Quake. Usually when I get an access violation in QME it's because some of the UVs have moved outside the skin limits. QME hates that, non-software engines actually cope OK with it. So that's one theory.
On the other hand, the earlier version didn't have an issue with this, so unless you had a reason to tweak the UVs it's probably not the cause. Perhaps I might need you to upload the latest file and I can take a look again. good job on following that through to the end. the hardest stuff is always the first mod/model/map/whatever.
also, i really like that 'hand crafted' muzzle flash. very nice. Good stuff, glad all the work's paid off. I may have to write up the stuff above about how to get blender to spit out an MD3 file on my blog - it's certainly far from intuitive...
I am having no luck installing QME on my Windows 8.1 machine. I don't really have much desire to have these crappy old abandonware tools from the 90s on there either tbh.
I don't want to edit anything, just view Has anyone suggested the idea of introducing a simple A simple model viewer QC mod would suffice. I assume one is already out there - anyone know?
Create a map with an entity class of viewthing. Then use the commands
viewmodel viewframe viewprev viewnext to play around with the model and the frames. Need a mod to set the skin I guess... you can try my shitty java model 'editor':
http://shoresofnis.com/temp/ne_modelEditor.zip it's unfinished, but you can load a http://image.noelshack.com/fichiers/2015/40/1443817762-step2wip.png
This is gonna be similar to Q2's chaingun, with the difference of replacing the pre-fire state by a spin-up state. Note that it'll only be available in a secret in the secret level of the episode, and as a secret in the final level. than was making quake web tools a while back, I'm pretty sure there's a HTML5
ahh: https://github.com/andyp123/quake_web_tools found it, it's on his secret other site that doesn't have his name in the name
http://pecope.co/experiments/quake_web_tools/QuakeWebTools.html Without frame interpolation: http://webm.host/b5668/vid.webm
With frame interpolation: http://webm.host/a0164/vid.webm https://dl.dropboxusercontent.com/u/1849053/Shambler_Wip_02.jpg
Posting this here... nibbling away at my shambler remake. Looks more like a suit than fur so far. :P
Good luck with getting the animations to be tolerable though. :s how does it compare to the uprezzed grunt and dog by Capn'bubs?
http://quakeone.com/forums/quake-mod-releases/works-progress/9573-authentic-model-improvement.html Looks pretty close in terms of density :) tbh, you could make it 1/4 the polycount and you wouldn't notice the difference in game.
I was wondering about the skin resolution in QMLE.
I know there are several limits, I thought something like 308 x 240. So I keep myself to these limits untill recently I found a static model I use that has 480 x 215 and seems to work well. Is this a marginal exception, that confirms other errors? Most likely wont be going with fur. We'll see what I end up with. As for the chest area yea its a little too structured looking right now. This model is going to use a 512x512 though for the final texture. which gives it the same pixel density for its size in relation to all the other monsters. This is how I see the shambler in my head when playing the game :)
I might make another lower detail one later that is closer to the original. long ago i heard that a max height of 200 was the guideline, but i can't remember where i got that or what engines/tools it applies to, if any. (dpaint?)
Floyd.mdl has a skin size of 256 x 512 and that seems to work in all engines i've tried it (which isn't that many, e.g. i didn't try dos quake.) i think the guideline was max height 256, because while you could do 320, the whole shrinking skin thing in normal glquake would make it look worse (resizing 320 to 256).
then fitzquake started doing the opposite (i think it just pads outwards to make it ^2?) so that problem went away. All models I made I always kept the limit of 320 x 240.
Often when I crossed that number quake just quit before starting giving the error maximum skinsize exceeded. So I was rather surprised to see the skinfile of my waterfall turned out 480x215 without error. I have another big static entity I would like to use, but when it is possible the skinsize can be larger then 320 x 240 maybe it could meet high resolution size. Maybe preach has an explenation for this? Just tried in qmle a skinfile of 512, but it says indeed
maximum skinfile height is higher then 480. Learned something again. The question is simple and yet doesn't have a good answer. The actual binary format for MDL doesn't impose any particularly hard limits on skin size, I think you could go to 1,000,000 or so in each direction (but going that far in both directions would take up 1TB for the skin texture which some might consider excessive).
The restrictions lie instead with the various engines and tools instead. For instance, the original DOS version of Quake had a restriction on height which I dimly recall being 200 pixels, but later engines stopped applying that limit. QME was designed in certain ways to support making engines for DOS Quake, like the way "Cut Away Unused Skin" arranges skins from left to right. GLQuake needs textures which have power-of-2 dimensions, but this is a soft limit because it resizes skins with other sizes. The resizing looks blurry, so you should try to avoid it occurring. It might also have a maximum dimension somewhere and resize everything down to that size. But if it does then you can bet newer engines will do something different. So I recommend using only these values for skin dimensions: 8, 16, 32, 64, 128, 256, 512 Nothing in-between, exactly these values. If you also want to be compatible with DOS quake, you can't use the last two as the height, but a huge number of custom models (including many of my own, several from Quoth etc.) don't bother and nobody has ever complained. I have one for GIMP somewhere, if someone interested...
I'm interested! Sorry I only replied to this post now; was away from my primary computer for a while and out of the loop. Might have drunk too much beer, as the width of the skinfile is 480,
not the height. Always get confused with these latitudes and longitudes. The height of the waterfall skin is 215, so it could be made larger to 320. But that's qmle maximum extention. max skin height seems to be either 200 or 480 in id's engines: https://github.com/id-Software/Quake/search?q=MAX_LBM_HEIGHT&type=Code
Not sure why it appears to be 480 in winquake but 200 in quakeworld. I guess someone would need to test specific exe's to be sure. It's still 480 in Fitzquake and Quakespasm. So I guess if you're going over 200 pixels high, and want the most resolution you can get, try 480 high? if it's still in fitzquake/quakespasm, that seems like a good idea to change from an error to a warning (load it, but warn that it won't work in standard engines)
http://image.noelshack.com/fichiers/2015/41/1444334148-gatling-gun.png
Is there things that need to be fixed here, or is it good enough? -@ Preach: I use the qmle version 3.0 from Rene Visser.
I found that I could raise the standard skinfile from height:320 x width: 480 to a measure of height:380 x width:570. When I go higher to 460 par example I get the warning maximum skinsize 480 exceeded. When I try to use your version I can't find an excecutable. Maybe it is my systym, winxp dunnoh. I use Fitzquake085. did you use a tutorial specifically to get this done? any resources or steps that you followed?
I would love to dabble in quake models at some point. I used experimentation, assumptions on how things work, basic Blender knowledge, and help on that board, but I can help you on some points:
1.I use Blender, a MDL importer, a MD3 exporter plugin, Preach's MD3 to MDL converter tool and QME to properly save the mesh's texture and check if the actual model is Quake-compatible and see if the initial result in Blender is very close in here. 2.For scale references, import quake models from the actual pak files. 3.Do low-poly meshes. Import more quake models if you want references or look for low-poly tutorials. 4.Mark Seems properly depending on the mesh's elements, so texturing is comfortable. You can then organize them better by splitting the image in two and manipulating the UVs here. Don't forget to snap them to pixels. 5.Do texturing in Photoshop or Gimp. I used photoshop, I always start with a 216*216 resolution, and used various Blending options while taking colors from the quake palette, and noise filter to make things more grainy. I go back and forth between Photoshop and Blender to see if the texture's elements are placed right (Use "Reload Image" option in the UV editor). When it's done, I scale down back to 200*200, darken the texture to fit into quake's lighting if necessary, and apply the Quake texture on it. Final exture must be a pcx file with the quake palette applied on. 6.Apply the texture as a Material. Preach made a post about this earlier. 7.MD3 export, MDL convert, QME check/texture save. For animations, you have to use Shape Keys. It works like this: https://www.youtube.com/watch?v=ecAHLfp9Nw8 To apply them as actual frames, you have to use the Dope Sheet editor type, where you apply the percentages of the keyframes and register them as frames. It works like the TimeLine, so frames are made consecutivally. Hope that helped. Ok so for * reasons * that are too long-winded and boring to explain I am writing my own
Anyway, there are a couple of minor things about the format that I'd like clarifying: using this page as reference: http://www.gamers.org/dEngine/quake/spec/quake-spec34/qkspec_5.htm#CMDLF In the file header: scalar_t radius ---------------------- Should this be the radius of a sphere that bounds the entire model over all frames? Or something a bit more fuzzy like the average bounding radius of each frame? What does the engine do with this? scalar_t size -------------------- Average size of the triangles over all frames apparently?? Trivial to calculate, but a peek inside some Of the ones that do bother with it, their value often differs subtly to the one I get when I recalculate it (assuming it's the average over all triangles over all frames) and I'm sure my code is perfectly pukka. What does the engine do with this? Is it just some obtuse software quake relic? From what I remember, Carmack's software renderer would just paint vertices if a model got too far away from the camera
I imagine nobody sets it because it's sort of a non-useful optimization these days. From what I remember, Carmack's software renderer would just paint vertices if a model got too far away from the camera
Fantastic prompt reply cheers! And yes that rings a bell now. Anyone know about "radius" ? radius appears to be parsed but never used by the original engines: https://github.com/id-Software/Quake/search?q=boundingradius
I imagine it was put in to reduce loading time in case the model radius was needed, but they didn't end up using it and didn't bother removing it from the format. If you still use QME as your model viewer (which I still do) then the eyeposition determines where the ground plane for the model is placed. Useless in-game but sort-of handy outside it.
Another useful reference for the format is: http://tfc.duke.free.fr/coding/mdl-specs-en.html There's an error in the link you posted, as well as in the link I posted, which both describe the
Both of them include the same error in their descriptions of the framegroup structure, i.e. they both say struct { long type; // Value != 0 trivertx_t min; // min position in all simple frames trivertx_t max; // max position in all simple frames float time[nb] // time for each of the single frames simpleframe_t frames[nb]; // a group of simple frames } but it should be struct { long type; // Value != 0 long nb; // number of pictures in group trivertx_t min; // min position in all simple frames trivertx_t max; // max position in all simple frames float time[nb] // time for each of the single frames simpleframe_t frames[nb]; // a group of simple frames } I guessed where those tasty bytes of crucial extra info were stored and turned out to be correct. I imagine the radius thing was probably being used as a culling shortcut at some point
FWIW, ToeTag included the source as a download and it read MDL files successfully
http://wantonhubris.com/toetag/ToeTag.html Can't promise it's pretty, but it works. :P No writing tho... Another error in the quoted text (kinda)
float time[nb] // time for each of the single frames Aha, you wish! It makes you think that you could have a variable framerate in a framegroup animation. And in software Quake you can. But in GLQuake (and basically all engines nowadays) this is broken, and the time value of the first frame sets the animation rate for the entire thing. So the only option compatible with all engines is having the entire sequence animate at the same rate. To add insult to injury, you still need to set the values correctly for software compatibility (plus any engines which might try to fix the bug - a futile effort by now). And they aren't set how you'd expect: wrong: [0.1, 0.1, 0.1, 0.1, right: [0.1, 0.2, 0.3, 0.4, http://image.noelshack.com/fichiers/2015/42/1444897285-gatling1.png
http://image.noelshack.com/fichiers/2015/42/1444897286-gatling2.png http://image.noelshack.com/fichiers/2015/42/1444897284-gatling3.png http://image.noelshack.com/fichiers/2015/42/1444897284-gatling4.png http://image.noelshack.com/fichiers/2015/42/1444897282-gatling5.png Quakespasm webm: http://webm.host/5aed6/vid.webm Darkplaces webm: http://webm.host/9f98d/vid.webm But I think that muzzle flash is a bit over the top. I would tone it down a bit, it looks cartoony as it is now. Or was that the intention?
Preach - Cheers! That's some useful info to have. It sounds like it could be nice to have the corrected
Daya - I like the cut of that weapon's gib. I think I'd have gone with a smaller/subtler muzzleflash, and I'm not too big a fan of the raised "idle pose" of the weapon, but basically do what you want and don't listen to me. I may update the quake wiki myself with all the
You worried that team fortress might outcode you, but there's no doubt now your model surpassed what they could do.
Realized I missed to play an extra frame in the programming for the barrel to rotate smoothly during the shooting loop. Also fixed the non-fullbright pixels on the muzzleflash texture.
Quakespasm webm: http://webm.host/b2613/vid.webm Darkplaces webm: http://webm.host/08742/vid.webm Also, I have started working on the Nail Infantry, which is basically a recreation of Doom 2's Chaingunner. Taking the Enforcer as a base, I have 2 designs in hand, but I don't know which one to choose: http://image.noelshack.com/fichiers/2015/42/1445001145-nailinfantryconcepts.png Obviously the messy textures are temporary. I'm just looking for the right shape. What does it look like when played against a Quake enemy? First impression is really good but just wondering if the muzzle flash might be a little too big?
Nevertheless, I like it. It does take up a lot of the screen, yeah. Resist the urge to put all your work front and center - AAA shooters that lavish detail on their guns and then make them cover a quarter of the screen are sort of irritating. When the gun is firing, the muzzleflash comes all the way up to the crosshair.
Still gives me Wolf3D flashbacks, too. :) How did you solve the problem of vertex interp on the rotation? If I stop firing on the right frame does the gun collapse on itself? I made a convoybelt with an injector.
It moves on 40 frames, so one cycle takes 4 seconds. I also made a sprite that lights the injector. It lights with 14 frames on self.nextthink = time + 0.01; To make them work synchronical I need a wait time of self.nextthink = time + 2.7; This works well for 42 minutes, then the sprite starts to act slow, after 65 minutes it's out of order, meaning it misses the synchronity and falls out of the movement. I tried time + 2.69 and time + 2.71 but that doesn't seem to help. Do time accounts excist in that timescale? Of course I can say, finish the map in 42 minutes, but that's a hatch of the hat. as always, it depends on the engine.
sv_gameplayfix_multiplethinks 1 (this is always enabled in quakeworld servers and thus default-enabled in fte, and default-disabled in dp, I don't know of any other nq engine that implements an equivelent) NQ servers normally only run one think per frame. if the entity thinks faster than a game tick then it can easily miss a think. the time global will be larger than the nextthink value used to be. additionally, floats have limited precision, centered around 1. that is to say that as the float becomes larger, it can no longer hold smaller numbers quite so precisely. this means the server's framerate might slow down as its own timing degrades. this is especially true of 'listen' servers. it shouldn't really be a problem for 100fps at 42 mins though. 1000fps might start to have some issues though. bigger intervals will be more reliable with larger time values. As I expected this goes far beyond my hat.
I'm not thinking about a server at all, neither that I can imagine what happens on the moment my console opens. I fear it is much more than my small mind can suspect, as I am only translating my poor knowledge into the quake world my singleplayer attitude has learned. I would gladly know how to get around this repositioning every once in a while, but.., would it change things if I turned the sprite into a static entity, at least the convoybelt is also. So maybe they interact synchronical? Maybe I misunderstood. Was this a mod entity to make a conveyor? If it is just trains then maybe you can't fix it...
You need to rewrite your code so that the conveyor belt is in charge of the sprite. Get rid of the 2.7 second delay so that the sprite doesn't loop at all by itself. Instead make it so that when the conveyor belt hits frame 40, it triggers the sprite to begin animation one more time. Then they cannot go out of sync.
But what piece of code should I use here:
convoybelt = truns.qc void() trun_stand40 =[ 39, trun_stand1 ] {}; for a sprite = vonk.qc void() model_vonk something like: void() trun_stand40 =[ 39, trun_stand1 ] {vonk_stand1();}; I can't integrate framerates of a sprite with a static entity.
So.., if I add a statement to the convoybelt.qc that goes like the grenadecode it works. It looks like: void() LightVonk = { self.movetype = MOVETYPE_NONE; self.velocity = '0 0 0'; self.touch = SUB_Null; setmodel (self, "progs/vonk.spr"); self.solid = SOLID_NOT; vonk_stand1 (); }; Now it sparks all the time. That wasn't my purpose. Before I dump the screenshots and webm, I'd like to say something first.
You see, the first draft of the guy was to edit the existing Enforcer model, by removing his blaster, replacing it with an infantry gun with a nailbelt going to an ammo cylinder on his back. Unfortunately, editing his model in Blender not only deletes the animation frames, but trying to fuse the gun model with the modified enforcer model deletes its UVs. And so I said "nah screw that, for now on I'll just make a reskin of the enforcer.". Maybe one time I'll do an actual full-fledged model on what I was trying to do, but for now I'll concentrate on getting things done. In the meantime: http://image.noelshack.com/fichiers/2015/46/1447608405-infantry20151115174322-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608410-infantry20151115174332-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608404-infantry20151115174336-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608404-infantry20151115174345-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608405-infantry20151115174559-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608406-infantry20151115174625-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608414-infantry20151115174740-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608416-infantry20151115174746-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608415-infantry20151115174849-00.jpg http://image.noelshack.com/fichiers/2015/46/1447608415-infantry20151115174901-00.jpg http://webm.host/41821/vid.webm Now I'm satisfied with the convoybelt, working in a rather reliable way, I'm trying the map in other engines.
They all work right, except DarkPlaces. One of the convoybelts picks up the cellboxes just half the right time. So the engineclaw puts down a cellbox, on the place where one has to appear. But it doesn't. It is there on half the time, while other engines: JoeQuake-WinQuake-Quakespasm-Fitzquake-glquake are just in time. What is so different with Darkplaces? I assume you're animating at least something using framegroups.
framegroups are normally directly linked to the server time. (there is a model flag which can sync it to some random time base instead, basically acting as a random offset so torches etc arn't all in sync) darkplaces instead links it to the time when the entity's frame last changed (including when it first became visible). this is much more useful when using framegroups for animations - especially firing animations. the quakeworld protocol does not reveal the server's time (at all!), so timings will be screwed there too - fte implements the dp behaviour because $REASONS. I'm using framegroups.
I made the static entities in that way that as soon as the claw picks up an ammucell it disappears from the convoybelt, and as soon as it puts one down it is deleted from it. If I had made one static entity from both convoybelts I wouldn't have had this effect. But I didn't saw this coming, at least three of the four work well, so I guess it is a mirror effect. I'm afraid I can't do much except warn DarkPlace player the server is cheating. darkplaces instead links it to the time when the entity's frame last changed (including when it first became visible).
this is much more useful when using framegroups for animations - especially firing animations. What, really? That sucks. I had a great idea for a trick which exploited the global timer on framegroups. I might even have to press on and just warn that it breaks in darkplaces... I made a fishing Ogre. It sits aside the water.
It consists of four cycles of 12 frames with a break on the first frame {ai_stand();self.nextthink = time + 2;}; for timespace. The last stand frames are a whip of the fishingrod. I just need this entity for sidekick, not as monster. My first question: how do I stop the attack routine, as when I enter the map the monster freezes when I don't use notarget? My second question: This stand pose takes about 30 seconds. I made another walk cycle, so he stands up and takes a few steps, then sits back again. This is done in the ai_walk, but what I need is four times the stand subroutine, then it should be followed with the walk cycle, then back to the stand cycle, and so on. My first thought was just to make one long script of the stand and walk frames, but then I realized there is a limit to the monster frames. I thought it was 256 frames and this amount would exceed this count. That stops him from freezing in attack.
Now I try the next part, the walk cycle. For making it not to complicated I added the last part to the stand pose. This looks like void() forg_stand109 =[ $stand33, forg_walk1 ] {}; Now he starts the walk cycle, but again it freezes because of the ai_walk() part. If I use notarget the walk cycle ends well. Now I can't get out by deleting ai_walk() as I need it to make him move. Thanks necros, you're a star!
Now my last intention, say I make it sit, walk to aside for two steps, then I want him back to the startpoint with another function, I think of ai_run, still without attack. How do I fix that in the stand function? I mean, the last forg_stand109 goes to forg_walk1. So I can use this function again, but when I use the ai_run I must formulate the stand function again to forg_stand109 =>forg_run1. I know this sounds all complicated, maybe I should turn the whole thing into a static entity. But as far as I can see, the limit of a static entity is 256 frames. What is the limit of the monster.qc? I've been tinkering on the player.mdl.
I decided to remodel the whole model poses, just to have the fun of adding some new ones. I'm not a deathmatch player so I will never have the change to meet him, but if someone has a request to give it a new pose I'm willing to do. Here's the beta of the foxplayer I added a swim pose, but any other possibillity would go. quakeworld requires that your skin is not modified.
you can change the texture coords, but make sure your model still looks okay with the vanilla skin exactly as it is. (this also applies to nq replacement textures, but is harder to control for). you can use framegroups to get around protocol limitations. or you can just use a better client that supports higher frame numbers. I don't understand a word of it.
Did I modify the skin texture? I'm sure you try to inform me well, but I just took the original skinfile and dropped it on the model after making sure it had the same texture cooords and Q1pal. Further I don't have that much engine experience, I'm just a singleplayer in a shooter fence. After weeks on working with these guys, they're now fully operational (although need some polishing up but still), and are ready to be integrated on top of Scourge of Armagon's source code, so I could use rotating doors, force fields and try to look for a way to make monster spawners to use in TrenchBroom.
Rocketeer - shoots accelerating rockets: http://image.noelshack.com/fichiers/2015/53/1451432379-infantry20151230002549-00.jpg Dimensionnal Traveller - once humans seeking the power of Shamblers, they got it without their endurance and resistance to explosions. See Doom 2's Hell Knight: http://image.noelshack.com/fichiers/2015/53/1451432382-infantry20151230002559-00.jpg Shell Trooper - A retake of Quoth's Defender, he shoots grenade with great accuracy on top of a nasty Shotgun blast as a close range attack: http://image.noelshack.com/fichiers/2015/53/1451432382-infantry20151230002619-00.jpg Butcher - An Ogre that took a cybernetic suit to better endure attacks and switch from a Grenade Launcher to a Flak Canon: http://image.noelshack.com/fichiers/2015/53/1451432380-infantry20151230002642-00.jpg Shock Marine - The Elite version of the Enforcer, he's now better equipped to do his job: http://image.noelshack.com/fichiers/2015/53/1451432379-infantry20151230002656-00.jpg http://image.noelshack.com/fichiers/2015/53/1451432778-infantry20151230004523-00.jpg Nice work Daya, glad they're coming together at last!
In celebration of Arcane Dimensions coming out, and some of my models getting some use at last, I've finally got round to releasing a new one! Animated gif and details at the post below: https://tomeofpreach.wordpress.com/2015/12/30/vortex/ Daya is now mastering the magic of character development. Respect.
Preach, effects mdl is a great insight. It's environment art, maybe I should start there. I have a request for modders It's a player/mapper request. Arcane Dimensions brought nice improvements to Quake 1 weapons. But a design weakness still annoy me: the boomstick. Why two shotguns? It's Doom inheritance, I believe. It also makes a lame noise, and it's not a very interesting model. I use this ugly duckly a lot, whenever I want precision at a distance with cheap ammo. Playing thru a level with that "broom-broom" purring stick is a downer. I'd like it replaced by a powerful silver 45 revolver. Or a desert eagle pistol. It would be hitscan or shoot fast projectiles like AD's shotgun. The damage would be lower than SG, but at a higher fire rate. And it would make a decent noise. It requires "bullets", a new ammo class. Or maybe it would be a powerful longer gross caliber pistol, wild west style, that shoots shells and toss pellets. There is the problem of the player's model holding a shotgun. All Quake weapons are long, so that shape of a long gun in his hand doesn't look so odd. The exception is the axe, and the game switches the player model when you choose it. A pistol would require a change like this. Or not? What do you guys think? Throwing in a pistol will only make the game more like Doom. I think Quake could have done better to distance itself from Doom further. I will agree with what you're saying about weapons in a sense. I think AD having a single barrel and a triple barrel is an interesting distinction. I always felt like the starting gun should have been the nail gun, or maybe a crossbow like weapon that shoots nine inch nails.
This would provide a really nice distinction between guns and you could also have a more powerful single barrel shotgun too. Well, if it has to be a shotgun, at least it should be more interesting, since it's an "initial gun" we use all the time. If you want to keep away from Doom, many other games have cool shotties, like Duke Nukem. Better animation and better sound, at least.
I'd say the AD shotgun feels more fun to use even though it's functionally a little worse by not being hitscan.
adib it's interesting you're thinking of a revolver, because for the redoing of the shotgun I thought of a similar thing, by taking inspiration from this: http://www.smashbros.com/images/character/mii_fighter/screen-9.jpg (minus the fact they're arm canons). I already changed the shooting sound to TF2's scattergun to make it more punchy, and the big change would come in animating and coding the barrel for every shot. It could be renamed as a Revolver that's big and shoots tightly-spread shells.
Same thing for the Super Shotgun, by taking inspiration from Bioshock 2's 2-barelled Shotgun with the 3-shot upgrade: http://bioshock.wikia.com/wiki/File:2BarrelShotgun-2.jpg So with what's happening now I feel more inclined to work on this. Great! I also regret that you're already in a mod, because I have some ideas for one and was hoping to drag you in. It would be sort of steampunk. If you like to talk, send me an email.
Smart way to patch the vertices.
I was trying something with animated texture, but in game it is too slow For software rendering, none.
The fact you're modeling with quads means there's no way to know what the actual triangle layout will be, and good triangle placement is crucial to avoid bad distortions in affine texture projection. Triangle placement also affects the gouraud shading (Both in software and GL renderers), but that's mostly a problem in organic animated models with high contrast lighting. Also, without a textured view of the models, there's no way to know if your textures will work well with the triangles.
Yellow has been left untouched (just like in the HUD) and is here just for comparison sake:
http://image.noelshack.com/fichiers/2016/02/1452786366-armors.png Posted by Skiffy [115.132.145.180] on 2016/01/18 15:37:14
Does anyone here know what palette format I need to use on PCX files for Preaches MD3toMDL tool to remap the colors correctly for the final compiled MDL file? I'm using an Thanks for any help or tips you might have! Cheers. You need to use the 8-bit, 256 colour palette that Quake uses. The tool ignores the colour values and just reads the palette index values directly(for good reasons I will explain below). This means that the palette you use has to be in exactly the same order as the original palette. You also need to avoid any options that try to reduce the palette when saving the file, e.g. an option which removes duplicate colours.
You might be surprised to learn that the Quake palette features duplicate colours, but it's too late to change that now. There is a red colour which appears once in the 2nd row, and once in the second to last row. The latter row is a fullbright (glow-in-the-dark) row, so there's a difference in game to using these two colours even though the RGB values match. This is why the tool reads palette indices instead - if you only read RBG values you have no way of telling if the pixel was intended to be fullbright. easy way, load up any random model in qme, import your file as a skin, then export as pcx.
Hello Preach.
I am indeed using the quake 256 color palette. I've done this with many level textures in the past. And it has the correct color order as well which is why I am confused with why things are getting all messed up using the MD3toMDL compiler.. As for the duplicate colors I am also aware those are used for fullbright rendering FX like the fire and muzzle flash FX. I wanted to try and use QME indeed to replace the texture but the program crashes with MDL's generated using the compiler. Yeah, how do you create the skin using QMe if you don't have a model yet? The answer, as necros said, is to use any old existing model, like shambler.mdl. Resize the existing skin in QME to the target skin size for your new model. Now import your new skin and export it to
If your models are crashing QME, check that you don't have skin UVs positioned outside the extents of the skin, and QME and software renderers don't like that. to understand why the colours get messed up requires understanding a bit about pcx.
pcx is a simple format where pixels are all stored in one long line as palette indices. now, one option is to store the palette in the pcx, so the start of your image file has 256 * 3 bytes wasted on colour information. save a pcx file from your image editor. now open it with windows preview. chances are, it looks fine. now, open any model in QME and export the skin as pcx. now open that with windows preview. it will look black and white and the shading will be wrong. this is because QME exports pcx files without a palette. this type of pcx assumes your application will know what colour is what index. ok, that's fine, so why does a pcx from your image editor with the proper 256 palette from quake still look wrong? the problem is with the palette order. Your editor saves the image with the 256 palette so when you open with windows preview, it looks fine because, while the colours are not stored in the same order they are for quake, the image viewer will look at the palette and use the right colours anyway. but when preach's md3tomdl opens it, it doesn't care about the palette. it's only looking at the indices. Now, preach could look in to dealing with that. doing comparisons on colour values and guessing the correct index in a pcx with a palette is pretty trivial. the only problem is where there are duplicate colours. there's no way for an algorithm to know that one red pixel is fullbright while the other is now. I think this is why he hasn't done that, because it would just lead to confusion. PCX info makes sense. I remember quake2 had similar issues with some textures looking truely odd back in the day but fine in engine. As for the model crashing QME... no UV's outside the UV space. I have some overlapping islands where parts share but that should not be an issue I think.
I've been reworking and finalizing a new proper revamp of the shambler model. That is what all this MDL messing about is for. What version of QME are you guys using? It can only export and import bitmap files with the one I have... Ok got it working! and even figured how to remove fullbrights and such other lovely things similar to texmake for map textures. My MDL pipeline is pretty solid now sweet.
So yea here is a sneak peak then... :) https://dl.dropboxusercontent.com/u/1849053/Shambler_Remake_2015_Alpha.jpg So um is there much use to naming frames? Right now its just generic fromase01 and so forth... If there is a reason then I need to figure out the python tool from Preach with all those lovely rename options and so forth... Thanks for the help everyone and Preach for the tools making all this retro min maxing possible!
About what I figured out or something else folks are talking about in this thread?
I thought Preach manual on his site goes pretty well.
I am doing lots of modelling but if I was asked to make a tutorial it would be more about knowing engines like Blender and Max. It is rally not that lot of work, in blender it's easy to import a model, giving it bones takes more care but certainly the joy of animating it. Qmle can be a harsh editor, quiet old but effective to import the dxf models. The greatest kick for me is to see the thing jumping in game! "FUCK THAT IS BRILLIAAAAAAANT!!!!!!!!!!!"
It's taken from Q2's BFG, I added more polys to the cylinders and redoing the entire texture
After I'm done doing the bases, I plan on darkening it, put some noise, and apply the quake palette. This is the method I did for all my models.
If all goes well I might release it on the weekend. At least a alpha version for folks to try out and comment while I clean up animation looks and refine the texture a bit.
That is my theory at least....
For the shambler I will be able to add a bunch of additional animations at the end btw... for maybe some new abilities like running and clawing at the same time? Or some new AOE lighting shockwave attack.. always thought the shambler could use some additional tricks on higher skill levels. Or variants! we have a zillion ogres in Arcade Dimension... now that I have this bases I would be up for making some extra Shambler variations. Zombie shamblers anyone? :) keep in mind, max number of frames in a model (for compatibility with most engines) is 255. i know how easy it can be adding in new animations. :)
Well considering the current shambler is using 94 frames that gives me 161 frames of extra options? Let me get this sucker done first but I would love to work with the Arcane guys to maybe add some souped up Shamblers? :)
Oh? How is this done exactly? Just giving them actual names then? So the Run frame group and idle frame group can be no bigger than 255 frames? I would love to find some documentation to read on this...
Framegroups are indexed as single frames. If your first framegroup starts at frame 250, the other frame(group) following it will have the index 251, no matter how many frames are inside of the framegroup.
Framegroups were most likely a late addition to the engine, because none of the vanilla models uses this feature, even though it's certainly beneficial to idle and running poses. Here. Click on the "Main Window" link, and then scroll down to the "Frame Tree Panel" section:
http://renep.home.xs4all.nl/qmehelp/ Ok so how do I add these without using QME? :)
Preach do you have some magic tools for this per chance? There's a way to do it using the Helper in the python module. The Vortex model from
https://tomeofpreach.wordpress.com/2015/12/30/vortex/ has an example in its python script, the relevant portion are: from qmdl.helper import Helper #read the model file mymdl = Helper() mymdl.load("model.mdl") mymdl.group_frames(0, 15, "spiral") mymdl.save() Hmmm too much edgework with no light direction.
https://www.dropbox.com/s/00e0kunjg9z5bvs/Quake_3_Weapons_2.jpg?dl=0 Here is some inspiration and the textures show a lot of directional lighting and tasty little highlights. I knew I was going to have to get around to installing the python tools at one point...
Now my question Mankrip about framegroups... does it only really help at the end of the file or if I start adding them in the beginning and it somehow encapsulates them making each index add to the count instead of the actual frames? What is the theoretical limit? :) I wanted the edges to be rough like that.
Although yeah I could rework on the overall light, to be on top. only thing with frame groups walk and run anims: stock models have different movement per frame. this is accounted for in the code, but with frame groups, you do not know what frame you are on because to the code, it's all the same frame index. you would need to redo the animation so that the movement is constant on all frames.
So if I understand this correctly I could have 255 frame groups for some crazy reason? Its not a 255 frame limit but index limit. But if you dont group frames then they each take an index... so to speak.
Daya I do look forward to having this in Quake though :) Here is another take from the one mode that added all the quake2 weapons to quake 3. http://www.wireheadstudios.org/album/album35/strogbfg_shots.sized.jpg Amusing... I thought quake1 ran at 10fps logic all the time. Then again I think the minotaur in Arcane has some at a higher framerate?
Individual timing does work. But IIRC, maybe not in GLQuake.
PS: Confirmed, it's a GLQuake-only bug. All hail software rendering! http://celephais.net/board/view_thread.php?id=60097&start=179&end=179 And here's the proof that it does work in WinQuake. See the function R_AliasSetupFrame:
https://github.com/id-Software/Quake/blob/master/WinQuake/r_alias.c Hmm so now I just need to make a model that uses a zillion frames and work with a programming on this form crazy enough to do it with me? Shub Niggurath proper boss fight anyone? :)
Dont let her just sit in a pool of lava waiting to be tellefragged. Have her take off and hover and fly around after a certain amount of damage coming after the player with all manner of evil spells. IMO I think you should animate it so you can use it to replace the current model. You can always add extra frames at the end anyway which will be ignored by standard quake.
Any future models I would add additional features on the back end for any intrepid programmer to tinker with if they are up for it. I plan to add at least 1 new range attack and death for the shambler after his first release. Some sort of AOE lighting sphere channel attack is what I have in mind.
Any future models I would add additional features on the back end for any intrepid programmer to tinker with
If you want I can add the new Shambler model to AD with alternative channel attack. Please don't listen to anyone about framegroups, they are freakin nightmare to get right in QC. Things to consider with your model, add idle animations (checking hands, looking around etc), alternative death animations, maybe a stomp to the ground attack (could be cool for a stomp+lightning combo) Any new stuff you add, let people know the movement speed you animated at, it will make implementing the QC easier. Also if you have time, update the horrible head gib model, that is so damn ugly it makes me cringe when I see it in game. Any extra gib models (claws+feet) are always welcome! :P Since the topic came up, the group_frames function in qmdl does support an optional 4th parameter called duration, which defaults to 0.1 if not set. This sets the duration of frames in the framegroup. Because of the GLQuake bug that prevents per-frame setting of the value in most engines, the function only takes a single value and applies it to all frames. You could write your own code to set individual values if you desired but I wouldn't recommend it.
Avoid mixing blue tones with gray, that's very hard to get it looking really good in the software renderer.
Try to use similar hues for both the base image and the weathering, only drastically switching hues on neighbouring pixels that have the same brightness, to smooth out the transition. Grayscale tones are difficult to mix with other colors. They mix better with more desaturated colors. That would be a nice debut for this guy I think in Arcane Dimension. I just finished his original animation set so now I can look into adding some new one. Check it out!
https://youtu.be/OemMkCeTB6Y New Idle and death for sure! AOE Stomping lighting attack would be murder. Speaking of lighting... Its one of the things I would love to redo. Longer more varied chunks because the default tiles like crazy and does not give me the electric vibe. this time trying to put more rust, bonus point for software rendering (I don't like that because it stings the eyes, but some people do so eh)
http://image.noelshack.com/fichiers/2016/03/1453577612-wip4-bfg9500.png That would be a nice debut for this guy I think in Arcane Dimension. I just finished his original animation set so now I can look into adding some new one
I would recommend 2 idles, something with claws as they are obvious to see from a distance. Also as the Shambler has no neck, turning would not be obvious to see. 3 channeling lightning animations (start/looped/stop), a single foot stop (shockwave effect, lift all around up into the air unless jumping) and 1 extra death animation. I would suggest any new features be on a shambler with a new skin (always best to keep the original behaviour) and to keep the HP exactly the same with GL/RL resist as before. If you want this as part of AD then then let me know as it could be added as a patch easily. Longer more varied chunks because the default tiles like crazy The lightning bolts are hard coded to the engine lightning effect. If you want more variety of bolts then its needs new QC to calculate the length, draw the segments and then fade them. It could be easily added as this is what I am doing with the AD fire wraith. Hey Daya, that latest one has come on leaps and bounds from the first shots. Making the weathering rusty is a good move because it gives the metal a contrasting warmer colour to the blue body. It could probably stand to take a bit more noise on the flat portions, perhaps by adding a specular highlight on those portions (the directional illumination is already much better).
I think you could also get some more mileage out of that blue glowing bit at the back. If you can bake some fake blue reflected highlights into the surrounding portions it will stand out much more. You are working with the quake palette of course, but you might be able to switch palette rows to do it, using the lower bright blue row to find some more saturated highlight for the blue bodywork, and pale blue tones on the nearest metalwork highlights. One final idea for the light itself, since the palette has very few fullbright blue tones it's hard to do anything other than make it totally flat. However, perhaps you could try a chequerboard pattern with the lighter shade. In software mode you might hope for an effect like: http://i.ebayimg.com/00/s/NzU1WDE2MDA=/z/KpsAAOxyVLNS8SsT/$_35.JPG In GLQuake the smoothing will at least create more texture and perhaps some kind of gradient effect. But more so. The light had a great pattern now. The highlights on the edge are what's needed, but can you try adding some spilling onto the surrounding elements? Like the inside edge of the crank handle, maybe the metal part of the stock and the blue portions right below the light. Make it so it's really emitting (fake) light onto the surrounding portions.
http://www.quaketastic.com/files/screen_shots/1453584132-bfg9500-backlight.jpg
One thing I didn't mention was the highlights on the ridges. It looks like the light is coming from back to front on the model (a good choice for first person models), so the sides of the ridges closest to the player should be in highlight. Others may have suggestions but I'm liking it now. The way the blue highlights on the handles define the shape is really nice, it's a shame that will only be seen on the pickup model. Unless the handle can drop down during the fire animation to show it off...
If there's any way to fade the blue highlight out towards the back of the middle surface of the stock that would be nice, but it might take some clever pixelisation depending on how deep the palette will go. One last job to do when all the skin is basically finalised is to look for all the seams, and use QME to try and unify the pixels on the edges. For example, the caps on the cylinders have bright pixels on the lower half, which clash with the shadows on the sides of the cylinders. You can paint in 3d view, using right-click to select the pixel colour from one side of the seam, and left click to apply it to the other. I do recognise this is a level of nit-picking very few of my models would stand up to... It did wierd stuff with edges and texture deformation for my Infantry Gun and Gatling Gun while they looked good in both Blender and Quake (Quakespasm and DP).
As for the viewmodel, I plan on cutting the crank. I prefer viewmodels where we can't see the player's hand, and while making the hand appear like in Q2 would make the weapon look exceptional, I just prefer going the "no-hands" way. Still, when that crank rev-up sound comes up I'll be sure to lean the model left and backwards to simulate that strong pull Ranger has to do to recharge the big guy. Oh and, thanks for your input Preach, as always it has been helpful. When I suggest tweaking the skin in QMe, I mean
1) Paint on the skin using QMe 2) Export the modified skin to a new file (so the original is backed up) 3) Import that modified skin to the model made using the original tools (e.g. blender/gmax/etc) Saving the model in QMe directly will usually degrade the quality in some way, but changing the skin in this way should be safe (assuming you don't do something you dislike on the skin AND you lose the backup you started with). Blender has some way to paint on the skin in 3d as well, right? Can you still work in the quake palette when you do that?
But I don't know much about it, never tried it as I don't think it supports layers and palette import.
So I noticed one thing.. the way the default Shambler is implented the use of the lighting cast animations is terrible. It frame skips and does not use the entire range from the original model. When looking at it ingame it clearly does not use all the frames and has no interpolation when doing so. Is this just me or do some of the more programmmer skilled folks here agree when looking at the code itself? That be the first place I start to fix the default Shambler in AC's implementation.
As for Channeling casting I would just add a casting look because you can use the first few begin frames and then the last few end frames and the begin and start. I also like the idea of adding a glow shell effect model like on the lost soul and rune knight. For a more souped up shambler he has constant static and glow around him and glowing claws or something. I'm not sure that's quite the problem here. The frames which get skipped are magic7 and magic8, but they're hardly different from magic6 in pose. The real jump is between magic5 and magic6, which I guess is meant to be a fast and sudden unleashing. Part of the trouble with tidying that up is that it's also the transition from the lightning ball to the lightning beam, which you can't interpolate nearly so easily. This didn't matter when the shambler was designed of course...
Well in the animation I made those frames work much better as a single sequence. Just looks terrible frame skip jitterness in engine now. But its strange that the animation interpolation looks like its not working either during that attack sequence.
I believe if an entity does a muzzleflash effect, interpolation is skipped.
I solved this in my code by putting the shambler flash on another entity. Hi there, I'm new here.
I recently got interested in quake/idtech again and went from zero to this in the last couple of days http://i.imgur.com/VyVhPgp.png I'm really proud because I tried to achieve the same thing at least 10yrs ago but my comprehension was lacking then. I learned to use blender for modeling and uv-unwrapping on youtube (DarrinLile has some great tutorials) http://i.imgur.com/CoNfA8k.png The model is fairly simple and the texture is just a material bake. Next step is painting the skin. I used the mdl exporter by taniwha and arcane dimension's misc_model entity to make it show up in quake. * Im still not sure how to properly scale and align the mdl to the floor (any advice on that?) * Regarding animation I assume I'll set up an IK-rig, animate stuff and then export with the mdl exporter. Next I'll have to learn quakec and tell quake what to do with the stuff (Is my thinking correct here?) * I've found no comprehensive tutorial on all of this, just scattered information all over the web. Is there like a goto tutorial for creating a monster for quake? * Also do you guys have an irc channel to hang out at? IRC chan is http://webchat.quakenet.org/ #terrafusion but it's usually fairly empty. Best to post here most of the time in my experience.
What I do is importing in an existing quake model, and scale/position mine from this one.
You'll need this plugin: http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Quake_mdl Is 24 units below origin.
Small boundingbox is 32 wide, large boundingbox is 64. Small to fit. Preach had a great tutorial on the QuakExpo2008.
This link is now in use for the QuakEpo2016. I think it is somewhere on his site now, you should take a look. Here is a short overview I made of it, still a must have for everyone who wants to make Quake1 models. PreachModel Madfox may have forgotten that he actually helped me put this back online by filling in the gaps in my own archive of the tutorial.
https://tomeofpreach.wordpress.com/qexpo-tutorial/ The version above has bonus "annotations" where I now disagree with something I suggested in the original tutorial, so I think it's worth seeing. Nowadays it might be preferable to do everything in Blender because of the opportunity to export directly (personally I still use GMAX) so there's plenty of room for someone to better that tutorial. Other recommended reading: https://tomeofpreach.wordpress.com/2012/11/24/a-modelling-pipeline/ - how I make models currently https://tomeofpreach.wordpress.com/2013/08/01/skin-maps-for-mdl-format/ - information on how skin maps work in mdl format https://tomeofpreach.wordpress.com/2013/08/19/normals-in-mdl-format/ - mdl format has smoothing groups, get the info In time, when I was making the screenshots I thought myself about industriously because the pages still would be on the QuakExpo site all time.
Now I'm glad they are still be conserved as there is not that much info about the subject. I use it when I'm off line, but the one on the site is much more readable. thank you very much for the link. there's some great info there (the whole site). this saved me a lot of time searching :) especially about animation and qc.
Thanks also for the tip about the -24 unit floor height. That worked well. Already made some progress on the skin.
http://i.imgur.com/rMyzykI.png My UV seams are shit. I need to understand this better. Next time... Also I've tried Krita ( https://krita.org ) for the first time. I was always looking for an opensource/linux-native photoshop alternative but I hate gimp. So far Krita works really well. I myself use the Blender mdl exporter because I love Blender. If you want to add more skins, you have to use Preach's java script. It works well but figuring out how to get the thing to run...I always forget. Something about the pyshell maybe? Or dragndrop onto the pythongui? And where in blang's dame did I install python at again...
Wish it was as easy as just having it as a little exe you dragndrop your I use 3dsmax. I then use the snapshot tool inside 3dsmax that generates a mesh for every frame of animation. I then use Keens Batch Exporter to save each frame to an ASE file.
Then I use NeroMd3 compiler to import all the frames and save it to MD3 which I then convert to MDL using Preaches command line tool. It takes me less than 15 seconds to do all this. I love batch tools. I'll have to check out that NeroMd3 compiler! I've always wanted to add more anims to the existing monsters.
I'm starting again with the basics of Blender again. I'm trying to export/import mdl files but with the plug in I can't seem to handle.
Usually I make my animations in AnimationMaster and export them to 3ds, obj or dxf after first having made my most comfortable base file. Then I import them into Qmle, and start rescaling the base skin tex to heigh 300 x */64. It's my way, as everyone has its own. What I learned is that MeshLab is a good program to help low polymodels turn up right in Qmle. When importing a model from Q2 or 3 they are easy to controll the verts and tris to lower patterns. Where I'm leaning at are the so called *.bhv files that can be imported in Blender. It are drawn movements of easy animations and free downloaded at animation street site.
I'm searching a way to translate these to a model, but it is a rather complicated way to attache the drawn animation to a model. If it would succeed it would be a practic way to add new poses to a model. Import your animations in Blender, make sure to assign the material on it:
1) Go into edit mode on your mesh, and on the properties section click the button with a sphere (Materials) 2) Click the + button near the top to create a new material, then click the assign button to apply it to your mesh. 3) Still in properties, click the checkerboard button next to the sphere (Textures), and scroll the control back up to the top. 4) Click the + New button to add a new texture to your material. 5) Scroll down to Image, and click the picture image. A list of images appears, pick your g_infg.bmp image from the list. 6) Scroll even further down to Mapping, and click the button right of "Map:", then select your mesh to import its UV map (there's usually just one choice). Then export to Finally open the model in QME. If your texture is messy, just import it in there, and save your model. You're assuming his Blender is set to Internal Renderer. If, like me, you only ever use Cycles, you will need to change the dropdown at the center of your files tab (usually very top bar in default blender layout) before you will be able to follow Daya's explanation.
I wish I could follow your edit way, but for now I only can import a single 3ds file into blender.
This is the base file, all add on files clip the first one so I don't see a way to import a cycle of files. http://image.noelshack.com/fichiers/2016/06/1454944158-shotcyclerwip.png
Based on Q2's SSG viewmodel I'd like to collect all the good quality remakes of Quake models that are compatible with vanilla and put them into one PAK. They should also be appropriately licensed so I am allowed to release this collection, naturally with appropriate credit to the original authors.
I currently have the new knight model and the very recent shambler model to put into this collection. What other models could I add? Vanilla Quake only, please. I'll release this compilation via Quaketastic once you've answered my question. And I'll update it later if new models are released that I can add into it. It's nice to have one pak you can just drop into the data directories you want, if for example you want to keep your original Quake files unmodified. There are a bunch of remade models in the Makaqu engine's PAK10.PAK file.
And there's also the dog and the grunt from capnbubs. I found a collection of several models compiled into one package by user NightFright on QuakeOne forums. It doesn't include the new Shambler, since the pack was created last year, but does have player, grunt, rottweiler, knight and rotfish models, and also a knight statue thing for the Mission Pack with the knight statues. (I can't tell them apart anymore. Maybe I should replay them.)
http://quakeone.com/forums/quake-mod-releases/works-progress/9573-authentic-model-improvement-47.html#post157901 The package is at Quaketastic: http://www.quaketastic.com/files/models/auth_mdl11.zip The parent directory has something weird going on. It is http://www.quaketastic.com/files/models/ and when I try to look at it, it just gives me a file whose entire contents are apparently this text: TAh....Who dey waba This isn't how other directories at Quaketastic work. It's a bit weird to say the least. And it does mean I cannot upload an updated version into that directory. I couldn't locate any recent versions of Makaqu to have a look at its models. I will add the new shambler model to this package and release the result in a similar format soon. I don't have an account on QuakeOne forums, but I could see that NightFright hasn't been active there for several months. So, it's easier to make my own version rather than try to contact him and ask for an update. I'll just have to write a readme with appropriate credits, and I'll post an update here. I'll put a preliminary version up on my Dropbox and the nask you folks where I can upload it permanently, because of that thing with the Quaketastic models directory. (Update probably tomorrow.) I'm now done texturing my little model
http://i.imgur.com/rrM3DdG.png This work is really hard. I've learned a couple of things that I might do different with the next model. 1. To start with a concept. Not having any idea what I am going for lead to me staring at the blank texture not knowing how to proceed too often. 2. Work on the whole texture all at once. I did single parts. Then detailed them. Then I was afraid to touch these parts again avoiding major changes. 3. Make better seams. I'm not sure how I will do it but hiding these seams was a horrible task. This probably goes with *1 because if there is a concept I might know spots where it might be easier to hide the seams beforehand. 4. Closely watch the color range I use. I've found myself in not utilizing the full range of brightness values. I confined myself to the upper half. When exporting to quake the whole thing looked off and too bright. Had to use filters to fix it in the end. Up next is animation. I haven't done this before so this might take a while. I plan stick to the original dog monster (regarding ai and animation) just to get it done while not overestimating my abilities. PS: I discovered a neat website called sketchfab. It allows you to share modeling work in 3d. Animation is possible too. https://skfb.ly/KSDT Hey everyone. I had a weekend and did stuff.
I also made a model collection for myself to use with vanilla Quake the Rogue Mission Pack 2 (Dissolution of Eternity), based on a model collection by NightFright to which I added Skiffy's Shambler model. This is a link to the zip in my Dropbox. This isn't a permanent link. https://www.dropbox.com/s/yo98meyxvgrj574/auth_mdl_p12.zip?dl=0 Let me know if this is useful thing to share with others in the current format. I'll do so, and upload them somewhere permanently if anyone else is interested in it. Let me also know if there are any mistakes or problems in the file, or you have some changes to suggest. THere is a readme inside. I decided to not add any models from Makaqu after looking at them. I wanted to keep my package monster and player models only, and I like the ones in the NightFright's collection best. I used the zip format because it's not a large file and almost everyone can unzip it without any special software. So, gimme feedback please! And tell me if there is another place than Quaketastic that I could upload the zip file to. Otherwise that is where I will put it, if anyone says I should do share it with others. I hope it would be useful to others too. the readme says it requires an advanced engine, why is that? I thought most of these were vanilla engine compatible.
It was in the original readme, which I copied as a basis for my own. I took the entry to mean that it is asking whether an advanced engine required, and putting in Any means "No, any Quake-compatible engine will do." However, it's not necessarily how other people will read it.
I should change it to say "Should work with any engine" and test the paks with some other engines besides QS, so I actually have some basis for saying this. I have the GoG version of Quake with some version of DOS Quake to run in DOSBox and Winquake, so if the models work with those, they should really work with anything, right? I'll update the readme and the zip soon. Can't start playing with DOS Quake right now, as tempting as the idea is :) That first pic is some proper late 80s/early 90s golden age Realm of Chaos stuff as I'm sure Shambler will agree.
This is how the dog and grunt models look in GoG-packaged WinQuake or GLQuake. Whatever it is that it wants to run with a glide wrapper. They don't crash the game, but that's not really a good look.
http://imgur.com/fqZczna In turn, DOS Quake 1.08 fails to start when I have the pak file in the id1 directory. Sadly, I can't see what error it prints before exiting. I'd need to find out how to run it from command line instead of in a window that closes immediately, so I might get back to you on how it goes. (The problem might be that the skin is too big?) I have found out that DOS Quake can handle the Knight model by Lunaran, but the Shambler model makes it quit. I worked this out from being able to play on E1M3 in Normal mode (no Sham-Shams) and not in Hard mode (with three Sham-Shams), while using a pak with only the knight & shambler in it. So, I have modified the entry to say it requires an advanced engine after all. Since this is such a minor change, I replaced the previous file, and the link is same: https://www.dropbox.com/s/yo98meyxvgrj574/auth_mdl_p12.zip?dl=0 Please check it out for any dumb mistakes. Is this package worth releasing now? I will upload to Quaketastic and write up an announcement in a couple of days, unless someone suggests more improvements. I made this mostly for myself, but I can share it with the hope other people find it convenient. Small thing really, with all the work being done by the actual modellers. Thanks to them for their work. Btw the gl quake thing could be due to outdated mesh cache -- gl quake stores on disk optimized copies if the model files that it generates only if they don't exist already, so if the mdl file changes and the cache isn't cleared, it looks like gibberish in game. I think you can find and delete the files in a "glquake" folder inside your id1 folder
yeah. here is a demo video
https://youtu.be/sDa8cVHDhP4 Even though this is not the greatest model I feel a great sense of achievement having successfully gone through all the steps to get a model in game. Animation and especially the running/walking ones are pretty hard to get at least decent looking. AI wise the monster behaves exactly like the vanilla dog with a little more health since I didn't want to make anything special except getting it to work. Although I gotta say playing with quakec is where the real fun begins. First thing I did was throwing 500 gibs instead of just 3, which looks awesome. Then I replaced those gibs with ogrenades which in turn was stupid. In the end I left everything pretty basic though. Except for the soundfx (which a buddy of mine made) I used open source software (blender, krita, mdl exporter, fteqcc, slade3) and I didn't need much else really. I'm going to zip everything up (including, qc and blend files) and then upload to quaketastic I guess? I'd very much like to do more of this. Next time with a little more effort. Are there projects in the making that need some models/monsters? I wouldn't want to just create something random that in the end doesn't get used. http://shoresofnis.com/temp/objExport.PNG
mdl -> obj exporting! need to clean up the code and probably fix bugs, but hopefully should have a new download for my shitty model editor soon.... mdl to obj is not overly useful, but might be nice if you plan to kitbash the stock models and want to preserve the UV mapping. necros
Wow, so they put the texture seam on the fiend in the most visible place possible. Smooth. :) In most cases they just cut model in half, so you have front and back UV isle. No packing, no mirroring, ugly seams etc.
http://www.textures-resource.com/pc_computer/quake1/texture/1700/ I think I need to offset all the uvs by half a pixel due to the way quake vs everything else displays them, so that seam is worse than it should be.
but I put it in the wrong directory. I meant to put it in the models directory.
http://www.quaketastic.com/files/mon_knut.zip http://www.quaketastic.com/files/mon_knut.png Can I move it? Maybe it is not the greatest model, but it is working, has its own style and finished. I mean it is not using some placeholder checker pattern instead of texture or same animation for all states.
<cough>write a tutorial</cough> Where would I go if I wanted to find custom models and resources as a mapper? Be it enemies or static meshes. Is there a goto place?
@DeeDoubleU I could write a bit about some technicalities, prerequisites and workflow. But I'm no expert in any of this. flp, preach has some nice models on his website -
https://tomeofpreach.wordpress.com/category/models/ Yes, just write down your experience like in a blog. It's always helpful to others. Also, you can get opinions, corrections...
hey guys, as promised, here's my shitty model editor:
http://shoresofnis.com/post.php?postID=9 to convert, just open an mdl or obj, then File->Save / Ctrl+S. You need to use the file extension drop down. Just typing it in will not work. You can also mess around with UVs a bit too and batch rename frames with a text file. the idea is if you are importing your model with a bunch of separate files, you can do a dir /b in the folder and dump the output to a text file. yes, i know, this is super primitive and just awkward. mainly it was to learn 3D picking and Open GL, but it does let you bring models into your model editing program with their UVs intact, and I think the UV editor is pretty good... oh yeah, you can preview animations by shift+clicking to select multiple frames in the listbox.
also, when exporting to OBJ, only the first frame selected will be exported. Really glad with a new model editor. Surely will try it out.
It's hard to find new Q1 model editors. I was puzzling how far I could go with only two triangles in shape of a squad in Qmle. It seems that without a max or blender I was able to compose e new rune only by adding vertices. J- Rune well.... don't get too excited. my model editor is useless without a modeling program. :(
it started off as a reason to learn open gl and 3d picking. then i wanted to make a better UV editor. then i needed to batch rename frames for sock. then i needed to convert an mdl to obj and preserve UVs for a model I am making... basically, that editor only contains things I needed. i posted it in the hopes that maybe someone else needs the exact same things. :3 @fifth
thx for the link. I just then discovered there is an "older entries" button. @necros the 3d view doesn't work in linux Exception in thread "3DViewThread" java.lang.UnsatisfiedLinkError: Can't load library: I dig the colorscheme of your website though @tutorial I did write the tutorial http://pnahratow.github.io/creating-models-for-quake-1.html and have put some effort into it. It's quite a wall of text. If you care to read the whole thing I'd very much like to hear feedback. oh... that would make sense since the libraries are windows DLLs. :(
i'll try to figure out what I need to do to get it to work in linux. Thanks for logging what you did. It works as an overview that gets one quickly in the right direction. Congrats on the model too.
the
the app crashes a lot on file selection though. https://drive.google.com/open?id=0ByZIVx6Ii7ooVktPX2N5Nk1JSWc I didn't get it to run even after downloading libs because I was trying lwjgl3
it worked with this: https://sourceforge.net/projects/java-game-lib/files/Official%20Releases/LWJGL%202.9.3/ looks nice. And seems handy when browsing animation frames. I'm currently working on some kind of enforcer thingy as an enemy for base maps. I feel like there are a lot of enemy types for these gothic maps but base maps lack visual variety in enemies.
http://i.imgur.com/gABFNPE.png I'm thinking of a bulky guy that maybe alternates grenades and blaster projectiles. Carrying the gun on the side like a minigun. Slow but deadly. Not sure if I stick with whats in the sketch. Armor still seems kind of boring. The description seems like a tech version of the ogre which is pretty cool. Even the quake icon on the chest plate just like the ogre.
Look forward to the progress! I wouldn't mind sharing work on this but the boots are still lacking definition/a general ideas plus I myself would have to do the sideview before I could start modeling.
flp: good concept. Maybe give him a thunderbolt instead of a blaster. Use the thunderbolt on medium range, grenades on long range and a kick as a melee attack.
I'm very happy with the the result.
http://i.imgur.com/VaJcIX2.png I also made a lot of in between saves to document the stages later. I might be able to reduce a little geometry on the boots and then do a weapon. I hope it will fit in the quake poly limits I went with Bloughsburgh's idea about the base ogre a bit and made some sort of chainsaw/grenlauncher fuse.
http://i.imgur.com/MPgv3TR.png but I'm not entirely sure about it. Do you know if it is necessery in quake to merge the model geometry with the weapon? All quake models that have weapons seem to be one solid object. Could I have disconnected geometry in my model? Taking a base frame of the soldier in account show a model, a weapon and a gun blast. The weapon looks attached but it is diverted.
So it is best to keep the weapon apart, and the blast fire later will be used for attack scenes. I just reexamined some of the models in necros editor and they actually aren't connected.
I also didn't realize that there where muzzleflashes. They seem to be hidden inside the model also detachted. Thx, now I know how to proceed. I think I'll stick with it. It's kinda cool.
http://i.imgur.com/OkWRNGx.png Blender's riggify is awesome. Rigging took 10mins and it just works. The model (including gun) currently has 681 verts, 1366 tris which should be just okay. if you are making a muzzle flash, best to hide it in the gun, near the muzzle. some engines will lerp the muzzle flash and if you stick it in the body you can see it moving between those two spots which can look bad.
You are right. It's very hard to get the colors right. I don't even think there's very much blue in quake at all. I will change the weapon. I've tried color picking from the original textures to find base colors. Seems like quake in general is a world of brownish mud.
http://i.imgur.com/SpciqRk.png Model looks great but I'm concerned that such polygon density will cause a lot of the detail to just collapse once you run it through the meat-grinder that is 8-bit MDL vertex precision...
These are just wip shots. The polycount is well in quakelimits and the model looks good in quake too.
The texture resolution is double the targetsize and also in truecolor because thats just the way I paint. There is a lot of detail that will get lost in translation. Luckily this includes some of the dullness and subpar painting. Here's a screenshot of what it will look like after the conversion. http://imgur.com/VHsPzeh The polycount is well in quakelimits
It's not about polycount - it's about vertex density, and you'll only see the collapsing verts once all the anims are done, not with a t-pose test. However, you seem to know what you're doing so I'll stop being annoying now. It's about vertices that are to close to each other?
I actually didn't think about this :( Well I'll just hope for the best then. Basically, imagine finding the maximum X, Y, and Z extents of the model, over all frames.
In each dimension, the vertex coordinates are then quantized to adopt one of 256 values fitting inside the maximum extents. I don't know if I've explained it well, but if you have two vertices that are very close to each other relative to the model extents (remember it's over all frames, not per-frame), then they will collapse. Quote: "I don't even think there's very much blue in quake at all."
http://www.simonoc.com/images/design/sp/1000cuts3l.jpg It should be possible to get rough aproximation with single frame by adding temp triangles on min/max values for each axis extent, correct?
If you can reasonably guess what the biggest mins/maxs are gonna be for the animated version.
Melee attacks and death anims are usually the worst offenders in my experience. @Kinn
thx for the clarification I didn't know that about quake. That's probably why these idle animations seem so wobbly most of the time. Cause the animations are so small that only a few vertices skip the treshold to the next interpolated point. Well I'll make sure there are no van damme splits in my animations. @PyroGXPilot Are those stock textures. The enemies sure seem to pop out of the picture. Hah no they're not stock. :-)
There is tho an interesting amount of blue, red, and green in Quake... it just depends on the episode/theme (and they're all earthier tones of course). For basemap style enemies "tan" is definitely the dominant environment. Wow, thank you @JohnnyLaw & @metlslime, always good to get feedback on my articles, took me forever to create it. Made my evening!
@Shamblernaut
The shirt area needs more detail. As of now the shirt is almost one solid color without dithering. I plan on some leather straps and more variety and then I can get rid of this awfulness. I tried a few different conversion algorithms but I might need to push pixels manually in the end. I've also prematurely documented some of the process while procrastinating. Here's an overview of the stages the modeling went through. http://pnahratow.github.io/chainforcer-lowpoly-modeling-stages.html Here is a timelapse video of some texture painting. https://youtu.be/SlOZWpu9t7o Is there some sort of hybrid between nearest neighbour and dithering that works well?
It's been probably a decade since I had to use the (I'm showing my age a little here) reduce colour depth function in Paint Shop Pro. Also, until I started watching your video just now, it never occurred to me just how silly it is shading on what really should be a dynamically lit model. @ Bloughsburgh, KillPixel
ty, very much! @Shamblernaut ... it never occurred to me just how silly it is shading on what really should be a dynamically lit model I must say I really disagree. Sure eventually you're going to be right. But given the years of ugly plasticy looking video game renderers we witnessed ever since normalmaps entered the jungle the handpainted artwork is one of the reasons why I like quake/old games so much. Sadly, nowadays this kind of stuff has drifted a bit into the cartoonish world of games like Dota or Lol. True, the tech needs to be able to emulate what you would have been able to convey with shading. The benefit is that it is dynamic. Things like the reflection on your models visor should be dynamic rather than static.
But yeah, it was a comment on the ideal situation, certainly not what is best for quake. Strong reflections do look very good in modern games and painting that stuff is in fact silly.
There is an updated version of the Authentic Models package after all. I didn't find it earlier, so I went ahead and made my own candidate version a while ago. This one is dated March 2nd and contains the new Shambler model.
http://www.quaketastic.com/files/models/auth_mdl13.zip I don't need to make and publish my own after all. This one is by the same guy as the previous versions. Hello, I am Hiro-Hamada from Quakeone.com
considering this is a request fourm, here is my request: I am wanting to import a giant crab into Quake 1 darkplaces as a new enemy, and call it 'Macra'. More info about the crab mod here: http://quakeone.com/forums/quake-help/general-help/12114-hello-new-guy-here.html crab can be found here: https://3dwarehouse.sketchup.com/model.html?id=aa0b6c19c73e14c269c25319f5f1c1e1 also, I am wanting to port a Special weapons Dalek that shoots rockets. It is to be a static model Oh! forgot a few things!
here is the special weapons dalek model: both Macra crab and Special Weapons Dalek are from sketchup. also, I want the crab's pinchers (the part connected to the claws) to be a bit bigger, EXACTLY like in this image: http://orangecow.org/who-sprites2/macra-sm.jpg . I also once tried before to put the ^^ This Hiro-Hamada above is a ZDoom modder and he's picked up QuakeC real quick and already made a couple of nice weapon mods (no kidding -- he's a quick study).
He wants to convert models to Told him not too many people who know modelling participate that much @ quakeone.com lately. Can someone give him some pointers? He definitely seems the type that if someone gives him some tips, he might make something awesome. Oh! yes!
I am also a big Zdoom modder! correct you are, baker! I am also a teen with a bit of a short attention span, and big-time autism. So I must be able to understand the explanations fluently. I have decided to do a different type of Macra crab model. The model itself does not exist, but these pictures provide what it looks like. https://whoflix.files.wordpress.com/2015/02/macra-terror-shawcraft.jpg http://vignette2.wikia.nocookie.net/doctorwho/images/0/01/Macra_terror.jpg/revision/latest?cb=20120222195739&path-prefix=es http://www.dalek6388.co.uk/images/macra.png here is how the macra crab moves regularly: watch 11:02 to 11:37. https://youtu.be/1M_t6okgEa0?t=663 To attack, it could reach out and snatch at it's opponent, this crab is not slow, but not too fast. when he dies, his claws slam down, then his anntennes and eyes slowly look down, as if it's a robot shutting down. and That's it for the Macra crab Description. Correction:
tried to turn the grenade launcher into a flame thrower, but failed. all I can do so far, is go into crab model needs more pixel density, less HD crab.
Go on! but flp posted a tutorial recently: http://pnahratow.github.io/creating-models-for-quake-1.html
well, it could be turned pixel density by lowering the model polycount. which crab are you referring to? the one with visible legs, or the one that i showed in the 3 images (the one that has a big mouth, and 2 antennas)
https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Quake_mdl
How do i install the exporter/importer into python. I also agree that the first model you posted was too high poly for q1. The second concept (from the video you posted) looks would fit it to sewer maps or tight maze maps perfectly.
Yes! I think the Classic Macra would fit in good!
but could someone (other than me, for i am not too good at all at making models) make a model for it? I've found out that several custom models out there have inverted lighting normals. This screws up with directional lighting in engines that supports it.
Here's a video. Can this be a Blender exporter issue? Rescaling the model in qME makes qME recreate the lighting normals, but the smoothness across non-continuous areas is lost, so it isn't a proper fix. Ok, so, conidering my last post, what happens if you request someone to do a model the way I did on my last post, by simply asking (after giving info) Also, what is the best Quake 1 map editor out there?
Jackhammer and TrenchBroom are the most commonly used map editors.
http://www.celephais.net/board/view_thread.php?id=60335&start=1284 http://www.celephais.net/board/view_all_news.php Also: you are very new, the emphasis of this thread is more self-help and a good storage of information and helping someone already familiar with modelling figure out how to get them into Quake (which can be quirky). You can make requests, but the thread info also cautions those "may well be met with silence". (i.e. if you are real lucky someone might "do it for you", but those would probably be something like a knight holding a different weapon or something simple and someone owes you a favor or likes your existing body of Quake maps that you have built). You might consider getting familiar with map editors, maybe play some Arcane Dimensions (its open source, has a lot of monsters) and do some QuakeC tutorials. http://www.celephais.net/board/view_thread.php?id=61270 https://www.youtube.com/watch?v=8YsKfkV6LV4 Doom monsters are just sprites right? Quake is far more complex than Doom and you probably should level up on mapping and QuakeC before walking down that hard road. Arcane Dimensions has quite a number of new monsters and the source code is with the download. Arcane Dimensions has so much it can do, it should entertain you. There is also Quoth: https://www.quaddicted.com/webarchive/kell.quaddicted.com/ (Arcane Dimensions has some of Quoths monsters in it). i know that the 3ds to md3 converter i use didn't generate normals at all unless i explicitly clicked a button to do so. i never actually noticed until sock pointed it out to me though.
Ok, most quake modding tools request a file called 'QUAKE.EXE'
What is the 'QUAKE.EXE' Of Darkplaces? now, what are the:
-Base Game Directory -Source Maps Directory and -Model Viewer for Darkplaces Quake 1 Jackhammer? -id1
-where you put the maps you're working on -where you put the model viewer software you're using, like qmE qme 3.1 https://www.quaddicted.com/files/tools
Scroll down to qme https://www.quaddicted.com/files/tools/qme31.zip And if you don't have pakscape already, you better have it available.
https://www.quaddicted.com/files/tools/pakscape-011.zip And probably texmex: https://www.quaddicted.com/files/tools/texmex_34.exe Lastly:
As far as I know TrenchBroom doesn't have docs (nothing does except for ancient Worldcraft 1.6) But entity stuff applies to any editor: Tutorial: http://www.quake-1.com/wc16a-tutorial/ Entity reference: http://www.quakewiki.net/archives/worldcraft/entity/standard/standard.shtm @Hiro-Hamada, I would recommend starting with the design of the monster first before modelling, especially if you plan to create the QC.
Think about its attacks, range or melee or both! Does it have any special ability? jumping, charging or stomp attack! What scale is the monster going to be? Can it fit through small gaps, drop off ledges or will it require special wide doors? What speed is this monster going to be? How aggressive will it be towards the player or other monsters? All these considerations will affect how the monster is used and what animations, sounds and additional models it might need. Already have the monster design (Post # 1296)
It's attacks are described (some sort of claw pinch) a video of it's animations is provided (minus pain, attack, and death) I described how it dies, It's range is a bit far (arm length) It's a bit of an aggressive crab, heck, the pictures of the monster is provided in post # 1296! and I already have all of it's sounds. Additional Models? The best way to do such things is to do it yourself. You're certainly passionate about it, and that's the key to making a really great work. This will motivate you to learn how a modeling tool works, and by working on it yourself you'll be able to tweak all of the little details in it to make sure it'll come out as you expect.
It may seem intimidating at first, but actually it's the best way to get help. When you need to figure out how to do rigging, uv mapping and so on, people can help by giving answers or by pointing you in a direction where you may figure it out. The creative work of translating such technical skills into an artistic design is something very personal, and the quality of the final result tends to be directly proportional to how involved the person working on it is. I recommend taking a look at how flp progressed on his model here for inspiration. Follow his replies to see how things worked out for him. There's a good amount of information in that discussion. https://drive.google.com/open?id=0B9DxOfPvG2G1WlhGNXFNQ2ZieGs
With two finished weapons in about two years, I really like my chances of making a full replacement pack in this century. I Made A New SSG
That SSG model would look lovely in the AD MOD! Is there any chance you could add a second barrel flash for the V model? Also maybe add some more polygons for the firing trigger underneath the barrel for the G model? I made both shotguns a long time ago, but I didn't like them, as well as my SNG concepts, so I was discouraged from continuing. A few weeks ago I dug out the shotguns and thought they were salvageable. Although the work ratio between then and now turned out to be about 30/70%.
I'm still treating UV coordinates like vanilla Quake does, so they may be a little off in GLQuake descendants, but it shouldn't be too bad. Yeah, I guess I could do both.
BTW, I noticed that animation frames and/or coding of the current double shotgun in AD are slightly off. It's possible to release the trigger and still see the muzzle flash without the gun actually shooting. https://drive.google.com/open?id=0B9DxOfPvG2G1aFU2VlJFc1F0ZHM
Seems excessive for MDL and Quake as a whole, but what the hell. Thanks dwere for the model updates, I have added them to the next AD update. If you can mail me some credit details that would be awesome.
Can't think of anyone else to credit. Maybe except Winchester Repeating Arms, because I totally ripped off their 1887 model.
Unless you mean my name, but I dunno. Russian names look funny in English. I was doing some GLQuake skin optimizations, because the target engine is QS. Now I remember why I hate GLQuake.
https://drive.google.com/open?id=0B9DxOfPvG2G1Z3pGNHVGTmF0Qkk
GL-friendly. Don't like the lever, may still try and do something with it. If anyone is using my qmdl python module or the standalone fbxtomdl.exe converter, I recommend you trundle over to my blog and download the new versions.
https://tomeofpreach.wordpress.com/ The new versions incorporate several fixes to make exported models compatible with software-based engines, ranging from optimisations to visual corruption and even crashes! Thanks to Sock for his help in identifying the issues. Can you add a fix for the skin normals?
A while back I've posted <a href="https://youtu.be/a73Z4JxKPko";this video</a> showing the problem. What tool are you using which creates models with the backwards normals? Is it the fbxtomdl tool? Because I don't have the same issues with models I create from the main library.
Those models aren't from me, they're from Skiffy and Capnbubs.
According to the readme, Skiffy used your MD3toMDL tool: http://www.celephais.net/board/view_thread.php?id=61285&start=92 Hi mankrip, can you drop me an e-mail? My address is on my profile. I wanna send you a model which you can check that the normals are correct on. If that's so, I'll need to get in touch with Skiffy and find out what's going wrong. Unless they have the pre-2013 versions of the tool which did have a bug in calculating normals...
https://drive.google.com/open?id=0B9DxOfPvG2G1akY3SXFMV3BaSkE
I'll shove everything in one archive from now on. Making two versions of every model is rather butt, maybe I should stop. Contains recent versions of shotgun, double shotgun, and nailgun. The shotgun has a pickup model that's useless outside of mods. GLQuake reorders the model into the form that it sends to OpenGL (tristrips and fans), the ms2 file is that form cached that to disk.
Both the caching-to-disk (presumably it was faster in '97 to load the file from disk than to reprocess the model) and the rearranging into tristrips/fans are useless nowadays, so no engines do this anymore. Okay, thanks.
I was just searching for a way to include GLQuake-optimized models with regular models in a single package that doesn't require tinkering in order to play with different engines. It was a stupid idea, but I wanted to make sure. This situation with model skins does bad things with my motivation. I wish the habit of shifting texture coordinates died with vanilla GLQuake, but important engines retain it (while other important engines don't), and it's some sort of a standart now (just like not paying attention to garbage fullbright pixels). What do you mean with shifting tex coords? First time I've heard of that. Just being curious...
Software Quake (as well as several source ports, including darplaces, strangely enough) places tex coords between pixels. GLQuake shifts them half a pixel right and half a pixel down, placing them at the pixel centers. Elaborate detailing goes out the window. Fitzquake/Quakespasm are also affected.
Find the Quakespasm thread, do "show all posts" or start at 1 or whatever it is to see every one of the 2000+ posts.
Then in your browser Find look for the word "coord" and you'll find an informative discussion on this from a couple of years ago that discusses the differences that dwere refers to between software Quake and the hardware renderer versions. Do you have techniques to minimize the damage? Or do you just work with one engine and hope your model won't look too broken with another? If it's the latter, then which standart do you prefer?
I was thinking about the former, and I can see a way to preserve symmetry where it's needed, but it'd require constructing the model in a certain way. Simply making something decent is hard enough for a novice, and then I have to worry about all this compatibility nonsense. Why, GLQuake, why? When I made the static entity for a convoybelt the hardest part was to make the cell_ammu blocks correspond to each other.
When they all four made the simultaneously movements and I had it right counting on the framenumbers the different engines all made their own movements. Framegrouping helped, but as each engine treated it accordingly strange effects was the result. I'd go with designing your models with GLQuake in mind, for two reasons. The first is that so many more ports are based on glquake, and they're so much more widely used, that they've become the de facto standard now - even if the software vertex placements came first. Secondly, the software renderer has so many approximations and wobbles when it comes to alias models that it's not going to benefit from that level of care and attention.
As your screenshot seems to be going for a pixel-art look, I wondered if you could try doubling the scale of your skin. So each "pixel" on the visible skin would actually be a 2x2 block of pixels. Sure, you've effectively wasted 300% memory compared to the original, but the GL and Software renderings will be more alike. As a bonus, it might look less "muddy" for people not using nearest neighbour in the GL world. DirectQ and Darkplaces are using the original way of interpreting tex coords, so it's not that simple.
As for your second suggestion - IIRC, the software renderer can't work with skins taller than 128, so I'd have to redo a lot of things. In any case, I'd rather not resort to something like this. Thanks for your thoughts anyway. regarding max mdl skin height.
MAX_LBM_HEIGHT appears to be 480 in winquake/glquake, here. Dosquake had a lower limit iirc. The limits for skins:
In DOSQuake the max is 200px (so 128px is the tallest power-of-two, the largest sensible size) In Winquake, that gets bumped to 480px (so 256px is the largest sensible size) I don't think you need to worry about DOSQuake, I'm pretty sure all the custom software engines start from a base of Winquake at least. For reference, Quoth has included models with 256 pixel tall skins since the first release and nobody has ever complained that it causes a crash. Bit more of a pain that there are non-software engines emulating the old behaviour. For darkplaces you have the option of creating MD3 copies of your models, with UVs that match the GL versions. Which only leaves DirectQ... I stopped using it once development/support ceased. I would like to see quakespasm implement the HUD options that DQ had.
DQII was great, would love to see a final build with some of the loose ends tied up. I remember a request for tree static entities.
I am using some in my new map so they may be also in others interest. Quake trees forest
<a href=""http://home.kpn.nl/lo2kf8/tree1.jpg">for</a> <a href=""http://home.kpn.nl/lo2kf8/tree2.jpg">the trees</a> For some reasons statics that are under 1000verts ans 2000 tris won't show up in fitzquake.
Like these trees, there's one that shuts down fiztquake immediately when added to the progs. It's just the same as the others but it won't fit. if not for the entire tree, just the foliage?
The trunk looks quite nice in those pics, but those leaves aren't so hot. old sprite tree test I guess I'll just leave this here: http://www.celephais.net/board/view_thread.php?id=60831&start=994
Would be nice if more engines supported it :} I like those...
Madfox, the trunks are ok but the leaves being giant squares don't seem to look right to me. I think what you've created would look good if there was masked texture support (where you put a { before the texture). #1372 - Thanks! full-on sprite trees probably aren't appropriate for vanilla quake, aesthetically speaking.
#1373 - those look nice, are the trunks simply brushes? that map reminds of something out of spyro. Has anyone done the conversion of the Quake 1 mdl files into a skeletal animation format? The idea would be to use skeletal animation skinned to a rig that would maintain a fairly close match to the original animations, for use in engines that don't support vertex morph animation.
Thre are engines that do not support changing the values of the vertices of a model? Odd, to say the least...
I converted several Q1 models into an animation studio by using a redrawn base model of (let's say) a death22 pose frame of a monster.
This is done by using a skeletal base bone and attached it over the new base frame. From that point I can change it into any pose and export it into any commen format. obj,3ds etc. So far so good. I'm not familiar with vertex morph animation. I decided to take a break from original content and do something I wanted to do for a long time: touch up the existing weapons so that they look less broken in the modern era of neat, polished visuals.
Then I decided to take a break from that, so I'm releasing what I currently have: all view models except axe, one world model. https://drive.google.com/open?id=0B9DxOfPvG2G1UDZtLXA1MXVSWlE some nice improvements. I like the extra shadows on the NG and RL.
The world LG model is really awesome. Love the little touches you've done there, like the cell ammo on the gun at the butt, super nice. Not 100% sure on the more rounder LG. I think the sharper edges of the original make it feel a bit more violent maybe. It still looks nice but I'm not used to it I guess. I'd say the SNG skin could be tidier on the bottom of the barrel but is otherwise nice. Similar on the SSG, looks better but the texture blending near the bottom of the barrel is a bit too sharp. Cant see what's updated about the GL, it's a shame that the v_model was basically a cylinder. Would love to see a touch more depth to the model? I made a bit of a modification to the SNG skin to demo what I am talking about, it's not super clean because I'm not sure where the wireframe is exactly (lots of trial and error here).
https://www.dropbox.com/s/ykzofayufsec0vs/v_nail2.mdl?dl=0 Yeah, the SNG bothers me too. I probably should've left the bottom connected to the barrel itself on the skin, but I wanted to avoid distortions after having problems with SSG. I don't want the barrel to look as monolithic as on your skin or in Arcane Dimensions, but the parts should be connected in a more natural way.
GL is pretty much the same. The mesh is less crooked, the skin was reorganized, the flash was redone, but those are subtle changes. As for LG, I think it's pretty clear from the skin that those things were supposed to be round. Being square made them weird - I mean, I understand conserving tris, but in this case it looked ridiculous to me. I even considered smoothing them on the pickup model, but forgot. I did notice that you had redone the skins on each model, they're much easier to understand now, less wasted space on them.
I think the barrel of the SNG is probably better smoothed off at the end. It's subjective, I never did like the black holes at the bottom of the originals. Well, the black holes won't be black holes in any case - the main reason for updating the skin was to get rid of them.
http://i.imgur.com/vMJuLHR.png
I didn't want to stray too far from the original designs unless absolutely necessary, but I dunno anymore. From a technical standpoint that is some really nice texture-work. From a purely subjective standpoint it looks a bit like a mans willy... Dr Manhattan's big blue one.
hahaha... sorry, I know you probably don't want to hear it cause you've put a lot of love into it. ;) IMO all of quake's weapons should contain phallic design motifs. The rocket launcher always took pole position in my list of favourite slaying tools, and I like the fact that dwere is enhancing this aspect of the game.
I was well aware that a certain amount of people tend to see things in random elongated objects. When using elongated objects in art, one can only hope that none of those people would be brave enough to openly admit it.
BTW, don't blame me for SSG. It always looked like balls. https://drive.google.com/open?id=0B9DxOfPvG2G1Q2Z2a2Izd0ppWTQ
For those of you who were waiting for the Improperly Aimed Quadruple Dildo Gun: I'm sorry, but I had to partially cover it to avoid AO rating. these are bloody awesome! The b-models are exceptional. I do hope that the grenade launcher gets beefed up a little on the v-model though, it needs to look as epic as the b-model.
Great work so far though! I'm flattered.
I don't know what to do with v_rock. Tried adding a few more polys, didn't like it. I think I shot myself in the leg by making the SNG casing look so elaborate on the view model. Now other things look blocky. There was a high poly one that looked good, cant remember where to get it now though. I think just turning some of the texture detail into actual geometry detail would be enough to improve it.
That's the best solution I've ever seen. Now it's just a matter of adding a small rounding around the edges of the darker gunmetal parts, and it'll be perfect.
I think rounding would be too much. I'd rather leave it as it is (inlaid wood, simple corners), otherwise I'll have to do something with other models as well.
What I meant is to bevel the edges. I didn't know the "bevel" word yet, I'm not a native English speaker.
https://drive.google.com/open?id=0B9DxOfPvG2G1VmI4ck5HcHZ1Ymc
Axe seemed to have a potential to be a giant pain in the ass for a relatively small gain, so I decided to postpone it and go straight to the software mode testing stage. Some of the models crapped out much worse than I predicted, but I fixed the most glaring issues by adding redundant geometry. Fixing the less glaring issues would require adding even more crap and mangling the shit out of skins. I felt bad enough while applying the basic fixes, so I probably won't go any further. Compatibility issues always cheer me up. After days of tinkering in MAx3d I begin to remember what it was to import a quake1 model.
One is to find the right dxf exporter with quads. HDXFEXP Export PlugIn Designed (X) 1999 by hab. Then after boning the model it seems as if the attachment won't bring up an animating scene. The bones animate, the model also, but the animation bar won't respond. It seems I can't make keyframes odf the imported mesh. So I'm saving every frame for free, which is a rather long way for a pose. But yes, I can add new models to an excisting original. stupid ogre http://images.imgur.com/3nldAfK.png
Ironically, I spend 90% of my time tweaking things that 90% of people will never see (this is a FOV 110 screenshot). Just wondering if there is any updates coming on mods or anything, that shotgun looks like it should fit in quite nicely mega/super super shotgun. I'm not saying that ad mod's version isn't good or anything, but feels a bit out of place. It's interesting to know that many of those guns were actually scanned, and they scanned mostly toys when id was working on gun models, so I can't say is that the most professional way to do it.. but I guess that can make quite unique guns.
I think I preferred the symmetrical one. Actually I thought you were pretty much down with the models, I've been using them!
I'm mostly doing compatibility tweaks now, but sometimes I see less under-the-hood things I'm not entirely happy with, so I change them as well.
you need boned?
Static entity of 124 snowflakes on a 512x512 dimension.
Still a small glitch, but if I succeed to break the symetric patron it could have a flakey environement. Flakes are 8vert/12tris, the demo model of qmle. Now there are 21 frames but it could vary to more. If I lower it to half I could dazzle 248. Hey Shambler! I'm afraid it will break when interpolation is enabled. First and last frame will do a weird interpolation, but I may be wrong.
you could solve the rain lerping upwards for one frame by having the drop go to zero scale the frame before and after the upwards lerp.
-metlslime, general abuse thread nice test, madfox. is it necessary for the flakes to be models or could they be sprites? My first test was with a sprite, but as I haven't fixed the viewframe with it, it keeps turning.
When it are models of a small size it's easy to fill up 124 of them or even more. Only bad is animating as the lot gets me dazzled. Strange falling startframe without framegroups. in game I made the flakes smaller so the amount is larger. There's that strangle sizzle in the animation, as if the interpolation slides along the stroll. It makes no difference if I use framegroups or not.
So far I'm glad with the result. Now I bit of turbulence. Because the uniformity isn't great (I know it's only a test). And the white colour doesn't suit the quake aesthetic at all. It would probably work on a whole new palette / texture set though.
http://www.howtogeek.com/wp-content/uploads/gg/up/sshot4d2ab8c3eb126.jpg The concept is interesting to me, I'm fairly sure particle effects would look nicer though. And would maybe be more "quakey". .. are a little bit too organized IMHO.
This would need a little bit more of randomness to show up like real snow fall... anyway... Good try ! Keep it up ! It's a static entity of 90 frames and caused by a qc-file. Result is a coloured skin I added, but my main concern is the interpolation.
I know it's been a point in earlier statics I made, but the ignorant collapsing of the first frame destroys the view of it. It seems to make no difference if I framegroup or not, the first frame keeps on falling back. They are surely too orginized, but I have to take a little care with the amount of triangles. They now are on 1525verts/1830tris. So it's more a case of seeing the engine can handle the lots of flakes. Particle effects would look better, but imagine, this static entity carries 305 flakes. If it would be individual ones 305 entities would be needed. Now they're closed in as one. Just an another stupid idea how to make it more optimal.. would it be possible to make circle raycast check or something, from player to some range.. increasing range more and more, grouping snowflakes and giving them different alpha values.. or just making them much smaller until they dissapear from player's view.. after all player wouldn't notice that if done right. But that should make it much faster I believe.
Hopefully you get the point, sorry my terrible English skills. I trimmed the flakes into a circling motion so the symetry is broken, but by scaling them out the shape of the flakes become to pronounced.
mdl In game the large shape is rather out of place, or I should try to make them smaller. @newhouse- I'm already glad I can spawn the static without typo's. My first idea was to use the viewport to project a transparanr sprite, but that wouldn't have depth. Maybe a sphere that surrounds the player could catch up with a static ebtity, but as far as I know statics are lame. https://drive.google.com/open?id=0B9DxOfPvG2G1Y1BSWmRJMkczY1U
New: axe, grenade, nail, super nail. Changes: - Lots of tweaks. - Played around with Edge Split, mostly for source ports that use Gouraud shading in a meaningful way. - The view weapons should look semi-inoffensive in FOVs up to about 130. In Quakespasm anyway. The value might be lower depending on your engine and settings. Then there are optimizations of various levels of retarted. They were supposed to make the models look better in software engines, Darkplaces, and the like, without affecting how they look in Quakespasm et al. Results: - My sources are a mess. - The result for software engines is underwhelming. - Darkplaces and DirectQ look serviceable. - I introduced a very subtle glitch in the intended engines. Nevertheless, I think it was educational. I probably won't do that again. Making two versions of each model (just like I wanted from the start) would most likely be a better solution. I thought it would make a mess, but now I'm not sure which of the two evils is the better one. One thing the latter approach would certainly help with is getting 100% OK result for each engine (instead of 99% for half of them, and 80% for the other half). One thing the current approach is good for is a partial conversion with maps. I wouldn't want to complicate it with two possible setups. Another reason to not redo everything immediately is the fact that I'd have to go over the skins again just to be thorough. Ugh. Despite all this, I more or less got to the point where I almost don't really hate this thing all that much, so I'm considering it to be one-point-zero. Incredible work Dwere !!
I like them very much. If you need some comparism screenshots or gifs, please visit this page: http://quakeone.com/forums/quake-mod-releases/finished-works/12408-new-faithful-weapon-rework-dwere-da-werecat.html Thanks again, Seven Heh, wow. Thanks.
Yeah, the gifs are appreciated, since I didn't make such comparisons myself (other than between versions, comparing new models to slightly older new models). Very good job, dwere. I'll stick to the hi-poly weapons I have installed but I can definitely see this as a default replacement for id's originals. Well done.
https://drive.google.com/open?id=0B9DxOfPvG2G1YXRNZ0JqQVNHdTg
Fixed subtle glitchy seams where I found them. I'm using Ruohi's. Check this link: http://quakeone.com/forums/quake-help/general-help/10727-definitive-hd-replacement-content-list.html
They're the first entry in the "Weapons" section. Two The link is akward to use, and I need a proper
Please, could you give a link to a proper weapons PAK file for Quakespasm ? Awkward to use? Huh! In what way? I can access the page just fine, even on my phone. The dropbox links to the files are at the top of post #2. pk3 is simply a renamed zip, so you can extract the files and build the pak yourself using a program like PakScape - I have no idea what programs exist on Mac, so the research is up to you. If you still can't manage to sort it out, let me know and I'll see what I can do.
Thanks,
I successfully downloaded both pk3 files and unzipped them. I'm getting several prog and textures files, that I could drop into the prog and textures folders in the id directory, but they don't show in Quake. I'm not even sure that Quakespasm could use them. I'm unable to find any tools on OS X to make them in a proper PAK file for Quakespasm. Is it possible for you to try to make a PAK version for Quakespasm ? That would be great ! Quakespasm complains about the wrong MDL version number. Apparently, these models are in a modified format or something.
I made a pak with the files and tested it in QS. It doesn't work. Apparently there needs to be some modification to the progs.dat to make them work, but this goes beyond my knowledge. Use them in Darkplaces or search for info on how to make them work in QS. I'll upload the pak if you want but besides that, I can't help you further. Sorry.
That second (allegedly more faithful) weapon pack works in QS (unpacked), but the external skins don't load. It makes some models black or indistinguishable from the stock ones.
No need to upload the PAK (unless someone else wants it), since it wont work in QS anyway. This is sad, since these HD weapons look awesome.
It would also be great to have an HD version of the HUD, in Quakespasm (I'm not asking HD textures for the game itself, i.e. monters and maps, since it would look ugly for that old game). dwere, your weapon PAK is working great. The improvements are very subtle, though. Personally, I would prefer some higher HD weapons, since I have them "in the face" constantly, like the HUD. A quick glance at this thread http://quakeone.com/forums/quake-help/quake-clients/12339-quakespasm-hd.html and I found an answer by our esteemed Baker: "Quakespasm doesn't support model replacement textures." There you go. Maybe the Spiked version does?
For QS, use either dwere's pack or NightFright's Authentic Model Compilation. The latter will replace the original models of monsters, weapons and pickups with slightly higher poly versions while using the same textures. Or switch to Darkplaces if you want to dabble in HD content, that's the best solution for now. The improvements are very subtle, though.
Well, that was the point. I haven't tried myself at HD content yet. Well, excluding some embarrassing crap I made when I first discovered Tenebrae. Luckily, I had enough sense in me to not share it with anyone. Maybe the Spiked version does? The changelog doesn't mention it, unless I'm missing something. I'm sticking to Ruohi's for DP but your pack is definitely adopted for my QS. I find yours better than NightFright's, especially the axe, GL, RL and LG. Not sure about the big thingie you added on the handle of the SNG though, but I'll get used to it.
In case you don't know, Seven created this thread http://quakeone.com/forums/quake-mod-releases/finished-works/12408-new-faithful-weapon-rework-dwere-da-werecat.html
There's a guy there complaining that your pack causes the demos not to play on vanilla/PSP. Upon closer inspection (I opened the pak file), it would appear that NightFright's pack does NOT replace the weapons.
I included quake.rc to modify some settings, and I forgot that it was based on an already modified quake.rc that didn't include the startdemos command.
I'll fix it later. That's some rapid development!!!
https://drive.google.com/open?id=0B9DxOfPvG2G1YmNPUmRFMDV4YU0 From the changelog: - Restored the startup demo sequence. - Brought back the nozzles that were removed from the barrel tips of the nailgun (view model). - Fixed fullbright seams on the view model of the super nailgun. I think you should make snow with sprites instead. It's weird to see non-flat snowflakes, and you could use an actual snowflake texture for the sprites. As is, they look more like hail.
As for rain, if it's possible you should make it transparent to prevent this icicle look. Good job anyway. It has rain and droplets when it hits the ground, maybe you should look into that
Does anyone know if there is a simple skin utility to add skins to a quake 1
I did that "refactoring" I was talking about.
https://drive.google.com/open?id=0B9DxOfPvG2G1NC15bnVkRjlmY0U A pixel here, a pixel there.
Well, it's not that subtle, but, honestly, I don't even remember what I did between the latest versions, other than v_nail barrels being redone almost from scratch. They look more or less the same though. Really, 90% of my time I'm dealing with compatibility crap instead of improving the artistic aspect. Rant rant rant. Hah fair enough. It would be nicer to have one set of models really. Loving the models, using them mostly as the defaults now.
Try running the installer in compatibility mode.
Right click > Properties > Compatibility Check the box and select an old version of Windows (probably 95 or 98/ME) or use Compatibility Troubleshooter: Right click > Troubleshoot Compatibility The Quaddicted 3.1 Lite download is a
I use Win 7, all the executables in the What specific file QME 3.1 file is not running? My guess was that the installer in qme30_full_installer.zip was the problem.
Often with older software the installer is more picky about the version of Windows than the program it's installing. I have a strong dislike of programs that insist they must be "installed" and avoid them as much as possible. These new weapon models are great! Not really a fan of the new g_rock (grenade item model) but oh well.
I'll start making new skins for the Mispack2 (rogue) weapons unless you've already started to. Folks at Quakeone already made alternative skins for both mission packs. I still want to make my own versions, eventually, but I haven't started yet.
Not really a fan of the new g_rock (grenade item model) but oh well. I just didn't know what to do with the old design to make it appealing to me, so I started from scratch (not counting a little bit of Q3 for inspiration). I ran the installer in my '98 VM and it went through fine, then I ran the patch so now it says it's 3.1 preview 2. Am I allowed to post a link here? I zipped up the results and I can upload them somewhere if you're still interested Qmaster.
If I were to upload it, what would be a good file host that isn't likely to serve ads or dissappear in the near future. I noticed the http://www.quaketastic.com/ link at the top of Screenshots and Betas, would that be alright? 7-Zip can often open the contents of some installers, if you right-click and go to "7-zip->Open archive...".
Unfortunately the version of the installer I've found "Cannot be opened as an archive". Regardless, there's a link to a fully patched installation in the post above yours so i'm not sure we need to worry too much now.
The handle looks a bit out of place. That's all I have to say, I'm not a model or texture artist.
Extremely newb question:
How do I add a custom (static) entity to a map? I've made a model: http://67.media.tumblr.com/5437614355495b387dea15a1ea6e3b18/tumblr_ofgk3urXGE1usc8qto1_1280.png And I got an add-on for Blender which exports to However, I have no idea have to add a custom entity to a map editor. I tried TrenchBroom, because it seemed the most intuitive, but although I could see a list of entities, I saw no option to add any. Sorry for asking what is probably a dumb question, Help is much appreciated. Quoth:
"classname" "mapobject_custom" "model" "progs/yourmodel.mdl" "spawnflags" "1" // Makes it static https://www.quaddicted.com/webarchive/kell.quaddicted.com/quoth/quoth_tutorial.html#mapobject_custom Thanks for the reply Baker,
I'll try Quoth if I can't get it to work through TrenchBroom. I found this TB addon, however: http://leray.proboards.com/thread/3653/add-custom-models-trenchbroom-1 There's not much of an explanation, but the script format (in the def file) looks like this: @PointClass base(Models) model(":progs/models@bits2@banner@tris.mdl") size(-16 -16 0, 16 16 52) = models@bits2@banner@tris : "" [] So, I thought I could try simply substituting the file path to that of my own. Loading the def file in TB allows me to place an entity named after my file (just an empty cube), but loading up the map (in Quakespasm) I can't find any model. (Also, what's up with the @'s in the file paths? Some python convention?) Tried adding a couple of entities from the normal ID1 def file (with 3D previews in TB and everything), but none of them would show in-game.
You should probably ask map editor questions in the thread for that map editor.
I could tell you how to add a entity to a map, but knowing how to use your map editor of choice is something you have to bring to the party. Yeah, I wasn't sure this was the appropriate place to ask.
>I could tell you how to add a entity to a map I'll try your way if you'd be willing to share? I just want to see if I can have my model rendered in Quake, nothing more complex. If you want to do that and do it fast, use Pakscape to open quake\id1\pak0.pak and delete g_rock.mdl (make a copy of your pak)
Then put your model (renaming it) as quake\id1\progs\g_rock.mdl (make the progs folder). Start Quake, load dm6 and go to where the grenade launcher would be. That would be the fastest way to do what you want. In the future I may need to do this kind of stuff but I intend to map primarily for AD.
Thanks a lot, Baker!
I'll try that! @Mugwump I was trying to edit the AD start.map in TB, without luck. I'm certain I'm just doing something remarkably stupid, though. Yeah, I was using TB2, but hoped that it wouldn't be all that different. The addon seems to work (at leats it adds entity boxes to the entity browser).
Haven't been able to find any other tutorial... Which makes me wonder: How did all you Quake mappers even figure these things out? Back in the day, it must have been an insane puzzle to figure out on your own, but even today there doesn't seem to be much in the way of documentation and tutorials on how to use the map tools online. Perhaps my google-fu is just weak, but I'm quite impressed with you all. Especially if you made maps through 2D views(!). Also, @Baker Found this in the AD readme: "Mappers : The editor : the worldspawn entity to have "no_item_offset" set to 1" Yeah, I suppose I should've just tried a vanilla Quake map. Thanks for pointing this out. If you connected to #Terrafusion on QuakeNet (IRC) I suspect that these things that take you hours to figure out would instead take minutes or seconds because it is real time chat and anyone there has either made 10 maps or played 200 of them.
#Terrafusion was always the IRC home of the mappers that live here. Dwere,
Just want to throw a thanks for your efforts. I really enjoyed the new weapon improvements you made! I just emailed spirit with an updated installed for QME so that it will install on more modern machines.
That was one frustrating 3 hour rabbit hole. Could it be that modern engines (win7) disturb older programms (qmle) to work properly?
IMHO now I understand a bit why my Abe'sOddWorld wouldn't play on OS while it went fine on OSX, I blamed the program. This after trying Wally, Texmex and QME with Win7 and WinXp, older programs work best on what they were made for. So - I have the standard player.mdl, and a g_plasma.mdl, and I got into qme, and merge the g_plasma.mdl into player.mdl because I was to animate it on the quakeguy. The vertices get all fecked up, like so:
[url]http://i.imgur.com/oLYGSfN.png[/url] [url]http://i.imgur.com/bJ54262.png[/url] How do I fix this? What other ways of doing this are there? How did other people do it? Beat way to fix it by move your object ie. g_plasma.mdl upwards.
Then export your all the frames by export multiple frames to another file. Start a new object with import the frame you rised the g_plasma gun. You will get a new model with a better skin file. Import all frames back to the new model file. I uploaded q2mdl29b_alsoq1.zip to quaktastic/tools.
It is Quake2 modeleditor, but Quake1 also. A bit stiffy, but a good reference in between qmle. It might be strange, but quark4.07 was one with the first modelstudio. I use them three when working on Q1 models. @madfox, can you give me a step by step example as I'm not fully understanding what you mean. Thank you
You had merged your g_plasmagun into the player model.
I tried the same appearance as your bj54262.png, loading player.mdl to rockrun3 and merge another weapon in. As result I get a player with the weapon through its head, but on the skinfile I get one weaponskin extra. In your png I see the right plasmagun skin, but there is interference with the player skin. I can't restate the effect you result, as mine show the player with the extra merged weaponskin aside. Can you send me the file of the g_plasmagun,mdl? That was a bit of a hussle. I'm not exactly sure what happens, but for some reason the g_lavagun skin keeps interfering with the player skin.
I tried different placements of it in the merging file, but even from the corners it kept crunching the player's back. For me I wouldn't mind, as it's just a small side of the gun. It takes more time to scale it and make it move accordingly the shotgun.(compare before delete). I don't have an explanation for it, my weapons just load fully aside from the orginal. Solution I found is load the model in the Quark4.07, clip the brushes in the skin view so you see vertex points light. Then slowly turn them back to left so they don't tresspass the ones of the player skin. Takes some skill c0burnplayer https://drive.google.com/open?id=0B9DxOfPvG2G1RDdoY0wtTzU5RW8
Changes: new hand, improved lighting, skin pixelings. The last one cost me the most time for the least amount of visible change, as always. Source files are included. Ignore the hammer, it's unfinished. The stock id1 axe wasn't updated with the hand mesh and rigging improvements I made when molesting the AD axe, so it's a little obsolete. I had to unmangle the original shadaxe from what the MDL format did to it, then the model was animated from scratch, and then it was mangled again during exporting => the shape might not be exactly like it was. Since the hand that I made takes more space on the skin, I had to cut the second side of the blade. I could make the skin bigger, but I wanted its size to be power of two, and preferably not very ridiculous. I wanted to reinclude the second half for the pickup model, but I'm too tired after doing cruel and unusual things to 7 subtly different versions of the first half. http://i.imgur.com/xdBH3Az.png That looks amazing, I use all of your weapon mdl revamps so I am excited to check this out later!
The hand still needs work, I think. It was supposed to be the main (or even the only) improvement, but got neglected in the end.
Dwere,
I want to let you know your SSG model is my favorite. Love the small details done there. And to Skiffy, Your HD shambler is irreplaceable and a must have whenever I reinstall quake anywhere. I hope you are still continuing with the vore work but I lost track of any updates/cancellations. Which one? I made two sets - one stock-ish, one completely different (lever-action).
Regardless, thanks for the kind words. The model with the subtle wooden details on the sides? At least I think it is wood!
Also that reminds me, I recall you talking about some animations or the like you use for Quake and shared them somewhere but I can't find where... This reminds me of the sock's updated SSG in AD (view model). Its forestock looks more like wood than the one on the original id model.
I like it, but it's not mine. I made the 1.5 pickup model though, except the version that's present there is obsolete and I hate it. Also that reminds me, I recall you talking about some animations or the like you use for Quake and shared them somewhere but I can't find where... Not sure what those could be. Maybe someone else said it? Nope it's yours!
I just tested and compared with 1.5 and then adding your pak. I was mistaken, the brown "wood" is from the subtle brown reflection or what have you that the detailing on the sides gives (My favorite part) But AD's is indeed wooden I do see that now. -Hmm, I have no idea about my other question it was just an offering in a random thread...oh well! I created a folder using a static model.
Therefore, a space with an additional block, in which there are two entities with their own skin. The exterior is an animated sky texture space. When I compile the directory without lighting, so good. When I using light, the two models are suddenly the animated sky colored texture, not their own skin. How can I avoid this, or doing wrong? Models take their light values from the surface directly below them. Even though a sky texture is always drawn at the same brightness, that doesn't give it a light level automatically. Replace the sky brush on the bottom of the map with a normal solid brush, add some lights until it is lit correctly and the models look OK, then place a thin sky brush on top of it to restore the appearance.
I placed lights right under the info_static, but for some reason these only give a dim glow.
Covering the bottom brush seem to give the light a chance, but as it's such a large distance, I found my skill with the sky light in worldspan. Thanks for the hint, Preach! starlog I've been modelling quiet some time now for Quake1 models, but there's one thing that keeps on erratum.
After creating my model frames according their position, and adding the corresponding qc in game the model refuses to die. The first hits relate with blood gibs, but after three shots the model just animates on, without dying. model The error is in wocat_die, and it's something that the function is missing. Compare it line by line to shalrath_die and see what is missing in your function.
|
.svg){kind=link}
|
|
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |