Recently code was added for Uint16 textures with Cycles, Ive been looking through the source to find out how Blender internally generates buffers and textures but seems textures and buffers are handled differently through-out the software.
e.g Cycles does it’s own image format handling, but Blender’s image editor handles buffers and generated textures with completely different code? Would it not make sense to have one module that generates buffers and handles different image formats that every section of the code base just calls.
I want to look at adding 16bit half and uint16bit texture generation to the image editor so that I can bake a 16bit format rather than 32bit per channel like now, as trying to bake a high quality asset with 32bit per channel eats memory and means having to limit texture res, 99.9999% of people don’t need 32bit per channel precision for a displace/normal map, major overkill. 16bit float is just fine.
Ive found the relevant code to change in image_ops.c for the image editor texture generation which also then links in to BKE_image.c which links to image_gen.c but how and exactly where the float buffers are generated is less clear to me, as is how would be the best way to add the ability to use 16bit half format or uint16bit float as BKE also seems to link into the depsgraph.
There’s various reasons why sharing code is not always possible. Cycles is designed to work as a standalone render and is written in C++, CUDA and OpenCL, while Blender is mostly C and OpenGL.
Native 16 bit support in Blender would be useful, though this affects a lot of code (painting, rendering, baking, image display, Eevee, texture evaluation, compositing, …). In C code we can’t use templates and so a lot of code is already duplicated for byte and float, adding uint16 and half means it would be 4x duplicated.
To implement this you would basically have to search the source code for ImBuf and adapt all the places that access its pixels. A starting point would be imbuf/intern/allocimbuf.c.
However, it’s not clear to me why memory usage would be a big bottleneck for baking. Usually when you are baking images it’s one of many images that will be used in a render or game, and so if you’re baking one image / one object at a time it wouldn’t be that memory hungry compared to the final render or game?
Hey Brecht, Well the reason for me is baking height maps for terrains which have to be very large in resolution. If i want to bake a 16kx16k height map right now Im forced to have to use the 32bit per channel format or you get stair stepping in the terrain displacement.
UE4 uses these height maps to generate the terrain, If I can use 16bit float as the bake height format it gives me the ability to generate much larger terrains, right now having to render even a 4kx4k height map in 32bit per channel format kills mem and my machine.
Im not overly bothered about supporting 16bit fully through out blender right now even though for future that would be a major plus to people, I just want to be able to bake to 16bit, So as long as 16bit is supported for texture generation in the image editor that’s all I need.
Most PBR texture sets like andrew prices site, mega textures etc all support 16bit now, So generating my own PBR sets for realtime really needs me to do the same. It’s just the fact that only 8 bit or 32 bit is supported for baking right now that is breaking my work flow.
For example, This Vid shows 1 4x4k terrain element (this case a volcano), Ive built a library of 40-50 different terrains like rock mountains, grassy fields, volcano’s etc with their pbr files included with flow maps, debris, rock masks etc.
The idea is to be able to use these pre built terrain height maps as stamps in the sculpt tool. I can directly paint in different terrain features to match how I want the final terrain to look by mixing different terrain maps together. My shader then auto add’s rock grass masks etc based on the terrain face angle. Then once the user has finished sculpting the terrain the just bake out the new modified height map to export to their renderer of choice or realtime engine.
Good terrain support is always one of the most over looked features of most DCC apps, this is to try and make Blender better at handling terrains.