This example would return the name of the image attached to the texture on slot 1. This then tells MOSAIC which texture channel to extract that token from. In the Blender materials area you can define which of 10 texture channels to connect a map to. This parameter should be followed by a number indicating which texture map channel to connect to. One last option is thats only available to textures is the "X" parameter. This would adjust the range from 0 -100 to 0.0-1.0 by multiplying by 0.01. You would therefore use something like this: An example would be, say if you had a shader parameter that requires a value from 0.0 to 1.0, but the Blender control only returns values from 0 to 100. No matter what order you specify these in, MOSAIC will always first multiply and then add by these values, also you don't have to use both so you could just add or multiply only. All you have to do is insert the parameter followed by the value you want it to adjust by, this value can be a float or an integer, positive or negative and can even be in scientific format. Integer and float types can also use the "A" and "M" parameters to adjust control ranges, the "A" means Add and the "M" means Mutiply. This means use the "Mat" catagory "SpecCol" control, which is a "C" color type. To put all this together up to this point, this is how to hook into a Blender materials specular color button for use in a standard RenderMan "plastic" shader: Surface "plastic" "uniform color specularcolor" The next parameter is a type identifier, and can be one of the following: The first parameter is the token identifier, these identifiers usually begin with a section identification such as "Scene" or "World" or "Mat" and end with the exact spelling of the Blender control (wherever possible).
>WHiTeRaBBiT" and have a series of parameters separated by "_". at least until a fully integrated solution arrives! I realize that a plugin script will never be what the community really needs, but hopefully it will help get us by. The more pre-built content and example files there are, the easier it will be to get up and running on almost any project. My hope is people will begin to contribute custom shaders and code fragments to a community library. Technicians can write and test shaders and code fragments and artists can use those fragments to produce models and scenes. On the surface it would seem needing to know so much about RenderMan is a bad thing, but in reality you need a good understanding of RenderMan to use any RenderMan exporter on any system! The use of shaders and code fragments opens up an opportunity to view the production pipeline in Blender from a bigger perspective. This assembling of code fragments is the core concept of MOSAIC (not to mention the meaning behind its name!) and although it demands at least a basic knowledge of RenderMan, it allows for rapid scene design in a open ended and unrestricted way. To achieve this philosophy MOSAIC facilitates inserting custom, library or generated code (aka code fragments) to almost any part of Blender. In MOSAIC I'm using a different philosophy, one that says RenderMan as a set of languages is a good thing, and is capable of far more than any interface could provide, but that the user interface should be simple and automate those things that must be automated. This of course is too complicated for most to do and is also very time consuming, plus its very difficult to visualize during creation. The opposite approach is to assemble RenderMan scenes by hand, using several programs and hand written RIB to pull everything together (such as using "wings" to export a model in RIB and "cutter" to assemble the scene). This is of course simpler to use because its visual, but quickly becomes frustrating because (of course) the one thing you need it to do theres no button for! This approach also has a tendency to produce very complicated interfaces that have to be "hardcoded" with every renderer variation or new feature. The first approach is to wrap everything that RenderaMan (and its myriad of renderers) can do around a complex interface. When I began looking at current RenderMan solutions, I noticed two basic approaches to building a system for RenderMan. This may seem unnecessary at first glance, but understanding how RenderMan's scene structure works goes a long way to understanding how MOSAIC ties it to Blender!īefore we begin I want to say a few thing about MOSIAC in relation to RenderMan. This introductory page summarizes some of the underlying principles behind RenderMan and MOSAIC, and how these design concepts are connected to Blender.