- User Since
- Nov 28 2009, 10:22 PM (507 w, 3 d)
Mon, Aug 19
@Philipp Oeser (lichtwerk), you need to access runtime.curve_cache from evaluated object, and write new texture space based on the min/max values calculated from it to original curve.
However reading upstream discussions around these topics, I expect at least half of these would not be accepted.
Sun, Aug 18
Sorry, I can not accept this. This is a quick hack which:
Sat, Aug 10
Fri, Aug 9
Tue, Aug 6
Mon, Aug 5
Particle dynamics is to be baked prior to render, otherwise it's hard to give predictable results.
Is there any harm to remove if(WITH_COMPILER_ASAN) checks? From historical reasons i didn't use it and instead was passing -fsanitize via CMake's CFlags. If we remove the check the new code will "sanitize" compile times for such manually injected cflags as well?
Sun, Aug 4
There is no way to fix history.
Please properly configure your git's user name and email.
See https://wiki.blender.org/wiki/Tools/Git#Making_Local_Changes for instructions.
Is deleting/excluding invisible collections making playback faster?
Fri, Aug 2
Hrm, weird. Can not say i remember such slow compile times., but sounds like it is too annoying for people.
I don't think it's great idea to disable ASAN options for Debug builds.
I don't have issues compiling or running debug kernels with ASAN enabled. And that does help catching some mistakes and bugs.
Think is fine, but interesting to hear from William.
Thu, Aug 1
Does it happen with both MSVC 2017 and 2019?
This isn't really my area: is something to do with depth picking from viewport.
@Germano Cavalcante (mano-wii), something you are familiar with?
It is indeed some invalid state, but i am not sure what's going on. Same bug happens in 2.79, and this isn't really my area.
Sounds reasonable, but will trust you on tests and such.
CTX_data_depsgraph() usage is wrong. The underlying code requites dependency graph to be at an evaluated state. But you can't simply use CTX_data_expect_evaluated_depsgraph() in those functions because there is no guarantee they are not called from a loop or stuff like this (see how ED_object_sculptmode_enter_ex is used in ED_editors_init). Also see rB3566b81c8bf.
Those functions are wrong and without knowing where or how they are used is impossible to make them right.
The fix was done after the merge window for 2.80, and is not fully safe fix. It will be in 2.81 together with many more fixes which didn't happen in 2.80.
You can also use latest builds from builder.blender.org which includes this fix.
Guess whatever is taking to make Blender to work? But this sounds weird. Any DLL which uses C++11's thread_local will cause issues in any application? This doesn't sound correct. Or maybe this CRT is just broken by design?
This of course can and will be fixed.
Wed, Jul 31
Think all feedback has been addressed in one way or another.
All previous daily builds
This is indeed better approach for threading performance.
Is there a noticeable memory peak with this change?
OPTYPE_USE_EVAL_DATA is no longer to be used. See D5377 for more details.
Quite sure that revision also fixers this case.
Tue, Jul 30
It depends on complexity of the function which handles element.
One question here is whether we should provide usercode with a spinlock by default, or enforce it to always handle its own sync mechanism. I kept it, since imho it will be needed very often, and generating one is pretty cheap even if unused.
Changing modifiers and constraint enabled state does not tag relations for update. This means you can not check for enabled modifiers in BKE_object_modifier_use_time(): if modifier which is dependent on time is disabled in .blend file, it will not properly update when you enable it in the interface.
Mon, Jul 29
@Sebastian Parborg (zeddb), ideally should indeed share code, so the drawing and normalization are based on same exact things.
Surely, there could be some missed extremum which falls between of sampling points, but it will be missing for drawing as well then. So I wouldn't worry about this.
It seems that for movie clip this change doesn't move progress, but also shows it in the status bar, making it so progress is displayed in both clip editor's header and status bar. I don't think this is a great redundancy.
OpenCL drivers on macOS are on an abandoned state. They have known bugs which will never be fixed in the driver (because Apple decided to go their own Metal way) and which can not be worked around from Blender side.
Sun, Jul 28
@Brecht Van Lommel (brecht), on a more technical note i've looked into gpu_texture_create_from_ibuf which is used by the background images, but it is not really clear to me how view transform fits there. Linearize the result of view transform, and apply sRGB transform in there? Or separate split the background image and make them always be in display space?
Sat, Jul 27
@takaaki takeda (popqjp), please make a new report, is better this way.
@Antonio Vazquez (antoniov), DEG_get_ctime() is intended to be used from evaluation code. From operators it is not really accessible because dependency graph might not be yet properly evaluated:
- On undo there is no dependency graph
- On other cases it is possible to have operators running from a script or macro, inbetween of which dependency graph is not guaranteed to be evaluated
- Operators are intended to be working on an "original" domain, and this is what CFRA is.
Thing here is: the color management changed quite a bit in 2.80, and it's not always possible to preserve it 1:1 due to some looks removed, some renamed and so on.
Fri, Jul 26
This is not dependency graph.
A lot of updates (tm)