<div dir="ltr">Hello all,<br><br>I&#39;m new to the list, having been lured here by the 
promise of a standalone renderer with OSL support :) In the past I&#39;ve 
written Maya-&gt;RenderMan exporters and procedurals and shaders for 
various renderers. At the moment I&#39;m working on an open source 
node-graph-based scene assembly tool, which is very much in its infancy 
but can already output simple scenes for 3delight and Arnold (<a href="https://github.com/ImageEngine/gaffer%29." target="_blank">https://github.com/ImageEngine/gaffer).</a>
 I&#39;d love for it to also support one of the open source renderers, and I
 really want to work with OSL, so the Cycles announcement was very 
interesting to me.<br><br>I&#39;d like to suggest that rather than focus on 
what the file format should be, a better focus would be on defining a 
simple API for describing scenes to Cycles. That API could then be 
implemented in two modes - one for writing a file in whatever file 
format is chosen, and another for talking directly to an embedded 
renderer and sending updates to it for interactive rerendering. Having 
the same API for both is very convenient for anyone integrating Cycles, 
and the file format parser can then just be implemented in terms of 
making calls to the API. Although I&#39;ve worked a lot with the RenderMan 
API, my feeling is that it doesn&#39;t lend itself very well to 
introspection of the current scene and sending interactive updates.  
Attributes stacks don&#39;t seem so handy these days, getting in the 
way of instancing things on the fly and sharing shaders across locations
 - and it&#39;s pretty easy to simulate a stack on top of a stackless system
 if you need to.<br><br>My preference for an API would be something with
 direct access to a flat list of geometry and shader nodes and the 
ability to introspect and set their properties. Querying and setting the
 available properties through a generic interface for all nodes could 
provide a layer of insulation from the inevitable addition and removal 
of settings as the renderer develops, rather than just exposing the 
internals directly. My apologies if any of this exists already - I had a
 wander around the cycles code and couldn&#39;t see a simple API aimed at 
renderer integration, but may just have been blind.<br><br>Thanks for the renderer, and for the standalone initiative...<br><br>Cheers...</div>