My scenes really use a lot of textures, and I recently hit the 95 texture limit of cycles. Then I started thinking if it would be possible to work around this, and I think I have a solution. However, I’m not very familiar with the C-code of cycles, so I have trouble figuring out which parts of the code would be involved, and into what extent things can be solved in python and where C is needed.
I’m hoping someone more familiar with this code is willing to tell me whether this solution is feasible, and is willing to help me understand the concerned code.
Requirements for the solution
- amount of textures should not be the limit, only the size of your graphics memory
- typical UV tricks that are supported now (tiling textures, textures outside of [0,1] range) should be still supported
- solution should be transparent (invisible) to the user
- before rendering starts,textures which have the same size and pixel-type are grouped together in an atlas.
- The concerned image nodes are notified that they have to re-map to an area of that atlas.
- When a node has to sample the texture, it will use the remapping info to sample the right area. border-cases should be handled correctly.
- When rendering a movie, the same atlas can be re-used for rendering the whole movie in this way.
Areas of concern
- The design of the node system will probably get more complicated: some manager needs to manage all the texture nodes
- performance - the re-mapping is not a difficult calculation, but will happen a lot (every time that one of the textures is sampled) so the code needs to be written with care
- limits - is there a limit to the texture sizes?
- Graphics pipeline features - does the cuda code use typical graphics-hardware features like mipmapping or texture border handling, which could be messed up when playing with the sampling coordinates?
- image texture management: C or python?
- image sampling: C? cuda?