existing code was very stupid.
- all ID pointers for clipboard strips are handled uniformly.
- clipboard stores a duplicate ID pointer which are restored on paste.
- restoring pointers...
-- use ID's that are still in the database (copy&paste within the same file).
-- fallback to name lookup.
-- fallback to loading them from the original filepath (movie-clip and sound only).
also fix bug pasting where initialing the sound wasn't done if there was no frame-offset.
the way Curve.len is used at the moment is really stupid, calculate string size on save for now, but should really store the length in bytes and total number of characters.
custom pynodes tree edited directly as library data would get a 0 user count on reload and subsequently not be saved. Now the node space follows the same pattern as the image space: the node tree(s) user
count gets incremented on file load and opening in the editor ensures a real user. This leads to 1 "unreal" user for the editor (dropped on reload), but seems to be the only viable solution atm.
* [#35724] Backdrop zoom can be set to a very small value, making the backdrop disapear.
There were checks in the drawnode that needed to be placed in the readfile.
The checks checked if the zoomlevel was 0.0, then it was defaulted to 1.0, but the zoomvalue had a minimum limit of 0.01, hence it did not work.
Moved the check to the readfile and checked for all values smaller then 0.02. These values are then reset to 1.0
Jeroen & Monique
- At Mind -
Previously it was nearly impossible to have fast moving objects emitting smoke or they would just leave behind a row of smoke poofs instead of continious stream of smoke. Now it's possible to set number of subframes for each smoke flow.
Another new thing is ability to set size of smoke flow particles instead of using closest smoke cell. This also works with my earlier "full sample" commit, so no more blocky particles either. :)
For more info check my blog post: http://www.miikahweb.com/en/blog/2013/05/17/blender-smoke-subframes
This commit also includes couple of fixes I spotted while testing:
* Fix: dissolve was applied at different time for low res and high res simulations.
* Fix: full sample setting didn't get copied with domain.
This is hopefully the ultimate solution against smoke blockiness near emitter.
Previously high resolution flow/emitter voxels were generated based on the low resolution ones. So if you had 32 resolution and 4 division high resolution, it still used smoke flow generated from those 32 resolution voxels. Now I introduced a new sampling method called "Full Sample" that generates full resolution flow for for high resolution domain as well.
Read more about it in my blog post: https://www.miikahweb.com/en/blog/2013/05/10/getting-rid-of-smoke-blockiness
Also changed "quick smoke" operator default voxel data interpolation mode to "Cubic B-Spline" to smoothen out it even more.
Issue was caused by ntreeUpdateTree calling for a ntree
which is not in G.main.
This lead to issues in ntreeVerifyNodes (which is called
from ntreeUpdateTree).
Made is so ntreeUpdateTree now accepts main as an argument.
Will work for the release, later we could either solve the
TODO mentioned in ntreeUpdateTree which will eliminate need
in main there or make it so context's main is used from all
over where ntreeUpdateTree is called (currently there're
still some usages of G.main).
Also removed unneeded image buffer scaling, it was only needed
for "early output" if there was no rotation. That is no longer
supported since it used to pixelate result a lot and interpolation
is always used now.
Saves quite a few of memory and CPU cycles.
Initial fix was not fully working, because faulty
edge shared the same address as screen area. This
lead to screen freeing issues -- double free (which
was supressed by guarded allocation actually) but
also freed memory access when iterating via edges
to free them.
Solved by a small hack which removes edges with bad
vertices from edges list. This prevents double-free
and freed memory access cased by corrupted files we're
currently fixing. In other cases this tweak is likely
be harmless -- in worst case scenario it'll lead to
small memory leak, which is not as much lethal as
freed memory access.
Added provision for saved corrupt blend files - caused by a startup.blend
addressing > 16 GB space, which was read in 32 bits.
Now an invalid screen will get removed immediate after read. Might give
a memory-not-in-memlist print, but that's quite safe.
Added a mutex lock for smoke data access. The render was already working with a
copy of the volume data, so it's just a short lock to copy things and should not
block the UI much.
Issue was cause dby ima->ibufs being stored in a ma on
undo/redo and ima->rr not. In case of multilayer image
ibufs hares pointer with render result, so current
undo/redo policy lead to a dead pointer stored in ibuf.
Made it so ima->rr also stores in the map and restores
on redo/undo keeping all the pointers fine.
Because of our release soon, feature has been added behind the Debug Menu.
CTRL+ALT+D and set it to -1. Or commandline --debug-value -1.
When debug set to -1, you can put the viewport to 'render' mode, just like
for Cycles. Notes for testers: (and please no bugs in tracker for this :)
- It renders without AA, MBlur, Panorama, Sequence, Composite
- Only active render layer gets rendered. Select another layer will re-render.
- But yes: it works for FreeStyle renders!
- Also does great for local view.
- BI is not well suited for incremental renders on view changes. This only
works for non-raytrace scenes, or zoom in ortho or camera mode, or for
Material changes. In most cases a full re-render is being done.
- ESC works to stop the preview render.
- Borders render as well. (CTRL+B)
- Force a refresh with arrow key left/right. A lot of settings don't trigger
re-render yet.
Tech notes:
- FreeStyle is adding a lot of temp objects/meshes in the Main database. This
caused DepsGraph to trigger changes (and redraws). I've prepended the names
for these temp objects with char number 27 (ESC), and made these names be
ignored for tag update checking.
- Fixed some bugs that were noticable with such excessive re-renders, like
for opening file window, quit during renders.
code was modifying pointers in the Mesh which gave crashes with another thread
accessing the data at the same time. This could crash other threaded operations
like blender internal render or physics baking too but was less likely.
As a solution I've now changed the save code that it does not modify the mesh
data structure in place but rather a copy, as undo file saving should probably
be fully read-only regardless of how an improved threading architecture might
work.
Thanks to Sergey for tracking down the cause of this crash.
This option replaces previously added GPU limit
option, which became tricky to follow after GLSL
display space conversion.
There're 4 modes available:
- AUTO which will try to guess which mode is
best to use.
Currently It'll try using GLSL and if it fails,
will fallback to 2D textures.
Probably it'll make sense checking on whether
2D textures works well but currently such behavior
shall be sufficient.
Later we could make this method smarter (for example
don't try to use GLSL on certain GPU or so).
- GLSL will currently behave the same way as AUTO,
but it is intended to always try using GLSL
(unless it can not be used because of existing
limitation of dither and RGB curves).
- 2D Textures will use CPU-based color space conversion
and use OGL 2D Texture to display the image.
Image will be displayed in tiles, so there shall be
no big GPU memory consumption.
- DrawPixels will straightly fallback to glDrawPixels
without trying to use any fancy GPU stuff.
Hopefully this will also fix
#34943: Blender crashes when resizing the Compositing Screen Window
