[Bf-cycles] Cycles Standalone

[Brecht Van Lommel]

Good points about the API, we should indeed have something that
closely matches the file format. The current API indeed is not totally
decoupled and could use some abstraction.

Also to be clear, we just announced this relicensing but unfortunately
that doesn't mean I immediately have much time to work on API / file
formats. I'm happy to gather feedback, discuss design and help other
developers work on making Cycles more suitable as a standalone
renderer, but right now this is not a development project I do myself,
it's up to volunteers mostly for now until I find some time.


On Wed, Aug 21, 2013 at 7:39 PM, John Haddon <thehaddonyoof at gmail.com> wrote:
> Hello all,
>
> I'm new to the list, having been lured here by the promise of a standalone
> renderer with OSL support :) In the past I've written Maya->RenderMan
> exporters and procedurals and shaders for various renderers. At the moment
> I'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 (https://github.com/ImageEngine/gaffer). I'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.
>
> I'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've worked a lot with the
> RenderMan API, my feeling is that it doesn't lend itself very well to
> introspection of the current scene and sending interactive updates.
> Attributes stacks don't seem so handy these days, getting in the way of
> instancing things on the fly and sharing shaders across locations - and it's
> pretty easy to simulate a stack on top of a stackless system if you need to.
>
> 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't see a
> simple API aimed at renderer integration, but may just have been blind.
>
> Thanks for the renderer, and for the standalone initiative...
>
> Cheers...
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>