[Bf-cycles] Cycles Standalone

[Matt Ebb]

* Would it be possible to move (or somehow mirror?) Cycles to its own
repository so that people don't need to check out the entire blender tree
just to get cycles? It would probably help to dispel any notions of GPL
infection if the code is completely isolated and presented that way.

As I'm sure you guys were aware (hence this recent decision) many larger
companies such large animation/vfx studios want absolutely nothing to do
with GPL code, not for idealogical reasons, but for their own legal
protection, when adding proprietary/in-house plugins and connections to
proprietary software, so showing clearly that Cycles is a separate project,
fully standalone and not mixed in with GPL blender, would help a lot here.
Right now even if technically it is Apache licensed it seems more murky to
someone not familiar with it.

* It would probably be a good idea to keep the definition of shaders
separate to the definition of geometry/scene hierarchy (eg. .rib vs .sl)
and rather, control the assignment those shaders in the main scene
description file. This would already be the case for OSL presumably, but it
might be worth thinking of the svm nodes in a similar fashion. In larger
pipelines, shaders are usually not exported each time from the lighting
artist's scene, but referenced, often from some kind of versional
controlled location.

* XML is probably ok to keep, but it might be good to make sure the actual
implementation isn't overly verbose, perhaps (optionally) using encoded
binary blobs for geometry and/or reading xml.gz, in order to speed things
up/save space. Probably should try and get an idea of what sort of things
you want to support in such a scene description format (eg. hierarchical
transformation stacks, instancing, ribArchive style file inclusion). Might
also want to consider what sort of bottlenecks or restrictions might be
imposed on Cycles by the scene description format (i.e. can you parse or
read files or included files in parallel? Do you need to read ).

Either way, as long as it's reasonable simple to write out, it doesn't
matter too much imo.

* I would not use RIB itself - unless you support all kinds of
renderman-isms (eg. attribute hierarchy stack), it probably won't be
compatible anyway, and will just be confusing.

* Supporting geometry directly loadable at render time (delayed load or
not) like Alembic would obviously be great, for blender users and
non-blender users alike, but perhaps not trivial.

* Having a generalised C/C++ API, that's clear and not tied to blender-isms
would of course be great as well, especially for the purposes of things
like live updating from a non-blender application's viewport.







On Wed, Aug 21, 2013 at 2:49 AM, Thomas Dinges <blender at dingto.org> wrote:

> Hi everyone,
> here some information and notes about our Cycles standalone app, which
> could be interesting for external developers.
> Also some ideas how we could improve it a bit.
>
> 1) What we have
> http://temp.dingto.org/cycles_test1.png
>
> * Cycles standalone code can be found here:
> https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/cycles/app/
> * It's a pretty simple and was developed as a quick test program (before
> Cycles was integrated in Blender).
> * Geometry and Settings, Shaders etc. can be passed via XML files. Some
> (probably outdated) examples can be found here:
>
> https://svn.blender.org/svnroot/bf-blender/branches/cycles/intern/cycles/test/
>
> 2) Needed fixes
> * I haven't tested lately, not sure if it compiles still. As far as I
> remember the standalone app doesn't link with OSL yet.
> * The XML API is outdated, basically most nodes and settings which have
> been added since 2012 are missing. But maybe we will go another path?
> See below.
>
> 3) Possible improvements
> * Should we keep the XMP API and update it, or should we replace with
> something else? I am not sure what would be best for external applications.
> * Maybe split import into a Settings and Geometry part, where Geometry
> loading is handled via .obj (or even alembic)?
> * I guess we could make the App GUI optional, so people can just compile
> a console version, without the freeglut dependency?
>
> Feedback and discussion on this is welcome, also feedback from external
> developers who would be interested in integrating Cycles into other
> applications.
>
> Best regards,
> Thomas
>
> --
> Thomas Dinges
> Blender Developer, Artist and Musician
>
> www.dingto.org
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20130821/97fbe9ee/attachment.htm