- User Since
- Nov 18 2013, 5:57 PM (287 w, 6 d)
Fri, May 24
Please check if your GPU driver is up-to-date.
I cannot reproduce the bug. Can you try the latest version of Blender, please?
I'm able to reproduce the issue in the version you mentioned, but not in latest master. So, I guess this is fixed already. Please test if it works in tomorrows build.
I was able to reproduce the bug in the version you mention, but not in the latest master. So I guess it is fixed already. Please test if it works in tomorrows build.
I cannot reproduce the issue. I can select them just fine. Which keymap do you use?
Not a bug, in that example you have to increase Max Shape Angle to something greater than 90 degrees.
BLI_listbase_count(tracksbase_src) = 1 and BLI_listbase_count(tracksbase_dst) = 2, but the code seems to assume that both lists have the same length.
@Andrei Salamandic (andreymd87) can you provide a simple example .fbx file, please?
@Philipp Oeser (lichtwerk), then please also commit the fix mentioned by sergey.
Thu, May 23
Thanks. Unfortunately, BKE_curve_copy_data is not called when ID_RECALC_SELECT is used in ED_curve_editnurb_select_pick. However, it is called when ID_RECALC_ALL is used.
The alpha is premultiplied with the color values in IMB_colormanagement_imbuf_to_srgb_texture, even though Alpha is set to "Straight". Is that correct?
There is nothing the gpu can do here, because the color information is lost in the premultiplication.
@Sergey Sharybin (sergey), the issues seems to be that when tagging the curve with ID_RECALC_SELECT, cu->actvert is not copied to the curve-copy in the depsgraph. Is there a place where this just has to be added?
ok, in that case I don't really know at which level this is wrong.
Wed, May 22
I don't think this is a bug currently, that is just how it works for now.
I could not reproduce it yet.
I can see that there is some selection behavior that I don't understand and that seems buggy. Can you reproduce this in a new file?
Tue, May 21
- ensure new buffer always has at least len unused bytes
The code looks correct to me, but I still have to learn the new depsgraph API. @Sergey Sharybin (sergey) should say if this is the right usage.
Looks like the issue here is that Output -> Post Processing -> Sequencer is enabled in the properties editor.
Without it, it seems render correctly. Can you confirm that?
I left the define because I was not sure if that variable was used in some other place, I'm new modifying this kind of code, so you mean that I just create a function "static int MAX_PARTICLES_PER_TASK(void)" and call that function instead of using the variable?
Just one minor thing. Other than that seems fine.
- Generally seems like a good idea to use another number than 256. Can you provide a test file that allows us to easily verify the performance increase?
- Please remove the old comment, it does not add any value. Also remove the timing code which should not be part of this patch.
- I think it should not be a define anymore after this change. Just use a normal function call.
- Please run clang-format (make format) on the changes to ensure that the code style is correct.
I cannot reproduce it.
@Tomasz Kaye (bitbutter), can you upload the .blend file please?
Can you reproduce the issue from the default startup file?
Personally I'm wondering why x should be a special case here. Why not have an enum with CURSOR_WRAP_X, CURSOR_WRAP_Y and CURSOR_WRAP_XY and pass it to WM_cursor_grab_enable. That seems much cleaner to me.
hm the unit says "px", so I used it as pixels. I can also just multiply it with the UI scale, yes.
Mon, May 20
That is certainly a threading issue. I can have these two call stacks at the same time: