
Blender Git Statistics -> Git Master
Git Master Branch
Total commits : 104 340
Total committers : 496
Average commits per day : 15.5
Commits by Month
Date | Number of Commits | |
---|---|---|
March, 2021 | 236 | |
February, 2021 | 733 | |
January, 2021 | 825 | |
December, 2020 | 530 | |
November, 2020 | 755 | |
October, 2020 | 906 | |
September, 2020 | 863 | |
August, 2020 | 1009 | |
July, 2020 | 1002 | |
June, 2020 | 968 | |
May, 2020 | 1015 | |
April, 2020 | 855 | |
March, 2020 | 894 | |
February, 2020 | 736 | |
January, 2020 | 703 | |
December, 2019 | 350 | |
November, 2019 | 425 | |
October, 2019 | 614 | |
September, 2019 | 746 | |
August, 2019 | 732 | |
July, 2019 | 569 | |
June, 2019 | 639 | |
May, 2019 | 1138 | |
April, 2019 | 654 | |
March, 2019 | 1092 | |
February, 2019 | 788 | |
January, 2019 | 856 | |
December, 2018 | 808 | |
November, 2018 | 1172 | |
October, 2018 | 856 | |
September, 2018 | 955 | |
August, 2018 | 824 | |
July, 2018 | 820 | |
June, 2018 | 1254 | |
May, 2018 | 1388 | |
April, 2018 | 890 | |
March, 2018 | 505 | |
February, 2018 | 525 | |
January, 2018 | 562 | |
December, 2017 | 415 | |
November, 2017 | 571 | |
October, 2017 | 457 | |
September, 2017 | 414 | |
August, 2017 | 552 | |
July, 2017 | 539 | |
June, 2017 | 540 | |
May, 2017 | 707 | |
April, 2017 | 784 | |
March, 2017 | 645 | |
February, 2017 | 464 | |
January, 2017 | 259 | |
December, 2016 | 141 | |
November, 2016 | 306 | |
October, 2016 | 360 | |
September, 2016 | 346 | |
August, 2016 | 368 | |
July, 2016 | 459 | |
June, 2016 | 337 | |
May, 2016 | 449 | |
April, 2016 | 284 | |
March, 2016 | 332 | |
February, 2016 | 419 | |
January, 2016 | 448 | |
December, 2015 | 380 | |
November, 2015 | 372 | |
October, 2015 | 371 | |
September, 2015 | 303 | |
August, 2015 | 375 | |
July, 2015 | 506 | |
June, 2015 | 447 | |
May, 2015 | 533 | |
April, 2015 | 568 | |
March, 2015 | 455 | |
February, 2015 | 542 | |
January, 2015 | 642 | |
December, 2014 | 314 | |
November, 2014 | 338 | |
October, 2014 | 424 | |
September, 2014 | 335 | |
August, 2014 | 456 | |
July, 2014 | 372 | |
June, 2014 | 443 | |
May, 2014 | 523 | |
April, 2014 | 582 | |
March, 2014 | 508 | |
February, 2014 | 594 | |
January, 2014 | 609 | |
December, 2013 | 449 | |
November, 2013 | 460 | |
October, 2013 | 448 | |
September, 2013 | 481 | |
August, 2013 | 567 | |
July, 2013 | 586 | |
June, 2013 | 578 | |
May, 2013 | 618 | |
April, 2013 | 692 | |
March, 2013 | 682 | |
February, 2013 | 661 | |
January, 2013 | 715 | |
December, 2012 | 695 | |
November, 2012 | 784 | |
October, 2012 | 750 | |
September, 2012 | 604 | |
August, 2012 | 654 | |
July, 2012 | 699 | |
June, 2012 | 832 | |
May, 2012 | 934 | |
April, 2012 | 702 | |
March, 2012 | 695 | |
February, 2012 | 683 | |
January, 2012 | 632 | |
December, 2011 | 609 | |
November, 2011 | 817 | |
October, 2011 | 595 | |
September, 2011 | 806 | |
August, 2011 | 720 | |
July, 2011 | 665 | |
June, 2011 | 634 | |
May, 2011 | 499 | |
April, 2011 | 405 | |
March, 2011 | 593 | |
February, 2011 | 629 | |
January, 2011 | 540 | |
December, 2010 | 508 | |
November, 2010 | 523 | |
October, 2010 | 490 | |
September, 2010 | 472 | |
August, 2010 | 512 | |
July, 2010 | 656 | |
June, 2010 | 361 | |
May, 2010 | 376 | |
April, 2010 | 436 | |
March, 2010 | 497 | |
February, 2010 | 616 | |
January, 2010 | 794 | |
December, 2009 | 578 | |
November, 2009 | 781 | |
October, 2009 | 592 | |
September, 2009 | 568 | |
August, 2009 | 704 | |
July, 2009 | 660 | |
June, 2009 | 598 | |
May, 2009 | 459 | |
April, 2009 | 493 | |
March, 2009 | 301 | |
February, 2009 | 365 | |
January, 2009 | 535 | |
December, 2008 | 497 | |
November, 2008 | 302 | |
October, 2008 | 332 | |
September, 2008 | 476 | |
August, 2008 | 290 | |
July, 2008 | 332 | |
June, 2008 | 197 | |
May, 2008 | 346 | |
April, 2008 | 283 | |
March, 2008 | 350 | |
February, 2008 | 376 | |
January, 2008 | 391 | |
December, 2007 | 269 | |
November, 2007 | 230 | |
October, 2007 | 200 | |
September, 2007 | 201 | |
August, 2007 | 148 | |
July, 2007 | 133 | |
June, 2007 | 131 | |
May, 2007 | 175 | |
April, 2007 | 186 | |
March, 2007 | 252 | |
February, 2007 | 179 | |
January, 2007 | 413 | |
December, 2006 | 413 | |
November, 2006 | 413 | |
October, 2006 | 139 | |
September, 2006 | 130 | |
August, 2006 | 163 | |
July, 2006 | 251 | |
June, 2006 | 398 | |
May, 2006 | 220 | |
April, 2006 | 170 | |
March, 2006 | 208 | |
February, 2006 | 308 | |
January, 2006 | 339 | |
December, 2005 | 261 | |
November, 2005 | 298 | |
October, 2005 | 258 | |
September, 2005 | 171 | |
August, 2005 | 235 | |
July, 2005 | 327 | |
June, 2005 | 87 | |
May, 2005 | 188 | |
April, 2005 | 192 | |
March, 2005 | 258 | |
February, 2005 | 67 | |
January, 2005 | 99 | |
December, 2004 | 144 | |
November, 2004 | 184 | |
October, 2004 | 172 | |
September, 2004 | 130 | |
August, 2004 | 68 | |
July, 2004 | 217 | |
June, 2004 | 112 | |
May, 2004 | 151 | |
April, 2004 | 228 | |
March, 2004 | 94 | |
February, 2004 | 44 | |
January, 2004 | 255 | |
December, 2003 | 116 | |
November, 2003 | 154 | |
October, 2003 | 235 | |
September, 2003 | 37 | |
August, 2003 | 43 | |
July, 2003 | 163 | |
June, 2003 | 95 | |
May, 2003 | 182 | |
April, 2003 | 37 | |
March, 2003 | 57 | |
February, 2003 | 73 | |
January, 2003 | 123 | |
December, 2002 | 77 | |
November, 2002 | 77 | |
October, 2002 | 22 |
Committers
Latest commits
Revision cb0f159 by Joseph Eagar 2 hours 41 min ago |
Merge branch 'master' into temp_bmesh_multires Merge not finished, but need to commit to move to different computer; laptop being sent in for repairs |
Revision 7c1ebab by Michael Kowalski 2 hours 52 min ago |
USD Import: simplify xform matrix computation. Updated the USDXformReader matrix computation function to use the standard UsdGeomXformable API for querying the prim's local transform and to determine whether the matrix is time-varying, rather than explicitly iterating over the UsdGeomXformOps. |
Revision d25ab68 by Hans Goudey 3 hours 6 min ago |
Cleanup: Complete earlier geometry component refactor This was meant to be part of rB9ce950daabbf, but the change dropped from the set at some point in the process of updating and committing. Sorry for the noise. |
Revision 7be1708 by Michael Kowalski 3 hours 12 min ago |
USD Import: Formatting fixes. |
Revision 8df968d by Philipp Oeser 6 hours 0 min ago |
"Show Texture in texture tab" button: full support for Sculpt / Paint In {rBb279fef85d1a} the button that displays a texture in a Properties Editor texture tab was added for geometry nodes. Same commit will actually show them for Brush textures as well (but disabled -- because the Texture users dont match). This task is for finanlizing proper support for Brush textures as well. There was originally a separate patch for this (see {D9813}) but most of it was already implemented by above commit. **what this solves** from the default startup file: - go to any sculpt or paint mode and add a texture to your brush - observe the button to edit this texture in the Properties editor is greyed out {F9860470} There are two possible solutions: - [1] call the texture template for the brush `texture_slot` texture (instead of the brush 'texture') from the python UI code, this is then working in harmony how ButsTextureUser works for brushes - [2] tweak the way `ButsTextureUser` works (dont rely on `RNA_BrushTextureSlot` there) This patch implements the first solution. Since `brush.texture_slot` is `br->mtex` RNA wrapped and `brush.texture` is `br->mtex.tex` RNA wrapped, this really comes down to doing the same thing. I checked that creating a new texture and unlinking/deleting will have the same results even though they take slightly different code paths: assignment and NULLing the pointers are working on the same (see above) and RNA update callbacks also do the same [even though in different functions]: - brush.texture will do rna_Brush_main_tex_update - brush.texture_slot.texture will do rna_TextureSlotTexture_update / rna_TextureSlot_update (only difference here is an additional DEG relations update in the case of texture_slot which should not do harm) Differential Revision: https://developer.blender.org/D10626 |
Revision 2e19509 by Hans Goudey 6 hours 0 min ago |
Geometry Nodes: Rename subdivision nodes This makes the following changes to the name of the two geometry nodes subvision nodes: - `Subdivision Surface` -> `Subdivide Smooth` - `Subdivision Surface Simple` -> `Subdivide` Most of the benefit is that the names are shorter, but it also better mirrors the naming of operations in edit mode, and phrases the names more like actions. This was discussed with the geometry nodes team. |
6 hours 46 min ago |
Fix T86357: EEVEE: Shadows: Casters have exponential performance degradation with many objects When you have many distinct objects, in an Eevee render then the shadow caster gets exponentially slower as the number of (distinct) objects increase. This is because of the way that frontbuffer->bbox (EEVEE_BoundBox array) and the associated frontbuffer->update bitmap are resized. Currently the resizing is done by reserving space for SH_CASTER_ALLOC_CHUNK (32) objects at a time. When the number of objects is large, then the MEM_reallocN() gets progressively slower because it must memcpy the entire bbox/bitmap data to the new memory chunk. And there will be a lot of *memcpy* operations for a large scene. (Obviously there are a significant number of memory allocations/deallocations too - though this would be linear performance.) I've switched to doubling the frontbuffer->alloc_count (buffer capacity) instead of adding SH_CASTER_ALLOC_CHUNK (32). As I understand this is the only way to eliminate exponential slowdown. Just increasing the size of SH_CASTER_ALLOC_CHUNK would still result in exponential slowdown eventually. In other changes, the "+ 1" in this expression is not necessary. if (id + 1 >= frontbuffer->alloc_count) The buffer is 0-based. So when the buffer is initially allocated then id values from bbox[0] to bbox[31] are valid. Hence when frontbuffer->count == frontbuffer->alloc_count, is when the resizing should be triggered. As it stands the "+ 1" results in resizing the buffer, when there is still capacity for one more object in the buffer. I've changed the initial buffer allocation to use MEM_mallocN() instead of MEM_callocN(). The difference is that malloc() doesn't memset buffer (with zeros) when allocated. I've checked the code where new bbox records are created, and it does not rely on the buffer being initialised with zeros. Anyway, isn't calloc() safer than using malloc()? Well no, it's actually the opposite in this case. Every time the buffer size is increased, it is done using realloc(), and this does not zero-out the uniniitialised portion of the buffer. So the code would break if it was modified to assume that the buffer contains zeros. Hence I believe initialising the buffer using calloc() could be misleading to a new developer. Won't this result in increased memory usage? Yes, if you have millions of objects in your scene, then you are potentially using up-to twice the memory for the shadow caster. (However if you have millions of objects in your scene you're probably finding the Eevee render times a slow.) Note that once the render gets going the frontbuffer bbox/bitmap will be shrunk to a multiple of SH_CASTER_ALLOC_CHUNK (32), therefore releasing the overallocation of memory. As observed in Visual Studio - this appears to be prior to peak memory usage anyway. Note this shrinking is executed in EEVEE_shadows_update() - during the first render sample pass. If necessary you could consider shrinking the buffer immediately after the EEVEE_shadows_caster_register() has done it's work. (Note however it appears you would need to add that function call is multiple places.) Anyway as per the bug report I raised, I observed a 5% increase in peak-memory. And I'm unclear whether this difference in memory is due to me running the debug build. (It could be that there is no difference because of the shrinking.) I couldn't figure out how the shadow caster backbuffer works. I see that EEVEE_shadows_init() has an explicit command to swap the front/back buffers. However this is done only when the buffers are first initialised and there is nothing in there yet. In my testing, the backbuffer->count was always zero, EEVEE_shadows_update() never did anything with the backbuffer. Finally this problem is most evident when using Geometry Nodes or a Particle System to instantiate many objects. Objects created through say the array modifier do not cause any issues because it is considered one object by the shadow caster. Reviewed By: #eevee_viewport, fclem Differential Revision: https://developer.blender.org/D10631 |
Revision 84a4f2a by Hans Goudey 6 hours 53 min ago |
Geometry Nodes: Improve performance of point distribute node This commit refactors the point distribute node to skip realizing the instances created by the point instance node or the collection and object info nodes. Realizing instances is not necessary here because it copies all the mesh data and and interpolates all attributes from the instances when this operation does not need to modify the input geometry at all. In the tree leaves test file this patch improves the performance of the node by about 14%. That's not very much, the gain is likely larger for more complicated input instances with more attributes (especially attributes on different domains, where interpolation would be necessary to join all of the instances). Another possible performance improvement would be to parallelize the code in this node where possible. The point distribution code unfortunately gets quite a bit more complicated because it has to handle the complexity of having many inputs instead of just one. Note that this commit changes the randomness of the distribution in some cases, as if the seed input had changed. Differential Revision: https://developer.blender.org/D10596 |
Revision 4292bb0 by Julian Eisel 7 hours 0 min ago |
Outliner: Port scene elements and some related types to new tree-element code design Continuation of work in 2e221de4ceee, 249e4df110e0 and 3a907e742507. Adds new tree-element classes for the scene-ID, scene collections, scene objects, and the view layers base. There is some more temporary stuff in here, which can be removed once we're further along with the porting. Noted that in comments. |
Revision f0ad78e by Julian Eisel 7 hours 0 min ago |
Cleanup: Rename recently added Outliner files to exclude "_base" suffix These files can contain more than just the "base" tree element types. E.g. the class for the view-layer base element can also contain the class for the view-layer elements. Otherwise we'd end up with like >50 files for the individual types, most of them very small. So just give the files a general name and put the related classes in there. |
MiikaHweb - Blender Git Statistics v1.06