Module Owner: @Lukas Toenne (lukastoenne)
Module Owner: @Lukas Toenne (lukastoenne)
@Philipp Oeser (lichtwerk) @Jeroen Bakker (jbakker) Thanks for investigating this more. I also remember at some point when I was accessing the pixels directly through "Viewer Node" image block and stored them on disk. What I realized however was the pixels were sort of rotated. I remember the depth map rendering that I got was shown 90 degrees rotated. So I have a request from you: I would appreciate if you can provide a nice Python API that allows people to easily access the rendering results without having to store the renderings on disk. Maybe bpy.ops.render.render() could take an argument like keepInMemory=True. Then people can access the rendering results through something like renderings = np.array(bpy.ops.render.results). The should also account for having a couple of output nodes. For instance, if in the node editor I have 5 Viewer nodes, renderings should be a 5 x 4 x resolution x resolution tensor.
Noisy changes like this aren't really worth as they can just cause merge conflicts and don't have much benefit.
Thanks for the patch but I am closing this one to let us keep focusing on more important things.
@Brecht Van Lommel (brecht) Just an update: I can get somehow around the forking issue using subprocess and doing one rendering at the time. However, the problem with using subprocess is I have to literally import everything I need from scratch. This makes the rendering much more time-consuming than doing the rendering normally. Sorry if it's too obvious that I'm just trying to convince you to prioritize this :) I hope that happens :)
@Brecht Van Lommel (brecht) I hope you will prioritize this in the future. Many people like me need to use Blender as a module for their research work. Anyways, I used gdb to get you the back trace after Python freezes. Here's what I get (I had to CTRL+C at the end):
This is a very low priority issue for me, since it should be quite easy to work around in the ways I suggested and the python module is not something we officially release. Given that there are many more important bugs to solve I'm not going to spend time on this now.
@Brecht Van Lommel (brecht) I'm not sure if this could be very relevant but I used OpenEXR Python bindings package to do some tests. Here's what I found out: if I have a function that simply loads an exr file and separates its channels into (R, G,B) as shown below and I execute this function via multiprocessing.Process everything works fine. However, when I just do import bpy and execute the same function via multiprocessing.Process things do not work and Python freezes. I would say this is a bug in Blender. Could you please look into this? I would really appreciate it.
I would not make a bug report to the OpenEXR project, it's not clear at all there is a bug in their library and I wouldn't expect them to investigate a vague report like that. It's a possibility but too early to tell.
@Brecht Van Lommel (brecht) You said it wouldn't surprise you if some parts of Blender of OpenEXr does not work well with forking. So I wonder, which one do you think is more likely to be the case given that I can store my renderings in other formats? Would you think it's more likely that OpenEXR is the one to blame here?
@Brecht Van Lommel (brecht) I tried with spawn but I keep getting weird errors and things do not work. It seems that I have to somehow make the process spawnable and I don't know how to do that precisely. I hope you can find a solution for this. It's so annoying for me since I have to millions of renderings and I didn't expect to do it sequentially :(
If there's another bug with OpenEXR saving unrelated to multiprocessing, another bug report can be created for that,
Maybe try using the spawn start method?
@Brecht Van Lommel (brecht) Sorry for the missing information. I just realized that the problem is being caused if I call the rendering function using multiprocessing.Process and updated the script in my bug report that shows how exactly I do rendering in my project, with all other irrelevant details removed. The strange thing is I can easily render my meshes if I do not want the rendering result to be stored in EXR files. So, if I replace OPEN_EXR with PNG and replace 32 with 8/16 I will definitely get the rendering results stored on disk. This does not happen when trying to store the result in OpenEXR format and I did not know that the multiprocessing package might be causing it. What should I do now? Why I cannot store EXR files when using multiprocessing.Process?
@Brecht Van Lommel (brecht) Sorry I should have been more clear. The problem is I am compiling Blender as Python module in Ubuntu 16.04. I don't think it is possible to import the Blender module given those arguments you mentioned. Could you please double-check this as well?
I can't reproduce this issue. I tried putting the above code in a test.py script with bpy.ops.render.render(write_still=True) at the end, and then running ./blender -b -P test.py.
can confirm on windows with both 2.79 and 2.79a
Thanks for the report, but this is a known limitation of our shading system in master branch, which is stated in our TODO list.
Ok, so this is about GLSL material display.
You can update the change by selecting different frame or continuously by playing animation.
Are we talking about the previews in the node editor? Those are not expected to update when changing the object index, they are only previewing the material in isolation, the object(s) in the scene have no influence.
Confirmed on ubuntu 16.04 64bits NVIDIA Titan Black with master 5bc2c17 and 2.79aRC.
Ohh okay, i didnt know.
The option for metallic is not for all metal textures available.
I don't think that's right, you should be downloading the metalness workflow textures from Poliigon to use with the pinrcipled BSDF. The reflection textures comes from the specular workflow which is different. They don't seem to map directly to any of the principled BSDF inputs.