Help with an experiment

[ahaigh01]

but Unreal is acting like it needs to have them actively loaded to memory first with a hardcoded reference before you can assign the textures.

That's a drag. I was hoping that wouldn't be the case. The originals are only a few megs altogether, but the new ones... yikes!

[ahaigh01]

Ok, I have renamed all the textures in the tree to:  S3_filename.bmp

Here is a link to the file:

http://www.streamload.com/kkorker/unreal/S3_UnrealShare_tree_normal_textures_renamed_to_S3_.zip

So far I haven't tried to build any new utx packages yet.  I'm still having the issue that Diehard pointed out - when I open up a dds texture that was made as alpha, there is no alpha channel.  It seems that the alpha channel gets tossed out every time.  Diehard, could you test one of my files and see what you get?  It contains the PSD and the DDS that was made from it.  Here is a link to one of them:

http://www.streamload.com/kkorker/unreal/JTree101_Mask_example.rar

[DieHard SCWS]

I may have been on the wrong track  :-/


When i save them, and re-open them, they do lack an Alpha channel..............


I opened several Alpha channel DDS files that already are saved and ready for packages, and all show no sign of an Alpha channels, therefore i asume the Alpha channel is there in the file alright, but embedded and can't be recalled by Photoshop (weirdly enough).


I never check my own files like i did on yours, just to see if all was correct and you did save them correctly, since this was new to you. And thats why i noticed there were no Alpha channel............



After compiling the package, and than use UTPackage tool to extract them, it sure enough contains an Alpha channel, which means you prob did it correct all the time  :-[




My bad, sorry............


I guess you learn everday new stuff, even there when you don't expect it.
.
.
.

[ahaigh01]

Cool, thanks for checking. Everything is working ok then.

[ahaigh01]

OK, I've made the 2 S3_UnrealShare.utx packages - normal and S3TC versions with the new plants and trees textures added. They seem to work fine for me. If they check out and are ok, BOZO should be able to use them to continue his work.

http://www.streamload.com/kkorker/unreal/HighRes_S3_UnrealShare.rar

http://www.streamload.com/kkorker/unreal/Normal_S3_UnrealShare.rar

[BOZO]

Thanks for producing those. I've been very distracted lately but will try to get back to this project as soon as possible.

[ahaigh01]

Hi all,

Well, I haven't been doing much with Unreal high-res texturing for the last 6 months or so. I'm just checking back in to see whats going on in this forum. Doesn't seem to be much activity lately. I would still like to see something happen with this "experiment" we were going to work on, if possible. BOZO, are you still around? Hi diehard!

Best,

ahaigh

[DieHard SCWS]

Yep i am still around


If you havent been hare in six months you may have missed the last updates i released a couple a months ago.

And i guess i am curious too how the experiment worked out ?

At this moment i am still working my @$$ off to get the website redone, and i am working on the SGC map textures. The URProject is more or less on hold for the moment, but i will go work on that again after SGC is being released.


Actualy i can't wait to go back on the Skaarj package, i would love to go work on those and get the whole package done
.
.
.

[BOZO]

Unfortunately this year I had to drop all of my Unreal development right where I had left it due to many real life issues.

I bought a new house, moved, am still working on getting my old house ready to rent, the company I worked for was bought out by Sprint/Nextel and I have been dealing with all of that hassle, and my wife is pregnant with our second child (due in about two weeks) and has had a very difficult pregnancy.

Needless to say, Unreal has been way on the back burner since around May. I think next year I will be able to get back into working on some development and I plan on starting with this project once more as my first priority. I know folks are interested in many things I had been working on early last year and I hope to take them up once more. I have not left Unreal by any means (although that Gears of War looks pretty cool).

[DieHard SCWS]

Can't argue with real life lol. Thats still there and needs to be lived too

In that case hopefully everything will work out for you, and on forehand, congrads with the new little one  :D

As said my biggest timeproblem lies in the SGC map, but thankfully the end is near. And when that is done i will be working on the URP project with full throttle.
.
.
.

[Raven]

Can I use this cool plant skins in The Chosen One UT'99 mod?? In case someone didn't hear about it here's a link: http://mods.moddb.com/6265/the-chosen-one/

[DieHard SCWS]

I don't have any problem with it, and i doubt Ahaigh will too. But the High Resolution versions are his. So you have to ask Ahaigh for permission.
.
.
.

[ahaigh01]

Raven,

I answered your post in the other thread, so this one stays on its original topic.

[DieHard SCWS]

Raven,

I answered your post in the other thread, so this one stays on its original topic.

In that case you may want to repost the complete answer here too
.
.
.

[ahaigh01]

Good to hear everyones doing well. I've been busy too - changing jobs and careers. My kids and I have been playing unreal coop lately and having a blast - 1 kid was just born around the time unreal first came out, and the other wasn't born yet.

[BOZO]

Just thought I would pass on a bit of an update.

I am finally through most of the real life things that has been eating all of my free time and am able to get back to Unreal development work.

I have a very rough mutator approach that is currently working (with a ton of bugs and operating very slow at the moment) that is doing the texture replacement on existing meshes where the server side of the equation if very minimal. The server side basically just looks for new players jointing and creates an autonomous client side and controlled texture replacement class that runs everything from the client side only. There is no currently no replication required from the server to client to adjust textures for the classes I have been investigating. Everything active with the texture replacement operates client side only. I am making it so each client can be running a completely different texture package from any other client since each is client side configurable via a *.ini file. Thus different amounts/versions of S3TC texture files can be in operation on each client and will still work fine. (IN THEORY) It should also run just fine on standalone also. I have also worked past the requirement to have a reference texture loaded at runtime. Everything is dynamicly loaded.

I would guess that I can get something available for limited testing by the public in a couple of weeks.

[DieHard SCWS]

Well that would be cool


On the other hand, Smirftsch mentioned he may be able to change the Mergertool so it can handle .u files as well.


http://www.oldunreal.com/cgi-bin/yabb2/YaBB.pl?num=1139172605/45


Not sure how far he is with it. In any case it would be awsome if other than the plain utx files could be updated, same goes for wet textures and such.
.
.
.

[BOZO]

Ok I have run into another snag that may put a dampener on things.

I am having issues with loading the DXT1 textures onto meshes. They will load and display correctly but the Texture Mapping Time has increased by a large factor.

You can test for this time increase by running from the console the following command:

STAT MESH

The TMAP field gives you the time required to draw all of the meshes on the screen.

TEST CASE 1: Takes 23 times as long as standard mesh to render.

ORIGINAL TEXTURE / FINAL TEXTURE
128x128 1024x1024
TMAP=0.3 TMAP=7.0
PCX DXT1


TEST CASE 2: Takes 100 times as long as standard mesh to render.

ORIGINAL TEXTURE / FINAL TEXTURE
256x256 2048x2048
TMAP=0.3 TMAP=30.0
PCX DXT1


Now some good news.

If the higher resolution texture is PCX no additional time seems to be required to render.

TEST CASE 3: Takes same amount of time as standard mesh to render.

ORIGINAL TEXTURE / FINAL TEXTURE
128x128 16x16/32x32/64x64/128x128/256x256/512x512/1024x1024/2048x2048
TMAP=0.3 TMAP=0.3
PCX PCX

I currently don't believe I have a test texture package containg DXT1 files at different resolutions to use for a thorough test to see if this is just a general problem when switching from PCX to DXT1 or if it is a resolution switching thing. Can someone produce a test package that includes multiple DXT1 versions at all of the various resolutions I was testing above: 16x16/32x32/64x64/128x128/256x256/512x512/1024x1024/2048x2048.

Thanks!!

Making great progress with this. I think most of my slowdown that I was trying to track down actually came from this issue. If we can work around it easily then we will be in good shape.

[DieHard SCWS]

You want all the textures look the same, or do you want noticably different ones for each size ?
.
.
.

[BOZO]

I will specify the texture to use in my ini file so it doesn't matter if they look the same. Try to make the texture names descriptive so it easy for me to remember waht resolution I am looking at though. Thanks!!

[DieHard SCWS]

Ok, i create two test packages for you:

[url=http://www.celticwarriors.net/Downloads/Research/Textures/Normal/BOZOStuff.zip]Normal Version[/url]

[url=http://www.celticwarriors.net/Downloads/Research/Textures/S3TC/BOZOStuff.zip]S3TC Version[/url]

I named all textures like follow:

ACrate2_16
BCrate4_32
CCrate8_64
DCrate16_128
ECrate32_256
FCrate64_512
GCrate128_1024
HCrate256_2048
ICrate512_4096

For the texture i used one of the crate textures for SG1.

First number is the BMP filesize. second number is the 24Bit DDS file. Additinally i added A, B, C, D, E, F, G, H, I in front of each texture to make sure they appear in the correct order in the editor.

I also added the DDS size readable on the crate, of course the smaller textures it will get  unreadable because of the texture size, but its there never the less



General Note: I do not give permission to use this package in an actual map, at least not untill the DmSG1 is released (and than this package would be obsolete anyway because those package contain the actueal usable ones) . Its for testing purpose alone.
.
.
.

[BOZO]

Thanks!! Downloaded and will begin testing with them tonight!

[BOZO]

The Normal package has the wrong resolution textures loaded in it.

Looks like you accidently provided the 512x512 version of the texture and called it the 4096x4096. All other textures provided for that package had this same problem.

The High Resolution package seems to be loaded fine. I ran the tests again replacing a P8 encoded (PCX/BMP/TGA) texture with the DXT1 replacements and got the following load times:

Base TMAP time = 0.3

A 16x16 FAIL - GPF Direct Draw Texture Load Problem.
B 32x32 TMAP = 0.4 INCREASE = 1.5x
C 64x64 TMAP = 0.5 INCREASE = 1.67x
D 128x128 TMAP = 0.55 INCREASE = 1.83x
E 256x256 TMAP = 0.8 INCREASE = 2.67x
F 512x512 TMAP = 2.0 INCREASE = 6.67x
G 1024x1024 TMAP = 7.0 INCREASE = 23x
H 2048x2048 TMAP = 30.0 INCREASE = 100x
I 4096x4096 FAIL - GPF Direct Draw Texture Load Problem.

The results are about what we were getting with my limited test earlier. We are seeing that no matter the resolution we are using as a replacement we will see an increased processing time. This leads me to think that the Unreal Engine is recalculating the required texture mapping assignment on the fly each frame.

Note that the GPF only crashed the client. The server was completely unaffected by the client rendering problems. I think this is a hardcoded limit in the conversion process causing the problem.

I am doing some conjecture here but I think that if you have a DXT1 texture assigned to a mesh at compile time then I would see the same processing increase if I tried replacing it with a P8 texture. We should also see no net processing increase time if a DXT1 texture is replacing it. I will try a test case to see if this is correct.

My guess is that a DXT1 texture and a P8 texture will end up using a different method of creating the assigned meshmap that is used to map textures to meshes internally. Unreal sees that the wrong meshmap base type is trying to be applied and recalculates the meshmap settings on the fly for the other type.

Smirftch, I think it might be worthwhile for you to review the texture mapping code for Meshes and LOD Meshes and see if my guess is correct. The only thing I can think of doing is possibly trying to come up with a means of assigning multiple meshmaps (P8 and DXT1) to the same mesh. Otherwise we may have to go with using High Resolution P8 textures.

[DieHard SCWS]

Well yes, that is what i wrote, the first number is the (BMP) texture size as it has been added to the normal package, the second number the counterpart (DDS) texture size that has been added to the S3TC package.

Did you want me to add all the normal ones in 128 x 128 ?
.
.
.  

[BOZO]

Sorry, I didn't quite follow what you had done the first time. I was thinking you were creating two packages - one with DXT1 textures and one with PCX textures containing all of the various resolutions. It makes sense now that I look at what you produced. I can easily make what I need from what you sent me so far - thanks.

I finally got a mesh to accept a DXT texture at compile time so I should be able to proceed from here and complete my various tests.