Page 2 of 3

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 9:42 am
by Aloys
I just read your email Robert and now your post but there's something I still don't understand. I have added the exact same texture as well as the PAK to at a test Age and it works perfectly, but in Ahra it doesn't. I am missing something here.
Anyhow I will test that method and see how it works.

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 12:00 pm
by Robert The Rebuilder
Aloys:

If you exported your test age via the "Generate Release" option, then you'll find that the linking panel image does not appear. [That's how you usually export Ahra Pahts, right?]

However, if you exported it via the "All as full age" option, then it will appear.

Once you prefix your texture file name with "noCompress", then it will appear no matter how you export it.

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 5:40 pm
by Aloys
Ohhhh I see. But that shaters something I had been assuming for a while now. The textures cache files always include both the compressed textures and the uncompressed ones to cover both the "all as full age" and "release" export settings?

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 5:46 pm
by Paradox
If necessary, (particularly for shells), you could export "Age full Age, Release Settings" to compress all textures, then manually import the textures from the resulting Textures.prp file.

That's certainly the route that I'm looking towards at this point, but it would also be great if we could find a flag or button in Blender and use that to toggle "Compress" or "UnCompress".

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 7:08 pm
by Aloys
Well I had actually been doing 'differential' exports for the latest version. I would export once using "release" settings, and once using "all as full age" settings, and I would end up with different files in the texture cache.. Because when compressed the sky dome texture would noticable loose quality (overly smooth gradients don't compress too well) so I would put the non-compressed texture cache file put it in my regular export cache folder and then re-export to end with a textures PRP with all my textures dully compressed except for the sky textures..
A bit of a convoluted method when at first sight, but it worked. Reading Robert's previous posts I wonder if I had that method right or if it was sheer luck...
For the next version I will start using PRPexplorer, that should make things easier. :)

I took a look at the material panels and I can't see either any button we could use. That's in this kind of situation that I curse Blender's interface and its scripts integration.. It'd be so easy in any other 3D software to just add a PyPRP panel next to the regular Material panel and stick in there all the buttons and fields and checkboxes we need.. :(

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 7:32 pm
by Robert The Rebuilder
Yeah - the "noCompress" prefix is a kludge, but lacking any suitable button in Blender, that's our only option for now.

Regarding texture compression: I've made some fixes to the stable plugin to allow you to set the texture_compression flag and export as per-page textures. I also added the ability to tag objects to ignore the per-page-texture export. Using these combined features, I've managed to shrink my PRP file size to 20% of the original size. I've asked Trylon to upload the plugin to hbyte.net; once he's done that, I'll post instructions on how to do this.

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 8:10 pm
by Aloys
Very nice robert. :) Thank you for your work. That should prove to be a good ressource saver for this particular Age. :)

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 8:11 pm
by Paradox
Actually, I just looked through Trylon's work both in the branch, and the latest version in the trunk. I'm not seeing anywhere that the "noCompress" string appears.

It's also not entirely clear where the texture compression is set, but we have a "UseAlpha" and a "MipMap" button that don't currently serve a purpose.

I propose the following:
- Any texture using any form of Alpha must specify the USEALPHA flag. This will ensure that such textures are stored with the proper DXT Compression level.
- Any texture needing to be mipmapped and compressed must specify the MIPMAP flag.
- Any textures not specifying these flags will be exported as uncompressed data or with jpeg image compression.

A few notes:
- Both DXT1 and DXT5 (the most commonly used compression types) support Alpha, but different types. "on-off" alpha is supported by DXT1; but full alpha must use DXT5. We might possibly use a different flag to distinguish between the two.
- Linking panels and GUI images should be JPEG compressed. If that isn't possible, then they should remain uncompressed.
- The option to disable mipmapping or texture resizing is a complete waste of time IMO. All textures that are compressed should specify mipmap levels, and all textures should be resized to a power of 2.

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 8:28 pm
by Aloys
I agree with everything. I have one small question though: in the future is it possible that we use the alpha channels for something other than transparency. (specular lighting, reflection, glowmap/self lighting etc). Then the UseAlpha behavior might need to be changed, right?
Although that's probably a little early to think about that.

Re: Shell Memory Limit

PostPosted: Tue Dec 04, 2007 8:53 pm
by Paradox
Most of those are flags set on the material, or on the layer. There are loads of material settings that we aren't using right now, and if necessary we can always pretend that some buttons work in ways that they aren't meant to ;)