- User Since
- Apr 11 2017, 11:26 PM (109 w, 6 d)
- Simplified Linux soft delete, now using fork and execvp
- Added keymap entries back
- macOS currently commented, because changes necessary to make Objective-C work
- removed duplicate include for <sys/stat.h>
Since 64acb70e7f0f removes the ability to delete files, is development on this patch still of interest?
Wed, May 15
Mon, May 6
Sun, May 5
I'm currently quite busy, updates may take a while. Hopefully I can squeeze these in next weekend.
Sun, Apr 28
It's likely just outside the clipping plane. Select the object in the outliner (top right window where the collections are), go to the object tab (the window below that, click on the square icon) and set the location on all coordinates to zero. You may have to adjust the scale as well, if it's very large.
Sat, Apr 27
What you described sounds unrelated to Blender and more like your computer has been infected with malware.
Fri, Apr 26
@T.L (T.L) Yes you're right, that's why I wrote that it seems to be a different cause.
Seems to be a different cause.
It's quite possible that this isn't a bug in blender, but another case of the strange way Windows handles encoding / code pages. Depending on your locale, it may be that è is not included in your code page, which results in Windows replacing the character with ? when passing the argument to the program. If that is the case, then there is nothing blender can do, because it's not getting the right string. You can check if that's the case by temporarily activating the UTF-8 beta feature described here. If that works properly, it's Windows' fault.
Wed, Apr 24
Tue, Apr 23
Correct error messages
Mon, Apr 22
Replaced malloc with Blender's allocator.
Added missing include for macOS
Fixed wrong debug print function for Linux.
I can't test the macOS implementation, perhaps somebody can help with that . I'll test the Linux implementation later this day.
Removed unused argument from Windows delete_soft()
Several small fixes. Sorry for spamming the tracker.
Work in progress implementation of soft delete for Linux and macOS
Sure, no problem. I'll implement it today. Do you have any special security policies regarding system() for calling the CLI utilities?
@Brecht Van Lommel (brecht) just in case you change your mind: I have implemented the trash specification (currently without directory size cache).
Apr 18 2019
That would be an option, although I'd favor a general solution that works on all Linux distributions and desktop environments. @Campbell Barton (campbellbarton) @LazyDodo (LazyDodo) Do you agree with this approach?
Not sure how relevant this is to the bug report, but I can't reproduce this with my Wacom Intuos.
I think the complexity is manageable, but that is your decision. The problem that I see with the Electron approach is finding out what desktop environment we're on (which implies what CLI utility can be used). Does Blender already have an equivalent of libgtkui::GetDesktopName?
Apr 16 2019
I would like to implement support for $topdir, but in case (1) and (2) fail (see spec) refuse to trash. This means we can simply use rename since we don't move files over across devices. This makes the code simpler and doesn't require reimplementing mv.
Work in progress.
Apr 14 2019
Looks like this might be the same issue as T63582
Can you share a minimal .blend file where this error occurs?
builder is a nullptr.
As you've said yourself, you're running out of memory. Your project likely needs more memory than Windows allows you to swap to disk, resulting in a crash. If this is the case then there is nothing to fix, you simply don't have enough memory available to render the scene. If you suspect that the crash isn't caused by OOM, you can go to the installation directory and run blender_debug_log.cmd. This will give you a detailed output about what went wrong.
Apr 13 2019
Currently a bit busy, but this isn't forgotten. When I got some time I'll implement the Linux soft delete based on the approach that trash-cli uses.
Apr 12 2019
Does this happend with the most recent build? If yes, can you provide the .obj or .blend file?
This is likely because you use an old driver for your graphics card which doesn't support OpenGL 3.3 or newer. Install the latest driver and see if that resolves the problem.
It seems v_curr is pointing somewhere it shouldn't.
Apr 11 2019
col_tot is zero in the division which causes the crash.
> blender.exe!image_sample_rect_color_ubyte(const ImBuf * ibuf, const rcti * rect, unsigned char * r_col, float * r_col_linear) Zeile 3085 C blender.exe!image_sample_apply(bContext * C, wmOperator * op, const wmEvent * event) Zeile 3161 C blender.exe!image_sample_invoke(bContext * C, wmOperator * op, const wmEvent * event) Zeile 3279 C blender.exe!wm_operator_invoke(bContext * C, wmOperatorType * ot, wmEvent * event, PointerRNA * properties, ReportList * reports, const bool poll_only, bool use_last_properties) Zeile 1343 C blender.exe!wm_handler_operator_call(bContext * C, ListBase * handlers, wmEventHandler * handler_base, wmEvent * event, PointerRNA * properties) Zeile 2144 C blender.exe!wm_handlers_do_intern(bContext * C, wmEvent * event, ListBase * handlers) Zeile 2462 C blender.exe!wm_handlers_do(bContext * C, wmEvent * event, ListBase * handlers) Zeile 2720 C blender.exe!wm_event_do_handlers(bContext * C) Zeile 3141 C blender.exe!WM_main(bContext * C) Zeile 421 C blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Zeile 505 C
Looks like this was already fixed in adaa7688ee77
This was reproducible in a previous version from today, but the current master doesn't crash. GPU_texture_width was dereferencing a nullptr.
I can't reproduce with the current master. Your blender version seems to be an older build, does that happen with the current 2.8 build as well?
Apr 8 2019
@Sergey Sharybin (sergey) It seems to me that object_for_eval is set to the result of DEG_get_evaluated_object which has the modifiers applied, is used incorrectly in:
The functions rna_Object_to_mesh(), rna_Main_meshes_new_from_object() and BKE_mesh_new_from_object() all get apply_modifiers set to false as it should be. Could it be that this is an error introduced in 46eb5a0b8a4f3a7826b5e5a1a11e114e09037dba @Sergey Sharybin (sergey) ?
Looks like EXPORT_APPLY_MODIFIERS is set to False when the option is unchecked but to_mesh() or another function applies the modifiers regardless.
Can't reproduce with the current master as well as previous releases. What exactly happens or doesn't happen? Are you sure that the search pattern doesn't apply to all files in the directory?
Apr 5 2019
Patch is D4655. Haven't use arcanist before, will look into it for future patches.
Oh no. I just noticed, that I made a mistake in the reset of colindices. Sorry.
- Warning when vertex color is ignored because a color channel is there, but not all of the required R, G and B are present
Removed the print. Should there be a message if fewer color channels than RGB are present?
- Removed redundant check
- Less list comprehension
Sure, no problem. It'll be less DRY, but I guess that's ok.
Are sure about this? I haven't had time to test the glTF import, but the actual error from line 135 surely can't be fixed by editing code that happens after it. Also I don't see a nested loop in 149 where i would be shadowed. Can you submit a patch/diff? This is probably easier to discuss.
This is being worked on, see D4650.
Apr 4 2019
I think I found the bug. The current implementation requires an alpha channel for the vertex color otherwise it's ignored.
The code for handling vertex colors is there, but changes from the 2.79b version were introduced in 227fafdfcf4f. I'll have to take a closer look.
Looks like some code for the vertex color from the 2.79b release was changed in the port to 2.8. I'm not sure why, but there is a comment saying # XXX, colors dont come in right, needs further investigation. in the 2.79b version, so perhaps this feature didn't quite work as expected.
Apr 3 2019
After having a quick look it seems that mesh_circle_select() in view3d_select.c and all functions called by it, don't check if the coordinates are outside the viewport, which ultimately results in GPU_select_buffer_stride_realign() failing an assert.
I can confirm.
Apr 2 2019
- Proper indentation (now for real ;) )
Is the value clamping of minwidth of practical relevance, e.g. doing lots of collapses shrinks the node?
@Jacques Lucke (JacquesLucke) Sorry. For some reason the tab to space conversion was disabled in VS.
- Removed variable and used value directly in max_ff
- Proper indentation
This is the same behavior as in 2.79 (pressing escape had the same result). An actual undo reverts the extrude.
@Campbell Barton (campbellbarton) you have worked on this before, perhaps you can have a look?
@YAFU (YAFU) you're right in perspective mode this doesn't happen, but in ortho it does. So I correct my previous statement: I can reproduce this issue even when appending to a new project. However I haven't found a way to create an object the has this behavior using the current master build, I do get faces that miss the dot though. Perhaps there is something wrong with the drawing order?
This seems to be a problem with your particular blend-file, because if I append the mesh from your file to a new scene and enabled the face dot in the overlay it works just fine.
This is odd indeed. You shouldn't see the backside unless you have X-Ray enabled.
Could you post the blend file? This looks like overlapping bad geometry to me, which is hard to select because the faces coincide.
@Giorgi (Aganattu_Surodzai) given that you've posted two screenshots where you have selected the render tab and not the object tab, could the issue be that you're looking at the wrong tab?
Apr 1 2019
Is this the "Ray Visibility" you mean? When does it disappear, can you tell us the exact steps to reproduce?
I can increase the minimum width for the collapsed state, if you think that it's too short.
Mar 30 2019
The crash is caused by selbase being a nullptr in layer.c line 348. I'm not sure why it is though.
@Clément Foucault (fclem) has already been notified by others about the crashes. The problem is caused by commit dec9c7d87e5b
For reference this is commited with 4b6a4b5bc25b
- Resizing results in same size between open and collapsed node, except when the collapsed node needs to be wider due to the rounded caps
- miniwidth usage is removed
What is the expected behavior for resizing? I assume it should be possible to resize both in open and collapsed state and the size should remain consistent except for when the open state is too small for the circular arrangement in collapsed state. Then the node in collapsed state may be larger (the minimum width necessary to draw both circular sides without overlap).