search

MilchRatchet / Luminary

CUDA based Pathtracing Offline and Realtime Renderer
MIT License
30 stars 1 forks source link

Slow PNG Texture Loading #87

Closed SamuelTallet closed 12 months ago

SamuelTallet commented 12 months ago

Hello, is there a limitation on texture size?

When I load a model with a 8K or 4K albedo texture, Luminary.exe gets stuck on boot.

Whereas a 2K albedo texture loads without issue, except it's blur.

MilchRatchet commented 12 months ago

There is no actual limitation (unless there is one in CUDA that I'm not aware of), 8K textures do work. I had noticed this issue as well recently, Luminary needed 10mins to load when using 2 8K textures. I haven't looked too deeply into this but I assume it is the PNG decompression that takes up all the time since I'm using the standard zlib implementation by madler which is painfully slow.

Alternatively, it could be the OMM construction which is very suboptimal currently, you could try the command --no-omm, maybe that could help in this case.

Most scenes I have worked with used many but small textures instead of few large ones and there I never ran into any such issues.

SamuelTallet commented 12 months ago

I suggest to use libspng. It is simple (made of two files) fast and compatible.

libspng supports SSE 4.1 and miniz (a zlib replacement made of two files).

MilchRatchet commented 12 months ago

miniz does look like a very nice replacement for the original zlib, thanks for the recommendation.

SamuelTallet commented 12 months ago

You're welcome.

MilchRatchet commented 12 months ago

So I just pushed a fix, high resolution textures should now load fast (it should take at most a few seconds). The issue was actually due to a recent change where I started loading the png files completely before parsing them. The block size was too small during the reading which was inefficient. So everything should now be resolved now. Thanks for the issue report.

Commit: 40b04fa

SamuelTallet commented 12 months ago

Super! Thank you.