Pages

Monday, August 09, 2010

By popular demand, Eric Back (Whiterabbit) has posted a very detailed update about his development on the next generation of RIBMosaic.

What's done...
- all permanent panels in the UI are complete
- the pipeline manager and pipeline driven UI panels are working
- the pipeline link system is complete (these are like tokens in the old mosaic but can now connect almost anything and be used anywhere)
- the translating of slmeta shader files to pipeline panels is working (this converts K3D shader xml files to panels in Blender's interface)
- the core of the export manager is working and export of command scripts is just finished

A lot of this is pulled from the message that Eric posted....

Description from left to right:
- The first window is the render properties window showing the RenderMan Passes and Export Options panels. Of note is the partially visible link command in the Output property "Renders/@[EVA:.current_frame:####]@@[EVA:.pass_layer:]@.tif". These links pass information from the exporter directly into that string and can used in any text field. They can also pass values from buttons from the UI directly into code in pipelines allowing designers to build their own interfaces and pass the selections directly into RIB, RSL or embedded Python code.

- The second window is the render properties window showing the Pipeline Manager panel and a example user pipeline panel called "AQSIS - Layered Display". The Pipeline Manager panel is available in all properties windows and allows you to load and remove pipeline files as well as manage their content. Pipelines are XML files containing descriptions of UI panels with RIB, RSL, Python or shell script associated to them. The idea is a pipeline designer would build any panels they need along with the underlying RIB and shaders to provide a complete rendering pipeline for specific features (such as Aqsis's layered EXR display). The artists simply load the pipeline to add the functionality they want.
The example panel shown is a test using every control RIBMOSAIC supports and is completely designed and drawn from XML. All controls are connected to Blender properties so they can be animated. The buttons can trigger pipeline scripts and show message popups (letting you give the user feedback). There is also a file browser button to quickly putting file path in text fields.

- The third window is the scene properties window showing the Export Options panel. These panels are also available in almost all properties windows and show options relevant to where they are. In this case the scene export options have low level control over things like export path, search paths and global archive options. Also note the export path is also using links with Python eval expressions (to let the user do fancy things like make the export folder use the name of the blend or scene). Also worth noting is the pipeline manager is showing different categories and the panels loaded at the bottom are using different icons in the left corner. Pipelines can create three types of panels "Utility", "Shader" and "Command" each showing in a different category list in the pipeline manager and each with their own icon. Utility panels will be for adding RenderMan features to the UI and internally generate RIB code on the datablock they are on. Shader panels represent shaders and are created from slmeta files and also internally generate RIB code on the datablock they are on. Command panels represent shell scripts and contain code that's executed on the command line. This is an interesting feature as it puts complete control in the hands of the pipeline designer allowing them to do cool things like call renderfarm managers through MOSAIC.

- The fourth window is the material properties window and shows another Export Options and a shader panel. You'll notice several of Blender's standard material controls have been placed in the export options. The only controls that are kept from Blender's render pipeline are ones that are directly export, interact with Blender's 3D view or can be useful to passing to RenderMan in some way. The AQSIS - k3d_greenmarble panel was completely generated from a slmeta file (these will soon be created by MOSAIC but also by k3d and shrimp shader editor). Like everywhere else all controls can be animated. The little buttons with the chain icon can be used to "link" the Blender data path from another control to this shader parameter. In Blender you can right click on any control and copy its data path then paste that value as a link in MOSAIC. This lets you link the value from any control in the same window to that parameter, for instance linking Blender's lamp "Energy" to a light shader's intensity parameter. Data path links can also contain math or even eval expressions to manipulate the value under artist control (no need to code).

- The fifth window is the object properties window. The only thing to note here is the export options has CSG controls. RIBMOSAIC's new exporter will support parent/child archive structures so it will use this to handle CSG. For instance you may set a parent to "Union" and then all children will be joined together, then make some sub children "Intersection" and cut those children out of the union, ect. Also I've already setup motion blur to support sub-frames although this hasn't been added to the API yet, hopefully it will by the time I'm coding it.

- The sixth window is the objectdata properties window. In the export options notice a select for primitive type. This will let the user manually specify a primitive type depending on the underlying data type. For instance if on a mesh then a user can specify PointsPolygons, SubdivisionMesh, Curves or Points. If auto select then mosaic will attempt to guess (such as exporting a Subd if a Subd modifier is on the object or points if halos is enabled, ect). Also the user will have control over exported primitive variables and I plan to make pipeline for users to add even more. Lastly Levels of detail will allow users to specify different datablocks for levels based on distance.

In the top left background is the XML code for the loaded pipeline in Blender's text editor. The top right is showing the current console output. The bottom left is showing Aqsis's framebuffer output. The bottom right is showing Blender's render result automatically using the render from Aqsis.

This is exciting news and a lot of people have been patiently waiting for some news over the past 8 months. Plus with screenshots even so we can drool over our keyboards.

Thursday, August 05, 2010

This is a brand new commit to the Blender 2.5x code actually, something that has not been formally announced nor has it been fully worked out in functionality and there is probably bugs and needed optimizations ....

This is ptex, of course. The implementation isn't complete, but here's what working for now:

Per-face ptex resolution. Each face gets a U resolution and a V resolution based on its area (relative to other faces) and how stretched it is (i.e. a thin tall face should have a lower U resolution and a higher V resolution.)

Automatic generation of ptexes. This step is somewhat analogous to unwrapping your mesh, except instead of choosing UV coordinates, it's setting the default ptex resolution for each face. There's a UI control for texel density.

"Vertex" painting. That's a bit of a misnomer now, of course, but you can paint more or less normally. (Naturally I've broken some vpaint features like Blur in the process, but it'll all be restored.)

Note: ptex is designed mainly to work on quads. Triangles and other faces are split up into quads in the same manor as Catmull-Clark. I've coded it so that both quads and tris work (although there are some mapping issues with vpaint still), however quads are the "fast case"; for this reason I've applied one level of subsurf to Suzanne in this example.

A partial TODO list:

Add UI for setting individual faces' resolutions

Integrate the open source ptex library for loading and saving ptex files

Add upsampling/downsampling so that changes aren't lost when changing ptex resolution

Change default ptex to a flat color. The random noise is just for testing, of course :)

Very very cool to hear! Congrats to the Blender devs for adding this, now all that is needed is more render engines to support Ptex as well, I would imagine within the year this will be a sweeping motion to impelment this across the spectrum of graphics programming.