Objects with a flat gray surface?

[matthornb]

I'm testing Sevkor in Uru:CC for optimization reasons, and am running into a bug in which one or more objects turn out flat gray (untextured) when exported to Uru:CC.

This seems to be totally random, most objects look fine but usually two or three of them show up gray. The ones that are gray vary from compile to compile.

Does anyone know why this might be happening? I have the correct image files loaded for each surface in both the Texture/Materials area and the UV/Image editor, so I doubt that's the problem. Maybe I should reload them all again?

[tachzusamm]

I assume we are talking about Blender, because you mention the UV/Image editor.
First, there's no need to load images in the UV/Image editor. You can, to work with them, but no need.
Just check if textures are assigned properly in the materials.

Does it really vary from comple to compile, or is there something you do with the Blender file? Also simple small changes could give a hint.
And also check if it's not a game problem, so if you enter the game a second time (fresh from start) WITHOUT doing a new compile, are the affected objects exactly the same?

[matthornb]

Yes, I'm working in Blender. I have figured out that the textures turning out gray are doing so because there are multiple users of an image block.

This seems to be the cause of the problem.

[tachzusamm]

I have figured out that the textures turning out gray are doing so because there are multiple users of an image block.

It would really surprise me it that's the reason. I assign multiple users to images and materials all the time, nearly everywhere, and I never got any single problem with that.
That should just work, and it's a good way to keep your textures.prp small.
It could eventually be the case that you're doing some unusual stuff with the image blocks. Not necessarily forbidden stuff, but something I've never stumbled accross before.

[dendwaler]

It might be that jou join two objects , where one has the grey material and the other has a "real " material because you had textured the other object already.

Now you continue to uv map the new joined part with a material chosen in the links and pipeline pull down, but forget to delete the old grey one.
In such cases the whole object shows a textured one in blender but the rendered one can still be grey.
I have had this a few times when i split an object to texture it with multiple textures and then rejoin the splitted parts after texturing and removing the doubles.

Unfortunally i can hardly remember where it exactly went wrong but altering multiple materials on an object, which are already assigned elswhere can be very tricky if you do not exactly know how to do it.

[tachzusamm]

Matthornb, if you like, you could send me your project (or part of it if you don't want to spoil something) and I'll have a quick look at it.
I will keep it confidential. Send a PM if interested.

[matthornb]

I think I have another possible explanation.

Firstly, I must note that the surfaces that are gray are truly random; the same compile, when loaded in Uru multiple times, will have different textures turned gray each time the world is loaded.

I had a theory that the problem was due to inadequate texture memory on my (lower-end) video card, which is easily the weakest part of my PC.
I tested the theory by cutting all the texture resolutions in half and then recompiling. The result was that all the textures loaded successfully, but were also all somewhat blurry.

There is - BTW - no compression whatsoever on any of the texture images. They're all .tga 24-bit uncompressed, which right now is the only image format that PyPRP can compile since libjpeg and libpng aren't working for me for some reason. There is also no mipmapping on the textures, all of them are displayed at full resolution all the time, because again, pyPRP will not finish the compile for me if any texture's mipmapping is turned on.

These various unexplained bugs basically result in an age that has a collossally inefficient District_Textures file which is well over 200 MB. Ae'gura's, by contrast, is 55 MB, and mostly the other Uru ages are below that.

I'm convinced that if I can somehow get pyPRP to successfully compress the texture image files, this wouldn't be the mess it is now.

Yes, I did follow all the pyPRP installation instructions correctly, yes I have Python, PIL, & PYAML installed. I don't know why pyPRP is having these issues but it is.

Hopefully korman will be finished soon and we'll be able to move on from pyPRP in the next few months.

[dendwaler]

Huh?

I use Jpeg (jpg) with compression to 72% for 80% in my ages, the rest are png used for transparencies.
mipmap is also turned on.

Never had any propblem with Pyprp to output that.
So i realy do not understand why you are using uncompressed tga.

[Karkadann]

I think their is a way to look into the District_texture.prp file to make sure all the graphics files are being exported to start with
also if your video card is the weakest link in your PC your project may be using up more resources then it has which might be why
you get random gray textures.

You may wanna try using VisRegions, and load some of the rooms in as a prp file instead of one huge chunk of graphics and mesh
I find they come in real handy, when im working on details in an age where I dont need to export the whole age repeatedly I just export the Detail

[Tsar Hoikas]

There is - BTW - no compression whatsoever on any of the texture images. They're all .tga 24-bit uncompressed, which right now is the only image format that PyPRP can compile since libjpeg and libpng aren't working for me for some reason. There is also no mipmapping on the textures, all of them are displayed at full resolution all the time, because again, pyPRP will not finish the compile for me if any texture's mipmapping is turned on.

This is a very big problem. An uncompressed 1024x1024 texture (hint: your textures should probably not be smaller than 512x512 in this day and age) will take up 4mb of VRAM. If you don't have much VRAM, that's bad. You should only ever turn off mipmapping (and compression) for light and bump maps.

I'm not sure I understand the second part. libjpeg and libpng have nothing to do with PyPRP. What error message is the exporter returning? Your description is not useful enough to determine what the actual problem is.

I use Jpeg (jpg) with compression to 72% for 80% in my ages, the rest are png used for transparencies.
mipmap is also turned on.

This is terrible. JPEG is a lossy image format, meaning, you lose detail with compression. The Uru texture format is a different lossy format, meaning you lose even more detail (conversion from lossy to different lossy is always bad). So, you have textures in your ages that are probably about (or less than) 60% quality. Yikes. For an example of what this means, here is an excerpt of Romeo and Juliet run through the JPEG compressor at 75%. (Original Work)

THE TRAGEDY OF ROMEO AND JULIET
by William Shakespeare.

TEJ UQAHDFS"ME$NOLCR DLC!IULFGR ew#Tjlljdl Uh_ldrodbrf

Let's use PNG for all of our textures, m'kay?