- User Since
- Aug 13 2010, 4:07 PM (527 w, 20 h)
Thu, Sep 17
Tue, Sep 15
Fri, Sep 11
Mon, Aug 31
Thu, Aug 20
Jul 14 2020
Jul 3 2020
"I mean this is for creating imagery, and I'm fairly sure most of the planet treats the alpha as describing transparency for compositing"
Yes, which means that things like fire, require their separate layer, so they can be composited bypassing the rgba-mix blending mode mode, as they can be (and usually at least partially are) emissive without occlusion.
Jul 2 2020
@Bastien Montagne (mont29) Somehow that slipped past me. It indeed works. Which means complex character testing begins :) Thank you.
Jul 1 2020
@Bastien Montagne (mont29) Awesome! Tested, and kinematics driven ShapeKeys indeed seem to work. Which means that at least simpler characters should now be possible.
From bone custom properties they (as well as some IK/FK constraints drivers/switches etc.) are "Disabled: Can't edit this property from an override data-block".
Should one expect that to change within 2.9 or look for workarounds?
Jun 12 2020
Jun 11 2020
Jun 9 2020
Jun 3 2020
Disabling topology mirror in edit mode does work!
I bet people will complain about this again, but it does work.
Jun 1 2020
In fact this happens from time to time. For some reason mirroring hair particles stops working at some point and the mesh needs to be recreated from scratch. Couldn't find a reason.
May 31 2020
Sorry - my bad. he source mesh had double vertices.
Sorry, the mesh was broken. Recreating the mesh from scratch works. Though after removing double vertices in this one it still doesn't.
May 30 2020
May 18 2020
May 16 2020
May 14 2020
May 12 2020
Enabling showing armature in the viewport indeed seems to avoid the issue (it was hidden to avoid seeing two armatures after creating a proxy, which now seems not to be there).
May 11 2020
May 8 2020
Yeah, this is quite limiting in rigging. Having one transform channel dependent on another one is quite common - a jaw hinge or even simple rolling action. Having to create multi-bone rig for that seems wasteful.
It works however for some reason to use Self pointer (which often is an invaluable saver btw). But unfortunately, it requires allowing script execution regardless of what it tries to access, and that is a source of problems in collaborative projects, not to mention safety.
May 5 2020
@Vyacheslav (hitrpr) Of course it does. They aren't the same. When you divide the mesh into triangles, you get a mesh that doesn't need much interpretation. But when you leave polygons with lots of vertices the program has to figure out how to interpret those vertices as triangles all the time before they can be drawn. (I'm simplifying of course.)
The clip in question doesn't have camera/object "solved". All that is needed from it are just track point animations.
It would be logical to assume from a user perspective that start/end for baking is limited by the scene start/end. Limiting it by a valid reconstruction is probably smarter, but a fallback would be nice. Or an error saying something like "no valid reconstruction (use Bake Action)".
Why did you expect anything else? :)
I mean - you created a single face with thousands of vertices. It's a miracle you made it that far. A face undergoes "triangulation" depending on it's geometry to be drawn in an optimal way. It's a lot of work to check the geometry of what you did and figure out which vertices should have a common edge.
Apr 17 2020
Mar 20 2020
In my case Adaptive Sampling adds noisy dilatated (3x3px) shading mixed into AOV (both color and value).
Expected solid white mask:
Mar 10 2020
./blender -t 1 linked.blend
unfortunately gives the same result.
Hiding Status Bar doesn't change anything, although there's no hint to see anymore.
Mar 3 2020
Mar 2 2020
Did a test with builder.blender.org - blender-2.83-7b8db971d42f-linux64.tar.xz.
- I download all three files in a single folder,
- Opened "linked.blend"
- Entered pose mode on right armature. Scaling the bone works as expected (the box scales along).
- Entered pose mode on the left armature. Scaling the bone immediately offsets the box that should follow along in-place.
- Exiting pose mode and moving the armature moves the box back where it should be.
Feb 24 2020
2.8x decided that viewport visibility is off, for some reason. The behavior is almost the same (object doesn't get transform display now).
Feb 3 2020
Thanks, will try to test, but: https://developer.blender.org/T73563
Jan 30 2020
Jan 23 2020
Thanks for the reply.
What's the point of not fixing this given the solution is found? Doesn't FFmpeg API allow flags like command line version?
Thousands of people render ffmpegs every day not suspecting the colors get screwed, and those that do probably think (as I did before), that ffmpeg is just not good for anything and have to reseort to external converters.
Jan 21 2020
I am able to reproduce it in Blender 2.79, although way less often (about 1 of 100 region border transitions) than it was on win8.1.
In Blender 2.82, I can't say it doesn't happen definitively, but if it does it's negligible under tested conditions. Time will tell.
The OS on the machine was changed from Win8.1 to Win7, so I can't tell for sure, but in about 10 minutes of testing with 2.82, it seems I had this happen only once (if at all). So if no one else can recreate this, it probably should be closed for now.
Jan 8 2020
After a bit of shifting around - a probable workaround seems to be to link with unchecked "Instance Collections"
(then select rig in Outliner to make proxy, as it's usually hidden to avoid doubling).
That way, although a bit messy, everything seems to work, so there's probably some conflict with parenting when instancing.
Hi, the mismatch is still there.
Here's the file linking the files above as per description:
Edit3: Enter pose mode and move bone on the left object. The geometry doesn't match motion scale, which doesn't happen on the right object.
Dec 27 2019
Having them as separate buttons in the menu is what confused me.
It might be good to for things like this to appear in search for the same reason they are made as separate buttons, but it's not a bug then.
Dec 9 2019
Although none springs to mind - sure - affecting handles as if they are their own origin points might be a desirable feature in some situation,
Ignoring whether they're set to be aligned is the catch.
Dec 5 2019
Tested in 2.81 with the same result.
Nov 20 2019
Oct 9 2019
This still occurs in official 2.8 - rendering test ffmpeg produces color shifted image, compared to source png.
Aug 27 2019
I'll try to replicate it, but afaik the 'Delete' command was added in 'Blender File' view for cases like this - to force-remove the data if something goes wrong and it is considered used by something.
Thank you. That indeed worked.
Thanks, I'll probably find a work-around, but just to give an example - in my case there are 160 objects with linked data. Although it's probably possible to do some check on whether the data is compatible, I actually wasn't expecting that due to potential nuances. But what also wasn't expected is skipping the modifier alltogether, as it could skip just the hidden vertex binding list, still removing the majority of clicking work.
Aug 26 2019
Aug 20 2019
I mean - If the explanation behind is that ctrl+tab should always call a mode choice menu, then there is an inconsistency that in object mode, ctrl+tab leads directly to Pose mode instead. If not - why is it there for Bone edit mode? It's not like switching to Pose from Object mode is somehow less needed that from Edit mode.
Sorry for awkward explanation.
Wait.. I'm not sure I explained myself right - the complaint is that there is a new unnecessary menu added that does nothing but slows the user and is inconsistent compared to the other mode.
Meaning - From Pose mode - pressing Edit hotkey (tab) goes directly to that mode, but from Edit mode, Pose hotkey (ctrl+tab) does something else - calls a menu.
Aug 19 2019
Aug 15 2019
Also - this is even less of a bug, but graph editor frame strip eats away from it's viewport when making graph editor region full screen and back. Possibly it should be excluded from viewport height together with scrollbar, although strip's bg_color could just be more transparent by default, as what's behind it is actually still clickable, despite being hardly visible.
Regarding being a bug or not - you can't select a node after running the function that is supposed to make it available for selection (visible), so...
Sorry - I'm not using 3D machine for internet, so it's not really easier, but I'll try to if the time allows next time.
Anyway - if it's already fixed probably should probably be closed. Thanks!
Apr 16 2019
Apr 15 2019
Feb 26 2019
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?
Jan 31 2019
With latest build I can't reproduce it too.
Assuming there is no reason to believe the release will behave somewhat differently, I should've checked that first before posting, sorry.
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.
Huh - I thought "incomplete" means it's not yet worth trying to reproduce, and "Open" as being investigated.
No, those are different machines, however rendering in the file is set to CPU (gtx580 isn't supported as CUDA device in 2.8).
Btw - what's incomplete about the report?
Jan 30 2019
Sorry, I should've worded that clearer.
Color type differentiation sounds intriguing :)
- It doesn't reach 255 in sRGB display transform.
- 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.
Ok, so this:
does the conversion for other programs to read colors identical to png.
-color_primaries 1 -color_trc 1 -colorspace 1
makes Blender recognize the converted colors properly.
Found it! Adding this option to ffmpeg seems to produce result with no color shifting:
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.