Image textures fail to display correctly at first time

[zhang.jian_bin]

If a jpg file is assigned to a material, and a surface use this material would turns into white for a very short time before the right image is seen when the surface is firstly displayed.  How to solve this problem?

Edited May 22, 2018 by zhang.jian_bin

[silent]

The best way is to prepare power of two (512x512 / 1024x1024) DDS image for that (DXT1 compression). JPG is not GPU-friendly format (consumes more memory on GPU / CPU and slow to decode).

You can generate DDS in any 3rd party tool (Photoshop with nVidia / Intel plugins, AMD Compressonator, nVidia Texture Tools) or just simply by drag and dropping JPG into the asset browser in Editor2. If image has correct resolution it will be automatically compressed.

It's not completely clear what causing this behavior in your case, so it's better to contact our China support team via china-support@unigine.com for further assistance.

Thanks!

[zhang.jian_bin]

I'm afraid we can't do that, we have tons of jpeg images which are located on the remote server. if we convert them on the server side, the bandwidth needed for our application would be sky high.

We also tried to convert jpeg files into GPU-friendly format on our client side(using the Image class provided by Unigine SDK), it  works all right but it would cost too much time. 

So any ideas that could optimize the conversion process?

[silent]

You can try to compress images directly on GPU (see the Render::compressImage()). Or spend some time to re-compress all the images from jpeg to dds in offline via 3rd party tools.

[zhang.jian_bin]

We've tried Render::compressImage()  The performance is almost same as Image::convertToFormat.

And the document had mentioned that Render::compressImage() would utilize GPU features to do the work. It is obviously that our GPU(Geforce 1060) does not do the work. 

If we want to enable GPU compress, is there any other options need to be set on Unigine?  Or the GPU compress is automatically enabled and  Geforce1060 don't have the feature?

[silent]

It will work only if you have power of two textures (512x512 for example). We use this compression by default in Editor2.

[zhang.jian_bin]

pImagePtr->create2D(pTargetGeoImage->iWidth, pTargetGeoImage->iHeight, Unigine::Image::FORMAT_RGBA8)

Unigine::Render::get()->compressImage(pImagePtr, 0, Unigine::Image::FORMAT_DXT1)

The size of the jpeg files we are using is always power of two. Here is our  generation sequence, anything wrong? Or there is too much of image files even GPU can't handle it in real-time.

[silent]

We are doing the same internally. How large is your JPEG files (resolution / size in MB) and how many time does it take to compress a single image?

Please, make sure that you are calling this function from the main thread (otherwise CPU compression will be used).

[zhang.jian_bin]

Yes, that's the problem, calling that function from main thread only is super fast. We are now using 8 threads to complete the initialize task, processing images and geometries. 

But If we put all the task in main thread, the scene would stop rendering and stuck there. could us open another Unigine process to convert the image format? or other solutions?

And, the jpeg files we are using came from the oblique photographs. Sizing from 64*64 to 512*512, more than 100,000 files for each scene.

[silent]

I think you can write a separate application that will compress images on GPU, but it will slowdown the main application :)

If you have finite number of JPEG images the best solution would be to compress all of them to DDS and store near the JPG. For 100K JPEG images with a single main thread it would take 24h (1 sec per image). But in practice with multiple processes I think you can achieve 4-8 hours (0,5 sec per image) and 4-8 instances of the compressor application.

When JPG image is requested you can send DDS instead. You can also try to do some LZ4 compression on top of the DDS to reduce the size of the transferred image. LZ4 compression can be done on fly (before the sending).

[zhang.jian_bin]

We'll try this policy later, thanks for the help, sincerely.