|
Post by ksquared on Sept 4, 2010 16:56:10 GMT -5
So here is a simple tool for replacing textures in RigNRoll. There is a text file with the program that explains how to use it, but if anything isn't clear, feel free to ask questions. Two things to be aware of. There are two copies of texture for each truck. I think it might depend on which graphics settings you use, and on whether it's your truck or an AI. To be safe, replace both copies. Another thing is how the alpha channel is used. It's not transparency. The value sets reflectivity. So something 100% opaque in the editor will be 100% reflective in the game. Id est, your texture won't even be visible. Take a look at values used in the exported textures, and start with these. Here is an example of what the final result may look like. As you can see, fine detail doesn't come out very well. Probably my fault, because I wrote DXT compressor in a hurry. I'll try to add support for importing .dds files, so that you can use a proper tool for DXT compression and mip mapping. (There is a good plugin for GIMP, which is free.) Watch this space for updates. UPDATED LINK -- NOW WORKSAnd here is the download link for the tool itself. wdbTextureLet me know if anything is brok'ed.
|
|
|
Post by Hardtruckisthebest on Sept 4, 2010 17:51:14 GMT -5
Looks like its working! The only problem seems to be, that it distorts the image slightly, so the rivets and such dont line up.. hard to explain, check my pic: is this a hard fix?Nevermind that, the shift is caused by using DXTBMP. When I use photoshop, there's no texture shift. proof:  The only thing I wonder, is if you could help us eliminate some of the loss of quality K^2...  Otherwise its awesome!!
|
|
|
Post by Derrick...ツ on Sept 4, 2010 17:54:38 GMT -5
I am deff keeping a copy for backup incase this get's lost. I wonder how many people will love you for this, And hopefully it fixes the gloss issue what them stupid tards did.
|
|
|
Post by ksquared on Sept 4, 2010 18:46:12 GMT -5
The only thing I wonder, is if you could help us eliminate some of the loss of quality K^2... Well... I can explicitly search all possible combinations in color space. (I'm currently making a "guess" based on average and deviation within the block.) There are 65k of these. Not too bad. But it has to be done for every 4x4 block of pixels. So we are talking a few hours of import time on a good computer. Superb quality guaranteed, though. Next best thing would probably be to export a .dds file in correct format, and I'll write code to import these. Problem is that you'd have to enter correct compression. There are DXT1, DXT3, and RAW textures in the resources. You'd have to guess correctly which one it is, because that info isn't saved anywhere past export process. Of course, all of the truck textures are DXT3, so if you just want better quality truck textures, that's the best way. I'll sit down and look at importing .dds files tomorrow.
|
|
|
Post by Hardtruckisthebest on Sept 4, 2010 21:31:42 GMT -5
I'll sit down and look at importing .dds files tomorrow. That would be awesome. We've been using .dds DXT3 for 18 wheels of steel, and there is some loss of quality but not much as long as its only exported once. I wish we could up the size of the textures in rnr, from like 1024x512 to 2048x1024 or something.. But until we can change 3d meshes, there wont be much of a need for high-res textures either.
|
|
|
Post by ksquared on Sept 4, 2010 22:38:22 GMT -5
Some quality loss is inevitable with DXT3, but I think it can be improved even compared to some standard algorithms. It's all a matter of quantifying what the "best quality" is. I'll play with it a bit more, see if anything comes out of it. Maybe I should try throwing it into frequency domain...
I'm really not sure about sizes. When writing a texture of the same size, I simply write new data over old data. That's easy. Everything outside of current texture is exactly the same. If I change the size, all the data after this texture has to be shifted. Now, I can adjust the offsets in the file table. That's easy. But there is still a huge section of the header that I don't know what it's all about. And there is a second blank file table following the data. I simply have no idea how shifting things around would affect the game.
On the other hand, it's not that difficult to code for. So maybe that's another thing I can try. If it works, it'd allow textures of arbitrary size. If not, well, I'll just keep it as it is.
As far as meshes go, it's such a mess. There are certain optimizations in DirectX9 that forced people to switch to a really messy format. But here, I see things that don't even make sense with DX9 rendering. The triangle index lists have some arbitrary gaps from one vertex array to another, and if there is a map of offsets somewhere, I can't find it. In addition, there seem to be some transforms applied to the vertex arrays, which I can't find either.
|
|
|
Post by HighRoller on Sept 5, 2010 9:59:39 GMT -5
Welcome Sir...And thank you very much for your time and efforts.  This is a major step.
|
|
|
Post by Hardtruckisthebest on Sept 6, 2010 14:44:32 GMT -5
were you able to do anything with this k2? I noticed that when I replaced all the pictures for the cargos (they display in the warehouse screen and on the trailer) if I clicked too many times my game would crash. But when I put the original ones back in, I could click on the cargos as many times as I want. But file size seems to be the same for the edited ones or the original... Maybe when you improve your filter, that wont happen anymore  It happens with the interior files too, when I changed the interior texture, and in the truck options if I flipped through the different interiors a few times, game would crash to desktop.
|
|
|
Post by HighRoller on Sept 6, 2010 16:19:20 GMT -5
I had the same results...More than 1 or2 cycles thru them seems to kick you to destop...Also i noticed that the different paint types seem too be the extra images...I'm sure i am not the only one to notice this. But i put pete emblems on the freedom...only on one image and when you pick that skin it has them, until you change it to chameleon paint or metallic i think...was up all night so i believe that is correct. I used psp5 Btw...just to put it out there...and paint works as well...Other than that no trouble at all. Very simple.
|
|
|
Post by ksquared on Sept 6, 2010 22:03:13 GMT -5
It is entirely possible that I made an error in amount of data written. (It still wouldn't affect the file size.)
Could you tell me an example of a specific data .wdb file and preferably specific image numbers which you replace that result in a crash? I'll take a look at these, and see if the program overwrites something it shouldn't.
And no, I haven't had a chance to implement DDS support yet.
|
|
|
Post by Hardtruckisthebest on Sept 6, 2010 23:09:45 GMT -5
It is entirely possible that I made an error in amount of data written. (It still wouldn't affect the file size.) Could you tell me an example of a specific data .wdb file and preferably specific image numbers which you replace that result in a crash? I'll take a look at these, and see if the program overwrites something it shouldn't. And no, I haven't had a chance to implement DDS support yet. Well, if you want to be specific, do this: 1. Go to the truck "Titan Alpine", 2. open the cabin_res WDB (The interior textures). 3. Find the image with the steeringwheel and dash wood 4. draw something on it,, and repack into the cabin_res.wdb When you run the game, go to "single mission" then "select vehicle" then "restyle vehicle" and in the drop down menu for the dash wood, flip through them a few times. Click on the one you modified, then click on another, then click on yours again. Then the game will crash to desktop. It's kinda unpredictable.. You can even try it with the paintjobs for your truck.. change a paintjob texture, and then flip through the paintjobs in game a few times and it'll crash. Hope that gives you an idea 
|
|
|
Post by Hardtruckisthebest on Sept 7, 2010 22:44:31 GMT -5
sorry gang, link was down. updated
|
|
|
Post by ksquared on Sept 8, 2010 12:15:02 GMT -5
Well, all of the headers are in the right places. So it doesn't seem that I screwed up formatting. The only thing left that might be making a difference are the transparency tables. I don't see a way of fixing it without spending WAAAAY too much time on it, but the DDS version might take care of it on its own.
So what I'm going to do is finish the DDS version, set it up to both export and import .dds images, and see if it takes care of the problem.
|
|
|
Post by Hardtruckisthebest on Sept 16, 2010 23:36:22 GMT -5
Are you still working on this K2?
I've got a better way for you to debug this program. If I edit any file inside of a .WDB belonging to a truck, that truck will crash the game if I make a save-game with it.
I know now, because I made a save-game with my t2000, and when I went to re-load it, game would crash to desktop. So I tried replacing the WDB files for the t2000 with the original ones, and then savegame loaded properly.
Also, let's say I changed something on the red paintjob for the t2000, and all the other paintjobs were left alone, and I saved a game with the green t2000, or any other color t2000, the savegame would still not re-load. Just because another file inside the WDB was changed.. you know what i mean?
Hopefully you can work something out for us here.. thx
|
|
|
Post by ksquared on Sept 17, 2010 2:01:06 GMT -5
Hm. Even if you only make changes to the skin of the truck itself?
Since I did check the boundaries (nothing is written outside of the texture data) and I was able to reproduce the crash anyways, it means that changing the texture data is really responsible, and not some error in programming. That's bad.
I thought it might be something with alpha, but if you can get a crash with the screen, where we know that alpha channel is used for chrome, then this is really, really bad. There might be some hashes or CRC checks that I'm not paying attention to. I really hope that's not the case, because I have no clue where to start looking for that.
P.S. I did just discover that I was parsing WDB files completely wrong... But it still wouldn't have any impact on the textures.
|
|