[Addon] Mitsuba Blender Plugin (26-Nov-15)

This thread is about Mitsuba Blender Plugin developed by Wenzel Jakob and Bartosz Styperek, the Blender addon to export and render scenes with Mitsuba Renderer created by Wenzel Jakob.

Get the addon:

Development version (26-Nov-15):

  • Mitsuba repository, download archive, uncompress and copy mtsblend folder to Blender addons folder.

It’s a beta version. Some things may not work.

Use it with a recent compiled version of Mitsuba from this branch, will not work well with the current official version.

https://github.com/fjuhec/mitsuba/tr…er-integration

I created this branch to test blender related features and try to fix issues that affect the exporter.

The changes from Mitsuba master branch taken from commit logs:

  • Add emitter support to instance plugin referencing a single mesh shapegroup (used internally)
  • Fix ray intersection for animated transforms and clipping issues in disk plugin
  • Add support for camera shift and anamorphic pixels
  • Enable compilation of experimental deformable plugin to support deformation motion blur
  • Try to fix hair plugin generating division by zero errors
  • Change the way radiance values are computed in sun and sunsky plugins
  • Fix texture not working on ward alpha property
  • Allow shapes with index-matched bsdf to be emitters

In case you don’t want to compile Mitsuba, download one of the versions here. I compiled them myself, so I don’t know if they will work for everyone.

Windows: http://www.pigeoncode.org/downloads/mitsuba/Mitsuba_0.5.0_win64.zip
Mac (no OpenMP): http://www.pigeoncode.org/downloads/mitsuba/Mitsuba.app.zip
Ubuntu 14.04: http://www.pigeoncode.org/downloads/mitsuba/mitsuba_0.5.0-1_amd64.deb

Mirror: https://www.dropbox.com/sh/6qe5ily8ft6nouk/AABCHlHVzmIRNt9M95IV9VZaa?dl=0

This version of the exporter is still a huge update with many parts rewritten.

The main feature of this update is Motion Blur.

Note from previous version:
It is a huge rewrite of the exporter. Consider it almost as if a new exporter appeared out of nowhere. Material and Lamp settings from previous versions won’t work with it and maybe other settings too.

This version comes with two main features:

  • Material, Lamp and World nodes. More control on the way materials are created. New ways to define spectrum values with dedicated nodes. Sun, sky and hdr lighting are now defined in World panel, along with constant environment lighting. Sun lamp is now a directional lamp.

  • Basic direct support for simple blender/cycles material conversion. No need to convert the material, if there is no Mitsuba node tree then the exporter tries to convert the material from blender or cycles. Complex materials don’t work yet.

I am sorry for breaking compatibility again with previous versions. I have been struggling with the decision of keeping or removing the old material system and because it was becoming such a roadblock for me I decided on dropping entirely and go for a full node system.

Let the bug reports start!

Requirements:

  • Blender 2.75
  • Mitsuba Renderer 0.5.0+ (works best with latest version from repository, doesn’t work with 0.5.0)
Addon Features:

Material, Lamp and World Nodes!

Direct support of simple blender/cycles materials

Supports all Mitsuba integrators:

  • Ambient Occlusion
  • Direct Illumination
  • Path tracer
  • Simple volumetric path tracer
  • Extended volumetric path tracer
  • Bidirectional path tracer
  • Photon mapper
  • Progressive photon mapper
  • Stochastic progressive photon mapper
  • Primary Sample Space MLT
  • Path Space MLT
  • Energy redistribution PT
  • Adjoint Particle Tracer
  • Virtual Point Light (Hardware)
  • Adaptive meta-integrator
  • Irradiance caching
Supported samplers are (basically all):
  • Sobol QMC sampler
  • Hammersley QMC sampler
  • Halton QMC sampler
  • Low discrepancy
  • Stratified
  • Independent

Other features included:

  • Direct output of Mitsuba format scene and serialized mesh file
  • Binary PLY mesh files output
  • Partial export of mesh objects, avoids exporting already exported meshes
  • Support for dupli objects and dupli groups
  • Support for particle objects and groups
  • Preliminary support for Blender Hair
  • Basic SSS shader support
  • Environment maps (only one allowed per scene)
  • Multiple materials per object support
  • Dielectric material - glass
  • Conductor material - metal

Bug tracker:
https://www.mitsuba-renderer.org/tracker/

More things to come! :yes:

Feel free to post your renders, tests, requests, bugs. Anything related to Mitsuba Blender Plugin and Mitsuba Renderer.

1 Like

BUG1
it export hidden objects

BUG2
object names with äöü etc. do not work
possible other chars and for anything not working (mats etc)

BUG3
“subdivision surface modifier” setting “view” is used - but not “render”

This looks awesome! I really hope you guys can keep on developing the addon for mitsuba.

My only request would be to have a live preview within blender to see what materials are on the objects and to change them/adjust them in real time (like cycles). Rather than running the renderer seeing how it looks, go back to blender and adjust and so on and so forth until you get the right adjustments.

  • But that’s a huge request and I know it won’t happen. Just wanted to convey my wishful thinking…

Thank you TS1234.
BUG1 is easy fixed, already is in my local version. Will commit changes later.
BUG2 is a collada exporter bug. File generated by exporter is not a valid UTF-8 file.
BUG3 also depens on collada exporter, I am trying to find how to configure exporter to use render instead of view, if possible.

RealityFox, I wish I had the skills to do that. It would be great.

Thank you very much Atom! Useful info. It will help me learn more about Blender API.

The material preview scene was already in the plugin before I joined the project and is used in the material panel but sometimes does not refresh when certain values are changed.

preview worked all time…

do not copy plugin to blender
install it instead

fjuhec: for bug/feature 3 : using modifiers render values check this:
http://www.blender.org/documentation/blender_python_api_2_64_release/bpy.ops.wm.html
And search for collada_export - export_mesh_type_selection (view or render) -maybe this should be option in render panel.
Basically here are ale the exporter settings explained: http://blog.machinimatrix.org/blender-2-64-collada/

Also one thing - about excluding layers you made it ok way, but think what if we have some heavy mesh on hidden layers. The way it is now, heavy mesh will be exported in collada (and it may take some time on eg. 2mil mesh), and then it will be remove from scene. To optimize it would be good to not export it at all in first place - but there is no support for layers on scene.export_collada operator.
One workaround would be use ‘only selected’ parameter, so before render we cold do something like:
bpy.ops.object.select_all(action=‘TOGGLE’) – it would select all visible objects on layers
collada_export ( with ‘only selected’=true) – and export without invisible (possibly heavy meshes)

But from my knowlege belender do not like to edit scene state ( eg. using ‘select_all’) while exporting - it causes crashes. So I’m not sure if above trick with selection would be stable.

About interactive preview of scene, I think it would be possible with mitsuba python api, but I weren’t even able to make it work. Seems to complex for my no skills :/. I believe it would allow things like changing materials, or object positions on mitsuba scene without reexporting whole scene. It is described in mitusba doc at the ending chapters.
Maybe WJ would help with that.

Yes, you are right on the issues you mention and the possible ways to solve them.
I have been thinking on not using collada at all. I am coding a function to export all renderable objects as a serialized file for mitsuba. The other workaround is to export every object as a ply file, easier to implement. This way all trouble caused by collada will disapear.

I plan to take a look on mitsuba python api in the future, but not soon. First I want to try to compile mitsuba with mingw64 if it’s possible.

GASP! .PLY??? no more COLLADA??? that would be wonderful! i’m beginning to believe it’s really more useful for game asset export than anything else… some of the workarounds (eg, “only selected”) involved would make rendering animations more complicated. also, i posted in the other thread about armature export -

[ATTACH=CONFIG]200599[/ATTACH]

objects deformed by armature modifiers don’t get rendered (or is it that they’re not being exported?), and the parenting relationships are strange - if you move an armature in object mode, and it has objects parented to it, the child objects end up rendered in strange places. here’s a render with the armature moved in object mode, then the cylinder’s armature modifier has been applied. the cylinder has only been moved globally by its parent, its local transformations are still unchanged from 0,0,0, etc…

[ATTACH=CONFIG]200603[/ATTACH]

anyway, you guys are doing great work, PLEASE keep it up! :slight_smile: i can’t offer much help in the way of modifying the exporter itself, but i can certainly help with stress- and bug-testing.

So is the watermark a requirement for using this render system?

It seemed like it was open source…?

I did notice this from the FAQ.

How can I disable the ‘Mitsuba’ banner in output renderings?

                                                      Specify the parameter <boolean name="banner" value="false"/>                             to the film plugin.                             

Can we just have this built into the AddOn or is there some legal issue with doing that?

I guess I am wondering if Mitsuba output can be used in commercial work?

Hi! Sorry for not saying much, I am still learning python and blender while working on this, so I am reading a lot of documentation and running small tests and don’t have much time to post or commit the changes. It’s still alpha.

ohsnapitsjoel, I am implementing Mitsuba serialized format instead of PLY. PLY was only the last resort in case I was unable to create a serialized file. PLY is easier to implement but creates one file per object. Maybe I will add it as an option.
I believe I am making progress, last test I run loaded and rendered successfully on Mitsuba. I replaced the serialized file created by mtsimport from collada with the one created with my code and it worked. After this I have to code the remaining parts to export the rest of the elements of the scene.

Atom, there is a setting in Mitsuba camera options panel in Blender that allows you to disable the banner/logo. Just below film exposure.

ohsnapitsjoel - to test it those are mitsuba exporter bugs, or collada ones, could you export file to collada, and then import it back to blender to see if it is correct?

Atom - WJ asked me to make banner enabled by default. But it seems it is not working now and it renders without banner for me. Anyway banner option is at the bottom of camera settings.
Btw. I would be great if you joined mitsuba team to code some feature maybe. I know you can do it better than me :wink:

fjuhec - really cool. I wonder about perfornamce of exporter, collada is in c+ so it is fast. Do you write your serialized version in python?
About scene I think best option for exporting scene in mitsuba xml format woulld be just converting current adjustment code. I has most of stuff anyway. You would need to put them in correct order add shape definitions at bottom.

JoseConseco, I also wonder about the performance of the exporter. I’ll try a scene with lots of triangles to see how it performs. I got the function from LuxBlend geometry export and modified it to output serialized instead of Lux format, so I guess it will be the usual speed of a normal exporter, many exporters use python code directly. As it is now, the export is made twice, one from blender to collada and another from collada to mitsuba with adjustments, this also consumes time. After modification it is straight from blender to mitsuba.

About the rest of the scene, yes, I am modifying the adjustment code to output the scene directly, replacing ‘append’ elements for the element tag and looking for missing parts that were imported by mitsuba from collada.

I am just now looking through the exporter code but I did notice two bugs which may be fairly easy to fix. Mainly hide from render and layers are not being respected by the exporter. Here is some code from the 3Delight exporter that deals with returning a list of objects based upon visible layers and renderability.


#####################################################################
# From Matt Ebb's 3Delight exporter.
#####################################################################
def is_visible_layer(scene, ob):
    for i in range(len(scene.layers)):
        if scene.layers<i> == True and ob.layers[i] == True:
            return True
    return False

def is_renderable(scene, ob):
    return (is_visible_layer(scene, ob) and not ob.hide_render)

def renderable_objects(scene):
    return [ob for ob in scene.objects if is_renderable(scene, ob)]

def is_dupli(ob):
    return ob.type == 'EMPTY' and ob.dupli_type != 'NONE'    

This code also filters by scene, which is nice. If you call [I]renderable_objects you will get a list of objects returned that are valid for rendering.

As I dig further into init.py in the export folder, the layers are being honored for ‘MESH’ type objects, but not ‘LAMP’ type objects. I moved the Sun lamp to another layer but it still rendered. It might be a good idea to make a unified call to renderVisibility for all object types.

So in line #724 of init.py in the export folder, instead of


for obj in scene.objects:

Try something like:


objs = renderable_objects(scene)
for obj in objs:

I have been playing around with trying to get dupligroup objects from Empties to render. But I have a feeling that I still need to take the matrix of the Empty into consideration.


         elif (obj.type == 'EMPTY'):
            # handle duplis
            if is_dupli(obj):
               obj.dupli_list_create(scene)
               dupobs = [(dob.object, dob.matrix) for dob in obj.dupli_list]
               for dupob, dupob_mat in dupobs:
                  if is_renderable(scene, dupob):
                     print("Dupligroup Object [%s] is a %s" % (dupob.name,dupob.type))
                     self.exportNormalMode(dupob)
                     for mat in dupob.data.materials:
                       self.exportMaterial(mat)
                     if len(dupob.data.materials) &gt; 0 and dupob.data.materials[0] != None:
                       if dupob.data.materials[0].mitsuba_emission.use_emission:
                          self.exportEmission(dupob)
                       mmat = dupob.data.materials[0].mitsuba_material
                       if mmat.is_medium_transition:
                          self.exportMediumReference(scene, dupob, 'interior', mmat.interior_medium)
                          self.exportMediumReference(scene, dupob, 'exterior', mmat.exterior_medium)
               obj.dupli_list_clear()

looks promising!

thankyou

Thank you very much Atom!

After reading your comment I have some doubts on what to do next.

In layers panel there are two sets of layer buttons, one named ‘Scene’ and the other named ‘Layers’. The first one enables/disables visibility on 3D view and accessed in python by ‘scene.layers’ and the other one does not affect visibility on 3D view and is accessed by ‘scene.render.layers’. I used this last set of layers on the exporter plugin because I thought it had to be used to control renderability but I see that the code you copied from 3Delight exporter uses the first. What is the best option to use?

@fjuhec: I think the second layer set is used to filter the Scene layers by a Render layer for compositing purposes. For general rendering you want to use the first layer set, or Scene.Layers. During export it makes sense to fetch what is visible in the current scene at the current time. This will also accommodate user who animate objects between layers in the Scene.

As I type this out it occurs to me that Render Layers probably are not supported in 3Delight, which is not a big deal because Renderman is such a pass heavy based render system.

If supporting compositing for Mitsuba is important, you could deal with it now or just put it on the todo list. As an end user it would be nice to have, at least support the pass index for objects which is a common reason to use Render Layers. Even without Render Layers support as long as the result image is loaded back into the buffer it will appear to the compositor for nodes to operate upon.

@Atom: I didn’t know that, thanks. I will modify it to render active layers instead of render layers. As I am new to blender I don’t know what is the common way of doing things.

One thing I am noticing as I read through the Mitsuba documentation is that there is no way to simply specify a surface. With all its mathematical complexity the ability to define a simple triangle does not exist in the current Mitsuba API. This is why you are having to reply on the DAE, PLY or OBJ exporters. The Collada exporter does not seem to support dupligroups.

What Mitsuba needs is a new SHAPE type plugin called “Surface” which would let you arbitrarily define a surface based upon a set of supplied vertices. But that would require C coding of a new plugin type by the Mitsuba authors and a new release of the render system.

As a work around I would be tempted to simply export every ‘MESH’ object as single file, kind of like a Renderman Archive. Then you could simply define a SHAPE type (OBJ,DAE,PLY) in the XML for Mitsuba to fetch. This would mean a slower export than the single call to collada_export that is currently in place but would allow for a broader support of objects via the to_mesh method for objects. to_mesh will convert a curve to a mesh and apply modfiers in the process. This is how I am supporting fonts and extruded curve type under RE:Vis game engine render.

The problem with going this route is that you have to actually make new objects on-the-fly and link them to the scene so the exporter operators can actually see them. Also you may have to manage the selection state of these new objects and perform scene cleanup after the export is complete. All these tasks generate events within the Blender GUI which can cause crashes within the Blender system.

The safer method is to convert to mesh into a variable that never gets linked to the scene then falls out of scope once the export is complete. But this means essentially writing your own exporter for one of the supported Mitsuba formats, (PLY, DAE, OBJ) then passing that internal mesh variable to the exporter. The .PLY exporter is probably the best candidate to fork as it is only 200 or so lines long and is mentioned in the Mitsuba documentation as being better/faster than OBJ.

What I have been coding to export MESH objects is this test version here