Adventures In Texture Editing

[Grinkles]

Remember those unused Velious helms I posted about a long time ago? I made an interesting discovery today in the Velious files that reminded me of that.

I was looking over the Thurgadin textures earlier and came across the Shadow Dwarf, a.k.a. the Coldain. I saw the usual faces that I was used to seeing in Thurgadin and Crystal Caverns. However, I also came across several faces that I could swear I'd never seen before, and they were ordered differently from the run-of-the-mill faces. I found I was able to access them in-game by 1) opening the face menu, 2) shapeshifting to a Dwarf in Thurgadin, and 3) pressing the right arrow button in the face menu. This is bizarre to me, because no other NPC model I've come across works with the face menu.

Let's get to the pictures. Here's the standard blue-bearded male Dwarf that we're used to seeing in Thurgadin:

Nothing special there, right? Well, this is what happens when I click the right button in the face menu in this model:

Who knew there was a ginger Shadow Dwarf?! And that's not all:

This one looks a bit silly, and its beard lacks the detail that the others have. Maybe it got buried and was left unfinished. Finally, one last one:

Now that's a mustache!

Oh, and there are female variants, too! Here's the normal head we always see in SoD:

And here's the unused second version:

If you think that's unattractive, wait until you see the third:

At least the final female head is passable:

So what's the scoop on these Coldain heads? Were these faces ever in the game on Live? Were the textures dropped into the game files and then forgotten about? Are the SoD staff aware they exist and are at our disposal?

 

[Waldoff]

We made it so you can upload your texture files directly to the forums - so there is no more excuse not to post files with your pictures!

 

[Waldoff]

Just finished repainting frogloks in Mielech a, b and c except for the armored ones (need that file from one of you folks).

Tomorrow I hope to make the Gruploks a little different looking, and make Gruplok slaves look a bit less well kept.

Be sure to thank Grinkles for the frog diversification!

 

[Waldoff]

While I was trying to retexture athica, the little script I was making did not work correctly. Luckily, this is one of those rare times where the mistake turned out better than what you were trying for.

I give you: High Definition Athica 2.0. I highly recommend you put these files into your game directory and take a peek at the new Athica before it goes on the patcher.

This is the future of gaming, people. If for some reason you want to live in the past, you can revert it by repatching you lame-o.

 

[Grinkles]

EDIT: Wow, Waldoff, finally got it working! This is a huge departure graphics-wise from what we're used to, and I can't wait to see players' reactions to it.

 

[Grinkles]

I think the Rock Gem Man (a.k.a. Geonid, a.k.a. Gemathian) texture set is ready. I added two new variants at the end, tweaked the "sand" one a bit so it had some color diversity, and deactivated transparencies for a couple of them. Here's the set in full:

And attached is a fully functional S3D for Crystal Caverns for the staff. It contains all the above texture sets (numbered accordingly) and has already been treated with Zaela's Texture Adder + Transparentifier.

Should I do the same process for other zones that use this model, Waldoff? Wakening/Faentharc comes to mind. Maybe you have a simpler method though for doling out these new texture sets to the various zones that utilize the model. Could we change all references to rgm in _chr.txt files to point to this S3D instead?

There's also, for whatever reason, a more recent standalone S3D for the Rock Gem Man model, but I was thinking we could save ourselves some work if we simply always used crystal_chr.s3d as the referent from now on so we don't have to worry about converting (and then inverting) all the images between BMP and DDS. Besides, the the newer DDS textures are on a 1:1 resolution ratio with the old Crystal Caverns BMPs, so there's no advantage to using rgm_chr.s3d.

EDIT: Attached a functional (as far as I can tell) S3D for Wakening/Faentharc to take care of the Gemathians there.

S3Ds that utilize the Rock Gem Man model that I haven't accounted for include:

• letalis_chr (DDS)
• bothunder_chr (DDS)
• pojustice_chr (DDS)
• poknowledge_chr (DDS)
• potimea_chr (DDS)
• povalor_chr2 (DDS)
• rgm_chr (DDS)
• solrotower_chr (DDS)

I know that Burning Woods/Tears of Elael pulls from rgm_chr, but I can't think of other examples. Is there any reason we couldn't redirect it to crystal/wakening instead to avoid the whole BMP-to-DDS mess?

 

[mechkl]

why woldoff...... why did i trust you QQ...

 

[Vitali]

What even is that?

 

[Waldoff]

What even is that?

The new Athica.

 

[AngryCow]

The new Athica is great guys, you need to check it out ASAP.

 

[Zaela]

Should I do the same process for other zones that use this model, Waldoff? Wakening/Faentharc comes to mind. Maybe you have a simpler method though for doling out these new texture sets to the various zones that utilize the model. Could we change all references to rgm in _chr.txt files to point to this S3D instead?

There's also, for whatever reason, a more recent standalone S3D for the Rock Gem Man model, but I was thinking we could save ourselves some work if we simply always used crystal_chr.s3d as the referent from now on so we don't have to worry about converting (and then inverting) all the images between BMP and DDS. Besides, the the newer DDS textures are on a 1:1 resolution ratio with the old Crystal Caverns BMPs, so there's no advantage to using rgm_chr.s3d.

EDIT: Attached a functional (as far as I can tell) S3D for Wakening/Faentharc to take care of the Gemathians there.

S3Ds that utilize the Rock Gem Man model that I haven't accounted for include:

• letalis_chr (DDS)
• bothunder_chr (DDS)
• pojustice_chr (DDS)
• poknowledge_chr (DDS)
• potimea_chr (DDS)
• povalor_chr2 (DDS)
• rgm_chr (DDS)
• solrotower_chr (DDS)

I know that Burning Woods/Tears of Elael pulls from rgm_chr, but I can't think of other examples. Is there any reason we couldn't redirect it to crystal/wakening instead to avoid the whole BMP-to-DDS mess?

Probably not what you're looking for here, but a few months ago I made a little tool for extracting chr data for a model from a multi-model _chr.s3d file into its own stand-alone _chr.s3d file, including all of the textures it refers to (link). From the point of view of editing stuff, it would probably be preferable to only have standalone files and delete any entries for that model in multi-model _chr.s3d's, so that there really is only one location for it. Adding the ability to remove data for a model from a _chr.s3d to a tool shouldn't be difficult, if desired. Might make loading a bit less efficient, but having multiple different-but-equivalent versions of the same data in different files for different zones is pretty dumb.

Also a few months ago, I made a little proof-of-concept for using animated textures on models. Some zones have animated textures, I figured that the mechanism was general enough to be applied to model textures as well as zone textures, and indeed it was. Anyway, I was thinking of maybe remaking the Texture-Adder tool when I have some free time, and including the ability to add animated textures, if that sounds interesting to you. Just moves through a list of textures every x milliseconds swapping one texture for the next, and wrapping back around to the first texture when it reaches the end. Could do stuff like make little maggots crawling around on a zombie's flesh, or make a rainbow elemental that changes color over time, and so on.

 

[mechkl]

woldaff plays a troll enchanter i heard....

 

[Grinkles]

Probably not what you're looking for here, but a few months ago I made a little tool for extracting chr data for a model from a multi-model _chr.s3d file into its own stand-alone _chr.s3d file, including all of the textures it refers to (link). From the point of view of editing stuff, it would probably be preferable to only have standalone files and delete any entries for that model in multi-model _chr.s3d's, so that there really is only one location for it. Adding the ability to remove data for a model from a _chr.s3d to a tool shouldn't be difficult, if desired. Might make loading a bit less efficient, but having multiple different-but-equivalent versions of the same data in different files for different zones is pretty dumb.

This is a good idea, and I agree with the logic. I've been so frustrated sometimes by making up a set of, say, 20 new textures only to realize at the end that I did it all in BMP and needed them in DDS. That means inverting them all over the X axis and converting them. I realize there are batch applications to do this, but I've had mixed results with them myself. I know you and Reppots have said that simply renaming a file extension without even changing the actual contents/format of an image file works fine, but I get a bit uneasy at the thought of scattering all sorts of improperly named files throughout the S3Ds. I still need to test this on my own though, because it could potentially be a huge time saver. If I try to pass of a group of 30 BMP files as DDS files by renaming the extensions, do I still have to invert them all over the X axis? And would EQGExport still preview an image that has been renamed like this? I suppose I can test that myself later.

Also a few months ago, I made a little proof-of-concept for using animated textures on models. Some zones have animated textures, I figured that the mechanism was general enough to be applied to model textures as well as zone textures, and indeed it was. Anyway, I was thinking of maybe remaking the Texture-Adder tool when I have some free time, and including the ability to add animated textures, if that sounds interesting to you. Just moves through a list of textures every x milliseconds swapping one texture for the next, and wrapping back around to the first texture when it reaches the end. Could do stuff like make little maggots crawling around on a zombie's flesh, or make a rainbow elemental that changes color over time, and so on.

I was just imagining a tool like this two days ago when I was playing with the water textures in Athica/Felwithe. I've found some very nice water texture sets throughout the newer zones, but they're always something like 10 frames long. Original EQ water (which we're stuck with until 2.5, as I understand it) consists of a mere 4 frames. No matter how I've tried to make use of the new water textures, it just never looks right reduced to so few frames. I'd enjoy being able to bump it up to 10 so I could see the new water in its full (if flat and badly animated) glory, but I guess this would be chucked out with the new client in time anyway. Your zombie and rainbow elemental ideas are cool though! The elementals are something I'd probably never try to diversify though seeing as people are split on using the Classic vs. Luclin models, and it looks like those are on the chopping block anyway when the new client arrives.

Also, I have a suggestion for if you do decide to revisit the Texture Adder, which works wonders by the way! Apparently, the Texture Adder only works if the user adds strictly from texture set 00 of a given model. Can non-00 options be grayed out or something, so the texture set count can be seen at a glance without posing the risk of accidentally trying to add from 01, 02, etc? Also, if texture 00 has a hat, texture 01 has no hat (like Grobb Citizen, for instance), and I make my own 02 but want to use a palette-swapped hat from texture set 00, how would I go about doing this? Is there a way to clone just a head shape? (If a person wanted to clone the head shape from texture 01 or 02, though, I guess this would conflict with the "grayed out" suggestion I just posed....)

Still crossing my fingers for drag-and-drop on EQGExport someday. I'm fully converted to it from S3DSpy, which now seems clunky. I could probably also come up with some EQGExport suggestions for your consideration if you're going to update it anytime soon, but in its current form it serves its purpose very well.

 

[darksabbath]

my biggest problem with luclin-era elementals is not their appearance, but the difficulty in quick-click targeting them, if I need to. Trying to cycle using a hotkey to cycle nearby enemies sometimes proves ineffective. So, if the targeting on them was fixed, there would probably be far less people hating on them.

 

[Grinkles]

By the way, Zaela, I have always wondered something regarding animation of pre-Luclin PC models. All male models contain an "idling" animation whereby they drop their arms and take on a more relaxed pose after the character has idled for a short amount of time. Female short races, Trolls, and Ogres also do this. However, the middle-sized races (which all utilize the same animation set) do NOT contain this idling animation for the females. Surely, this must be an oversight on the part of the original devs. Animated emotes such as /tap, /salute, and particularly /eye give glimpses of what an idling pose might have looked like for these female models, but for whatever reason the actual animation was never put in.

I'm curious, is there a chance that the data for such animations actually exists in the files, but that they simply weren't activated or were coded improperly so as not to show? They've done this before. It would be akin to the fact that King Ak`Anon's unique model exists within akanon_chr.s3d (as shown here), complete with texture set, wireframes, transparencies for the crown, and even animation that piggybacks off either the Gnome or Clockwork Gnome models, yet the original devs seem to have forgotten about this and resorted to making him show as a run-of-the-mill Clockwork Gnome in game. So, is there any way of figuring this out using your utilities? Better yet, if such animations do exist and are buried deep in some forgotten corner of the files, is there any chance they can be restored and brought to life for the first time ever for us to enjoy?

 

[darksabbath]

Yes, fix the king, bring him from hiding... so that we may punt him also!!! *evil grin*

 

[Reppots]

It would be akin to the fact that King Ak`Anon's unique model exists within akanon_chr.s3d (as shown here), complete with texture set, wireframes, transparencies for the crown, and even animation that piggybacks off either the Gnome or Clockwork Gnome models, yet the original devs seem to have forgotten about this and resorted to making him show as a run-of-the-mill Clockwork Gnome in game. So, is there any way of figuring this out using your utilities? Better yet, if such animations do exist and are buried deep in some forgotten corner of the files, is there any chance they can be restored and brought to life for the first time ever for us to enjoy?

Don't forget about the King model in Kaladim!

 

[donfolstar3]

Someone needs to make Woldo a proper shield to Captain America around in.

 

[Zaela]

I know you and Reppots have said that simply renaming a file extension without even changing the actual contents/format of an image file works fine, but I get a bit uneasy at the thought of scattering all sorts of improperly named files throughout the S3Ds.

There's really nothing to worry about; it's not like a lot of people are working with these files. I was pretty sure that there were mismatched extensions in some of the official files, and indeed there are: a bit of quick scripting confirms that paineel, warrens, and hole all have files with the ".bmp" extension for what are actually DDS files.

If I try to pass of a group of 30 BMP files as DDS files by renaming the extensions, do I still have to invert them all over the X axis?

No, they only need to be upside-down if they are actually DDS files.

And would EQGExport still preview an image that has been renamed like this?

Yes. It, like the client, looks for the actual binary type of the file by examining the first few bytes of data. Extensions are just hints for humans.

Apparently, the Texture Adder only works if the user adds strictly from texture set 00 of a given model. Can non-00 options be grayed out or something, so the texture set count can be seen at a glance without posing the risk of accidentally trying to add from 01, 02, etc?

I think I'll just let the user decide which texture set to copy from in the new tool, with 00 just as the default.

Also, if texture 00 has a hat, texture 01 has no hat (like Grobb Citizen, for instance), and I make my own 02 but want to use a palette-swapped hat from texture set 00, how would I go about doing this? Is there a way to clone just a head shape? (If a person wanted to clone the head shape from texture 01 or 02, though, I guess this would conflict with the "grayed out" suggestion I just posed....)

Not sure! I'll need to look into how alternate head models are linked to the main one since my first assumption turned out to be wrong.

All male models contain an "idling" animation whereby they drop their arms and take on a more relaxed pose after the character has idled for a short amount of time. Female short races, Trolls, and Ogres also do this. However, the middle-sized races (which all utilize the same animation set) do NOT contain this idling animation for the females.

Not sure here either. Apparently most races share the same set of animation data -- I was having a hard time just finding the main source in a quick check I made a few days ago. Would need some research to figure out, but probably not worth the time.

 

[Grinkles]

Am I the only one able to see the new Santa Troll in his full glory? Some have told me they see him as a blurry mess without a face! I'm not going to spoil anything by posting a pic of what he's intended to look like just yet, but can anyone else chime in on the matter? He's the reason behind the "bad patch" a few days ago that ended up crashing everybody for about an hour, and it turns out the model I chose (Grobb Citizen) is problematic in and of itself in the first place. I had hoped at least most of the kinks had been worked out so people could enjoy Santa Troll's facelift, but I'm not sure we're at that point yet!