Age | Commit message (Collapse) | Author |
|
|
|
A missing continue in this loop.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D10610
|
|
This adds an extra option to the Face Sets Init operator to initialize
individual Face Sets based on the current Face Sets boundaries.
In particular, this is useful for splitting the patterns created by
Expand into individual Face Sets for further editing.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D10608
|
|
Document the fact that `bpy.types.KeyMaps.new()` will not create a new
keymap but instead return an existing one, if one with the given
name/space/region already exists.
No functional changes.
|
|
No functional changes.
|
|
This failed when the component did exist, but did not contain any data.
|
|
|
|
|
|
This patch exposes the "Shade Smooth" value as a boolean attribute.
This setting is exposed as a check-box in the mesh data properties,
but the value is actually stored for every face, allowing some faces
to be shaded smooth with a simple per-face control.
One bonus, this allows at least a workaround to the lack of control
of whether meshes created by nodes are shaded smooth or not: just use
an attribute fill node.
Differential Revision: https://developer.blender.org/D10538
|
|
Auto frees cryptomatte session when it the pointer is collected from the
stack.
Reviewed By: Jacques Lucke
Differential Revision: https://developer.blender.org/D10667
|
|
Use member initializer list for constructor.
Use `this->` for member function.
Introduced in rBef53859d24a9720882e3ca6c5415faefec6fb82c
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D10653
|
|
`-Winconsistent-missing-override` and `modernize-use-override`.
Reviewed By: jbakker
Differential Revision: https://developer.blender.org/D10654
|
|
Missing NULL check in {rB2bae11d5c08a}.
Candidate for corrective release I guess.
Maniphest Tasks: T86417
Differential Revision: https://developer.blender.org/D10666
|
|
This function writes areas, not regions. The old name read as if it was
regions.
|
|
Prior to rB99a7c917eab7, Shift + D was used to set detail size for both
constant and relative detail (using radial control). The commit added an
improved operator for doing this for constant detail (showing the
triangle grid representation), but left the user without a shortcut to
do this for relative detail.
Interestingly rB99a7c917eab7 only changed this for the Blender keymap,
the Industy Compatible keymap still has the "old" entry.
This patch changes both keymaps to have both entries.
For user experience, the real change here is to have both available on
one 'primary' shortcut (Shift+D), the improved
'dyntopo_detail_size_edit' operator will now act on all possible cases.
If it deals with constant detail, it acts as before, if it deals with
relative detail etc, it will fallback to the "old" way of doing it via
radial control instead. I assume this adresses what was stated in
rB99a7c917eab7: "Deciding if both detail sizes can be unified needs a
separate discussion"
Also, move dyntopo_detail_size_edit to sculpt_detail.c
Fixes T83828
Maniphest Tasks: T83828
Differential Revision: https://developer.blender.org/D9871
|
|
Triggered by temporarily appending library linked data from Python.
|
|
The crash would only happen when the output of the Join Geometry node is used.
|
|
|
|
A few changes to make this consistent with other modifier panels:
- Title case for UI labels
- Use property split (and therefore decorators)
- Declare sublayout variables after getting modifier info
|
|
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.
|
|
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.
|
|
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
|
|
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
|
|
Splits up `tree_element_id.cc`/`tree_element_id.hh`.
If we move all ID types into this one file, it will become rather big. Smaller
files are probably easier to work with. We could still keep small classes like
`TreeElementIDLibrary` in the general file, don't mind really, but this creates
separate files for that too.
|
|
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.
|
|
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.
|
|
Currently the implementations specific to each geometry type are in
the same file. This makes it difficult to tell which code is generic
for all component types and which is specific to a certain type.
The two files, `attribute_access.cc`, and `geometry_set.cc` are
also getting quite long.
This commit splits up the implementation for every geometry component,
and adds an internal header file for the common parts of the attribute
access code. This was discussed with Jacques Lucke.
|
|
This was due to the AO random sampling using the same "seed" as
the AA jitter. Decorelating the noise fixes the issue.
|
|
The actual sample count is rounded up to a multiple of 4 because we
sample 4 horizons directions.
Changing this setting forces the shader to recompile (because using a
GPU_constant).
|
|
This just bypass the occlusion computation if there is no occlusion
data. This avoids weird looking occlusion due to the screen space
geometric normal reconstruction.
|
|
The sampling is now optimum with every samples being at least one pixel
appart. Also use a squared repartition to improve the sampling near the
center.
This also removes the thickness heuristic since it seems to remove
a lot of details and bias the AO too much.
|
|
This is useful for debugging raycasting.
|
|
This is a major rewrite that improves the screen space raytracing
a little bit.
This also decouple ray preparation from raytracing to be reuse in other
part of the code.
This changes a few things:
- Reflections have lower grazing angle failure
- Reflections have less self intersection issues
- Contact shadows are now fully opaque (faster)
Unrelated but some self intersection / incorrect bad rays are caused by
the ray reconstruction technique used by the SSR. This is not fixed by
this commit but I added a TODO.
|
|
This removes the need for per mipmap scalling factor and trilinear interpolation
issues. We pad the texture so that all mipmaps have pixels in the next mip.
This simplifies the downsampling shader too.
This also change the SSR radiance buffer as well in the same fashion.
|
|
Fix ID preview not updating in Asset Browser, by actually sending an
explicit `NA_EDITED` along with the `NC_ASSET` notifier.
|
|
This was reported as opening alembic caches ignoring the
'use_relative_paths' preference, but this operator just did not have
this setting. Fortunately, adding this is just a simple switch.
Maniphest Tasks: T86063
Differential Revision: https://developer.blender.org/D10568
|
|
|
|
This adds the initial boilerplate code that is required to introduce
the new spreadsheet editor. The editor is still hidden from the ui.
It can be made visible by undoing the change in `rna_screen.c`.
This patch does not contain any business logic for the spreadsheet editor.
Differential Revision: https://developer.blender.org/D10645
Ref T86279.
|
|
Pass `FILE_OPENFILE` instead of `FILE_SAVE` when selecting a file for
reading.
|
|
Add operator `FILE_OT_view_selected` to the file browser (and thus also
to the asset browser) that scrolls selected files into view.
This includes the active file, even though it is not selected. In
certain cases the active file can loose its selected state (clicking
next to it, or refreshing the asset browser), but then it's still shown
in the right-hand sidebar. Because of this, I found it important to take
it into account when scrolling.
This also includes a change to the keymaps:
- Blender default: {key NUMPAD_PERIOD} is removed from the "reload"
operator, and assigned to the new "view selected files" operator. The
reload operator was already doubly bound, and now {key R} is the only
remaining hotkey for it.
- Industry compatible: {key F} is assigned to the new "view selected
files" operator. This is consistent with the other "view selected"
operators in other editors.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D10583
|
|
The Tool stores desired dimensions as `scale` and thus had to half the
scale again in `make_prim_init()` because by default all primitives are
created at a size of 2 in blender.
This worked, but:
- [1] it logged something like size=2, scale=2,2,2 for a 2x2x2 cube
[which does not sound right, it should be size=2 scale=1,1,1]
- [2] it had to make an exception for the case scale is exactly 1x1x1
[this happens when the property is not set specifically, e.g. adding
primitives from the menu]
-- this exception led to double sized primitives being created when the
tool asked for exact dimensions of 1x1x1
Now - instead of compensating in `make_prim_init()` - do this earlier in
the tool itself, see `view3d_interactive_add_modal`, this fixes the bug
and now also correctly logs size=2 scale 0.5,0.5,0.5 for a 1x1x1 cube.
Maniphest Tasks: T86347
Differential Revision: https://developer.blender.org/D10632
|
|
projectors
Make this clear in property UI descriptions and deactivate aspect &
scale fields if no camera projectors are present.
ref T86268
Maniphest Tasks: T86268
Differential Revision: https://developer.blender.org/D10634
|
|
This adds support for creating a `BlendFile` (internally called `Main`),
which is limited to a context.
Temporary data can now be created which can then use
`.libraries.load()` the same as with `bpy.data`.
To prevent errors caused by mixing the temporary ID's with data in
`bpy.data` they are tagged as temporary so they can't be assigned
to properties, however they can be passed as arguments to functions.
Reviewed By: mont29, sybren
Ref D10612
|
|
This allows adding ID tags when linking/loading data.
This is needed to implement loading non 'G.main' ID data-blocks,
see D10612.
|
|
Regression in b5d154f400e46ba322f0e08a231bb2557bf51a1e
|
|
crash
The handle of a drawing callback can be removed within the drawing function itself.
This causes `var = (type)(((Link *)(var))->next` to read an invalid memory value in C.
|
|
It looks like we never generated correct icon previews for images with
float_rects (non-8bit-images). Images from the report were 16bit pngs.
In this case, `icon_preview_startjob` would return early (it only
checked if the ImBuf `rect` was NULL -- which is the case if it has a
`rect_float` instead). This is not neccessary since `icon_copy_rect` is
perfectly capable of taking float rects.
Now correct the check and only return early if both `rect` & `rect_float`
are NULL.
note: this will not refresh icon previews from existing files
automatically. For this, use File > Data Previews > Clear Data-Block
Previews.
Maniphest Tasks: T86210
Differential Revision: https://developer.blender.org/D10601
|
|
Caused by {rB85421c4fab02}.
Above commit treated `SOCK_RGBA` and `SOCK_STRING` the same in
`std_node_socket_draw`.
That would turn a RGBA button into a text button (for attribute search),
leading to trouble.
Note these were just treated the same prior to above commit because both
were doing the layout split.
Now just give RGBA sockets their own case.
Maniphest Tasks: T86373
Differential Revision: https://developer.blender.org/D10646
|
|
|
|
This reverts commit 7a34bd7c2886dfc812345c0b1649d63a9ee4666f.
Broke windows build. Can apparently fix with /Zc:preprocessor flag
for windows but need a Windows dev to make that fix.
|