Yeah, I am currently suffering from the same problem. I think it's mainly a problem with the very bright intensities of glossy reflections. At least in my case it doesn't need any SSS to produce the issue, just a rather reflective surface. I am facing this problem mostly with metals in scenes with bright lamps. I think the denoiser somehow tries compensate for the brightness differences between the glossy reflection and the much darker surrounding areas, and by overcompensating that brightness differences it makes the problematic areas black. Or something like that. No idea how to solve that but maybe as a workaround the denoiser could just keep the super bright highlights just white?
Here's the above file but without SSS and point lamp, but with a metal surface, still producing a black artefact.

Oh that's right, I did not test previous versions before. Probably never worked, at least not in 2.77 which I just tried.

Yes, here is a file demonstrating the issue (GTX980ti here, on linux).

Yeah, it's true. Not quite sure if it's actually a bug, but it's annoying nonetheless. However, I think we can be sure that it will be more than fixed in 2.8 ;)

I didn't test this yet, but I can see how this can be quite useful, especially in large and complex nodetrees with long noodle connections, where you want to compare the effect of a node input with the original node input value. Visually it is consistent with the red color of the mute node functionality and seems pretty straight forward to use.

At least on a GTX1080 with Cuda on Linux and latest master it does not happen. So probably it's more an issue with AMD Cards, OpenCL or OSX.

Thanks for the report. However, this is very similar to a recent report about custom transform orientations, which turned out not to be a bug. Especially Extrude works totally as intended. See my answer in the other report here: https://developer.blender.org/T52618
It might be a bit counter-intuitive (though thinking bout it I wouldn't even agree to that), but it's not a bug, therefore I am closing this.
Unless you find another case except extrude where custom orientations do not work. If so, please describe in detail where and when it happens.

Yep, turning off AO solves your problem. No bug here, this report can be closed then, I guess...

It seems to me you are trying to open an OBJ file, which for some reason got renamed to .blend. Anyhow, without the attached file we cannot reproduce or test your bug report.
Also, please use the bug reporting guidelines, otherwise the report is considered incomplete.

Yeah, just displaying the finished tiles is totally fine. @Brecht Van Lommel (brecht)'s solution takes up even less space in the interface! Win-win! :)

I replied in the other report as well.
And yeah, I also think it should be changed. It might not be a code bug, but a grammar bug it definitely is. For instance it says it is working on tile 11 from 12, when it is actually working on tile 12 from 12. A bit confusing for the user.

I think that is actually weird as well. If I have 12 tiles in total it would report "Path Tracing Tile 11/12" when working on the very last tile. Isn't that confusing for the user? It says it is working on tile 11 from 12, when it is actually working on tile 12 from 12. So maybe not a bug code wise, but definitely a grammar bug ;)

The shadow catcher is indeed only catching shadows, as the name suggests. It will not pick up any reflections.
Of course it would be nice if it would catch every aspect of light interaction, but so far the shadow catcher doesn't do that.
So, not a bug here, as far as I can see.

My guess is that it could be a problem with extreme clip_start, clip_end settings in your view panel. But to check that you would need to attach your blendfile, if possible.

Sure! And a well written, detailed bug report never hurts, even if it turns out that it wasn't really a bug! So, cheers! :)

I don't think this is really a bug.
Extrude is actually a combination of 2 actions:
First it creates the new face, connected to the previous one.
Then it jumps into translate mode, with the face normal set as lock axis. For extrusion it usually makes the most sense to have the movement follow the face normal.
However, if you press Z the first time, it will "free" the axis lock, meaning that if you keep on moving the newly extruded face it will follow your mouse cursor in any direction.
If you press Z the second time it will move the face along the global axis, and if you hit Z the third time it will set it back to extrusion along the face normal again.
If you don't like the behavior, simply press Esc right away after Extrude and then G+ZZ to move it along your custom axis orientation.

Yeah, that's true. It's weird, the meshes are also note really broken nor do they have flipped normals, so I don't see why it shouldn't work here.
I also noticed it myself that sometimes Carve works better than BMesh for no apparent reason.

Yeah, I can confirm that.

This looks more like a feature request than a bug. There is no broken feature here that doesn't work as intended, but something that you miss as a feature.
I think it should still be possible to use the previous filmic blender config the same way you did before.
I am pretty sure that for 2.8 the whole color system will be investigated and improved anyway.

I am not sure if this task includes the compositor, but I'll post it anyway

It's true, happens here as well. It is a bit weird indeed. Every other draw type has a far better performance than solid draw type, be it wireframe, textured view, material view, bounding box. Just solid draw drops to about the same speed as if I join everything to one mesh, modifiers applied and switch to edit mode.

It would be interesting to see a file where it does work as expected. Because having the same case sometimes work and sometimes not seems weird. Would be interesting to see why :)

As a follow up to this:
Blender is in fact doing a bit of color management stuff with your alpha channel somehow. Or something else is going on.
Anyway: If you duplicate the node with your image (prop_shield_01_sg.tif), set the new node to non-color (as you did with your roughness map input image). Then you can use the alpha channel the way you want. However it will look differently than with the image you saved (the previous alpha channel, prop_shield_01_sg_a.png). Reason is that when you saved the alpha channel as an image, Blender was in fact applying the current colormanagement viewtransform to it.
You can simulate the same effect though when you add a gamma node with 2.2 after your non-color gloss+roughness map alpha channel output.

Thanks for attaching the blendfile.
You're right, it should work. I didn't properly double check the alpha output after disabling the "use alpha" option. So yeah, looks like a bug indeed. :)

Hey!
It's because of the way blender deals with images that include an alpha channel (premulitply, straight etc.). You can work around that easily by selecting the node with that image, go to node properties sidebar (N-Panel), and in the image properties simply disable "use alpha". That will fix your problem. So, not a bug here :)
P.S.: It would be nice if you could upload the blendfile demonstrating the problem, not just an FBX file which we have to import and then reconstruct your node tree ;)
Cheers!

Blender is indeed super inconsistent here:

• All simulations do accept start frame larger than end frame. (softbody, cloth, dynapaint, fluid etc.)
• Timeline works as expected.
• Seems it's really mainly the particles that have the bad behavior.

I do agree with @Howard Matthews (howiem) here. The timeline does behave sensibly:
You start with timeline being set 1 - 250.
You want the sequence to go from 300 to 600.
You start by entering 300 into start frame. Because Blender doesnt allow startframe to be larger than endframe, endframe is automatically changed to 300.
So you can happily continue to enter 600 into endframe.
That's workflow that makes sense to me :)
Should work like that everywhere.

Sorry, but this isn't a valid bug. It is more a problem with your keyboard. Hardware limitations cannot be addressed by the Blender Developers.
Instead, you could easily change the hotkeys for your setup.

Hey, thanks for the answer!
I was thinking of merging because you apparently committed it to addons-contrib. And since our addons both address how render-slots work, I thought it would be nice to have them both in one place. On the other hand sure it's totally possible to keep them separated.

Hey, just came across this script, very nice. What do you think of merging it with this one?
https://blenderartists.org/forum/showthread.php?418624-Render-Tweaker
https://github.com/blendfx/blender/blob/master/render_tweaker.py
It stores cycles render settings in the render slots (not directly in them, but sort of). I think they could go together well.

Actually it would be nice to be able to make it *not* use --factory-settings. Sometimes you do want to be able to use scripts for rendering. In my case it's the cube map render addon from Dalai. So if that addon is not available i cannot render my scenes the way I need it. Or maybe there is a way to activate or "inject" certain scripts just for rendering?

Hi Torsten!
As explained already in your previous report, this happens because you are using the skin-modifier wrong. The skin-modifier generates a LOT of geometry on top of your exisiting model, and apparently your computer simply cannot handle it. Which is no surprise, given the huge amount of geometry that is being generated. Even if your computer would be able to handle the geometry, the result would still look awful due to the nature of the skin-modifier. The skin modifier is supposed to be used with simple extruded edges, not with entire models. Maybe you are confusing it with the subsurf-modifier?

Since there are also many non-german developers are reading this I would like to ask to continue using English.
So, the problem is that the Skin Modifier is creating a LOT of geometry on top of your model, which is what this modifier is supposed to do. I think you are probably mistaking this modifier for something else, because the models that you show do not need to have this modifier applied.
Please watch this tutorial for more info: https://www.youtube.com/watch?v=Lfrv-IK_Agk
So your computer simply cannot handle the amounts of geometry the skin modifier creates. ;)
Then again, your models do look like as if they have been created using the skin-modifier, so I do not understand why you want to apply the skin modifier again?
Or maybe I am missing something or understood you wrong?

Hi Torsten!
First, thanks for buying my DVDs! ;)
Second, maybe it is not the best idea to include your full address here, since it is a public site. Then again, maybe it doesn't really matter to you. Just know that there is absolutely no need to include your address here. ;)

Just tested 2.78c, it's the same there. Also with all selection options.
Actually I found out something else: It seems to rely on the Pivot option. If I set pivot to the right camera and choose right eye view in stereo panel, it works fine for the right eye, but not for the left. Also the placement of the 3D Cursor happens accordingly. If I set Pivot to center I have to click in between, kinda, to get selection to work.

In T50024#404772, @Dalai Felinto (dfelinto) wrote:

@Sebastian Koenig (sebastian_k) how are you handling this at the moment?

Yeah, we did notice this noise veil kind of effect, but then again noise always looks crappy, so we just try to render as noisefree as possible. :)
And when doing so the "veil" is not noticable anymore. But different noise patterns per eye could be interesting. If I understand the code above correctly it seems like a great solution, since it is not totally random, but re-rendering parts of the image would still give the same result per eye so you can overlay with identical noise pattern, which is something we do quite often to fix stuff in final renders.

There is a way to fix the crash though. Select those black faces that don't have a material slot assigned yet and simply add one. Fixes the crash for me.

This is not a bug, this is by design (afaik). An object mode transformation does not affect the actual mesh itself, until you apply those transformations with CTRL+A.
If you scale the default cube in object mode and check edge lengths in edit mode, they will still be at the default of 2,2,2. Now if you apply the scale in object mode with CTRL+A(Scale), you can see in edit mode that the lengths are now shown in global scale.

If I create same amount of connected edges I get mostly identical result.

Why would you expect the same result for the upper one? They have a completely different amount of connected edges.

While I think the way you talk here, being aggressive and hostile, totally sucks, I agree that the actual bug (or rather call it weird behavior, since it might be a design decision) is indeed still present. I see no reason why the image save dialogue should not reflect the file settings in the file output panel.
It does indeed become obnoxious to override the settings again and again, every time you want to save an image. What makes it feel like a bug is that the image save settings do in fact reflect the file format, whether it's png or jpg, but not the file format specifics (BW or RGBA, or side-by-side, individual etc.).

Thanks for submitting this addon!
Just want to mention: We are using this addon in production since one year. It works perfectly to generate cubemaps for VR scenes, both monoscopic and stereoscopic. Especially in game engines like Unity it is great to have all the 6/12 sides of the cube separately (at least in our workflow). However, in some situations it is useful to combine them to one single very long strip of the 6/12 sides. For that situation I am using ImageMagick with this command:
convert EAST_0001_R.jpg WEST_0001_R.jpg ZENITH_0001_R.jpg NADIR_0001_R.jpg NORTH_0001_R.jpg SOUTH_0001_R.jpg EAST_0001_L.jpg WEST_0001_L.jpg ZENITH_0001_L.jpg NADIR_0001_L.jpg NORTH_0001_L.jpg SOUTH_0001_L.jpg +append output.jpg
Maybe it is possible to do this with python from within Blender?

I think it would be good to have some guidelines when designing pie menus. Of course this is just personal preference, but anyway, here's what I think should be considered when designing pie menus:

1. Pie menus are for fast and easy access to the most used tools and operators
2. They are not there to cram every single option related to the tool into the pie. For that we have menus.
3. Don't use non-pie-menus such as checkboxes and dropdown menus in a pie: they don't even animate together with the pie
4. Opposing operators should be on opposing sides of the pie. Example: play forward/backward, wireframe/solid view etc.

While I think it is great to be able to toggle the pie options separately, I have to say there are several pie menus that I really don't like at all.
As far as I understand, the idea behind pie menus is to have quick, muscle-memory based access to the operators. In many of these pie menus however, there are classical menus integrated along with the pie menus items.
Take for example the Shift+Z menu. In the lower left corner of the pie you have 3 checkbox items take the place of 1 pie menue entry. The problem is, I cannot even open up the pie menu and toggle all these 3 menus (Only Render, Outline Selected, World Background), because each time I activate one checkbox, it closes the pie. That makes the entire workflow cumbersome and slow, and it would be a lot faster to just use the menu in the properties panel.
Personally I think these classical menu items should not be allowed in a pie menu. At least not in an official one.
Pies are for fast access of the most important settings and operators, menu panels for all the stuff. Combining these jsut doesnt work, at least not in my opinion.

Btw, proposal for UI:

I would say it makes sense to have it enabled only when spherical stereo is activated too.
For stereo panoramas it just looks better on the poles. And if I render a perspective camera with spherical stereo enabled then chances are I am either rendering a cubemap (which has the same characteristics as a panorama when it comes to stereo viewing comfort) or want to integrate something into a before rendered panorama (be it cubemap or equi etc.), in which case I would want pole merging enabled as well so that it matches the panorama.

I tried it (before the most recent update) and so far it seems to work good, though I couldnt test it in VR yet. Having an option to use different mappings would be great, especially the most common one where you have a long stripe of images. I don't want to use the term industry standard, because one, the way that mapping is set up is super stupid (in my opinion) and things change anyway all the time in VR world... :)
Anyway, awesome to see this progress.
What we use in the studio all the time is Dalai's cube map add-on: https://github.com/dfelinto/render_cube_map
It's a bit of a hacky solution, but the nice thing is that you can render the different sides separately, which I think would be a nice addition to the "official" version too: you can distribute the single tiles to multiple machines, compositing works better and you can render single tiles again to fix mistakes.
When I am back in office I will test a bit more.

In D1872#42854, @Martijn Berger (juicyfruit) wrote:

Is there any known way to consume these... ?

While this implementation seems good I am wondering if it might not be better to also create a real case where these maps are consumed.

@Sergey Sharybin (sergey), spherical stereo is also used when rendering cubemaps, not just panoramas. so it does make sense to have it :)

That does indeed fix the issue! Plus, it renders faster :)
With own build (cuda 6.5) i get 9.9secs without sample all indirect, and 45.7 with sample all indirect.
With buildbot (cuda 7.5) i get 8.5secs without sample all indirect, and 41 sec with sample all indirect.
Tested rendering with gtx970, 980 and 980ti
So, yay!
Thanks @Brecht Van Lommel (brecht)!

Could it be because I compile with Cuda 7.5?

I get the same problem on OSX 10.11.2 with a GTX980.
Rendering the file from this bugreport renders the same as with just 1 sample in world settings, even though it is set to 24.
Rendering the same file with 2.76 behaves as expected and renders with 24 world samples.

Ah alright, good to know, thanks :)

And here it is with the backtrace:
http://www.pasteall.org/61079

I was able to reproduce again on my laptop, and have now the lldb log:
http://www.pasteall.org/61076
Not sure if that helps?

Confirmed on OSX 10.10.5, 2.76.4, 7fab7b6. Blender starts "Listing Dirs" but nothing happens, then it freezes.

In D1393#30218, @Julian Eisel (Severin) wrote:

The only open question I see here is which point we should use for measuring distance.
E.g. upper-left corner (as currently in this patch), upper-middle-of-header, node center (seems logical, but node link might be completely overlapped by node, making it hard/impossible to see)

This is something that should be tested by and discussed with users, so feedback/testing welcome!

Wow, everything seems to be working now! Also my issues from yesterday seem to be gone now.
Thumbs up from me!! :)

There is one more problem with frames:
In the attached image I try to insert a node into the lower connection. The frame is not pushed to the right, but the composite node is.

Weird. For me this renders identical. Can't see any errors.

Are you sure you don't have a Subsurf Modifier on that sphere with a different detail setting for viewport and render?
Because with just a default sphere I cannot reproduce it.
Maybe you can attach your blend file?

Tried the latest changes and it still is amazing. Probably even more. It is no problem to insert new nodes into even the most narrow, crowded, crammed spaghetti nodes. :)

I cannot reproduce that, neither in 2.75a nor in current master 0e2bbd0.
(OSX 10.10, GTX 970 with 4GB VRAM).

I tested the scene with dimensions set to 40% and I get the exact same render speed per frame when starting with F12 from within Blender and from commandline. Tested on OSX 10.10 with GTX970.

Yes, I should definitely do a review for this. The functionality is much needed! :)

Could you try to first reproduce this behavior with a smaller scene? Having to download 560MB makes checkin the bug a bit unpleasant ;)

I'm impressed. This works SO much better than the old behavior!

In D1373#28424, @Thomas Beck (plasmasolutions) wrote:

Yeah, that was a misinterpretation caused by two Germans that are talking in English ;) And just to prohibit further misinterpretation: Having a left / right combobox does not mean for me that you won't have a modal toggle possibility via a hotkey - that would be still needed..

@Thomas Beck (plasmasolutions) Actually, I misinterpreted your reasoning about left<-->right direction. Of course one can prefer to have output sit fixed and add nodes to the left. In that case the current behavior of toggle would be fine, but different from other tool-toggles. Using a menu is clunky from workflow point of view though.
So! UI-Team! What say you? :)

In D1373#28421, @Thomas Beck (plasmasolutions) wrote:

Hi @Sebastian Koenig (sebastian_k),

that maybe the case in your workflow, but you can't generalize this - as we have an infinite node space in every direction and we have users that come from ltr-languages as well as rtl-languages you can't predict how they build their node tree. If they like their nodes to offset generally to the left or to the right is a cultural habit and not at all by design. Even if the node execution itself seems to be from left to right that does not need to be reflected in the offset direction.

Therefore I still vote for a specification combobox. The alternative is to break the modal tool design (where your settings are normally reset on the next call) just like @Julian Eisel (Severin) did it just now - that would be acceptable too maybe but should be approved from our ui team. Personally I don't like to see design principles broken though.

Greetings, Thomas

In D1373#28419, @Thomas Beck (plasmasolutions) wrote:

In D1373#28415, @Sebastian Koenig (sebastian_k) wrote:

Usually the options that you toggle with a hotkey during transform, such as cut through with knife tool, are not permanent but only relevant during that one operation. Once you start the knife tool again it is set back to "normal".

I second that and @Julian Eisel (Severin) s comment about the header icon: I'd like to take the snap tool again as an example. We have a main tool (snap/auto offset) that is customizable for every subsequent use of it (snap to grid, component / auto offset right / left), so a direction specifier combobox ,next to the icon seems right to me - @Jonathan Williamson (carter2422), what do you think about it?

Another minor thing I'd like to see changed is the Hotkey "T". "D" seems much more ideal for the direction to me as we try to use always the first character of the action in our tools to toggle them on / off.

Apart from that - really awesome functionality, much needed!

In D1373#28401, @Julian Eisel (Severin) wrote:

• Print auto-offset information to header during translate
• Shortcut (Shift+V) to toggle auto-offset on/off
• Shortcut (T) to toggle offset direction during translate
• Remove offset direction menu
• Addressing review points raised by @Campbell Barton (campbellbarton)

In D1373#28150, @Julian Eisel (Severin) wrote:

• Implement option to toggle offset direction (currently displayed using a menu)
• Try yet another icon variation
  
  Didn't implement a shortcut toggle yet, might do that tomorrow.