| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Makes use_shadow usage consistent across supported lamp types (Spot and
Sun)
Differential D1148
Reviewers: Moguri, Brecht
|
|
|
|
The purpose of this change is to add extra possibility to render engines and
export scripts to reduce peak memory footprint during their operation.
This new argument should be used with care since it'll leave mesh in not really
compatible with blender format, but it's ok to be used on temp meshes.
Unfortunately, it's hard to get scene where it'll show huge benefit because
in my tests with cycles peak memory is reached in MEM_printmemlist_stats().
However, in the file with sintel dragon it gives around 1gig of memory benefit
after removing the polys which would allow other heavy to compute stuff such as
hair (or even pointiness calculation) to not be a peak memory usage.
In any case, this change is nice to have IMO, and only means more parts of
scene export code should be optimized memory-wise.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1125
|
|
Issue this commit is addressed to is that particle system and particle modifier
will contain caches once derived mesh was requested and this cached data will
never be freed.
This could easily lead to unwanted memory peaks during synchronization stage
of rendering.
The idea is to have RNA function in object which would free caches which can't
be freed otherwise. This function is not intended to deal with derived final
since it might be used by other objects (for example by object with boolean
modifier).
This cache freeing is only happening in the background rendering and locked
interface rendering.
From quick tests with victor file this change reduces peak memory usage by
command line rendering by around 6% (1780MB vs. 1883MB). For rendering from
the interface it's about 12% (1763MB vs. 1998MB).
Reviewers: campbellbarton, lukastoenne
Differential Revision: https://developer.blender.org/D1121
|
|
Currently, for animated textures we were allowing 16x16 tiles but we can reproduce 128 frames only.
Reviewers: moguri, sergey, campbellbarton
Reviewed By: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1164
|
|
|
|
Patch T36049 by @jeske
|
|
This patch makes it possible for the user to select all supported compression types in OpenEXR 2.2
Discussion points:
- B44 is only defined for half's it compresses to a fixed representation of 44% of the halfs. We do currently not reflect in the UI that in the case of float32's it will be equal to compression = NONE
- ZIPS is single scanline zip and is supposed to be useful in cases where importing in Nuke happens.
- The new Dreamworks formats, are the worth exposing etc etc
Reviewers: campbellbarton, sergey
Reviewed By: sergey
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1050
|
|
|
|
Reviewers: sergey
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D1167
|
|
|
|
cleanup_cddata -> clean_customdata
|
|
|
|
|
|
This method does not work for hair anyway. Even though hair collision
needs work at this point, it's still better than nothing.
|
|
(Note for the uninitiated looking at the diffs: this is very much *not* what
you're probably thinking right now, if you're looking at the line in
act_new_exec())
|
|
and relabeling some parts
|
|
Makes the drop-down push searchbox out of the view (which is already quite cramped)
change to "Orphan Data".
|
|
|
|
- spiral scheme is much more intuitive here. Also use float number for
spirals to avoid having samples on the same radial direction when sample
number is divisible by spiral number.
|
|
OpenGL is detected:
Hoping to decrease the frequency of by far one of the most frequent bug
reports by windows users.
There is some reorganization of the GHOST API to allow easy addition of
further OpenGL options in the future. The change is not propagated too
deep to keep the size of the patch managable. We might reorganize things
here later.
For OpenGL we do two checks here:
One is a combination of GDI generic renderer or vendor microsoft
corporation and OpenGL version 1.1. This means the system does not
use GPU acceleration at all. We warn user to install a graphics
driver and of cases where this might happen (remote connection, using
blender through virtual machine)
The other one just checks if OpenGL version is less than 1.4 (we can
easily change that in the future of course) and warns that it is
deprecated.
Both cases will still let blender startup correctly but users should now
have a clear idea of the system being unsupported.
A user preference flag is provided to turn the warning off.
Now stop posting those bug reports without installing a driver first -
please?
|
|
Was returning NULL, auto-completing:
bpy.types.Material.bl_rna.properties["type"].
Would crash, accessing 'default_flag', thanks to @lukastoenne for investigating.
|
|
|
|
|
|
|
|
There are more flags that trigger this assertion, so I want to discuss
an appropriate way to fix it before changing them all.
This reverts commit b1191e5caf1a888bfad2185ed41db2e91fbf46e2.
|
|
rna_RenderSettings_use_game_engine_get() in rna_scene.c would return 0 or 2,
whereas the assertion in rna_access.c:1843 indicates that boolean values
should only be 0 or 1.
|
|
|
|
controllers
|
|
input, instead make sure the end-start values are sane instead
|
|
D1100,D1105,D1106 by @lichtwerk
|
|
New Lock Z velocity parameter was added. This parameter avoid the micro-jumping.
By default it is actived except when you load an old file that it is deactived to keep former behaviour.
Additionally it was solved another issue related with the acceleration: That is the acceleration value was not taked into account and we had always the maximum linear velocity from the beginning of movement. Now the acceleration is taken into account until we reach the maximum velocity.
When you load an old file, the acceleration value is set to the maximum range (1000.f). This way we simulate a maximum velocity constant from the beginning of movement (former behaviour).
{F142195}
Reviewers: moguri, dfelinto, campbellbarton
Reviewed By: campbellbarton
Subscribers: sergey
Differential Revision: https://developer.blender.org/D1074
|
|
Prepare for using 'bool' type.
|
|
|
|
|
|
= Hide 3D Cursor in Paint Modes (with exceptions)
In paint modes, the 3D Cursor mostly is rather useless so it's more annoying than useful. This patch aims to hide the cursor in cases it's not used.
Included exceptions (cases where cursor is drawn in paint modes):
* Active object is in weight paint mode and a selected bone in pose mode can be found
* Clone brush (only if //Clone from paint slot// is disabled)
There might be more exceptions where the cursor should be shown in paint modes, but those are all I could find for now. Feel free to hint me for more.
Note: After D1110 was rejected, Campbell and me discussed this a bit more on IRC and agreed that this behaviour might be a good solution.
Reviewers: psy-fi, campbellbarton
Reviewed By: psy-fi, campbellbarton
Projects: #user_interface
Differential Revision: https://developer.blender.org/D1113
|
|
|
|
|
|
BLI_is_dir() in draw loop!)
Did not had any issue on linux, but looks like on some windows can slow things as Hell.
Or maybe just the presence of some network FS?
Anyway, not a good idea, so now fsmenu entries' valid status is stored and only evaluated
on startup (reading of bookmarks & co) and when opening file browser (refresh, like
for system bookmarks).
|
|
Support for user-defined customdata layers (named int, float, string
layers) was limited to polygon customdata. This is not accessible in
cycles because only tessfaces are used there. Furthermore the polygon
attributes were simply described as MeshFloatProperty, MeshIntProperty,
MeshStringProperty, omitting the distinction by element type.
The patch only adds vertex attributes so far. However, the code now
explicitly defines polygon and vertex attributes, so adding edges, loops
and tessfaces is much easier should the need arise.
Problem is that the RNA definition, which is already much more
complicated than the basic DNA/BKE definition of custom properties, now
becomes extremely bloated and cumbersome. A simpler solution would be
preferable but may not be possible within the constraints of RNA.
|
|
Orphaned datablocks are those which have either:
* 0 users
* A "fake" user only
In the case of the former, they will be quietly discarded from the file on the next
save + reload. Hence, it is helpful to have a view where you can confirm which ones
fall into this category and might be worth saving.
We also include datablocks with a fake user only so that datablocks given a user
above can have that easily turned off again (in case the user makes a mistake).
Another benefit of showing these is that it become easier to remove fake users from
datablocks you no longer want retained without having to hunt for them.
|
|
Turned out that I misinterpreted the feature request, plus there are some
minor issues with the commit that would need to be corrected.
After all, I decided to just remove it again as it seems to not be really
useful for the users.
|
|
This reverts the change made in 8872cba7e956a9d9a840e55e5323945497524795
which was contributing to actions being lost in some cases [1], even when
they were assigned to those actuaters, which needed them to be able to
function. Now there's one less case where users are needed but were missing :)
Note that this still doesn't solve the core issue where nothing is responsible
for associating actions created for a particular datablock (and not currently
being used in its active action slot, or in the NLA stack) with that datablock.
That issue is the cause of most action disappearances as well as for other problems
(such as renaming bones being unable to fix unreferenced/unused actions) where there
are diifferences between users' mental models and the data model. Proper fixes are
coming soon (restoring fake users here isn't a proper fix, as it only masks the
fundamental mismatch/problem here).
[1] http://blenderartists.org/forum/showthread.php?357021-BGE-loses-actions
|
|
This reverts commit e652f781a33b3b31fa95b543bf4003ff7b0c57d6.
@schlaile, mentioned in T43646 that this was an intended feature. Checked git
history and it's seems like he's right.
|
|
|
|
Maybe just another typo (tm). (Checked with @psy-fi)
|
|
|
|
|
