<div dir="ltr">Hi,<div class="gmail_extra"><br></div><div class="gmail_extra">We do indeed need build system work and improvements to the the file format to make the standalone version usable. I don't think there is any good standard for the scene file format that is worth trying to support, it will never be a perfect fit, we need a native file format. Some thoughts on that:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">FILE SYNTAX</div><div class="gmail_extra"><br></div><div class="gmail_extra">XML and RIB syntax are well known. JSON is perhaps more readable and less verbose due to not requiring start+end elements, but also seems a bit out of place. XML would be easiest as we already have a parser from OpenImageIO, though perhaps it's not particularly hip to use XML :)</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">It's mostly a matter of taste I guess, maybe someone can come up with a good argument for one choice or the other.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
SEMANTICS<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">We do not need an attribute stacks like Renderman does. That's nice if you really want to construct more complex scenes with just a text editor, but I don't think that's our target. I rather have a flat list of data with a unique ID that can reference each other, so instancing is natural and not conditional on the attribute stack state. The list of data types I imagine would be:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">* output settings</div><div class="gmail_extra">* integrator settings</div><div class="gmail_extra">* camera</div><div class="gmail_extra">* geometry (mesh, curves, .. in external file)</div>
<div class="gmail_extra">* object (either a geometry instance or parent object with child objects)</div><div class="gmail_extra">* material</div><div class="gmail_extra">* light</div><div class="gmail_extra">* shader</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">We should make it so that we can have RIB like archives that we can delay loading once we support that in the core. We have to be a bit careful here in defining the semantics, so we don't just assume the whole archive is included in place.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_extra">GEOMETRY</div><div class="gmail_extra"><br></div><div class="gmail_extra">Geometry does not need to be in the scene file format, we can reference external files in some standard format(s) instead. Alembic is quite nice for this, it supports an object hierarchy and is designed for efficient loading.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Main problem is that it is a big dependency, and we don't have Blender export here yet? Perhaps basic .obj and later alembic support is a reasonable compromise.</div>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">SHADERS</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Shaders are node based in Cycles and OSL. You would have 3 types of shaders that all look the same from the outside, as a node with inputs and outputs:<br></div>
<div class="gmail_extra">
** Builtin node</div><div class="gmail_extra">** OSL shader</div><div class="gmail_extra">** Shader group</div><div class="gmail_extra"><br></div><div class="gmail_extra">A material or light would reference such a shader and only have a few extra properties, most of its behavior is defined by the shader. A shader group is like a Blender node group and basically a more general type of shader instance as in Renderman. If we support archives this could be stored in a separate file but use the same syntax as the scene file format.</div>
<div class="gmail_extra"><br></div></div>