Builder Priest

[ascottk]

 

He's up & he'll need some rigging tweaks. The major problem is the legs sticking out of the robe. Also the normal maps are incomplete so the height maps are used.

 

He's using the citywatch's skeleton so he's mostly up to date with the recent animations.

 

EDIT: Not the latest screenshot. Most of the issues in this one is resolved on cvs.

[Springheel]

Awesome! This guy's been one of my favourites ever since the concept art.

[Ishtvan]

Awesome! I also can't wait to see him ingame, syncing now...

[Ishtvan]

This guy looks great ingame! I think one thing that makes Odd's models look so believable is the skin textures. The guy's face looks very believable. I also made the ragdoll breakdance a bit, and didn't notice any problems with the half-cape/shawl. As AscottK already mentioned, there seem to be some missing normals, especially the chain hanging down from his waist.

[sparhawk]

Looks really cool! Thanks for the work! And of course also to Oddity for creating it in the first place.

[greebo]

A triple hooray for ascottk (and one for the builder priest too)! Looks really good!

[oDDity]

THe normal maps aren't incomplete. The two you need are priestbottom_local_combined.tga and priesttop_merged2.tga which are both in the rar files.

No height maps are required, since I already merged the them into the normal maps.

[ascottk]

THe normal maps aren't incomplete. The two you need are priestbottom_local_combined.tga

I can't open this one with any graphic viewer/editor. The gimp won't open it. irfanview says there's no file header, and PaintStar says the "sample count per pixel does not correspond to the given color scheme."

 

Does anyone have a working copy of this?

 

and priesttop_merged2.tga which are both in the rar files.

No height maps are required, since I already merged the them into the normal maps.

This one works.

[ascottk]

I ended up using the gen_bronze material with a custom normal map for the metal:

 

It's not perfect but it's a start

[New Horizon]

Looking snazzy. I was afraid we would never get this guy ingame.

 

Oh, I just noticed this evening that a good majority of the textures on some of the new AI are the big 4 meg versions. We're going to keep all the uber hi-res stuff in a mirrored folder on the darkmod_hires repository on CVS. I set that up with Spar some time ago, but I haven't looked into it since Gil took over the textures...so I'm assuming it's still being used. I hope. Generally, those big suckers can be replaced with 512 x 512 versions.

[Springheel]

I can actually see a clear difference between the 512 and the 1024 textures when it comes to AI. I don't know how big they have to be to get to 4 megs though.

[ascottk]

Looking snazzy. I was afraid we would never get this guy ingame.

 

Oh, I just noticed this evening that a good majority of the textures on some of the new AI are the big 4 meg versions. We're going to keep all the uber hi-res stuff in a mirrored folder on the darkmod_hires repository on CVS. I set that up with Spar some time ago, but I haven't looked into it since Gil took over the textures...so I'm assuming it's still being used. I hope. Generally, those big suckers can be replaced with 512 x 512 versions.

When I first got the citywatch in game I downsampled the textures to 512x512. Who noticed?

 

I can actually see a clear difference between the 512 and the 1024 textures when it comes to AI. I don't know how big they have to be to get to 4 megs though.

Ah yes, Spring did

 

It might be better to use dds on these guys to cut down on the size. Come to think of it, I didn't use the gimp for some of these textures. It's the only image program I have that has the option of using RLE compression or any compression at all. The priesttrim_local (not used by the way ) is the biggest culprit of an uncompressed tga.

[Springheel]

Ah yes, Spring did

 

It's my job to notice.

[New Horizon]

I can actually see a clear difference between the 512 and the 1024 textures when it comes to AI. I don't know how big they have to be to get to 4 megs though.

 

1024 x 1024...unless we were to use .dds. Currently they're TGA, and big as hell. Back when oDD first uploaded the player arms, there was a fairly noticeable delay when you selected the weapons, when I reduced some of the player weapon textures the delay went away.

 

This is just my opinion, but I think the TGA textures are a HUGE waste of resrouces...especially when we could save the same file as a .dds, retain roughly the same quality...and not have as much of a hit when the AI are on screen. When I had my old card installed, I swaped out the TGA's for smaller sized files and it did make a difference. The only real problem with using DDS is that we would need to disable the Ultra settings for Dark Mod, because it only uses TGA's. High will allow for the use of both....so there is really no need to have the Ultra setting. I would actually suggest doing away with TGA completely to be honest, plenty of games use them exclusively and they look fine. When TDS uses 512 and 1024 textures....not the over compressed 512's/ 256's that they used in the end...it looks fantastic. I don't see a reason why we shouldn't use them exclusively.

[New Horizon]

It might be better to use dds on these guys to cut down on the size. Come to think of it, I didn't use the gimp for some of these textures. It's the only image program I have that has the option of using RLE compression or any compression at all. The priesttrim_local (not used by the way ) is the biggest culprit of an uncompressed tga.

 

Yup, dds is really the way to go. Don't bother with RLE, I learned the hard way that cards aren't able to read them...and the textures have to be expanded to full size again at load time..it's only good for saving disk space. DDS doesn't get blown up again, so we save on load time...and processing. We'll have to take measures to remove/disable the ultra settings though, as the dds would be ignored if it is set. That's why some were having issues with bonehoard.

[OrbWeaver]

I don't see a reason why we shouldn't use them exclusively.

 

The problem with DDS is that the compression can look really ugly on normal maps -- look closely at some of the TDS textures at an acute lighting angle and you can see lots of little squares where the 4x4 pixel block compression is working. There are also certain diffuse textures which don't compress well, for example a bright red diagonal line on a white background without any detail or noise in the texture.

 

In our case DDS is probably valuable as a means of reducing download size, but there is good reason why vanilla Doom 3 provides TGA versions of textures (although IIRC, we are only using DDS for diffusemaps not normalmaps).

[Springheel]

Well, it would be interesting to run some tests and see exactly what the framerate did when going from tgas to dds. If it had a positive impact on framerate when lots of AI were onscreen it is probably worth doing.

 

Although it might mean a lot of work switching materials over. It might not though...sometimes D3 ignores the file extension for assets, so as long as the textures had the same name, it might load the .dds without being told.

 

I still get an immediate crash if I try to run the map in fullscreen mode. Something about the DDS textures and some combination of my ATI Card, Drivers, or the D3 renderer settings.

 

Though we'd have to make sure .dds files aren't causing problems like above.

[SneaksieDave]

Yes, I'd noticed some time back that there were some "too big" textures in the folder(s). DDS works fine for architecture and the difference is pretty much imperceptible. A reminder and warning though (OrbWeaver is correct): keep the normalmap versions as (perhaps lower resolution) TGAs; there are some cases where, for whatever reason, some systems can't used compressed normalmaps (case in point, my previous videocard, despite running D3 just fine).

[New Horizon]

In our case DDS is probably valuable as a means of reducing download size, but there is good reason why vanilla Doom 3 provides TGA versions of textures (although IIRC, we are only using DDS for diffusemaps not normalmaps).

 

Doom 3 uses a special compression technique for DDS textures, so you don't get the artifacts. I never had any problems running doom 3 on my old card. If I wanted to play the game at a faster frame rate, I always dropped it down to low settings...this would scale all the textures down to very low res dds files. I didn't see any nasty artifacts that usually appear from compressing them...like you do with JPEG. TDS normal maps were all dds as well and they didn't have any weird banding...they were blocky, but that's just because they were low res. Doom 3 uses them all the time, speculars too. I'm not saying we should reduce our textures to 256 x 256 like TDS...I'm just saying we should use dds to keep our textures at higher res. It will definitely save on some processing power. I think the issues with some of the compressed normal maps may have been that they weren't compressed properly with the compressonator. I'll run some tests on my system, and post a dds_testmap.pk4 for people to try out, using nothing but DDS. We'll see what issues cause it to break. I would like to get down to the bottom of what is causing issues for some people, as the dds files should work right across the board. I think it might just be stray settings somewhere.

[OrbWeaver]

Doom 3 uses a special compression technique for DDS textures, so you don't get the artifacts.

 

It does, but the technique it uses is specific to the graphics card -- there is one technique which ONLY works on newer cards and another technique which ONLY works on older cards. That is why in the previous tests, it would either work for SneaksieDave but nobody else, or everybody else except him, depending on which technique was used.

 

This means there is a choice between (1) not supporting pre-DX9 cards, which is feasible given the expected release date of the mod, but might be seen as uncharitable, or (2) not using DDS-only for normalmaps.

[New Horizon]

What was the optional technique? I'm only aware of the official iD technique of using the compressonator....which is what iD used for all their DDS and they worked fine for Sneaksie.

[sparhawk]

... or (3) provide both sets of textures. Not that I would advocate this, but it would be another solution.

[New Horizon]

... or (3) provide both sets of textures. Not that I would advocate this, but it would be another solution.

 

It's the current solution. It's just something I'll look into on my own. I'll report back what I find.

[OrbWeaver]

What was the optional technique? I'm only aware of the official iD technique of using the compressonator....which is what iD used for all their DDS and they worked fine for Sneaksie.

 

It's the options provided to the Compressonator which are important. For DX9 cards (those that can run fragment shaders) Doom 3 uses RxGB compression which swaps the alpha and red components of DXT5 in order to improve quality, requiring the fragment shader to unswap them. The pre-DX9 cards used something else, whose details I am not fully aware of, because there are no fragment shaders to do the swapping.

[SneaksieDave]

Also keep in mind that old card is fried and replaced, so I can't verify either way anymore - so we run serious risk of excluding a fair number of people from TDM unless we can find someone who can repro the situation and test with him.