Page MenuHome

Cycles: Implement texture size limit simplify option
ClosedPublic

Authored by Sergey Sharybin (sergey) on Nov 17 2016, 12:20 PM.
Tags
None
Tokens
"Pterodactyl" token, awarded by erickblender."Pterodactyl" token, awarded by aditiapratama."Pterodactyl" token, awarded by fsiddi."Pterodactyl" token, awarded by pablovazquez.

Details

Summary

Main intention is to give some quick way to control scene's memory
usage by clamping textures which are too big. This is really handy
on the early production stages when you first create really nice
looking hi-res textures and only when it all works and approved
start investing time on optimizing your scene.

This is a new option in Scene Simplify panel and it acts as
following: when texture size is bigger than the given value it'll
be scaled down by half for until it fits into given limit.

There are various possible improvements, such as:

  • Use threaded scaling using our own task manager.

    This is actually one of the main reasons why image resize is manually-implemented instead of using OIIO's resize. Other reason here is that API seems limited to construct 3D texture description easily.
  • Vectorization of uchar4/float4/half4 textures.
  • Use something smarter than box filter.

    Was playing with some other filters, but not sure they are really better: they kind of causes more fuzzy edges.

Even with such a TODOs in the code the option is already quite
useful.

Diff Detail

Repository
rB Blender

Event Timeline

Sergey Sharybin (sergey) retitled this revision from to Cycles: Implement texture size limit simplify option.Nov 17 2016, 12:20 PM
Sergey Sharybin (sergey) updated this object.
Sergey Sharybin (sergey) updated this revision to Diff 7827.

Fix compilation error caused by variable size array declaration

I can't spot any bugs, just minor nitpicks. A box filter is quite ok for downscaling I think.

intern/cycles/blender/addon/properties.py
134–140

Could use the actual 128, 256, .. values as enum values for simplicity.. though doesn't really matter.

intern/cycles/blender/blender_sync.cpp
516

Style inconsistency.

intern/cycles/render/image.cpp
502

No need for &[0] here and following lines since pixels is already a pointer.

Sergey Sharybin (sergey) updated this revision to Diff 7868.

Updated for the comments from Brecht.

Left enum as is for now. Not sure what's actually better here.
Using absolute values will be somewhat more flexible for adding
new hard-coded values, but wouldn't let us using some special
values like "Auto texture size based on screen space".

Also updated the interface a bit (was conflicting with changes
about distance culling). The interface is verified by @venomgfx
now.

This revision is now accepted and ready to land.Nov 21 2016, 9:56 PM

Left enum as is for now. Not sure what's actually better here.
Using absolute values will be somewhat more flexible for adding
new hard-coded values, but wouldn't let us using some special
values like "Auto texture size based on screen space".

Is the plan to eventually re-purpose these controls as part of a mipmap/texture cache function? This is starting to sound like the same functionality, just done a different way...

Mipmap is actually a higher memory usage because it needs to store several resolutions for the texture and pick up best one for the current "screen space". This patch is a way for artists to quickly make their scenes to fit into GPU for a fats preview. But sure some code might be shared here, like mipmap generation (i wouldn't mind looking into improvements to our downscale function).

Caching is a separate thing from this changes.

This revision was automatically updated to reflect the committed changes.