I love Portal. 

http://lag.thps3.net/q_portal.php 

is dzip? 

usually used for Quake demos because Quake can access the archive without it needing to be extracted.

But its a bit shit, because if the demo is too big the dzip extra compression stuff (ie. the tools geared towards compressing the demo smaller and better than standard windows zip) are disabled.

I tend to use 7zip for everything to do with Quake; its a good all-rounder that has great compression performance over both zip and dzip in several cases, although you do need to manually extract the archives to use them.

The only compression software that works better in any case I've found (a fair few equal it at times) is winrar - and thats only when using audio files. 

Some of us actually like to have our file browsing tools handle archives similar to directories, so arbitrary compressors are a pain in the ass - they throw you out of your toolset.

if you want to have people actually look at your stuff, provide a zipped/tared version. 

but with regular zip/tar, demos compress surprisingly poorly. They're just immune to the regular lzw techniques. 

But nobody wants massive downloads when a quick compression can save anywhere up to 10 minutes on upload and download, even more for dialup users.

7zip isn't too arbitrary, dzip neither - both being pretty standard q1 formats (ok 7zip isn't as well known, but its a lot better).

You can get away with standard zip of . . . tar? But every now and again it corrupts the compression or something. I've never once had a corrupt file in 7zip - touch wood.

Cue wood touching Jokes in 5 . . . 

"Arbitrary compressors" ... There's nothing arbitrary about the extremely well established and stable WinRar or 7-zip, they just provide superior compression and a wide range of possibilities to get a good compromise between speed and ratio.

Using the 20-year old zip tech is only interesting when you don't care much about compression ratio, want widest accessibility or are mainly targetting users with low computer knowledge.

And even in the latter case, you can just create a self-extracting archive, just like many installers already do. 

usually used for Quake demos because Quake can access the archive without it needing to be extracted.

I think the reason it's usually used for demos is that it was designed specifically to compress quake demos really well. Quake can't open them. If some of the custom quake engines can, that is a recent development and people have been using dzip long before that :) 

can be seen as a multimedia filter wrapped around std zip and usually offers major compression gains while still keeping the speed of zip.

I actually made a brief attempt to see if DZip could be used in conjunction with 7-zip for even more compression, but that didn't seem to yield much. The DZip filter already removes redundancy, leaving little left for any other compressor.

And several engines can load dzips directly since several years; my NehQuake, JoeQuake and any of its descendants. 

1) It wasn't a demo
2) The file is 249,729b large. doubling the size would mean about one more second of download on my line (i can't even save the file that fast), and this is the smallest dsl you can get around here.
3) you can just create a self-extracting archive and alienate experienced/other os users in turn.

i just don't see a reason to use anything else than zip on such small files besides the oss argument (7-zip?). :) 

i found this on another board: http://www.crazybump.com/

it can take a typical shaded diffuse map (quake, quake3) and extrapolate a normal map from it with pretty good results...

on top of that, it can render out the regular greyscale map for regular bump mapping as well as make a fake ambient occlusion map based on the normals of the texture.
i've been playing around with it for a bit, and i've gotten really good results with some quake 3 textures. lower res it has a little bit more trouble, but anything over 128x128 seems to be pretty good. 

Yeah it's nice, good to use along side the photoshop normal plugin to get best results. 

So sup. 

Looks like a viable alternative to the Nvidia toolset. 

to be based on difference-of-gaussian filtration, which I often do by hand when I'm trying to pull a more accurate normal out of a diffuse. (There's nothing I hate more than seeing a brick wall normal map with a ridge at the top of every brick and a trough at the bottom because someone just fed the raw diffuse map into the nvidia plugin.) 

that still happens sometimes with this. it's far from perfect, but much better than just sticking the diffuse in there.

you can fiddle with different levels of detail to bring out (or hide) different aspects of the image. the 'very large' slider will accentuate (usually) the larger differences in height. the 'analyse for 3d' thing is hit and miss. sometimes it works, but othertimes, not so much.

you could probably get a good mix with doing the basic shape of the stuff yourself by drawing the grayscale in photoshop and then mising in the greyscale this program creates, masking out the less good areas or something. 

I've heard alot of arguments about retouching normalmaps; hand painting, basicly. The constant pompous response by programmers is that it's no longer a normalmap if retouched.

I'll be trying this out monday and through the week by which time I'll be (maybe) posting some intelligent feedback.

When putting the diffuse through the juggins of normalmapping are you putting the exact same diffuse or selected layers of it? Obvious question, I think, but I've been evolving methods for a while and how others have approached it is interesting.

Especially when some twat trying to justify thier paycheck by saying everying needs diffuse, normal, specular, etc. Even though on screen its smaller than a little finger nail. 

The constant pompous response by programmers is that it's no longer a normalmap if retouched.

Artists are capable of understanding what a "normalized vector" is and how that translates to color because they're reading the normal map in the first place. Programmers don't trust artists to be smart. :) (and granted, it's usually because artists are putting 2048 textures on things like donuts)

Don't ever just feed the diffuse into the normal map filter. At the very least, pick the color channel that looks the most like a heightmap and retains the least color/dirt/lighting information. Invert it if that helps. But remember that the height map you feed the filter will not look like the diffuse map at all, and sometimes it takes a lot of work with overlays/airbrushing/dodging and burning/etc, but it's always worth it. 

The constant pompous response by programmers is that it's no longer a normalmap if retouched.

Well technically, to be a normal map all vectors have to have the same length, which can easily not be true if you retouch an RGB image. But since those vector components are pretty much passed directly into the dot3 equation, it probably doesn't matter and none of the math really requires that the vectors are all normalized as far as i know. 

But any artist with half a clue will obviously normalise his map once he's messed around with it by hand, so the map is just as valid as it was to start with really.
I pretty much do what Lun says, and I split up my diffuse alot, when I'm making the diffuse I think alot about what different layers I should keep to be able to produce the best normal map, using different settings on each layer as I transform it, and then combining them together. When I have the time I do a quick object in max or zbrush though. 

how do you normalize a normal map -- is there a plugin or filter in photoshop that does it? 

http://developer.nvidia.com/object/photoshop_dds_plugins.html 

ah, I'd used that before but didn't know it could normalize an existing normalmap. 

asset creators already using that four flash camera or some laser scanner or something to make the normalmaps from real world stuff, along with the diffuse ones... specular might be harder?