[Bf-cycles] Build without OpenImageIO

[Nathan Letwory]

We use them in RhinoCycles as well, the problem is just that OIIO is a code
dependency that could be abstracted away completely.

Biggest problem though is ustring and company. Those are use throughout.
For RhinoCycles I have a stripped down OIIO with only those utility classes
left.

On 5 Mar 2018 6:03 pm, "Mohamed Sakr" <3dsakr at gmail.com> wrote:

> as Stefan mentioned,  ImageManager::builtin_image_info_cb,
> ImageManager::builtin_image_pixels_cb and ImageManager::builtin_image_fl
> oat_pixels_cb
> we use these callbacks also in Cycles4D to handle Cinema4D textures.
>
> On Mon, Mar 5, 2018 at 5:29 PM, Stefan Werner <stewreo at gmail.com> wrote:
>
>> There is a callback system already, Blender is using it to load packed
>> textures. If I remember correctly, the Poser integration is loading all
>> textures through its own imaging library and not OIIO.
>>
>> The callbacks are:
>> ImageManager::builtin_image_info_cb, ImageManager::builtin_image_pixels_cb
>> and ImageManager::builtin_image_float_pixels_cb
>>
>> -Stefan
>>
>>
>> On 5. Mar 2018, at 14:58, Nathan Letwory <nathan at mcneel.com> wrote:
>>
>> The better way of course would be to have a callback system whereby
>> clients (Blender, Rhino, Goxel) can register the necessary functions to
>> handle image data the way they see fit. For Blender they'd be the current
>> functions behind which OIIO is hidden etc.
>>
>> On 5 Mar 2018 3:52 pm, "Nathan Letwory" <nathan at mcneel.com> wrote:
>>
>>> For RhinoCycles I have added a simple define bypass to cut out much of
>>> the image reading code.
>>>
>>> Unfortunately OIIO utility code is used quite extensively, so I left
>>> those usages in.
>>>
>>> https://github.com/mcneel/cycles/commit/5f8ca9d2e49ad63a7776
>>> 8bac0b8e4b987f761149
>>>
>>> On 5 Mar 2018 3:33 pm, "Guillaume Chéreau" <guillaume.chereau at gmail.com>
>>> wrote:
>>>
>>>> On Mon, Mar 5, 2018 at 8:37 PM, Brecht Van Lommel
>>>> <brechtvanlommel at pandora.be> wrote:
>>>>
>>>> > Alternatively you keep use the OpenImageIO_Util library that is part
>>>> of
>>>> > OpenImageIO. It is much smaller and includes just these utilities, so
>>>> you'd
>>>> > only have to make the image reading/writing part in Cycles optional.
>>>>
>>>> Yes that would be acceptable like that I guess.  I will try to keep
>>>> working on that when I have time and see what I can come up with.
>>>> Meanwhile you can see a screenshot of my first attempt of using cycles
>>>> in goxel:
>>>>
>>>> https://user-images.githubusercontent.com/107679/36977390-ef
>>>> 3db750-20bb-11e8-9064-b8c9ddc3504f.png
>>>>
>>>> Regards,
>>>> Guillaume
>>>> _______________________________________________
>>>> Bf-cycles mailing list
>>>> Bf-cycles at blender.org
>>>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>>>
>>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> https://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> https://lists.blender.org/mailman/listinfo/bf-cycles
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.blender.org/pipermail/bf-cycles/attachments/20180305/fbcef906/attachment.html>