[Bf-cycles] HDR texture support

[Thomas Dinges]

1) Because Mike is not finished yet. ;-)
http://blenderartists.org/forum/showthread.php?243645-Cycles-HDR-texture-support&p=2045451&viewfull=1#post2045451 


Am 12.02.2012 21:11, schrieb Virgil Ioan:
> 1. I understand, though i'm not sure why it's not finished.
> 2. Using an HDR environment as a 8bit-LDR environment without any kind of warning is definitely a bug so it could use this bug fix.
>
>
> ----- Original Message -----
> From: Thomas Dinges<blender at dingto.org>
> To: Virgil Ioan<vimaxus at yahoo.com>; bf-cycles at blender.org
> Cc:
> Sent: Sunday, February 12, 2012 9:03 PM
> Subject: Re: [Bf-cycles] HDR texture support
>
> 1) It's not finished.
> 2) We are in BCon4 atm, meaning no new features, only bug fixes.
>
> DingTo
>
> Am 12.02.2012 21:00, schrieb Virgil Ioan:
>> Any reason why this isn't committed yet? I could really use this particular patch as I'm sure many others would, besides, using HDR environments as LDR and without any type of adjustable tone mapping is kind of strange.
>>
>> P.S. First time poster on a list so I hope this is how it works.
>>
>> -Virgil
>>
>> Date: Mon, 30 Jan 2012 23:55:08 -0800
>> From: Mike Farnsworth<mike.farnsworth at gmail.com>
>> Subject: Re: [Bf-cycles] HDR texture support
>> To: bf-cycles at blender.org
>> Message-ID:
>>        <CAPZh=FueA8baN+=QRDLTX=ZuXK_rYZx8Q-qB-Pm3A9w2+-5MYA at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> As a stopgap, I've implemented the third option (I siphoned off 5 of
>> the 100 texture slots as float texture slots), but with the added
>> benefit that the user doesn't have to specify which textures are
>> float, and which ones are not.  It uses OIIO to detect texture
>> formats, and in the case that the native texture format is half, float
>> or double it will go ahead and use a float texture slot.
>>
>> Good news: this enables HDR textures for use on *anything* you can
>> assign a texture to for Cycles.  Bad news: there are 5 slots taken up
>> (for those that needed them for regular textures), but there are only
>> 5 slots available (for those that might need more than 5 for HDR
>> textures).
>>
>> I tested this with Radiance HDR/RGBE, EXR, TIFF, and some other LDR
>> formats to make sure it appeared to grab the correct slots each time.
>> Patch is attached.
>>
>> -Mike
>>
>> On Mon, Jan 30, 2012 at 10:57 AM, Mike Farnsworth
>> <mike.farnsworth at gmail.com>   wrote:
>>> I'm adding support for float format textures (particularly for
>>> environments and emission textures, as that's where they are
>>> particularly useful), and I'm to the point where I think I need some
>>> wisdom on what is the best way to proceed. ?Here are a few options,
>>> I'd like to see any feedback y'all have regarding them:
>>>
>>> * Force float textures for all textures. ?Pros: easy to do, very
>>> simple patch. ?Cons: takes up 4x the RAM, which is particularly
>>> troublesome for GPUs, and compiles in that way.
>>>
>>> * Global option. ?Pros: fairly simple to do. ?Cons: very blunt
>>> solution, and we have to compile multiple versions of the kernels, as
>>> the float vs. non-float settings on the textures are compile-time;
>>> all-or-nothing could put people over on RAM limits just because they
>>> need one float texture.
>>>
>>> * Hard-coded X number of float texture slots, out of the 100
>>> available. ?Pros: fairly straightforward to do. ?Cons: not very
>>> flexible.
>>>
>>> * CUDA layered textures, semi-dynamic texture management. ?This is the
>>> most complex option, where we would group all textures together that
>>> are the same size, and same format (e.g. float RGBA vs. 8888 RGBA)
>>> into a layered texture. ?Each texture then gets a slot as they do now,
>>> but also an index. ?There appears to be a 512 MB limit on total
>>> texture size, but I haven't verified if that's the case for layered
>>> textures, but that would also be taken into account for spillover to
>>> additional slots. ?A fixed number of float texture slots would also be
>>> allocated at compile-time from the 100 total slots, and textures would
>>> be grouped dynamically within those as well. ? ?Pros: much more
>>> flexible, potentially raises the 100 texture limit we have now
>>> substantially higher (and in my opinion, 100 textures is *extremely*
>>> restrictive for typical animation/VFX shots). ?Cons: more difficult to
>>> implement, and OpenCL only seems to support arrays of 2D textures in
>>> OpenCL 1.2, which is very new. ?Also, in order for this to work well,
>>> textures need to be the same size, or else we need to have the option
>>> of upping their resolution to match a slot that already is allocated
>>> when GPU memory is available. ?Then the grouping would likely be
>>> effective enough.
>>>
>>> I suspect that the last option is something that will have to be done
>>> at some point. ?The 128 total texture limit in CUDA is...embarassing
>>> IMHO, but using layered textures to work around it could be a good way
>>> to go. ?It is a bit of work. ?The first option is too blunt and will
>>> shut numerous people out of using the GPU. ?The second option I don't
>>> like at all; if we're going to complicate things, the other choices
>>> are better. ?The third option would work as a decent workaround, but
>>> if there are people already using all or nearly all of the texture
>>> slots we'd break their ability to use GPU rendering.
>>>
>>> Thoughts?
>>>
>>> -Mike
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>


-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org