[Bf-cycles] Build without OpenImageIO

Nathan Letwory nathan at mcneel.com
Mon Mar 5 14:58:48 CET 2018


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/5f8ca9d2e49ad63a77768bac0b8e4b
> 987f761149
>
> 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-
>> ef3db750-20bb-11e8-9064-b8c9ddc3504f.png
>>
>> Regards,
>> Guillaume
>> _______________________________________________
>> 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/5d594262/attachment.html>


More information about the Bf-cycles mailing list