- User Since
- Apr 13 2019, 3:18 PM (9 w, 5 d)
Sat, Jun 15
Wed, Jun 12
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.
Tue, Jun 11
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.
Wed, Jun 5
Sat, Jun 1
Fri, May 31
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.
Thu, May 30
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.