Yamyam: 1版をインポートしました

2018-06-28T21:14:28Z

1版をインポートしました

wiki>Levon: /* Moving Forward */

2015-07-21T12:37:53Z

‎Moving Forward

新規ページ

=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

<source lang=python>

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

</source>

===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.

<source lang=python>

object
{
object_param_2Dvector 1 2
object_param 12.345
object_param "string"
}
</source>

===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.

<source lang=python>

scene:
transform:
light:
</source>

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===

<source lang=python>

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

</source>

===JSON===

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

<source lang=python>
{"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]
}
}
}

</source>

And the same in Arnold:

<source lang=python>
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
}

</source>

==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===

<source lang=python>

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

</source>

===Vray .vrscene===
<source lang=python>
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;
}

</source>
===arnold .ass===

<source lang=python>
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
}
</source>

===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>

← 古い版	2018年6月28日 (木) 21:14時点における版
(相違点なし)

利用者:Levon/cycles standalone format - 版の履歴

Yamyam: 1版 をインポートしました

wiki>Levon: /* Moving Forward */

Yamyam: 1版をインポートしました