- User Since
- Jun 4 2010, 1:00 AM (589 w, 15 h)
Wed, Aug 18
Jul 29 2021
Jul 20 2021
Of course, here's an example file you can try out the operator on:
One more thing: It looks like the value of the cursor must be non-zero for the bug to occur. Cursor value is difficult to set if you aren't using right-click-select, so that may be why you aren't seeing the issue yet.
May 31 2021
It may not be my place to suggest, but I feel that this would be quickly solved by replacing "Voxel Size" with its reciprocal, "Voxels Per Unit".
Apr 13 2021
Thank you, Philip, that is a helpful workaround. But if the Extend Bounds option changes the image dimensions, that change is only apparent in the image output and the viewer node. Why does it not also appear in the render result when passed to a regular Composite output node? This implicit cropping in some outputs and not others seems inconsistent.
Mar 26 2021
It's a funny issue because the behavior of the Erase Alpha brush appears to be ONE bug when in fact there are two different bugs. And now I don't know which bug report is which! This is exactly what I was afraid would happen, lol
Mar 24 2021
Mar 7 2021
Feb 13 2021
@Robert Guetzkow (rjg) I've been on the road and I'll have to check when I unpack my workstation. I will let you know!
Jan 27 2021
Jan 25 2021
Thanks, @Robert Guetzkow (rjg) . It seems that although the audio does not continue indefinitely when this happens, it will continue playing beyond the end frame of the scene if the audio strip is longer than the frame range.
Jan 24 2021
Jan 22 2021
Jan 15 2021
This is a known issue. Whereas Eevee will actually render subframes for each step, Cycles uses a different method which unfortunately does not account for material changes between frames.
Nov 3 2020
Oct 29 2020
Oct 23 2020
Outsmarted by the devs again! Great job!
Oct 22 2020
Oct 21 2020
Sep 22 2020
Sep 21 2020
Aug 6 2020
Jul 31 2020
This behavior is intended. If you don't want it, uncheck this box in user preferences:
What is the problem? Your example works as expected. The empty moves with the camera in walk mode, but because it is animated it will return to its keyed location/rotation unless you add a new keyframe.
Jul 4 2020
May 28 2020
@Jacques Lucke (JacquesLucke) As far as I'm aware, the compositor handles alpha perfectly fine. This is an issue specifically with how the Blender image viewer presents an image buffer when only the RGB channels are displayed. Here is a very simple example:
Apr 14 2020
To be clear: This feature does not seem to be limited to animations. The hash characters are replaced with digits when writing a still image from the command line. So it works from the command line but not the python console.
Apr 12 2020
Apr 4 2020
The issue also appears to affect multiple app handlers? Not just frame_change_post but any handler which is called between rendered frames.
I should also add that this issue does not only affect console output. If a script affects scene data based on animated values, it will work in viewport playback but not when rendering.
Mar 25 2020
Mar 13 2020
Thankyou, @Germano Cavalcante (mano-wii) . It doesn't seem to affect the final image. If, for instance, you save the image to a file, the saved image will have the correct colors (the values explicitly stated when you mouse over the pixels), whether or not you enable alpha. It will not look like the result displayed in the viewer. The viewer is showing RGB values which don't seem to relate with how the final image looks.
Prematurely submitted. Sorry
Mar 11 2020
I can confirm this. The Sun Beams node seems to hijack the LMB; any click is used to set the Sun Beam position, but the user can't do anything else. This only occurs when backdrop is enabled.
Feb 28 2020
Feb 13 2020
Feb 4 2020
As far as I can see, this issue has been fixed. I can no longer reproduce it either.
Jan 24 2020
Jan 22 2020
Jan 15 2020
Jan 14 2020
Doesn't look like you did anything wrong. The uv_on_emitter function seems to cause a segmentation fault. Here's the backtrace:
Jan 12 2020
Jan 10 2020
The problem with mirroring the metaball assembly version would be (or should be) fixed by being able to apply all transforms to the metaball assembly items. But if you try to do that, all of the items disappear (when applying the scale), which is definitely a bug.
I have inspected the your file. The "weird rotation" you see when you attempt to mirror the metaballs is the result of the practical problem of mirroring any object that has a non-zero orientation (it can't be done in global space). As such, this is not a bug.
Jan 9 2020
Sorry, this is not a valid bug report. You must provide more information and specific steps to reproduce the issue.
I can confirm this. I have also experienced this exact issue, but I was unable to reproduce it reliably in a new file.
Jan 8 2020
Ahhhh, I'm dumb for this one. I should have studied this issue more closely. Sorry to clog up the queue. Thank you for your work!
Jan 6 2020
Wait, I see now that you have not misunderstood anything. But I still don't think this is a matter of confusing names or icons. The tool's intended functions are quite clear already- they're just switched! One simply does what the other ought to do!
@Philipp Oeser (lichtwerk) please repeat the steps with the transform side panel visible (N). You will notice that the tool which is called "Bone Envelope" does not alter the bone's envelope distance value at all. It only effects the radius size of the bone's head and/or tail. Likewise, the tool which is called "Bone Size" affects only the envelope distance, and not the radius (size) of anything. It's backwards.
Jan 4 2020
Jan 3 2020
I can confirm, although this issue seems to be caused specifically by how the period character is ordered, not by string length. For instance, if you remove the period or replace it with white space, the order works again as one might expect.
Jan 2 2020
Dec 20 2019
Good find. This appears to affect the main "Help" > "Python API Reference" link as well.
This report does not contain all the requested information, which is required for us to investigate the issue.
I can no longer reproduce this bug as of 2.81a. It was probably removed in the 2.80 overhaul. Great job developers!
Nov 30 2019
Oct 25 2019
I understand the issue now. It's not a bug; you are misunderstanding the color math!
I'm unable to reproduce this issue. Can you include a .blend file which gives this result?
Oct 24 2019
Oct 23 2019
I can confirm this behavior. However, this only affects the interface. You do not lose the rendered image, nor is the render cancelled. It can still be retrieved with "Show Render" (f11)
Oct 2 2019
Color management can be tricky and misleading, but I don't believe this is a valid todo.
Aug 26 2019
Glad I could help! To answer your other question, the node setup you have is definitely not the best way to save render passes (although I've been forced to do the same thing in order to work with legacy pipelines). Look into the Multilayer OpenEXR format. Choosing this option in your main output settings will cause all enabled render passes to automatically save to a single .EXR file without any node work or technically incorrect color transforms.
The appended node groups in your example file are quite simple so those probably aren't the cause of your issue.
Aug 13 2019
Confirmed on my end!
2 weeks, no response. Hope the issue went away!
Aug 1 2019
Glad it all worked out!