- User Since
- Apr 13 2019, 3:18 PM (26 w, 4 d)
Tue, Oct 15
I don't the fully know blender internals, but wouldn't an index -1 correspond to not found? Shouldn't this be handled, and just abort snapping?
From my experience with BVH trees and Octree, precision does indeed make a lot of difference.
Great. Let me know if you need anything.
Forgot to say that this was in master at this commit 3cdcd1fa9f0896632b05cc217649ac529f8e2e08 of 15 Oct 2019, 09:27 UTC
So the edits I did, were, turn wireframe overlay on.
Video showing the crash ;).
Sorry, but finally got the crash again. This was after leaving edit mode. Focus select, enter edit mode, select vertice, focus zoom, and 'g' to start moving. Attaching screenshot with the vertex that cause the crash and the file (its the same but with more edits).
Crash was again in line 2120 of math_geom.c in the isect_ray_seg_v3.
Tue, Oct 8
Sorry to make lose time, but definitely is some addon, just can't figure which one, even when disabling all, the behaviour persists. But I will keep investigating, please close this bug report.
Sorry for the delay, I'm rebuilding again before your commit, and will test with defaults. The only addon that I have for the nodes is the node wrangler.
Thu, Oct 3
Fig 1. Missing "grass" material
Just another example on the latest nVidia driver (GeForce RTX 2080 SUPER, 4.5.0 NVIDIA 436.48)
Ok, thanks ;).
Wrong sha for the compiled master, its aabd8701e98595bae57d59344ed5d127b8b0f7db.
Running master 93e8c962fcc1f9979d4dbb539d5ff4e1f5295068.
So far no crashes (3h session), I do have an issue with objects with multiple materials, where some of them don't show in Material and Texture shading mode. They do appear in Object shading mode. I can restore the visualization of the materials if I allow blender to compile with USE_MULTI_DRAW_INDIRECT 1, but node links disappear sometimes (as reported on other ticket related to this)
Mon, Sep 30
It was the standard fbx importer.
Ran the script and got more mesh errors, on other objects.
I believe the problem is with imported non-manifold meshes. Probably who handled the sketchup conversion in 3dsmax, just use "Convert To Poly" on every mesh, and this makes really bad non-manifold meshes that can cause crashes in 3dsMax (in certain conditions). I exported with "Triangulate" turn on, but in most cases, this isn't enough.
I also agreed that this isn't a "bug" since it's caused by bad geometry, but maybe it could be handled in a way to not crash blender :).
Sun, Sep 29
A better workaround was added.
Added missing TODO comment just in case.
Great @Brecht Van Lommel (brecht). I added that and the missing include making it work, at least on my tests. This should at least avoid a lot of tickets on your side while you guys try to find a permanent fix.
Sat, Sep 28
Thu, Sep 26
Wed, Sep 25
Wed, Sep 18
Sep 13 2019
Confirm that the commit 'rFD5C1972CD5' seems to solve this.
Fixed on version: 2.81 (sub 11), branch: master, commit date: 2019-09-13 21:07, hash: rB1cdfc1d199c3.
Probably with the revert of the draw call batching 'fd5c1972cd5'.
Sep 10 2019
Sep 5 2019
Sep 3 2019
Aug 27 2019
Commit d547f9d3d291 breaks builds, it's missing the BLi_system.h header on source/blender/editors/space_node/drawnode.c.
Aug 26 2019
Aug 25 2019
Aug 9 2019
Aug 3 2019
Jul 29 2019
Jun 15 2019
Jun 12 2019
Dan, can you review your fix (F1442978), so it uses the 0.1 tolerance? It should be that one that gets committed ;).
Results with the F1442978 applied. (all good at 0.1, 0.01 still gives artefacts)
Looking into F1442978, that should be the one accepted, since it solves all the proposed problems with a simple enough fix.
I do believe that the pseudo-inverse, since is only used in this case, could use statically sized matrix. I already implement this algorithm in Rust, and hand converted the original paper code. Maybe reducing the use of Eigen library with handwritten versions could improve compiler performance (no template instancing), and probably to some extent the overall function speed. But I think for now that is a bit out of scope, to fix this trivial error. I will change this to 0.1 and make the function static typed.
Lower the epsilon to 0.0001 with no visible side effects on tests done.
Jun 11 2019
Default Torus, SubMod: 3, Remesh: Depth: 9 (0.01f epsilon) - Good
I will do some tests. I upped the remesh voxel up to 9 with and no problems with 0.01 on a default torus with subd mod of 4.
This should give the same result as the F1442978, since the template function will expand at compile time to the Matrix3f version, which is the what is proposed in the diff, there should be no difference in speed between the 2.
Jun 5 2019
Jun 1 2019
May 31 2019
And another video, showing when you go over the "icons" of the outliner. In the previous video, the cursor wasn't captured, due to my HDPI display. I capture this one on the HD screen so it now shows the cursor.
Just to confirm this is not only on Windows, but it also happens on my Linux Laptop.
May 30 2019
May 14 2019
It a bit weird, now it happened when zooming out on the layout workspace with Solid Texture mode. Spend an hour doing decimate on highpoly to low poly people, switching from Wire to Solid Texture, and done tons of zoom in/out. When I was about to call it a day, and zooming out to see the an overview, puff :D.
No work lost thanks to great the autoback ;).
Call stack for the latest commit (3db4284 - Fix T64601 Error division by zero in GPUVertexFormat) :
Here you go, this was a build with the latest commit (c66a782 - Interface: Free argument callback for popups):
blender.exe!padding(unsigned int offset, unsigned int alignment) Line 221 (d:\dev\blender\blender\source\blender\gpu\intern\gpu_vertex_format.c:221) blender.exe!VertexFormat_pack(GPUVertFormat * format) Line 259 (d:\dev\blender\blender\source\blender\gpu\intern\gpu_vertex_format.c:259) blender.exe!GPU_vertbuf_create_with_format_ex(const GPUVertFormat * format, GPUUsageType usage) Line 68 (d:\dev\blender\blender\source\blender\gpu\intern\gpu_vertex_buffer.c:68) blender.exe!gpu_batch_sphere(int lat_res, int lon_res) Line 129 (d:\dev\blender\blender\source\blender\gpu\intern\gpu_batch_presets.c:129) blender.exe!gpu_batch_presets_init() Line 202 (d:\dev\blender\blender\source\blender\gpu\intern\gpu_batch_presets.c:202) blender.exe!GPU_init() Line 62 (d:\dev\blender\blender\source\blender\gpu\intern\gpu_init_exit.c:62) blender.exe!wm_window_ghostwindow_add(wmWindowManager * wm, const unsigned char * title, wmWindow * win) Line 739 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_window.c:739) blender.exe!wm_window_ghostwindows_ensure(wmWindowManager * wm) Line 861 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_window.c:861) blender.exe!WM_check(bContext * C) Line 290 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm.c:290) blender.exe!wm_homefile_read(bContext * C, ReportList * reports, bool use_factory_settings, bool use_empty_data, bool use_data, bool use_userdef, const unsigned char * filepath_startup_override, const unsigned char * app_template_override, bool * r_is_factory_startup) Line 1038 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_files.c:1038) blender.exe!WM_init(bContext * C, int argc, const unsigned char * * argv) Line 272 (d:\dev\blender\blender\source\blender\windowmanager\intern\wm_init_exit.c:272) blender.exe!main(int argc, const unsigned char * * UNUSED_argv_c) Line 427 (d:\dev\blender\blender\source\creator\creator.c:427) [Inline Frame] blender.exe!invoke_main() Line 78 (d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78) blender.exe!__scrt_common_main_seh() Line 288 (d:\agent\_work\4\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288) kernel32.dll!00007ff8358d7974() (Unknown Source:0) ntdll.dll!00007ff836caa271() (Unknown Source:0)
I believe this has to do with some changes on the way the GPU attributes are read or stored. The call stack ends up on file: gpu_format_format.c, function *uint padding* called by *VertexFormat_pack*.
If you guys guide me a little, since I don't know the blender code (I used to create plugins for 3dsmax, houdini and maya in the past), maybe I can help track the problem. @Clément Foucault (fclem) Where should I look for the garbage collection, I quite savvy on C/C++, have about 20 years of developer experience in all kinds of languages including C/C++.
And diving a little further, the MEM_lockfree_callocN makes no assumption on the request memory block asked, so if we ask a 0 block it will create one because it always has some memory used by MemHead. But I don't see a problem with this, and of course maybe its by design.
I was looking into the code where surf_per_mat_tris is inited, and there may be a corner case that could cause this, I have some objects without materials and the allocation takes in account the material count, well if the material count is zero, the new array pointer will be effectively zero in length.
This happens on draw_cache_impl_mesh.c line 2105.
Just for the record the fix is just this:
And it still crashed. Left blender rendering a Diffuse bake map, and went to take care of my garden. Come back and it crashed in the same line. Going to put back the null check again.
State of blender at crash.
Unfortunately, I can't share the file. This happens after working for a while. I was doing complex baking of some meshes, in the Shading workspace. This happened twice until I added the null pointer check, one of the time was while leaving the Local View (/ Numpad), the other was whne moving from the Shading to the Layout workspace. I will make a build without my patch to see if I get any crash during the day.
May 13 2019
I think it may be related to this bug: https://developer.blender.org/T64551
As a workaround I added a null check to my local build just to avoid this, mostly because I don't know where the cache is populated, still "learning" my way around the blender source code.
May 11 2019
I would avoid the revert also. Makes much more sense to have an option to auto-save preferences, that should be off by default. It would probably be much easier to just save the ´Quick Favorites` in some other file, just a list of operators, than duplicating a lot of the internal structures just to accommodate an Undo for the preferences.
To save some time, maybe this could help you guys:
diff --git a/release/scripts/startup/bl_ui/space_view3d.py b/release/scripts/startup/bl_ui/space_view3d.py index f05cdc8f5f8..8c803973fe1 100644 --- a/release/scripts/startup/bl_ui/space_view3d.py +++ b/release/scripts/startup/bl_ui/space_view3d.py @@ -4847,7 +4847,7 @@ class VIEW3D_PT_collections(Panel): if child.exclude: continue
Setting line 987 of fbx_utils.by to
May 8 2019
Not much confusion and I come from 3dsmax. Active Collection acts like the "active" layer, where all new stuff is added, like adding a new object, duplicates, and probably some more stuff.
The highlighted collection () in the outliner is the active collection.
May 6 2019
The bug was introduced in this commit: https://developer.blender.org/rBc5fe16e121eefe5dd02cc9f9ba572053c383ccfa
May 5 2019
I was able to "fix" with this patch. It's hacky, and there may some other problem lurking somewhere else, but at least this avoids crashing.
Hi, you can recover the scene, by using append and selecting the scene datablock. I also reported the same bug ;).
Using the provided scene in https://developer.blender.org/T64181 causes the same assertion, with the same stack trace.
Just some extra info, running a debug build an assert is triggered that confirms that the scene is in some invalid state.
Trigger at line 3096 on "source\blender\windowmanager\intern\wm_event_system.c" during DEG_get_evaluated_scene. It's possible to recover the scene with a simple Append of the scene datablock in a new scene.
If I get this to reproduce on a simple scene, I will post it here.