From BlenderWiki

Jump to: navigation, search
Note: This is an archived version of the Blender Developer Wiki. The current and active wiki is available on wiki.blender.org.

WIP

Introduction

Cycles stand alone currently uses an XML format as an exchange format from other 3d software to load data. while there are no 3d software that currently has a full implementation of cycles, currently blender has an cycles XML exporter.

The XML format was never ment to be a finished product and there have been a number of discussions about changing the format, however no progress has been made in changing the format to anything else.

the current state of Cycles standalone can be seen in the following links.

Motivation

Cycles has tight integration with blender. its easy to set up your lights, textures and press render and cycles renders in a blender window. To allow this in other 3d software would need a clearly defined API in C to hook into the host Application. An alternative method which is commonly used is an exchange format.

The host exports required data into the 3d softwares own format (rib, ass, vrscene etc) and the renderer can launch as a subprocess loading in the file. there are some overheads of exporting and loading data, but it seems to be quite acceptable in alot of cases.

A clearly defined Cycles exchange format will allow for better exporters from Host software, easier addition of new cycles features into host exporter scripts, and tight integration between cycles and the exporters.

An exchange format doesn't store everything about the scene, it only stores what the renderer needs to know, allowing for the culling of data on export from the host.

links

http://wiki.blender.org/index.php/Dev:2.6/Source/Render/Cycles/Standalone

https://developer.blender.org/T38279

https://github.com/fabiosantoscode/cycles-xml-exporter

https://developer.blender.org/project/view/26/

Moving Forward

Before any work is started on a new format, we should define what the format requirements are. I have been looking at a number of other render exchange formats to see similarities between them.

requirements:

  • human readable
  • ascii format
  • referencing other exchange files ( materials/mesh can be stored in one file, and referenced in main file)
  • binary mesh data
  • compression of mesh data?

other render exchange formats

In the Apendix of this page are some examples of the different formats used by 4 render engines, Renderman, Arnold, Vray and Appleseed

Methods

Renderman

Renderman uses a method of creating the object with one line, then setting attributes though nested attribute sets. IMHO its not very nice to read.

Vray

Vray is very similar in format to javascript. All non standard types (non str, int, float, etc) have to be cast. Line breaks


object
{
	object_param_2DVector = Vector(1,3); 
	object_param_float = 12.345;
	object_param_string = "string";
}

Arnold

Arnold is similar in structure to Vray, or The Foundrys Nuke.

no equal signs, no type casting.

Arnold doesn't uses equal signs, just parameter name and value, No line breaks.

object
{
	object_param_2Dvector 1 2
	object_param 12.345
	object_param "string"
}

Appleseed

Appleseed uses an XML format, similar to the current Cycles XML, but more fleshed out.


Cycles

One thing to note is Cycles XML has a transform node as the parent of the lamp, mesh, camera node.

scene:
	transform:
		light:

I quite like this way of thinking, and is inline with the ethos of blender, maya , Houdini.

Appleseed on the other hand has the transform node as a child of the lamp, mesh, camera node.

Arnold and Vray have the transform as an attribute of the lamp, mesh, camera node.

Options

Currently Cycles uses XML. which is a valid choice. ive outlined the possibilities of YAML and JSON.


YAML

Scene:
	Lamp:
		MIS: false
		color: [0.6079999804496765, 0.6079999804496765, 0.6079999804496765]
		location: [4.076245307922363, 1.0054539442062378, 5.903861999511719]
		max_bounces: 1024
		name: SunLamp
		shadow: true
		size: 0.10000000149011612
		type: SUN

JSON

Following the same example as before, creating a light. note that by default JSON has no line breaks.

{"Scene" :
	{"Lamp": {
		"location": [4.076245307922363, 1.0054539442062378,  5.903861999511719],
		"size": 0.10000000149011612, 
		"shadow": true, 
		"MIS": 'false, 
		"type": "SUN", 
		"name": "Lamp", 
		"max_bounces": 1024, 
		"color": [0.6079999804496765, 0.6079999804496765, 0.6079999804496765]
		}
	}
}

And the same in Arnold:

Lamp
{
	location 4.076245307922363 1.0054539442062378 5.903861999511719
	size 0.10000000149011612
	shadow true
	MIS false 
	type SUN 
	name "Lamp 
	max_bounces 1024 
	color 0.6079999804496765, 0.6079999804496765, 0.6079999804496765
}

Pros/Cons

JSON

Pros

  • Json comes with python.

Cons

  • Isnt exactly human readable by default (missing line breaks)
  • No custom data types.

YAML

Pros

  • Very easy to read.
  • Custom Data Types

Cons

  • pyYAML must be installed
  • Correct indenting is essential.

XML

-Pros-

-Cons-


Mesh Data

Using ascii floats and ints are fine for small amounts of data. but what about a mesh with 1 million quads?

Vray and Arnold have binary encoding of data. i believe Vray also GZIP's the binary data.

Arnold has the option to use Ascii b65 encoding.


I personally like the idea of breaking the scene up.

A main file with scene settings, and references all files in the scene, each mesh gets its own file, each material gets its own.

This way the scene settings, or material settings can be updated with out having to export the meshes each time.

Referenced files could be other exchange files, or meshes could be obj/alembic, smoke openVDB etc.



Python Wrapper

Regardless of which format is chosen, I think we should provide a python 2.6 comparable wrapper to create the exchange file, the host integration will be simpler and more consistent. The wrapper can be a 'black box' implementation. The host integration provides the required data to the main python Class, the wrapper generates the file.

Every 3D application i have used in recent years has python 2.6 or 2.7 but rarely 3.x, blender has 3.4 (as of july 2015, 2.75) so keeping 2.6 compatibility is essential.


Cycles Material Format

If cycles is eventually integrated into a number of different host applications, a Cycles Material file format will need to be created, Allowing for Cycles Materials to be exchanged between hosts. You can create your Materials in Blender, and then open the exact same shader in Maya, 3dMax etc. this format should be identical to what Cycles reads, but only contain a material.


Other Questions

  • Cycles has no official release, should BF start releasing Cycles?
  • Included in blender, or separate?
  • Should Cycles release cycle be the same as blender, or have its own?


Conclusion

I need feedback. i dont want to make any conclusions with out getting some ideas from developers and users.

Join the bf-cycles mailing list at http://lists.blender.org/mailman/listinfo/bf-cycles

Appendix

Formats

Renderman .rib

AttributeBegin 
Attribute "identifier" "string name" ["VRayLightRect1"]
Attribute "identifier" "float id" [1]
ConcatTransform [ 1.11022e-16 0 -1 0  -0.707107 0.707107 -1.11022e-16 0  0.707107 0.707107 0 0  5 5 0 1 ]
AttributeBegin 
AttributeBegin 
Attribute "identifier" "string name" ["VRayLightRectShape1"]
Attribute "identifier" "float id" [10]
Sides 1
ShadingInterpolation "constant"
Attribute "user" "int receivesShadows" [1]
Attribute "visibility" "int camera" [1] "int indirect" [1] "int transmission" [1]
Attribute "shade" "string transmissionhitmode" ["shader"]
Attribute "grouping" "string membership" ["+reflection,refraction,shadow"]
AttributeEnd 
AttributeEnd 
AttributeEnd

Vray .vrscene

LightOmni pointLightShape1 {
  enabled=1;
  transform=Transform(Matrix(Vector(1, 0, 0), Vector(0, 1, 0), Vector(0, 0, 1)), Vector(-5, 5, 5));
  color=Color(1, 1, 1);
  shadows=1;
  shadowColor=Color(0, 0, 0);
  shadowBias=0.02;
  photonSubdivs=500;
  causticSubdivs=1000;
  diffuseMult=1;
  causticMult=1;
  cutoffThreshold=0.005;
  affectDiffuse=1;
  affectSpecular=1;
  bumped_below_surface_check=1;
  nsamples=1;
  channels=List(
  );
  channels_raw=List(
  );
  channels_diffuse=List(
  );
  channels_specular=List(
  );
  shadowRadius=0;
  shadowSubdivs=1;
  storeWithIrradianceMap=0;
  decay=0;
}

arnold .ass

point_light
{
 name pointLightShape1
 radius 0
 decay_type "quadratic"
 matrix
 1 0 0 0
 0 1 0 0
 0 0 1 0
 -5 5 5 1
 color 1 1 1
 intensity 1
 exposure 0
 cast_shadows on
 cast_volumetric_shadows on
 shadow_density 1
 shadow_color 0 0 0
 samples 1
 normalize on
 affect_diffuse on
 affect_specular on
 affect_volumetrics on
 diffuse 1
 specular 1
 sss 1
 indirect 1
 max_bounces 999
 volume_samples 2
}

appleseed .appleseed

<souce lang=python>

<light name="Lamp" model="spot_light">

               <parameter name="radiance" value="Lamp_radiance" />
               <parameter name="radiance_multiplier" value="1.0" />
               <parameter name="inner_angle" value="63.749998424140145" />
               <parameter name="outer_angle" value="74.99999867197056" />
               <parameter name="cast_indirect_light" value="true" />
               <parameter name="importance_multiplier" value="1.0" />
               <transform>
                   <matrix>
                       -0.29086464643478394 -0.7711008191108704 0.5663931965827942 4.076245307922363
                       -0.05518905818462372 0.6045247316360474 0.7946722507476807 5.903861999511719
                       -0.9551711678504944 0.1998833566904068 -0.21839119493961334 -1.0054539442062378
                       0.0 0.0 0.0 1.0
                   </matrix>
               </transform>
           </light>

</source>