Feb 2 2019

@Troy Sobotka (sobotka) Could you elaborate a little or maybe refer to some resource on why it's not feasible to apply view transform to current scene input strip/node separately and then pass it into VSE/compositor, that'd have it's own view transform ("None" for example), to be able to combine with existing non-hdr material?

Ok, not a bug then.
As for design - then how about having separate View Transform profiles for 3D render result and for compositing result, so that a scene can be rendered giving output with Filmic transform, and combined with material that already has that transform (especially LDR video footage, which doesn't exist without "Filmic")?
Or - bit less convenient, but probably more flexible and simpler - having an option to apply inverse transform to input strips/nodes, so that when View Transform is applied it hits only the result of 3D render.

There is no slider to go beyond 1.0 if setting HDR color is the point. Which it probably is not, given 1 is "absolute" reflectance, which is how majority of material color settings are used.

Normal monitor isn't capable of displaying HDR. Pushing the value down is limiting the already very limited resource of color gamut.

Normal monitor is not able do display sensible hdr even if color is being pushed down like this. Meaning - it gives 1, max 2 additional stops with a highly trained eye. One can't tell what color it actually is and at what luminance beyond that.

It does happen in 2.79 on windows/linux too, however I was wrong - Converting in Handbrake (FFMpeg) directly from PNG does produce the color shift too. Converting from MOV+h264 that was created from the same PNG in AfterEffects however does not. Which suggests that there is a problem and that it is solvable, but it's unlikely to be a Blender's bug.

On an unrelated side note, given Filmic was mentioned - applying Filmic color space transform to scene rendering by default may be a good strategy for many cases, but it probably will be a source of headache and many complaints for anything involving video editing as any imported file already has color transforms applied to it, which will damage external footage and will accumulate on re-rendering even on that made in Blender, unless paid attention to turn off.

It is already set to sRGB/Default in the attached file. I was talking about the color space used by the FFMpeg encoder inside Blender (FFMpeg in converters like Handbrake seems not to have this issue). The difference is less perceivable than that between Filmic and sRGB, but it is quite strong in terms of color correction.

Jan 23 2019

If I may add -
Alt+scroll doesn't work for scrolling time (2.8beta), which was it's global function in 2.79. Wouldn't say anything, but it is the main navigation method for animation. Not having it makes things harder and slower.

Nov 12 2017

BSDF transparency is another can of worms I wouldn't touch. I was referring to input value of rgba(1, 0.5, 0.25, 0.25) fed directly into compositing Combine RGBA, resulting in grey (transparent white) output (at least in the output file), which I though from your comment is due to clipping of premultiplication. Which it seems shouldn't happen.

Thanks for the link and I understand the problems with background-color/premultiplication, but it seems taken a bit to extreme.
Whether the render layer is being passed into compositing premultiplied or not is a matter of preference, as long as it's consistent, but unless I fail to see something else, explicit values and channel transforms shouldn't be affected by any post processing "behind the scenes" before final output.
That is - nodes like "Combine RGBA" (maybe Color Input) shouldn't do any post-processing on values passed to them. In contrast, a "Set Alpha" node can be expected to do premultiplication as the user just expects it to work within given color system (which as you said is premultiplied), but nodes like "Separate/Combine RGBA" imply and are needed so that manual transforms can be made. And, I mean - it's not exactly manual, if it's being automatically transformed on the spot :)
Sure it'd be great to have a fancy "unpremultiplied" checkbox here and there, but given there are options to do something alike to math on channels, there should be no obstacle to output anything imaginable without the checkbox, by doing manually at least.

Particle cache, at least from how it looks, isn't exactly relevant here as the main problem is with inability to move the animated objects themselves.
However if the issue is tedious and as some claim the particle system will be rewritten in observable future, the workaround of temporarily disabling subframes could be acceptable in most cases.

Nov 3 2017

"I think it is expected behaviour in order to manage baking in files containing multiples simulations."
Not really, because it's a Bake button of a concrete object not the scene. That is - it is there to explicitly bake a concrete object and it can't do anything else.

Oct 27 2017

Thanks, I'm aware of that, the diversity itself is achievable quite easily. The goal was in interpolation of that diversity (like "clumping" in hair) and at moment that takes considerable amounts of magic, that instance modifier being compatible with skin modifier would alleviate in some cases. Sure, it may not be worth the time investment if the PS system will be rebuilt, but it's out of my competence to judge.

Changing the order eliminates the purpose. Which is to create impression of particles being bent differently with a controlled degree of cross-neighbor relatedness (think flower petals, mosses - lots of small scale repetitive structures). Because if the deformation texture scale is large enough for that to work (affecting particle mesh as whole, not just shifting separate vertices randomly), it begins also affecting particles as a whole, not individually.
A tested alternative for such cases is creating individual objects instead of particles with noise*location based driver deformation modifiers, however that has to deal with mass application of drivers, them using "self", etc, grinding performance of anything but unique cases to a halt.
A theoretical work-around would be having custom object hair PS, but objects seem to replace hair, not following their shape.

Oct 3 2017

@Vuk Gardašević (lijenstina) "If the area is made wider (by dragging the border) than the default width of T and N regions in pixels - they will be displayed." At least in 2.79 and before this seems not to be the case. If the n-panel in the viewport is scaled up and the viewport is reduced in size after, it won't show up regardless if there is space for the default size.

Could be called a minor headache but this sometimes does lead to confusion and thinking that keyboard button isn't working or something like that (had been banging it a few times :) ). "Instinctively" one often assumes that the panel will get reduced in size to available space or would even get displayed in any way possible rather than not show up at all. Especially problematic when opening a project saved on a big monitor on a smaller computer. Makes one wonder why suddenly all the panes "stopped working".

Sep 11 2017

Thanks, but the reason of using "self" is the object having many thousands of copies (things like petals of opening flowers etc.). Referring each one to itself is not really possible. If it will be fixed eventually, there's no use wasting time of course.

Aug 12 2017

Sorry, I'm not a developer :)
What I meant is it doesn't look like a bug, but something with geometry.
Also the general rule for reporting is to post an example .blend file. In this case that would avoid guessing.

Task manager graph shows CPU utilization not speed. It is logical that there's less computation while fetching transparent tiles, hence the lower utilization. Also the model seems to have relatively simple shader, hence not a big difference in render speed between geometry and background.

May 29 2017

Thanks. Not sure I get "delete for real" in outliner part though, as in Outliner->Blender file mode, Right click->Delete on objects acts the same as normal delete. That is - nothing happens if an object has shader node users.

May 24 2017

"When a texture coordinate shader node refers to an object and the scene is made a full copy of, the material itself gets duplicated, but the nodes still refer to an object in a previous scene, not the duplicate."

When a texture coordinate shader node refers to an object and the scene is made a full copy of, the material itself gets duplicated, but the nodes still refer to an object in a previous scene, not the duplicate.

May 23 2017

Open the attached file and re-save it. The file has only one object present (as seen in the viewport and outliner), the rest were deleted. But a bunch of objects remain saved in the file as can be seen when trying to append or browsing data blocks.