two apps that would be nice to be open sourced. 

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. 

Would be nice. 

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. 

Thanks for the info. 

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 ^_^ 

Be trying these out today - my skins are typically pretty ugly thanks to bad conversion. 

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. 

wtb Quoth 3 with emitters for steam and splashes and things :P

Also, looks neat to me :) 

love the blue one... the rest not that much...

blue is fucking awesome! 

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! 

Has splash sprites. or particles. 

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 :)