- User Since
- Jan 3 2003, 6:23 PM (758 w, 6 d)
We need a .blend and exacts steps to reproduce this problem. Append in general is working I think, there must be something specific about the case you found. It might also be worth trying the latest daily build: https://builder.blender.org/download/
There is now D2702 to improve this, it's more of a To Do anyway so we can leave the discussion there.
It does actually align to the center of the bounding box, but for text objects it works differently, while meshes and curves seem to be ok.
Fixed now. D2613 only affects Cycles side persistent data, so would not have made any difference here.
I like the idea. The main downside I see is that updating one texture (which can be an image or mesh data or shaders) will now free and re-transfer all the scene memory the GPU. That's going to be quite slow in complex scenes if you just want to tweak a single material color.
This .blend file is using generated images as textures. When Cycles renders generated / packed images, Blender will create / load the image buffers and keep them around in memory. For regular images on disk this is not a problem.
Given the FSF reply and links in T48109#369234, I think we can safely close this.
Thanks for figuring that out, that explains it indeed, no bug here then.
This bug report appears to be about Linux, where users can execute blender-softwaregl. Enabling software OpenGL does not require running Blender, in fact it is not in the user preferences at all, so there is no catch-22.
Tested on Linux now and it does still converge to a different result, maybe something compiler specific. With this many samples to resolve noise I wouldn't be surprised if float precision issues have an effect.
This one is more for the documentation team to review and commit, but seems fine to me.
This should be solved now with the continuous grab fixes.
Currently rendering with motion blur requires you to bake all physics simulations in advance. We have a to do item about better communicating when this, but for now it's not considered a bug.
This is indeed not a bug, the pass ID is not inherited by objects in the group. Overriding the ID is not always the desired behavior, it depends. The new collections / overrides planned in 2.8 are intended to let you control this kind of thing.
I've committed a fix now, tomorrow's build should have it:
Wed, Jul 19
The Blender internal BVH builder is running out of stack space, it might be macOS specific since threads there have a smaller default stack size than other operating systems.
Tue, Jul 18
I could test it with a gaming mouse now and the issue is much worse then. I found a fix now, mouse motion should be always smooth now, both for gaming mouse and heavy scenes and other mouse.
Probably this is some issue with NTFS file junctions. What is the exact error you message get, when saving a .blend to this folder?
@Stefan Werner (swerner), I'm guessing this is due to rBec25060a05e3: Unlimited number of textures for Cycles, mixing cases with bindless texture support and not. Not sure if there's a good way to make this work.
I think you forgot to attach the .blend file? You can drag and drop it into the text box, or press the file upload button above it. We also need to know the operating system and Blender version tested.
For Blender 2.79 we enabled more features in OpenCL to be on par with CUDA, but this also means we also require a recent AMD driver versions to have it all working correctly. Is upgrading to the latest driver really not an option?
Are you absolutely sure you compared the same .blend file on different operating systems, with the same blender version? This seems like a very unlikely bug. Note that the Principled BSDF and Glossy BSDF use a different roughness.
We need a .blend to reproduce the issue. In general there can be bugfixes that cause look changes so this is not necessarily a bug.
Mon, Jul 17
I updated the documentation to describe the reason for this behavior, the numbers must be powers of two:
This seems unrelated to T51971, spline IK is totally different code than IK.
Sun, Jul 16
Confirmed, looks as if premultiplied alpha is not being taken into account properly when doing the color space conversion.
Unless this happens with the default scene, we need a .blend file to reproduce this problem.
Fri, Jul 14
It's documented in the manual.
Thu, Jul 13
Looks good so far. Reroute and mute is still broken for Eevee as well, but should be solved if there is some solution to the localization for Cycles displacement.
Ok, the fix might be so simple, but some possible solutions:
- Put blenderplayer in blender.app/Contents/Resources/
- Distribute blender as a signed .dmg
Surely this is still a bug and something we can fix quite easily?
Wed, Jul 12
No problem, help is always welcome, it's not always immediately clear what the rules are.
@wky (bolt2009), did you try the solution suggested here, upgrading the CUDA driver?
Merging into duplicate report.
Please leave it to developers to close reports. I suspect there might actually be a bug here, specifically related to the smoke volume which is not in your test render.
Tue, Jul 11
Ctrl/shift/alt do indeed work different than other hotkeys that can also be used as modifiers, not doing that can lead to missed clicks when users press buttons quickly, and some other subtle key conflicts.
Also check that your tile size is small enough for there to be 36 or 72 tiles active at the same time.
The two methods are supposed to converge to the same results, but they don't seem to, which is a bug.
Mon, Jul 10
I can kind of reproduce this, when working in a heavy scene. In that cases the mouse cursor only moves when Blender redraws, and feels quite jumpy, though I'm not sure what's being described in this ticket. Sometimes the mouse position goes out of sync with object being dragged.
Actually we already have code for validating color space, we just didn't use that for sequencer strips yet. Fixed now.
This file is configured to use Filmic color management. Without that you would get an immediate mapping of the color ramp to the ones in the final render, however with Filmic there is contrast adjustment that causes the differences you see. For these types of toon renders disabling Filmic may work better.
Sun, Jul 9
Please attach a .blend file that demonstrates the issue.
Tests updated now, the newer renders are the correct ones.
Tests updated now, the newer renders are the correct ones.
Sat, Jul 8
This warning message is harmless, it is not the cause of Blender not starting.