[Bf-cycles] XML API proposal - objects and mesh instances

[Sergey Sharybin]

Hi,

This is totally valid proposal, we indeed should support instancing in
whatever-format-we'll-be-using.

And even if we'll switch to some cleaner format (yaml based? .blend file
reader? that's separate story tho) we still can keep xml reader around as
long as there're guys using it and maintaining it.

Only possible issue here i see is breaking compatibility with existing xml
files. But guess it's not so much of a deal at this moment?

On Thu, Mar 17, 2016 at 8:05 PM, Jasper Kindt <jasper.kindt at gmail.com>
wrote:

> Hello,
>
> I applaud Nathan for his efforts so far and ask the community to *support
> this guy* in his requests... The easier it is to implement cycles as a
> render engine in standalone apps, the better...
>
> ​I came across his project, trying to implement a node system for a
> complex math equation for holographic visualisations, which i never
> finished due to lack of finance and support...
>
> Nevertheless, I still think there is a huge market in converting 90's
> single core matlab programs for math visualisations to standalone software
> using the best of the graphics card and a node system export which can be
> understood by any artist, without too much study.
>
> Sincerely,
>
> JK
>
> On 17 March 2016 at 09:46, Nathan Letwory <nathan at mcneel.com> wrote:
>
>> I have been improving the XML API somewhat in my CCSycles project. I've
>> added in my own XML parsing implementation a way to essentially do mesh
>> instancing.
>>
>> In Cycles stand-alone XML implementation the <mesh> tag also results in
>> the creation of an object, but it'd be better if mesh and object
>> creation were separated.
>>
>> I propose that the <mesh> tag only creates meshes, and that we introduce
>> the <object> tag that can reference then <mesh>es.
>>
>> For this to work I propose <mesh> gets a new attribute 'name'. The
>> <object> tag takes a 'mesh' attribute that should have a value that was
>> introduced by a <mesh> with a 'name'.
>>
>> Example:
>>
>> <shader name="plane">
>>         <diffuse_bsdf name="cube_closure" roughness="0.0" color="0.8 0.8
>> 0.8" />
>>         <connect from="cube_closure bsdf" to="output surface" />
>> </shader
>>
>> <state interpolation="smooth" shader="plane">
>>         <mesh name="groundplane" P="1.0 1.0 0.0 -1.0 1.0 0.0 -1.0 -1.0
>> 0.0 1.0
>> -1.0 0.0" nverts="4" verts="0 1 2 3" />
>> </state>
>>
>> <transform translate="0 0 0" scale="1000 1000 0">
>>         <object mesh="groundplane" />
>> </transform>
>>
>> End example.
>>
>> For a larger example see
>>
>> https://github.com/jesterKing/CCSycles/blob/master/tests/scene_many_cubes.xml
>>
>> Now, I know that some want to move away from XML, but at this point I'd
>> prefer the Cycles file format stay in XML, since there is already a
>> wealth of tools out there that help with authoring XML, it is easy to
>> parse and transport.
>>
>> That said, I'm not much interested in writing the C code to do this
>> myself - my parser is in C# and will stay like that. But perhaps this
>> could be part of someones GSoC efforts.
>>
>> Cheers,
>>
>> /Nathan
>>
>>
>>
>> --
>> Nathan Letwory
>>
>> Integrating Cycles into Rhino 3D
>>
>> https://github.com/jesterKing/CCSycles
>> https://github.com/mcneel/RhinoCycles
>>
>>
>> _______________________________________________
>> Bf-cycles mailing list
>> Bf-cycles at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-cycles
>>
>>
>
> _______________________________________________
> Bf-cycles mailing list
> Bf-cycles at blender.org
> http://lists.blender.org/mailman/listinfo/bf-cycles
>
>


-- 
With best regards, Sergey Sharybin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-cycles/attachments/20160318/fd7edfdb/attachment.htm