This one looks really useful, also works great. :)

It's an interesting feature. But I would want to be able to set the amount of frames that are blended and also to be able to turn it off. I think it could also be an extra operator with separate shortcut, or maybe a mod to G (like the operator modes of knife tools). Or it could be a mode to enable, like proportional editing.

Please attach a blendfile with the bug, otherwise we have no chance of looking into your issue. Also, please provide the information required in the bug report guidelines.

Let me guess: You are not in edit mode when you press "W"? However, that's hard to tell, since you did not attach a blend-file, as required by the bug reporting guidelines ;)

This is not a bug. The renderer has nothing to do with camera solving. The fact that you got different results has to do with slightly different positions of your markers in the 2 different attempts. In fact the position of the tracking markers is your biggest problem.
In the video you had put the markers only on a flat plane, and only in the very center of the frame. That's a problem. Instead you should try to cover as much of the frame as possible, and also different heights, not just a plane. In your example don't just track the markers in the center of your frame, but instead also track for example the scissors, the pencil, the background objects.

I tested it with latest master on elementaryOS 0.4.1. and it renders a nice and round ball.

Did you also try with the most recent version of Blender from builder.blender.org?

Just noticed that also the eyedropper tool to pick other things like parent objects, camera focal distance etc. doesnt work anymore.

@Sergey Sharybin (sergey) Thanks! I tried the patch, but it did not work. Neither the MCE nor the IE can open the image. If I try, it gives me an error: IMB_ibImageFromMemory: unknown fileformat (/home/sebastian/1-38_A002.0000811.dpx)
I'll open a report.

What a pleasant coincidence! I just had the problem a few days ago that I could not load a DPX file into Blender which I got from some other application. I used EXR instead as workaround. But I tried the patch and that actually works (even though the frame itself is flipped)! Here's a frame from the sequence that did not work:

This is most likely the same issue as this one: https://developer.blender.org/T52802
And that one is confirmed and still open, so marking this report as confirmed as well. Not sure what the correct policy here would be though...

Here's a fix that seems to work:

True. I'd also consider this a bug. Not a dramatic one of course, but it is indeed an inconsistency...

That patch works great, thanks a lot! :)
But man, the ToS footage was soo much better than the one I have to deal with right now...

Oh alright, sorry. Thanks a lot for the answer! :)

Yeah, I agree. Also, playblast from viewport should ideally not be affected by filmic.
Although, thinking about it, it probably is not really a bug, but rather a TODO…

Please follow the bug reporting guidelines and make sure you include the following information in your bug report:

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/T52558
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.