<div dir="ltr">* 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.<div>
<br></div><div>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.<div>
<br></div><div>* 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.</div>
<div><br></div><div>* 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 ).</div>
<div><br></div><div>Either way, as long as it's reasonable simple to write out, it doesn't matter too much imo.</div><div><br></div><div>* 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.<br>
</div><div><br></div><div>* 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.</div><div>
<br></div><div>* 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.</div>
<div><br></div><div><br></div>
<div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 21, 2013 at 2:49 AM, Thomas Dinges <span dir="ltr"><<a href="mailto:blender@dingto.org" target="_blank">blender@dingto.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
here some information and notes about our Cycles standalone app, which<br>
could be interesting for external developers.<br>
Also some ideas how we could improve it a bit.<br>
<br>
1) What we have<br>
<a href="http://temp.dingto.org/cycles_test1.png" target="_blank">http://temp.dingto.org/cycles_test1.png</a><br>
<br>
* Cycles standalone code can be found here:<br>
<a href="https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/cycles/app/" target="_blank">https://svn.blender.org/svnroot/bf-blender/trunk/blender/intern/cycles/app/</a><br>
* It's a pretty simple and was developed as a quick test program (before<br>
Cycles was integrated in Blender).<br>
* Geometry and Settings, Shaders etc. can be passed via XML files. Some<br>
(probably outdated) examples can be found here:<br>
<a href="https://svn.blender.org/svnroot/bf-blender/branches/cycles/intern/cycles/test/" target="_blank">https://svn.blender.org/svnroot/bf-blender/branches/cycles/intern/cycles/test/</a><br>
<br>
2) Needed fixes<br>
* I haven't tested lately, not sure if it compiles still. As far as I<br>
remember the standalone app doesn't link with OSL yet.<br>
* The XML API is outdated, basically most nodes and settings which have<br>
been added since 2012 are missing. But maybe we will go another path?<br>
See below.<br>
<br>
3) Possible improvements<br>
* Should we keep the XMP API and update it, or should we replace with<br>
something else? I am not sure what would be best for external applications.<br>
* Maybe split import into a Settings and Geometry part, where Geometry<br>
loading is handled via .obj (or even alembic)?<br>
* I guess we could make the App GUI optional, so people can just compile<br>
a console version, without the freeglut dependency?<br>
<br>
Feedback and discussion on this is welcome, also feedback from external<br>
developers who would be interested in integrating Cycles into other<br>
applications.<br>
<br>
Best regards,<br>
Thomas<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Thomas Dinges<br>
Blender Developer, Artist and Musician<br>
<br>
<a href="http://www.dingto.org" target="_blank">www.dingto.org</a><br>
<br>
_______________________________________________<br>
Bf-cycles mailing list<br>
<a href="mailto:Bf-cycles@blender.org">Bf-cycles@blender.org</a><br>
<a href="http://lists.blender.org/mailman/listinfo/bf-cycles" target="_blank">http://lists.blender.org/mailman/listinfo/bf-cycles</a><br>
</font></span></blockquote></div><br></div>