with scene audio recursion in mattieu's gooseberry edit in sequencer.
Will probably cause something else to explode but let's just guard
against this in the audio lib for now.
The issue was caused by memory optimization marking particle system to recalc,
and because of the way how particle flags works it was possible that it'll
cause particle's re-distribution. Now this memory optimization will act the
same as loading the file.
Would need to review if this fix is to go to master/cycles_memory branches
but for now it'll be cool to figure out what to do with the farm.
Now file open operator also sets a temporary flag for collapse. This
allows the user to configure the option to always collapse files and the
editor will remember the setting and not reset it back after finishing a
collapsed file open.
This way we store quite reasonable amount of memory (density is stored as RGBA
textures, which ends up in gigabytes of RAM for hires smoke sims).
It's not really pretty implementation and we'll really need to support textures
with 1 and 3 channels instead of doing such packing, but we need to be able to
render some files here.
This happens if all object's smokes are backed to files and rendering is either
happening from command line of with locked interface.
The idea behind this change is to make as much memory available for path tracing
as possible, so after heavy swapping during synchronization period there's loads
of free memory to put important data back to RAM.
Notes:
* This is own coocking, since it seems hard to find papers on simplifying already existing bezier curves,
and we do not really need the 'generic' least-square fitting of bezier in a set of points, here.
* It takes advantage of specificities of FCurves (e.g. only difference that matters here is Y value at same X frame,
no vertical overlapping, etc.).
* It gives reasonably good results, but could most likely be enhanced quite a bit still.
* Only 'hooked' to bake action operator right now (needs more work to add it to graph editor too).
* Ultimately should probably be redone in C. Would keep it in Python until we have a real good
cleanup behavior though, much easier to experiment in later language.
Revert "Nodes: Remove hardcoded BLENDER_MAX_THREADS number of threads"
This reverts commit fdc653e8ce.
The threads override is not affected by the scene, and hence the limit of the
threads was not giving correct result. Need to re-consider some things here.
The addons tab in the User Settings window would be empty, due to
a FileNotFound error. This error can be caused by a broken symlink,
which is now treated the same was as a file that misses its bl_info
dictionary.
Issue was caused by passing NULL bmain to the path remap function when
localizing the node tree.
Paths are to be remapped, otherwise mapping of paths to OSL scripts
might happen in a wrong way.
Round-up was only enabled for viewport render, which was for a long time hardcoded to
use 64 closures. This was done in order to avoid unnecessary kernel re-compilations
when tweaking the shader tree.
We could enable selective closure compilation in the viewport later if it'll give
measurable speed improvements, but even then round-up is to happen outside of the
device level,
This commit also removes early output which happened in cases when max closure did
not change. It was wrong because other requested kernel features might have been
changed.
This features are now based on the scene settings, so scenes without those features
used are rendered even faster.
This gives about 30% speedup on the AMD A10 APU here, but at the same time it does
not mean such an improvement will happen on all the hardware. That being said, the
Tonga device here seems to have no measurable difference.
In any case it seems handy to have for the future, when we'll want to support SSS
in the kernel or to port selective compilation/split kernel to CUDA devices.
The view would jump each time, now compensate by adjusting the cursor panning.
Less jarring and helps avoid problems when the cursor gets outside the view, see: T40353
Made the test for whether one can "see" an adjacent edge less
knife-close to 180. This means it will chose to slide along
such an edge less often, and avoid some spikes.
As material is not NULL at this stage there is no need to do a NULL
check. Also to remove dead code
Reviewers: dfelinto, panzergame, hg1, moguri
Reviewed By: panzergame, hg1, moguri
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1330
Add slider to adjust the influence of weights relative to geometry distortion.
This allows subtle influences to be applied - without drastic changes in behavior.
Reported by pixaal on irc, basically reproducable by inserting bevel
modifier on cube and entering/exiting texture paint mode.
Now object stores last needsMapping variable as well as customdata mask.
Also now texture painting only needs mapping when we are in texture
paint selection mode, so modifiers that don't support mapping can still
be used to paint now.
Already committed similar fix (rBbeaed66f292dd) but saw it appearing on
other peoples screens a few times since them. Never was able to recreate
though.
This should make sure everything is initialized fine, so if we see it
appearing again, then it's likely because of manual tweaks or the
version saved in the .blend.
Very dirty feature that will have to be reimplemented when the new asset engine makes it into blender.
This commit tweaks the filebrowser to detect sequences of images that form parts of a movie. The
files need to be in the format <number>filelame.ext or <number>.filename.ext
There is a new option next to hidden file option that makes it so this collapsing takes place.
When collapsing is on, any movie files that have the same filename will be collapsed to the first
detected file in the sequence. Selecting that file will select all files in the sequence.
There is a shortcut in the sequence editor in the Add menu, "Image Sequence" that enables collapsing
by default. Unfortunately, selecting multiple movies will not add multiple sequences to the sequencer,
at least for now, but it should make it quite easier for people to quickly select the whole range of
images for a movie. Importing the image sequence into the sequencer will use placeholders, so any missing images
will display as black.
Using ints and floats would require prefixing the Alembic metadata
keys, which becomes messy and ambiguous. Encoding other data types as
strings can be done on the python side as well.
Also, changed the algorithm for generating the vertex meshes when not all
edges into a vertex are beveled. Now it tries to slide along edges that
form part of the silhouette when possible; when not possible, it tries
to snap to the best plane in between the beveled edges.
Also improved a bit behavior of adding new nodes, now they will not overlap that
badly. Still not ideal, but further improvements better not to happen at bcon4.
- label is shown on a UI_UNIT_Y heigh instead of 0.2 * total button size
- vertically centering non-ID previews labels
- making some constants dependent on ui units
- elongate the buttons to acomodate the icon without the label overlapping.
- removing the blue background
- adding a consistent margin all around the popup
The issue was caused by the reshuffle needed to make objects flags have proper
object's bounding box to solve regressions in SSS objects intersecting volumes.
There's actually a feedback loop happening here, which is now solved in quite
naive way -- for the true displacement we consider all objects are capable of
intersecting volumes, synchronize object flags prior to displacement shader
tasks runs and then re-update object flags for proper bounding box.
Not sure what will be the proper solution here, we can't do preliminary check
of intersection for displacement shader, but on the other hand we don't really
need this flag for displacement shader anyway.
We have to regenerate previews when we change language. But we also need to do it
when translation is changed or added for a language, etc.
Previously, we were storing one preview per language, which was also stuffing
preview dir with (potentially) tens of PNGs per font file, if user plays with translations.
Now we use a better system, which is storing an additional optional metadata in previews
(some hexdigest), that Blender can use in addition to datetime to decide when to regenerate
previews.
This is only used (and needed) by font previews so far, but can easily be reused for other
types of previews if needed.
This avoids some ugly 'missing char' in previews - not all cases of course, but most common ones.
A complete solution would be much much more involved, and probably not worth it here.
Definitively not before a release, at least!
properties.
This is necessary to distinguish e.g. vector semantics (linear vs. slerp
interpolation for positional/normal vectors). It would be simpler to
do this based purely on types, but the typing of common Alembic
properties is not sufficiently unique. Semantics arguments are enum
values, that can be omitted if the default interpolation should be used.
We had some reports where users did not even read the "Not supported on
release builds" message, and arguably writing a file sort of indicates
that the file may include something useful.
This will help figuring out cases when node was not properly handled by the SVM
by aborting execution on CPU, where all the nodes are expected to be supported.
This commits finishes initial selective nodes compilation into kernel, which
helps a lot performance-wise for AMD OpenCL kernels.
Split by node groups is based on statistics from simple scenes like BMW and
more complex scenes like mango and gooseberry production files. Further
tweaks are always possible, but it should be a good starting point.
TODO: Still need to ignore unused nodes when calculating requested shader
features.
For now it's reported to the stdout, matching to the CUDA behavior.
In the future we can hide this into GLog logging once the kernels
are considered all stable and so.
We cannot `direct_link_packedfile()` twice on a same address, because this tries to
map again pf->data address, which leads to nothing (NULL).
So now, since `ima->packedfile` and `ima->packedfiles` are mutually exclusive
in 'live' blender data anyway, we either read one or the other.
Tested from/to official 2.74 and current master, everything looks fine now.
rBe5fbeba0b3a6e9eea not only restored forward compat, it also broke backward compat...
for no reason at all even, exising ima->packedfile is only used by read/versionning
code if .blend version is below 274.4 (i.e. no multi-image packing exists).
This patch adds some new functionality to the Freestyle Python API, notably:
- MaterialBP1D, checks whether the supplied arguments have the same material
- Fixes a potential crash in CurvePoint.fedge (due to NULL pointer)
- Makes (error handling in) boolean predicates more robust
- Adds a BoundingBox type, to make working with bounding boxes easier
- Adds several new functions (get_object_name, get_strokes, is_poly_clockwise, material_from_fedge)
- Adds a StrokeCollector StrokeShader, that collects all the strokes from a specific call to Operators.create()
- Adds hashing and rich comparison to the FrsMaterial type
These new features (most of them, anyway) are needed for making a more robust SVG exporter that supports holes in fills.
Reviewers: kjym3, campbellbarton
Subscribers: campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1245
This features is needed for motion blur. All properties with position
semantics (transform matrices, mesh and curve vertex locations, etc.)
need to be interpolated for fractions of full frames, in order to
reproduce the motion and deformation correctly.
Alternatively we could store subframe time sampling for this subset of
properties. However, this would increase the amount of data stored,
and it might actually show artifacts from subframe interpolation in
Blender which is not visible to animators otherwise and should be
ignored.
archives, instead of Blender frame values.
This is easier to use for interpolation, the frame value is really only
required externally, before and after reading a sample.
when mipmap is off.
We used to always have nearest interpolation for texpaint but at least
make this work with mipmap off correctly.
Also added conversion casts to avoid integer overflow in filtering code
Like Camera Motion, only available in the Experimental kernel.
This should be it for the upcoming release, we now support almost everything, apart from Transparent Shadows, SSS and Volume.
T44869.
There are a couple of issues here:
* Code repeatedly calculated center of ready rendered parts even though
they would not change while the operation was done.
* Code would calculate distance of tiles from center multiple times
* Code would traverse all items, even the ones already sorted
* Traversal used linked lists which is quite slow.
Mitigated these by doing one pass for the center, a second to calculate
distances and a qsort at the end.
Should result in O (n * (log n + 2)) instead of O (n * (n * 2))
complexity, plus the number of repeated operations is much less as well.
Same as last commit, code is unused and this one actually would have required some fixes,
as these variants output values outside the 0-1 value range, which doesn't fit Cycles shader design.
Let's finally delete this code, after 4 years of being unused,
there really is no excuse anymore.
If we decide to extend the procedural textures in SVM, we can do this anytime in the future.
This requires some modifications to the existing preset python class.
Serializing curve mappings can not be done with a simple property
assignment.
Also the fact that operator confirm popups drop all layout context
pointers means that we have to store the modifier name in the operator
in order to apply the preset to the correct modifier.
multires.
Code had special guards for such edges to stop this from happening. I
don't see why this is needed though since code above assigns smoothed
positions for all vertices in the grid.
After removing the guards I saw that this in fact was the only place
where grd adjacency was used, so I completely removed it.
* Add space key to easily start-stop the player.
* Keep old behaviour of stopping when scrubbing.
* Sound scrubbing can be heard now even when scrubbing after pausing.
We must take kerning into account everywhere! Note this will disappear in upcomming filebrowser
refactor anyway.
Reported through IRC by Pablo (venomgfx), thanks.
This adds description of the Font object and about its (only one)
attribute, as well as an example of use.
Reviewers: campbellbarton, fsiddi, dfelinto, moguri
Reviewed By: dfelinto
Subscribers: lordloki
Projects: #documentation, #game_engine
Differential Revision: https://developer.blender.org/D863
The previous way of selecting preview ("realtime") and render settings
on the cache library level was complicated and confusing. Now there are
just 2 buttons for baking either the preview or render level.
Technically the cache still works the same way, so a 3rd button could be
added for baking both passes into the same cache, should the need arise.
The preview cache now also uses the preview frame range, which should
help in quick testing of hair simulation settings. Render always uses
the scene frame range, like render buttons do.
For display in the viewport and rendering the cache will now use
whatever data is available in the archive. If the cache contains only
render data, the viewport will also draw full render data. Vice versa,
if the cache contains only preview data, this will also be used for
rendering.
Hair toggles for children and motion now are only used for the viewport
display. This simplifies the settings a lot and removes one potential
button to be overlooked.
As used already for mesh & curves.
Add confirmation menu for curve & armature,
since this isn't such a common operation and undoing leaves object data
(long term bug/todo to fix).
This commit re-shuffles code in split kernel once again and makes it so common
parts which is in the headers is only responsible to making all the work needed
for specified ray index. Getting ray index, checking for it's validity and
enqueuing tasks are now happening in the device specified part of the kernel.
This actually makes sense because enqueuing is indeed device-specified and i.e.
with CUDA we'll want to enqueue kernels from kernel and avoid CPU roundtrip.
TODO:
- Kernel comments are still placed in the common header files, but since queue
related stuff is not passed to those functions those comments might need to
be split as well.
Just currently read them considering that they're also covering the way how
all devices are invoking the common code path.
- Arguments might need to be wrapped into KernelGlobals, so we don't ened to
pass all them around as function arguments.
It was possible race condition on empty curves -- it's possible that curve
object is fully updated and path is null in that cases, Proper way to deal
with this is to check curve_cache for non-NULL.
It was kept disabled due to render artifacts which weer in fact caused by bad
memory access, which is fixed in the previous commit.
We now also can make it enabled in regular AMD split kernel after someone tests
the updated code.
This is needed when you want to bake only part of an armature's bones, since they
all share a single action, otherwise you'd lose non-baked bones' animation...
This will print a warning and users will get overlap of pie buttons, but
it should be quick paper over the cracks and at least should keep
blender working until a more complete fix is coded.
Tweak event was being added to the end of the event queue (out of order),
meaning any mouse releases already in the queue wouldn't be used to exit the gesture.
Gestures could get stuck (mostly when the system wasn't able to handle events fast enough).
Now tweak events are now added in order.
This will fix exporting of metadata and importing for imbufs, but image
editor will not display these metadata since multilayer gets converted
to renderresult, which does not support metadata display yet.
This commit is more meant for external image editors/viewers.
Use first packed image as legacy image->packedfile, so saving .blend file with
latest builds makes it so packed images are not lost when opening with previous
releases.
This will only work reliably if mutliview is not used, otherwise it'll be only
first view in the .blend file, which is rather expected since previous releases
are not aware of views.
Enum's itemf callback can be called without context in some cases (UI, doc generation...).
Python's enum properties did not handle this at all - it's kind of odd this did not cause
more trouble and wasn't notice earlier... Probably dynamic enums using context are not
much used in py code.
Note about nodes: those are heavy users of dynamic enum with context. Now,
we expect `NodeCategory.poll()` and `NodeItem.poll()` to always be called with
a valid context (since when there is no context available, we can assume `poll()`
is always True). `NodeCategory.items()`, however, must accept NULL context, so if
you use custom `items` callable for your custom node categories, you may need
to update it (as was done here for builtin `node_group_items()`).
The code was failing to compile on runtime because of some path differences,
and it seems we don't need to specify full path to the file which originally
seemed to be needed to make include directives expansion working correct.
This was broken after the kernel file restructure.
Variables allocated in the __local address space can only be defined
inside a __kernel function.
We probably need to solve this a bit differently once we do the CUDA
kernel split, but this fix shoud be good enough until then.
Blenderplayer forgot to initialize the default material (defmaterail) with function init_def_material().
This reverts also the plumber commit 2fa4a48bce.
Reviewers: campbellbarton
cutting.
When using a dupli object from the same group as a target it is
sufficient to calculate the relative transform in the shared duplicator
local space. When using an external object though we have to transform
into world space first.
for child hairs.
The algorithm works by finding the first intersection of each child
hair with the target mesh. The child hairs have to be deformed with
their parents first (this usually happens *after* modifiers).
Since the kernel split work we're now having quite a few of new files, majority
of which are related on the kernel entry points. Keeping those files in the
root kernel folder will eventually make it really hard to follow which files are
actual implementation of Cycles kernel.
Those files are now moved to kernel/kernels/<device_type>. This way adding extra
entry points will be less noisy. It is also nice to have all device-specific
files grouped together.
Another change is in the way how split kernel invokes logic. Previously all the
logic was implemented directly in the .cl files, which makes it a bit tricky to
re-use the logic across other devices. Since we'll likely be looking into doing
same split work for CUDA devices eventually it makes sense to move logic from
.cl files to header files. Those files are stored in kernel/split. This does not
mean the header files will not give error messages when tried to be included
from other devices and their arguments will likely be changed, but having such
separation is a good start anyway.
There should be no functional changes.
Reviewers: juicyfruit, dingto
Differential Revision: https://developer.blender.org/D1314
Angle limit for join-faces was more advice then actual limit.
Now joining entire selection, gives assurance that no faces above the limit will be merged.
The purpose of this was to allow users to isolate 2 faces and always join them.
Instead, support this by bypassing limit only when its not set and 2 faces are selected.
Problem was float precision issues across tile boundaries. Since we are
comparing pixels, give a small tolerance when comparing clipped vertices
against triangle lines.
SCons was checking for a particular compiler version to see whether compiler
flags are available or not, but compiler ID was only set on OSX.
Now it should be set on Linux as well.
Previously, it would only save the eraser size if the session ended properly,
instead of being cancelled. However, that wouldn't happen if exiting the session
using Esc.
We have too much of those cases in our UI, if we want to keep operators doing
several similar/related but yet different tasks, we should have a real way to
support it on label/icon/tip side too. Easier to say than to do though. :|
Note: maybe we could even make `RNA_property_is_unlink()` always return false
for enum properties? But well, guess being explicit here does not hurt...
They were lost during simplification of kernel loading but might be rather
crucial for the performance.
Also made it so cflags are shared across kernels. Surely it might lead to
some unwanted kernel re-compilation but at the same time they might easily
run out of sync with the changes in kernel and so.
Previously decimate on flat areas of a mesh would more or less randomly collapse edges.
(giving bad topology).
This commit includes a topology 'cost', so smaller edges on flat surfaces collapse first.
Support speed of sound based on how fps is different from the movie fps.
For high fps the picture thread can lag behind the sound still, need
some way to framedrop.
Basically it's a clean tool, but also removes a channel if the only
remaining keyframe has the default value only and is not used by
drivers or generative modifiers.
It's supposed to help with performance of the heavy scenes in
gooseberry.
Field test in gooseberry for now, masterification later.
Strand shapekeys will be interpreted as delta keys without a basis,
since the basis would be animated and therefore useless for static keys.
To avoid complexity in the already overburdened shapekey functions and
to skip old legacy code, the strands shapekeys now have their own
functions.
This way it is possible to have single threaded depsgraph but threaded other areas
which is handy for torubleshooting.
he argument is: --debug-depsgraph-no-threads
We're currently only supporting save to a default format color space, which
makes it a bit tricky to prevent ImBuf from being changed.
For until when saving to a custom colorspace works we'll just reload image
if the space changes.
of an animated base.
This is necessary for strand shape keys. The basis of the data comes
from the cached animation or simulation results, i.e. we can't use the
fixed basis key or the result would always become static.
Previously we don't merge material cached list, it create dangling pointer and memory leak.
Now we merge material cache list during the scene merge, and remove material in this list during the library free.
Reviewers: agoose77, dfelinto, hg1, pgi, campbellbarton, moguri
Reviewed By: campbellbarton, moguri
Subscribers: campbellbarton, youle, kupoman
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1278
motion state.
This means shape keys work on the goal positions for hair as well as
the simulation results (hair motion).
If the simulation is created before shape keys are applied, the
resulting sim will be mixed with the shape keys, becoming more rigid
with increased shape weights.
OTOH the shape keys can also be applied to the animation result, before
doing hair simulation. In that case the shape will only affect the goal
positions and the bending shape of the hair, but the hair is otherwise
free to move.
color in GLSL
Issue here is that intermediate result was clipped as an optimization in
such nodes and thus not converted to the correct type properly. Now only
clip those values if types match.
This keeps both the optimization and the conversion. I looked at
converting uniform types always but it's more involved to compare types
at conversion time for such links because the type was getting
overridden during link duplication.
gooseberry and alembic branches.
The shapekey code has been modified in both branches, adding particle
shapekeys in gooseberry and cache library shapekeys in alembic. The
two approaches are slightly different, but based on the same idea of
extending the 'from' owner info in Key, so that keys can be used without
a 'from' ID and/or with an index for identification.
This patch unifies the approach in both branches to make it slightly
less messy and avoid merge conflicts.
The shapekey code has been modified in both branches, adding particle
shapekeys in gooseberry and cache library shapekeys in alembic. The
two approaches are slightly different, but based on the same idea of
extending the 'from' owner info in Key, so that keys can be used without
a 'from' ID and/or with an index for identification.
In certain configurations (for example when start resolution is set to small
value for background render and progressive refine enabled) number of tiles
might change in the tile manager. This situation will confuse progressive
refine feature and likely cause crash.
We might also add some settings verification in the session constructor, but
having an assert with brief explanation about what's wrong should already be
much better than nothing.
for slices.
Also the time sampling for slice output properties must be passed down
from the output archive, since the input properties use the original
start frame and cycle times.
than relying on values from Scene.
This gives more flexibility when creating archives. A default variant
for opening archives using the scene settings is still available.
range to a new archive.
This feature is useful when cache size becomes to big and unwieldy.
For sending shots to a render farm a large cache can now be split into
smaller parts, which are spliced off and can be sent individually.
Still lots of corner cases to check:
* sound FPS not changing with speed settings of player
* picture and video still not 100% in synch
* Haven't checked what happens when audio is finished.
Some changes were made to make things nicer:
* Scrub now initiates on mouse click instead of mouse motion, makes
things more predictable.
* When scrubbing a movie with sound, don't pause playing after
scrubbing.
It was possible that two threads will start calculating proxy group's inverted
matrix and store it in the object itself. This isn't good idea because it means
some threads might be using partially written matrix.
Previously it was very easy to run into situation when two objects are sharing
the same materials with drivers which will cause threading access issues.
This actually only needed for the old depsgraph, but since it's still the one
we're using by default we'd better solve this issue.
There were some reported data race conditions in the python interpreter which
seems to be rather valid.
Surely this is not very pretty solution, but it might solve some annoying bugs
related on threading.
For a long time this function was only intended to be used from the main thread,
but since out implementation of parallel range (which is currently only used by
mesh deform modifier) we might want to switch to threaded alloc from object
update thread.
Now we're using spinlock around the check, which makes the code safe to be used
from all over the place.
We might consider using a bit of atomics operations magic there, but it's not so
much important for now, this code is not used in the performance critical code
path.
Fix for T36639 caused all path changes to reload (which could loose user content).
Change behavior:
- Only reload data when a flag is explicitly passed
(currently only used by Find Files operator)
- Don't reload images which have been painted onto and not saved (dirty flag set).
The problem was that it was aborting too early after stumbling across a point which
might fit within the bounds required. This commit improves the logic here to solve
this and a few other little bugs like that.
Disclaimer: There are still a few cases where it randomly ends up picking something
way off. However, this only seems to occur very sporadically, so it's hard to say
how bad the problem may be.
In pipeline.c the function add_freestyle() was supposed to be called once
per frame, but after the Multi-view merge the function are called as many
as the number of views. There were however a few Freestyle parameters
that have to be initialized per frame, and initializing one of the
parameters for each view was causing double freeing of allocated memory
which was enough to result in a crash.
Remane sound_scene_handle to playback handle.
sound_scene_handle was a part of scene so we could see code like scene-
often in the same function.
If I understand things correctly, in audaspace lingo, the
playback_handle corresponds to a Reader while the scene_sound
corresponds to a Factory.
More cleanups will be done here later, but changing this now because my
brain hurts trying to remember which is which...
Holds 30 frames in memory. Could make it check memory instead but that
should suffice for now to make sure blender does not crash on me with
movie files.
Previously the system would load eveything in memory so something like
playing caminandes in player would swap after 30 seconds in local
computer.
For animations, you often want an animated render seed (noise pattern).
This could be done by e.g. setting a driver on the seed value.
Now it's a little checkbox, that can be enabled.
The animated seed is based on the current Blender frame and
the seed value itself. Simply enabling it, will already result in an animated
seed (different on each Blender frame), but it can be randomized further
by setting a different seed value.
Disabled per default, so no backward compatibility break.
Differential Revision: https://developer.blender.org/D1285
team.
There are 3 options here:
1) Keep range (previous behaviour)
2) Seconds - allows a specified offset in seconds around current frame
3) keyframes - zoom to include a number of keyframes around the cursor
Options 2 and 3 have their own properties to tweak the behaviour and all
options can be found in User Preferences->Interface under the 2D
viewports section.
Number 3 will probably need some refinement so commiting here for the
hwoozeberry team to test first.
Experimental feature set id currently unavailable for megakernel, it'll
require some changes to the cache system to distinguish cached regular
kernels from cached experimental kernels.
Currently unused, but some features will be enabled soon.
Driver fails to compile kernel in reasonable time for those devices here,
so for easier testing of the OpenCL split kernel work disabling bake kernel
for now.
This required allocating some memory related on object transform needed
by ShaderData and currently it is done for all the platforms. Since we're
targeting full feature-complete platforms this is rather acceptable at
this point and in the future we'll do selective NO_HAIR/NO_SSS/NO_BLUR
kernels.
This is experimental still and in fact there're some major issues on
NVidia platform and it's not really clear if it's a bug in compiler,
some uninitizlied variable or other kind of issue.
Some stupid fixes like spaces around operator and missing semicolon,
plus fix for wrong detecting of ShaderData SOA size. Thar was harmless
since there's only one closure array, but still better to fix this.
This file was actually checking for features enabled on CPU and surely all
of them were enabled, so removing them does not cause any difference.
ideally we'll need to do runtime feature detection and just pass some stuff
as NULL to the kernel, or maybe also have variadic kernel entry points which
is also possible quite easily.
It's good for testing and seems to work quite reliably here.
This probably not totally cheap in terms of performance, but this we
could solve quite easily by selective kernel compilation once other
things are tested/proved to be reliable.
The actual character motion actuator triggers every frame the jump method.
Adding an edge detection to trigger the jump method.
Reviewers: lordloki, sybren, moguri
Reviewed By: moguri
Differential Revision: https://developer.blender.org/D1220
team.
There are 3 options here:
1) Keep range (previous behaviour)
2) Seconds - allows a specified offset in seconds around current frame
3) keyframes - zoom to include a number of keyframes around the cursor
Options 2 and 3 have their own properties to tweak the behaviour and all
options can be found in User Preferences->Interface under the 2D
viewports section.
Number 3 will probably need some refinement so commiting here for the
hwoozeberry team to test first.
No need to store them in the class, they're unlikely to be changed
and if they do change we're in big trouble anyway.
More appropriate approach would be then to typedef this things in
kernel_types.h, but still use inlined sizeof(),
This resolves a problem where selected items edited for multi-value-editig
could include objects not in any visible views (unlocked layers, local view... etc).
Optimize the full rebuild case for now (though same code can be adapted to
partial redraws)
Main changes here:
* Calculate bounding centroid for faces only once (instead of every intermediate node)
* Faces do not get added to GSets immediately, instead we track a face
array which has faces that belong in a node in consecutive order.
Nodes just keep accounting of start and length in the array.
* Due to faces not being added to GSets, we can skip doing cleanup of GSets
and readdition for each intermediate node and instead only
add the faces to the final leafs node GSets when those nodes are created.
Results:
For a 1.9 million face test model, PBVH generation time (roughly measured by undoing) is
dropped from 6 seconds to about 4 seconds. Still too high, but still a nice improvement.
TODO:
Thread some parts. Unfortunately threading the GSet assignment part might not help much since
we'd need a lot of locking to avoid collisions with node assignments, especially for unique vertices.
EWA filtering with zero derivatives is introducing some fuzzyness into the
image. Currently solved by using regular sampling for cases when derivatives
are zero, which should also make compo faster in that areas.
Still need to look into checking if EWA filter can be tweaked in a way so
no fuzzyness is introduced.
Also use C++-style unused arguments tagging instead of legacy c-style.
It's less annoying this way because does not require adding argument to
two places of the function.
This commit integrates the work done so far on the new dependency graph system,
where goal was to replace legacy depsgraph with the new one, supporting loads of
neat features like:
- More granular dependency relation nature, which solves issues with fake cycles
in the dependencies.
- Move towards all-animatable, by better integration of drivers into the system.
- Lay down some basis for upcoming copy-on-write, overrides and so on.
The new system is living side-by-side with the previous one and disabled by
default, so nothing will become suddenly broken. The way to enable new depsgraph
is to pass `--new-depsgraph` command line argument.
It's a bit early to consider the system production-ready, there are some TODOs
and issues were discovered during the merge period, they'll be addressed ASAP.
But it's important to merge, because it's the only way to attract artists to
really start testing this system.
There are number of assorted documents related on the design of the new system:
* http://wiki.blender.org/index.php/User:Aligorith/GSoC2013_Depsgraph#Design_Documents
* http://wiki.blender.org/index.php/User:Nazg-gul/DependencyGraph
There are also some user-related information online:
* http://code.blender.org/2015/02/blender-dependency-graph-branch-for-users/
* http://code.blender.org/2015/03/more-dependency-graph-tricks/
Kudos to everyone who was involved into the project:
- Joshua "Aligorith" Leung -- design specification, initial code
- Lukas "lukas_t" Toenne -- integrating code into blender, with further fixes
- Sergey "Sergey" "Sharybin" -- some mocking around, trying to wrap up the
project and so
- Bassam "slikdigit" Kurdali -- stressing the new system, reporting all the
issues and recording/writing documentation.
- Everyone else who i forgot to mention here :)
This commit only adds callbacks which then later be used with major dependency
graph commit, keeping the upcoming commit more clean to follow.
Should be no functional changes so far still.
This calls are not strictly speaking needed for the old dependency graph, but
due to more granular nature of upcoming depsgraph more actions requires update
of relations of IDs.
On the one hand this extra tags could be wrapped with if() statements, but on
the other hand it makes sense to keep tag in sync so it's clear if some issue
is caused by missing/extra tag or by depsgraph itself.
Currently this function only tags pose itself, totally matching previous
behavior. But this will be needed in the future once new dependency graph
is landed, because of it's granular nature which relies on the fact that
pose channels are all up to date when building the graph.
Should be no functional changes so far.
Currently it is just moving existing functions into a new file,
but in the future those new files will be grown much more due
to upcoming more granular scene updates.
Should be no functional changes.
This reverts commit 1b32ac9779.
The goal spring is not working as intended, but is better than having
no bending force at the roots at all. Needs a better solution (virtual
root vertex).
- check for class/static methods assumed nonzero args.
- subclass references and set-flag items are now sorted.
- use 'order' for Py operator mix-ins,
so operator settings don't show in random order.
Most of this patch was created by Daniel Stokes, I'm mostly just cleaning
it up and testing it. Still todo: hardness. I need to figure out how to
handle the integer -> float conversion on a dynamic uniform.
Reviewers: psy-fi, brecht
Reviewed By: psy-fi
Subscribers: psy-fi
Differential Revision: https://developer.blender.org/D511
There are larger bugs still roaming free which need to be solved first.
Goal springs also are inherently unstable because the solver can not
properly estimate their Jacobian.
An assertion to check if `re->clipsta` < 0 (added as part of addressing
T36009 in rBrB795034c17d76bef2a15e576ac9c70ae2268a823b) was failing when
Freestyle viewport preview rendering takes place in the camera view with
an orthographic camera (in this case, the user-defined clipping range is
used without changes, so that `re->clipsta` is positive). The
`re->clipsta` property has a negative value only when the 3D viewport is
in an orthographic view but not in the camera view. It seems that this
viewport setting cannot be identified from rendering settings accessible
from Freestyle. Now a negative `re->clipsta` value is directly checked
instead, without relying on other render flags.
This commit mainly:
* Exposes PreviewImage struct in RNA, including ways for user to set images data.
* Adds a new kind of PreviewImage, using a file path and IMB_thumb to get image.
* Adds a new kind of custom icon using PreviewImage, unrelated to ID previews system.
* Adds a python API (utils.previews) to allow python scripts to access those custom previews/icons.
Note that loading image from files' thumbnails is done when needed (deferred loading), not
when defining the custom preview/icon.
WARNING: for release addons who would want to use this, please keep it to a strict minimum, really needed level.
We do not want our UI to explode under hundreds of different flashy icons!
For more info, see also the release notes of Blender 2.75 (http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.75/Addons)
and the example/templates featured with Blender.
Patch by Campbell (ideasman42), Inês (brita) and Bastien (mont29).
Differential Revision: https://developer.blender.org/D1255
caches.
The 'find' function was returning a bool value, but this does not
guarantee non-null pointers. Removed the return value to avoid
confusion, now callers should simply check the returned pointers.
The filter group was used by omitting any object instances that were
not in the group. This reduces the cache size, but it also entirely
skips objects.
Now the filter group only prevents writing of the actual object data,
but still allows storing dupli instances and dummy entries in the cache.
Any objects from cached dupli lists that don't have cached data (mesh or
strands) will now use the original object data instead.
The cache bake operator would always create a job in the window manager.
However, when running in background mode via a script, the operator can
not be modal and the script would return right after starting the job.
Then Blender is stopped and the baking job with it.
To prevent this the operator now only runs in a job when executed from
the invoke function (or when 'use_job' is set explicitly).
Currently we can't update the physics mesh of an added rigid body.
The cause is that that we need to update all shapes to say that the mesh was changed, for static object we don't do that previously because we use a odd way to reallocate memory at the same place.
So now when a mesh is changed we iterate all physics controllers which use the same shape info and recreate its shape with the correct mesh.
example file : {F168100}
Reviewers: scorpion81, sergof, hg1, sybren, moguri, agoose77
Reviewed By: moguri, agoose77
Subscribers: sybren
Differential Revision: https://developer.blender.org/D1269
This makes OCIO viewport color correction a little bit faster (about -0.5s for 100 samples)
Also set max half float value to 65504.0 to conform with IEEE 754.
Many thanks to Sergey, for practically giving the solution!
Note that it may also fix T44345, depends whether there are other missing
protections/locks or not...
Was confusing to have shade smooth/soft in both edge & vertex menu named differently.
This is an edge-flag, so keep in the edge-menu, use vertex option when in vertex mode.
rendering
Make scene background color as default for render-to-texture instead of
current blue color (0, 0, 255).
It is very useful for mirrors setups.
Reviewers: moguri, ben2610, sybren, panzergame, hg1
Reviewed By: panzergame, hg1, moguri
Subscribers: mpan3
Differential Revision: https://developer.blender.org/D1287
Only those ones are priority for now, all the rest are still testable
if CYCLES_OPENCL_TEST or CYCLES_OPENCL_SPLIT_KERNEL_TEST environment
variables are set.
This commit contains all the work related on the AMD megakernel split work
which was mainly done by Varun Sundar, George Kyriazis and Lenny Wang, plus
some help from Sergey Sharybin, Martijn Berger, Thomas Dinges and likely
someone else which we're forgetting to mention.
Currently only AMD cards are enabled for the new split kernel, but it is
possible to force split opencl kernel to be used by setting the following
environment variable: CYCLES_OPENCL_SPLIT_KERNEL_TEST=1.
Not all the features are supported yet, and that being said no motion blur,
camera blur, SSS and volumetrics for now. Also transparent shadows are
disabled on AMD device because of some compiler bug.
This kernel is also only implements regular path tracing and supporting
branched one will take a bit. Branched path tracing is exposed to the
interface still, which is a bit misleading and will be hidden there soon.
More feature will be enabled once they're ported to the split kernel and
tested.
Neither regular CPU nor CUDA has any difference, they're generating the
same exact code, which means no regressions/improvements there.
Based on the research paper:
https://research.nvidia.com/sites/default/files/publications/laine2013hpg_paper.pdf
Here's the documentation:
https://docs.google.com/document/d/1LuXW-CV-sVJkQaEGZlMJ86jZ8FmoPfecaMdR-oiWbUY/edit
Design discussion of the patch:
https://developer.blender.org/T44197
Differential Revision: https://developer.blender.org/D1200
The goal is to be able to compile kernel with nodes which are actually needed
to render current scene, hence improving performance of the kernel,
The idea is:
- Have few node groups, starting with a group which contains nodes are used
really often, and then couple of groups which will be extension of this one.
- Have feature-based nodes disabling, so it's possible to disable nodes related
to features which are not used with the currently used nodes group.
This commit only lays down needed routines for this approach, actual split will
happen later after gathering statistics from bunch of production scenes.
This will be used by split kernel in order to compile most optimal kernel.
Maximum number of closures is actually being cached in the session, so viewport
rendering will not trigger kernel re-loading when number of closures goes down.
This is currently unused but crucial for things like calculating amount of
device memory required to deal with the tasks.
Maybe not really best place to store it, but consider it good enough for now.
Previously we only had experimental flag passed to device's load_kernel() which
was all fine. But since we're gonna to have some extra parameters passed there
it makes sense to wrap them into a single struct, which will make it easier to
pass stuff around.
This header was already included into some of the implementation files already,
and this change is needed for some upcoming changes in the way how kernel_types.h
works.
Previously it was only set at compilation time which is all fine but does
not let us to check which closure the node corresponds to prior to the
compilation.
preview"
Looks like this does not work for animators here after all, will use a
different code for this (probably not hardcoded)
This reverts commit 3bbb4020e7.
shape.
Shape keys distinguish between the base shape (shape without any keys)
and the individual reference shapes for each shape key (which define
the delta offsets). For strand shapes, which have to work on top of
animation, the base shape must be the original cache result rather than
a static shape, but the delta for each keyblock is still calculated
wrt. an explicit shape.
group objects when editing shape keys.
The edit data (including CD_SHAPEKEY layers) is in the active object's
space, i.e. the duplicator. The original data however is cached strands
data, which is in the dupli object's space. All geometry data needs to
be transformed properly when entering/exiting edit mode.
This already exists for goal springs. Bending stiffness, however, is
preferable to global goal springs for physical realism. Controlling
stiffness in this way allows using bending forces to also simulate
unconventional hair, such as clumpy strands that are thicker and stiffer
at the base.
Note that hair interaction can also be simulated with this tool in some
way, although eventually better methods may be needed for such effects.
We can calculate tangents analytically for bezier curves, so just make
them awesome. New code uses forward differencing calculation for
efficiency just like curve calculation.
Picture before/after:
http://www.pasteall.org/pic/87843
solver.
This happens when using goal springs, which are now defined as linear
springs between actual vertices and virtual goal vertices. The Jacobian
was not accounting for the possibility of zero rest length.
Since it was not ensuring dest has valid mdisp data matching new multires modifier subdiv level...
Also, fixed a bug in `multires_subdivide()`, which would crash when trying to
increase from level 0 (aka no subdiv) to > 1 (wrong check, trying to interpolate
when it should not). And added a few sanity checks.
Looks like the previous commit here is really correct and fixes cases of
distortion that were in mirror-subsurf combination since blender 2.5.
This may cause some changed files in which case we will be adding an
option, but it is expected this will only happen with low res models,
and hand painted textures, and the better distortion here compensates
for that enough to consider not adding a compatibility option yet.
Leaving the facemap winding argument as is just in case we do consider
to add the option.
I have added an optional named "index" argument for methode get/setUV, I have also modified the and set to deprecated methodes setUV2 and getUV2 : the doc was wrong and the methode can't be called anyway because it declared as VARARG in the .h and convert directly the args value to a vector in the .cpp.
Reviewers: sybren, lordloki, hg1
Reviewed By: lordloki, hg1
Subscribers: agoose77
Differential Revision: https://developer.blender.org/D1240
Both the gooseberry and alembic branches contain extensions of the Key
DNA structure, in order to make it work for particles and caches
respectively. This was giving badly resolved conflicts on merge.
function.
This is a feature for display in the viewport and rendering, which has
nothing to do with the core cache reading functionality. In the general
case you'd want the child data to remain unmodified.
Getting a consistent look here is difficult since editors apply their
own scaling. ideally, here we would have a consistent look with constant
font size but this is still to be realized in master and needs some
extra thought.
The parent matrix is used for single-parent children ('simple'), in
which case the pa->num_dmcache has to be used to get the correct
position on subdivided meshes.
file, since we need the updated times and frames.
This was lost during stamp code refactoring. The refactoring moved the
stamp when render is initialized so we would be guaranteed to have
correct cameras even when saving render stills at a later time (and even
if cameras were changed). For regular render this would work since
render init takes care of stamp, but for openGL rendering we need to do
this manually.
Still not 100% correct, does not apply multiview cameras to metadata
This data is not strictly necessary for the strands drawing or rendering
or even hair simulation, because the hair root offset and rotation is
already cached explicitly. However, the strand edit mode needs this
information to correctly apply length constraints.
Strands require a valid DerivedMesh for calculating their root matrix
and surface mapping. The scheduler tasks were created such that strands
would be calculated while the DM task was not finished yet, leading to
missing DM data.
object.
The strand edit mode uses the local space of the active object, which
is the duplicator (and dupli cache owner). The strands data is in local
space of the original particle system object however, so have to
convert. This is a very hackish solution, using the first instance of
the strands data, which only works for single instance data.
Replace EnableCcdPhysicsController by AddCcdPhysicsController and DisableCcdPhysicsController by RemoveCcdPhysicsController.
Tested with compound shapes and collision sensors.
Reviewers:agoose77, ideasman42
Currently strand edit mode tool use the object data 'x mirror' flag.
This flag is only available on mesh objects, but the strand editing
can be used for dupli override caches etc. as well. Eventually strand
editing should get it's own independent flag to avoid this problem.
Now we calculate color in range 800..12000 using an approximation a/x+bx+c for R and G and ((at + b)t + c)t + d) for B.
Max absolute error for RGB for non-lut function is less than 0.0001, which is enough to get the same 8 bit/channel color as for OSL with a noticeable performance difference.
However there is a slight visible difference between previous non-OSL implementation because of lookup table interpolation and offset-by-one mistake.
The previous implementation gave black color outside of soft range (t > 12000), now it gives the same color as for 12000.
Also blackbody node without input connected is being converted to value input at shader compile time.
Reviewers: dingto, sergey
Reviewed By: dingto
Subscribers: nutel, brecht, juicyfruit
Differential Revision: https://developer.blender.org/D1280
Can now rip from multiple fans (mixed single faces or larger regions)
Also add BM_vert_is_manifold_region which only checks if a vert has disconnected fans.
separate file.
This may seem a bit like overkill, but it helps ensure that no particle
depedencies messes up the strand editing code. The same will be done for
other use cases of the strand editing code in the future.
Now shape keys don't replace the cached base data entirely with the
static Basis shape. Instead the current state as coming from the cache
is interpreted as the variable refkey instead of the Basis key.
The Basis key is in fact redundant, but removing it would require
changing a lot of shared shapekey code, so it's left in for now.
Code here did depth test always and depth range 0.0.
There is no real reason for object centers to write and get tested
against depth buffer in this case, just disable the depth test instead
;)
Helps with blurry object centers in depth of field mode too (centers
wrote depth 0 and were always blurry)
This way it is possible to have viewport simplification bumped all the way up,
making viewport really responsive but still have final render to use highest
subdivision possible.
Reviewers: lukastoenne, campbellbarton, dingto
Reviewed By: campbellbarton, dingto
Subscribers: dingto, nutel, eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1273
Own regression, previously it would do a full mesh normal calculation for each isolated shape
(could hang on meshes with many loose parts).
However the normals are needed, instead of doing a full calculation,
just set normals on new faces.
Thanks to Brecht for finding cause!
transform.
IMB_makeSingleUser makes a copy and destroys metadata. I am not sure if
this is the safest way to make a single user ImBuf (setting the refcount
to 0 is simpler and there's less, but no zero, risk of dangling
pointers) but I will leave this as is for now in case there is an actual
need for a copy here. The alternative approach should be tested at some
point.
Assumed the `reference` pointer is an ID, currently true, but may not always be.
Add a callback specifically for this purpose since cleaning up notifiers and space-types are different operations.
The Key struct in the cache strands shape modifier is in fact "owned"
by the modifier, but linked in the Main blenddata, so it does not have
to be written explicitly.
the source cache and then applies modifiers afterward.
This only performs non-iterative modifiers, which don't require the
passage of time to work (e.g. shrinkwrap).
This includes storage of the shape keys in a `Key` instance in the
modifier data, and accompanying operators for adding, removing, moving,
etc. shape keys, as well as the necessary UI code.
"Unexisting" particles must be freed after the unexist flag has been set,
which was no longer the case after 78c491e62a.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D1213
There are several ways to end up with an object with skin modifier, but no
skin data on the geometry. So we need an operator to add it by hands.
Also tweaked a bit UI of this modifier.
pointer for 'from'.
The Key DNA has some very old and largely deprecated legacy code that
needs initializing, which requires either explicit info or deduction
from an ID. The cache modifier creates keys in a new environment without
an existing known ID type to deduce the data element settings from.
cached strands data.
This modifier acts as a container for shape key data (i.e. as part of
the cache library). Such shape data can be applied to cached strands
data, which allows tweaking of animated hair shapes.
This could work both as a shape for the strand goals (adding dynamics
on top) or as a final modification after dynamics. Both methods have
their advantages (pre-sim allows control and sim at the same time,
post-sim gives accurate shapes but becomes rigid).
- simplify boundary handling (walk from boundary - no need to reset walking)
- early exit when the vert has >2 boundaries
- use BM_vert_step_fan_loop to walk the fan
color layers.
The layer data is added to the strands after creation, but can be
existing already. It should only be reallocated when the number of
layers changes, and must be freed cleanly in that case.
When using external forces to implement goal springs to explicit
positions in space, the system cannot calculate a stable solution based
on the goal velocities. The new approach implements goals as vertices
in the simulation, which are constrained to their animated locations.
This way they are treated like regular vertices, but the springs only
affect their non-constrained counterpart (the actual vertices).
When using the hair path deformation feature of the modifier, each copy
of the mesh can now be rotated around the path, in addition to changing
length and offset. This includes a constant phase angle as well as a
randomization factor.
simulation.
The hair sim skips the first frame (velocities are undefined there), but
still has to create the motion state data in order to have it written
as a sample. Otherwise the strands motion state samples start one sample
short and frames get mapped to one sample in the past. This then leads
to incorrect movement of all hair vertices other than the roots (which
are always clamped to the animated positions).
When working with a pen only, it was previously impossible to exit Grease Pencil
draw mode (when continous drawing was enabled). Now, clicking outside the drawing region
(e.g. in the timeline, properties editor, or the header/properties/toolshelf regions)
where you are drawing will exit this mode.
Some corner cases to be aware of:
* When Region Overlap is enabled, clicking on the overlapping panels still exits
draw mode (even though you can see behind the buttons)
* In the Nodes Editor, clicking on a node (while in drawmode) will still draw a
dot/stroke. But, you can still exit drawmode by clicking on any of the panels
(properties/toolshelf/header) mentioned earlier
* To cope with cases where the operator is launched from the toolshelf, the
code now sets a new "active region" when the first stroke is performed
(based on what region is under the cursor at the time of that stroke),
overwriting the setting that got stored when invoking the operator (i.e. the toolshelf).
This change doesn't have any real user-visible effects, other than making it possible for
this fix to actually work without breaking that use case.
This commit fixes several issues:
* island_store->items_to_islands_num was reset each time we added a new island, this is stupid! Harmless too, though, afaikt.
* partial verts bvhtree (with several islands) was hugely over-allocated...
* we would 'leak' in neighbor islands when geometry itself was contiguous.
* best_nor_dot was used incorrectly, leading to smaller weights for better matching normal!
All those fixes are related to T44522 (through personal communications with reporter).
Alternative to T32894, simple test which creates new data and compares with RNA defaults.
Can be used to keep the values in sync without having to maintain a large set of defines.
We cannot nuke treestore in readfile's `blo_lib_link_screen_restore()`, because this will
destroy all UI-state data (like opened/closed items, etc.).
Since we cannot know for sure whether an ID pointer from tselem->id is valid here, we
have to ensure they are never invalid, i.e. to always set them to NULL when we delete them.
To do so, this commit uses a similar approach as what already exists for ID references
in WM notifiers - it extends `free_notifier_reference_cb()` to also nullify those IDs in
all outliners.
Note that some ID types are not used(shown) by outliner currently, so `TREESTORE_ID_TYPE` macro
was added, that checks whether an ID is possibly used by outliner. Avoids a few searches
in whole tree whene deleting some IDs.
Reviewers: campbellbarton, sergey
Maniphest Tasks: T44439
Differential Revision: https://developer.blender.org/D1272
As a followup for the previous commit, do the same thing for the insert/delete
keyframe button operators as is done for the clear keyframes op. There really isn't
much need/reason for conducting the looping there, as those functions natively
handle this themselves already.
On second thought, the previous commit was just adding additional complexity which
wasn't needed, as the operator was wasting effort by doing this looping itself.
Moral of the story: Make sure that size_t is used whenever pointer
arithmetic is involved. For images, that basically means whenever any
squared dimensions are involved. Casting an operand to size_t early in
the operation is usually sufficient to force the entire operation to
size_t.
There might still be places lurking where we don't support this
correctly. This has been tested with render pipeline, quite a few image
functions (meaning we can paint on such images now, albeit somewhat
slowly ;) ) and export to jpeg. Too many places in code to check so I
guess we'll be handling cases as they come.
Don't try this at home unless you have an immense ammount of RAM.
First GPixel render of suzanne in the multiverse can be found here:
http://download.blender.org/demo/test/suzanne-billion-pixel.jpg
Can be viewed from blender (takes about 3.3 GB after loading but may
take more during loading so 8GB might be more safe to try this).
Issue was caused by de-referencing NULL pointer, rres did not have any
views because nothing was rendered yet.
Needs more closer look about where else such a de-reference could happen.
This replaces sequential ray moving followed with scene intersection with
single BVH traversal, which gives us all possible intersections.
Only implemented for CPU, due to qsort and a bigger memory usage on GPU
which we rather avoid. GPU still uses the regular bvh volume intersection code, while CPU now uses the new code.
This improves render performance for scenes with:
a) Camera inside volume mesh
b) SSS mesh intersecting a volume mesh/domain
In simple volume files (not much geometry) performance is roughly the same
(slightly faster). In files with a lot of geometry, the performance
increase is larger. bmps.blend with a volume shader and camera inside the
mesh, it renders ~10% faster here.
Patch by Sergey and myself.
Differential Revision: https://developer.blender.org/D1264
Object flags are depending on bounding box which is only available after
mesh synchronization.
This was broken since 7fd4c44 which happened quite close to the release
and oddly enough was not sopped by anyone. Render test is coming for this.
Was spotted by Thomas Dinges while working on another patch.
We can now scale from 32px up to 256px (default has been upgraded to 128px).
Thumbnails are now generated as 'large', i.e. 256px.
Previews are scaled up if necessary, unlike icons (for folders or files without preview images).
Note that .blend thumbnails themselves remain in 128px for now (they are embeded in .blend files,
not quite sure we want to make them four times bigger...).
Patch by DMS (Yaron Dames), with final edits by myself.
Reviewers: mont29
Subscribers: Severin, mont29
Differential Revision: https://developer.blender.org/D1260
Originally I wanted to get rid of RenderResult->rect* entirely, but it's
convenient to have for temporary structs.
This patch makes sure they are used only when really needed, which
should help clearing the code out.
(they are needed when using RE_AcquireResultImage() - which produces a
RenderResult with no RenderView)
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1270
This fix should actually happen in wiggly-widgets branch but it's now
has some commits which are not in gooseberry and merging them night
be not really safe.
with a dupligroup and distributed rendering.
The particle duplis were generated using the global RNG (BLI_rand). This
is unstable once scenes become a bit more complex and objects are
evaluated in multiple threads.
This patch is not in master, because it changes the look of existing
particle setups.
This is experimental. It might work for simple collision-like features,
by keeping goal positions for hair above the mesh surface. However, the
nature of nearest-point lookup on meshes means that the goal position
can flip to the other side of a mesh rapidly, which would lead to
strong forces and unstable behavior.
This code should be seen as an experiment.
CCFLAGS are used for both C and C++ compilers and one is better not to pass
C-related flags to C++ compiler. C-compiler flags are to be passed via CFLAGS
variable.
In this case we can calculate an offset without worrying about
perspective correction. Unfortunately if looking from a camera we still
have depth issues here. There's no really general case that can fix this
so I'm leaving this as is.
The UV and vertex color attribute export function expects the curve data
arrays to contain only a single attribute at a time. They must be
cleared before filling in data for each UV/vcol attribute.
The reported crash case seems to be caused by freeing compiled Python
objects in a thread. Now this issue is avoided by allocating a buffer to
store a Python script and using BPY_string_exec() to run the script. This
makes it unnecessary to repeatedly create and destroy Text data blocks.
Many thanks to Campbell Barton for his help on the bug fix.
Issue is zfighting with wire of mesh when parts of the mesh are close
together. We can make this slightly better by reducing the offset,
however this offset is calculated pre-perspective division and can vary
greatly with distance. Correct approach would be using polygon offset,
however we draw mesh wireframes as lines, (not polygons with polygon
mode line) so this approach will not work.
Alternatively, we could set an offset in a shader, however we don't have
code for that either.
would fail on coplanar faces (or smooth verts).
Loop remapping is really a tricky topic... For now, we enhance a bit more
our Frankenfunc by using distance between dest and source polygons as
fallback in case we have too much similar normals...
Probably not a perfect solution, but should be robust enough I hope.
One core question remains open though: do we want to stick to 'use only seams
to detect UV islands'? This makes things much simpler, but will obviously fail
in case of actual islands without matching seams. :/
Was changed to draw after meshes without depth mask to make grid not
contribute to compositing effects. Now only draw it like this when we do
compositing (unfortunately can't have both).
Caused by own commit that changed island detection code. In the case of
modifiers we don't want to take winding information into account, but
left the code since there are use cases (like painting) which could use
this.
content.
This group is only used for the baking operator (like the datatypes
filter), but has no effect when reading caches. The UI now uses a box
layout to reflect this.
This patch adds support for light portals: objects that help sampling the
environment light, therefore improving convergence. Using them tor other
lights in a unidirectional pathtracer is virtually useless.
The sampling is done with the area-preserving code already used for area lamps.
MIS is used both for combination of different portals and for combining portal-
and envmap-sampling.
The direction of portals is considered, they aren't used if the sampling point
is behind them.
Reviewers: sergey, dingto, #cycles
Reviewed By: dingto, #cycles
Subscribers: Lapineige, nutel, jtheninja, dsisco11, januz, vitorbalbio, candreacchio, TARDISMaker, lichtwerk, ace_dragon, marcog, mib2berlin, Tunge, lopataasdf, lordodin, sergey, dingto
Differential Revision: https://developer.blender.org/D1133
This more a workaround for CUDA optimizer which can't optimize clamp(x, 0, 1)
into a single instruction and uses 4 instructions instead.
Original patch by @lockal with own modification:
Don't make changes outside of the kernel. They don't make any difference
anyway and term saturate() has a bit different meaning outside of kernel.
This gives around 2% of speedup in Barcelona file, but in more complex shader
setups with lots of math nodes with clamping speedup could be much nicer.
Subscribers: dingto
Projects: #cycles
Differential Revision: https://developer.blender.org/D1224
I finally put the time into understanding what was going on here.
Basically RE_AcquireResultImage() produces RenderResults without
RenderViews. That will be fine for now since I'm planning to refactor
RenderResult soon.
Unlike particles, the Strands data stores UV coordinates and vertex
colors explicitly as a per-strand (const) property. This means Cycles
does not have to know the details of how particles map themselves to
a changing mesh surfaces (which is very complicated and fraught with
broken use cases and bugs). The UVs and colors are stored once for each
strand, since they are not expected to change over time (strands being
fixed to the mesh surface).
The idea is to evaluate derived meshes in multiple threads, which will
reduce overall write_sample() time. We can't make all routines threaded
in there because alembic's file IO can't be threaded.
In any case, this change gives 2x speedup of exporting render resolution
version of Franck here.
This is a kind of sloppy-focus,
resolving long standing bug with loop-cut/knife/ruler /w quad-view.
Where activating a tool would lock onto one of quad-views,
especially problematic when activating from the toolbar or menus.
Making the reference argument optional for the addObject function.
```
scene.addObject("Cube")
```
This allows to keep the rotation, scale and position of the original object.
To avoid layer problems with lights if the reference arguments is None, the new object have the same layer than the active layers in scene.
Reviewers: lordloki, moguri, hg1, sybren
Reviewed By: hg1, sybren
Subscribers: agoose77
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1222
Was checking all vertices adjacent faces,
now just compare the difference between normal angles.
Also default to inverse-square for loopcut-subdiv falloff.
D1233, Adds a way to quickly open/close multiple panels by holding LMB and dragging over the desired panels,
Suggested by @maxon
The decision if the panels are opened or closed is made based on the first Panel the user drags over.
If it is closed, all panels he drags over are opened
(including the first one) if it's opened, they get closed (matching existing drag-toggle logic).
Tried a couple of things to trigger an update/redraw for the exact right
moment (sending azone update event, timer, delayed redraw, etc) but this
seems to work rock solid without being *that* ugly.
In some cases the graphic card supports quadbuffer, but not the display.
In this case it is nice to go back to a window that does not have
quadbuffer if you change back to anaglyph, interlace, ...
Otherwise you may be stuck with a flickering window
Experiment for animators to try - only do full notification of scene at
end of scrubbing, do only manual area update instead like we do for
animation. Also skip audio update unless we do audio scrubbing.
Alembic exceptions and prevent crashing.
Alembic can throw exceptions on relatively common and uncritical errors,
such as mismatching properties in files which don't fit the expected
schema. These cases should now be handled gracefully and simple reject
the cache file with an error message.
Customdata layers also store some base information, such as "active"
layer for rendering. This information is needed currently for syncing
particle UV and MCol data in cycles, even though the MTFACE layer type
itself is pretty much deprecated.
Currently there are bugs with physics objects in inactive layers,
character and softbody.
I added a function in CcdPhysicsEnvironement to know if a physics
controller is currently active and for soft body I added the correct function in UpdateCcdPhysicsController to re-add a softbody in the dynamics world.
The bug was introduced in D1243 commit 3d55859
Reviewers: hg1, scorpion81, lordloki, moguri, agoose77, sergof
Reviewed By: sergof
Subscribers: youle, moguri
Differential Revision: https://developer.blender.org/D1253
If we fail allocating a proxy texture don't fail, instead create a
smaller nearest filtered image to display in its place.
This can make viewing slow (it's an extra O^3 operation), but this will
probably help us render the tornado in 3D viewport in gooseberry and
still actually see something - despite the rendering taking longer.
I've added a debug print so we can know when this happens.
I'll enable this mode in Release builds once I figure out how to best
handle opening files that are saved with the quadbuffer mode.
In fact I think no display mode should be saved/read from a file.
Tested in Linux with NVidia 3D Vision and NVidia 3D Vision Pro with
NVidia Quadro FX 580 and Quadro FX 4600.
(kudos for the Visgraf Lab at IMPA, for having me around with all those
gadgets ;)
Thanks for Cédric Paille (cedricp) for the code snippets and tests -
T44327
This one was nasty, issue comes with temp/nofree CD layers that get 'removed on the fly'
from saved mesh CDData. Since mesh struct itself was written before that cleanup, it would
still have the old, invalid number of layers. That would lead to a buffer overflow when
loading data later (odd you had to do this twice (i.e. have 2 'ghost' layers) to get the crash).
New code prevents that by always making a copy of the mesh (we were already doing that mostly
anyway, since we were saving without tessfaces), copying (by ref of course) in it cddata,
and then writing mesh struct. Makes code a bit more verbose, but... it works!
This otherwise prevents hair simulation motion showing up in renders.
The Alembic structure will have to be redesigned anyway. The current
concept of storing two separate entire scenes for viewport/render will
be replaced by a per-object detail level system. This allows performing
hair simulation only once and still use different resolutions etc.
where appropriate.
This is a temporary fix until I get to investigate it more carefully.
It will help if the report could include the steps to reproduce it
besides the buggy file.
Note: RenderResult should *always* have at least a valid RenderView,
which is not what happens here.
We used the node data as a store for node execution,
bad idea, since the data itself is a template from which
execution data should be derived, never to be modified during execution.
The idea is simple: make it so scene_update_for_newframe is only doing updates
of the stuff which is really needed for the currently baking group.
Implementation is a bit tricky since we don't have parent relations after the
DAG is built, so doing some graph traversal there.
This code is also now using simplified version of scene_update_for_newframe()
which means in theory we can try de-duplicating some pieces of code, but that
can be done later.
Additionally, the same approach can be used to optimize motion path calculation.
Apparently, even if the smoke is backed to an external files it still could be
tried to be simulated at the frames outside of the baked range.
Kinda weird feature which isn't really safe, but better not to crash here.
Not totally happy with the code yet, will check with Lukas or Daniel how it
could be improved further.
influence explicitly.
The previous code would only allow using the layers of the given object.
This is not useful for dupli overrides, because even finding which
layers an object in a dupligroup is in is cumbersome. It makes more
sense to use the layers of the duplicator instead.
There is an '_ex' version of the pdInitEffectors function now, with
an explicit layers argument. The simple version now also skips the
'precalc' argument, because this was true in every case except the
depsgraph dependency building anyway.
Note 1: If you go to a render slot previously rendered and change
something in the compositing the buffer will still vanish.
This is an old bug, T44181, and not addressed here
(I'm basically just fixing the regression introduced with multiview)
Note 2: I have a work in progress patch to get rid of
RenderResult->rectf/rect32/rectz entirely. It still not working, and we
should have a working code base before doing refactoring anyways.
step.
This calculate can take a bit of time (some seconds to a minute in
tests), due to having to loop through all array samples. In many cases
only the basic structure is wanted.
Placeholder images, means that the image sequence reserves a range for
images, displaying black while we wait for them to finish rendering.
This is meant as a feature to not break the layout of gooseberry
sequence edits while we wait for those frames to arrive.
Tooltips for buttons in the Outliner could overlap the Outliner's RMB
menu in some cases (and there's no way to get rid of the tooltip again).
This disables the button's tooltip before creating the menu (as we do it
for the normal RMB menu)
The issue was caused by RNA passing ownership from the cache data used by Blender
to Cycles. This lead to situations when all of a sudden blender looses data it
was expecting to have.
Now instead of passing ownership we're just copying strands from the data, so both
Blender and Cycles are having it's own local data.
Ideally this data will be shared between viewport and Cycles, but that's a bit
more tricky to do without modifying RNA API. Would happen eventually tho.
Rationale - this panel also enables metadata that get written on files.
Also moved draw_stamp property in the panel - to make it clearer it only
controls the drawing, not individual metadata.
Make sure stamp data is avaliable before writing stamp to image - this
still does not fix stamp, looks like issue is availability of the images
themselves for the view, investigating next.
Tweak hack of `file_draw_string()` (there may be better solution, but not worth
spending time on this, the whole filebrowser drawing code is to be rewritten anyway).
This callback allows the user to change the camera data right before the
rendering calculations.
scene.pre_draw[] is not enough here, because if you want to change the
camera matrices (projection/modelview) the culling test is done before
that (after pre_draw_setup[] though).
Reviewers: moguri, campbellbarton
Differential Revision: https://developer.blender.org/D1251
Python sample code using this. The sample scene would need a default
camera (not used for rendering), a dummy camera ('Camera.VR'), and two
cameras ('Camera.Left', 'Camera.Right') that will be used for the actual
rendering.
```
import bge
def callback():
scene = bge.logic.getCurrentScene()
objects = scene.objects
vr_camera = objects.get('Camera.VR')
if bge.render.getStereoEye() == bge.render.LEFT_EYE:
camera = objects.get('Camera.Left')
else:
camera = objects.get('Camera.Right')
vr_camera.worldOrientation = camera.worldOrientation
vr_camera.worldPosition = camera.worldPosition
def init():
scene = bge.logic.getCurrentScene()
main_camera = scene.active_camera
main_camera.useViewport = True
scene.pre_draw_setup.append(callback)
objects = scene.objects
vr_camera = objects.get('Camera.VR')
vr_camera.useViewport = True
vr_camera.setViewport(
0,
0,
bge.render.getWindowWidth(),
bge.render.getWindowHeight() )
```
locked
Really doesn't look like a bug on a first glance but the line of code
that was there previously seemed to be there to prevent the manipulator
from drawing in this case.
Basically, blender adds a few metadata fields to images when
we render an image. Those metadata can now be viewed in the
image editor.
Also, made sure metadata are available when we write imbufs
to disc with "Save As". There may be more cases here that need
fixing, but this means that loading an image with metadata
will now properly preserve them in blender.
A new panel is added for showing the structure and contents of archives
of a cache library (instead of simply dumping on the terminal). The
archive structure is stored in a lightweight tree structure, mirroring
the hierarchy of objects and properties in Alembic. These
object/property nodes can be expanded individually for easier navigation
through the archive.
Generalize logic for vert/edge/face selection:
- index cycling.
- selection bias with mixed modes.
Details:
- Edges now support index cycling (as verts/faces did already)
- Cycling over near elements is now only enabled when the mouse position remains the same.
- No longer do 2 selection passes to perform index cycling.
Fixes:
- Edges behind the view could be selected (surprising nobody reported!)
- Selection bias now only changes the element that gets picked without interning the return distance
(was buggy with mixed modes).
In addition to the unlink icon to clear a value,
When cleared, show an eyedropper to select objects or object-data
(was already available via the EKey).
This implements roughly the same functionality as the equivalent mesh
shape propagate operator, with some tweaks specific to hair editing.
The operator copies selected points to all the shape keys. Unlike meshes
these points may be shifted afterward to achieve consistent segment
length (this can be avoided by selected entire strands before using the
operator).
When mixing vert/edge/face with select-visible,
face selection could fail when not close enough to the center.
This also fixes a bug where the bias for verts over edges would
prefer faces over edges too, making edges harder to pick.
Mixing edge with other selection modes works more predictably now.
when switching the active key.
Particle shapes were always using the relative blending of keys when
evaluating hair data. This works ok for meshes, because their edit data
is entirely separate from the mesh data (using bmesh). For particles,
however, the edit mode is hardwired to the hair data, so when switching
keys in edit mode we must take care to replace everything with the
shape. Otherwise the hair data will be using blender shapes and the edit
data will overwrite any shape keys with that.
- distance from edge check wasn't clamping 0-1
- vertex bias wasn't taking pixelsize into account.
- index & pass counter were floats
Also some improvements
- use BMesh lookup tables when available.
- use structs to avoid issues getting out of sync.
Placeholder images, means that the image sequence reserves a range for
images, displaying black while we wait for them to finish rendering.
This is meant as a feature to not break the layout of gooseberry
sequence edits while we wait for those frames to arrive.
This way we can get rid of inefficient memory usage caused by BVH boundbox
part being unused by leaf nodes but still being allocated for them. Doing
such split allows to save 6 of float4 values for QBVH per leaf node and 3
of float4 values for regular BVH per leaf node.
This translates into following memory save using 01.01.01.G rendered
without hair:
Device memory size Device memory peak Global memory peak
Before the patch: 4957 5051 7668
With the patch: 4467 4562 7332
The measurements are done against current master. Still need to run speed tests
and it's hard to predict if it's faster or not: on the one hand leaf nodes are
now much more coherent in cache, on the other hand they're not so much coherent
with regular nodes anymore.
Reviewers: brecht, juicyfruit
Subscribers: venomgfx, eyecandy
Differential Revision: https://developer.blender.org/D1236
This way memory overhead caused by the BVH building is not so visible and peak
memory usage will be reduced.
Implementing this idea is not so straightforward actually, because we need to
synchronize images used for true displacement before meshes. Detecting whether
image is used for true displacement is not so striaghtforward, so for now all
all displacement types will synchronize images used for them.
Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene
from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after
the patch).
Reviewers: campbellbarton, juicyfruit, brecht
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D1217
This commit replaces name-based node matching in the mesh device update
with check of special type. It is more robust approach for adding new
nodes which could use image slots for storage. it's also adds updates
of environment texture nodes used in bump shader (this was missing in
the original image sync reshuffle commit).
Note that currently this has virtually no effect, because the mirror
option relies on exact positions of vertices, which does not happen with
random hair placement (the add brush has no mirror option yet).
Eventually topological mirroring should help with this case, but is not
implemented for either old or new strand edit yet.
These are a modified version of their BMEditMesh counterparts.
use_topology is not yet implemented for strands. Native strand topology
is not very useful for this. Instead, the topology of the scalp mesh
should be used for finding mirrored strand roots, then the arc- or
parametric length of a vertex from the root to find mirrored verts.
Conflicts:
source/blender/blenkernel/BKE_editstrands.h
When copying mesh data to bmesh the MVERT and similar customdata types
have to be omitted. Otherwise the bmesh instance ends up with NULL
pointers in customdata layers, but entries in the typemap != -1. The
effect was that when storing new steps after one or more undo, the
resulting original data would be copied, and subsequent undo steps
are ignored.
data masks explicitly.
A dummy mesh is used for strand edit undo storage like in mesh edit
to prevent unnecessary code duplication. However, when copying from/to
BMesh only the mesh data layers are copied by default, omitting the new
data layers for strands (currently only MSurfaceSample hair root data).
This uses the generalized undo stack system which is also used for
object data edit. An extension is necessary to tell the undo functions
which object is specifically used for generating undo data and
identifying the stack, since strand editing does not edit the obdata
itself.
consistent segment lengths when transforming vertices.
Warning: The implementation is not correct yet, but all the steps should
be there.
The main idea is to treat strands as a sequence of joints that are
displaced out of their original locations by a transform or other tool.
The solver then tries to find a global per-strand solution that keeps
the segment lengths unmodified, with a minimum change in angles from
the original starting shape. Such a solution is much more usable and
efficient than the current O(n^2) attempt of "spreading the error"
across the strand.
The inverse kinematics method is very flexible. It can also include
stretching, which would be very welcome for features like the length
tool. Different parts of the strand could be weighted separately using
scaling factors for the angle/stretch parameters.
Conflicts:
source/blender/physics/intern/implicit.h
mode.
This method is simple, but not really very usable. It works by
successively relaxing segments that are too long or too short, moving
both vertices along the edge between them. This is repeated N^2 times
(N: number of vertices on the strand).
A true IK solver could give a lot better results, as well as providing
many opportunities to apply weighting for targets (e.g. preferring to
move non-selected over selected vertices). Many different methods for
simple IK solvers exist, so there should be one that works well for
large number of simple strands. See e.g.
http://www.math.ucsd.edu/~sbuss/ResearchWeb/ikmethods/iksurvey.pdf
vertex positions.
This works a lot better with strokes perpendicular to the general hair
strand direction. With the previous comb tool such strokes would only
make a small dent in the hair curve and then vertices would slip out
of the tool circle. The edge combing affects the local direction of
strands, which acts as a kind of grabbing functionality by moving
further vertices in front of the tool circle. The result is that
drawing a curvy hair shape with the comb becomes much easier.
In addition, the new tool also uses edge filtering and weighting rather
than vertices. This means that small brushes also work well, instead
of having no effect when hitting the edge segments between vertices.
Further improvement could be achieved later by using a global strand
solver, which adjusts vertex positions based on an error metric along
the whole of the strand.
direction vector for the hair stroke tool.
This is necessary for directional tools such as combing, where the
stroke direction can lead to unwanted results if it changes too
abruptly.
The rationale behind this is that the BKE code could be used for
modeling hair and fur as well as a number of other features such as
grass. The primary addition to BMesh is the limitation to strand-like
topology (simple vertex chains, optionally rooted on a mesh surface).
The editor code OTOH is quite hair specific, since the result should
be suitable for hair simulation, and the workflow should mimick actual
hair grooming intuitively. Eventually the hair edit mode could become
a generalized strand edit mode with slightly different tool sets for
various purposes, but for now it is quite specifically built for hair.
Conflicts:
source/blender/blenkernel/CMakeLists.txt
source/blender/blenkernel/intern/particle.c
drawing code for edit mode.
The lighting uses the same method as the particle hair, interpreting
strand direction as the normal. This is nowhere near realistic hair
shading, but doing this with line shading alone in the fixed-function
pipeline is probably not possible. A GLSL shader could be used instead
for a more realistic alternative as part of the viewport project. At
least this simple shading mode gives some orientation feedback while
editing hair.
Currently uses the same approach as old particle edit mode (rescale
hair segments from the root on). A more sophisticated approach using
least-square error minimization of the displacement could yield better
results.
Stroke tools will be categorized by the hair elements they operate on:
vertices, segments or strands (roots). In addition to that a filter
function defines the influence of the brush. This should be defined by
the other brush settings and be largely independent of the main tool
mode.
This requires converting the old messy particle num/num_dmcache/fuv/foffset
data into the new mesh samples, which can potentially introduce floating
point errors and inaccuracies due to lack of face index mapping in the
new system. However, in any well-constructed particle system the hair
roots should be nearest to their num face, so mapping would be accurate
enough. If necessary face index data could be added to samples as a
legacy code hack, but probably it's best to eventually replace the
hair system as a whole anyway.
Currently particles only have a single weight value, controlling
pinning in the simulation (for root and virtual root verts) and goal
force scaling. This will be replaced by a full vertex group weight
system eventually.
This is more for testing purposes, since currently there is only a
single mass property for the psys as a whole. This should change in the
future though, to allow variable mass per strand or vertex.
Conflicts:
source/blender/bmesh/intern/bmesh_interp.c
Hair/Strand editing will only use a subset of the bmesh topology and
expect a specific topology that needs to be verified and enforced.
However, this extra requirement is much less work than reimplementing a
whole edit data system with the same feature set as bmesh and avoids
much redundant code.
Conflicts:
source/blender/blenkernel/intern/customdata.c
source/blender/makesdna/DNA_customdata_types.h
This means using mempools to store curve and vertex data, which allows
arbitrary addition and removal of data more easily. Also this includes
an iterator system similar to bmesh iterators (although the simpler
topology makes it a lot less complex).
Conflicts:
source/blender/blenkernel/intern/customdata.c
source/blender/makesdna/DNA_customdata_types.h
particle hairs remain visible.
Note that currently the hair root location (num/num_dmcache, fuv, foffset)
is not stored from edit data, so all hairs end up in a default location.
This makes it work more like editmesh, and avoid the awkward and
basically bad-level approach in particles, where the edit data is an
anonymous pointer in particle systems together with a callback for
freeing.
Conflicts:
source/blender/blenkernel/CMakeLists.txt
sampling system to keep the code simple.
Now there is a MSurfaceSampleStorage struct that encodes the storage
details, which the algorithms don't have to care about.
copy.
What happens is that the strip is copied, but it still refers to the old
scene. Here we need to fix this by referring to the copy of the strip
and also do it after copying to make it order independent.
Disabling group -> duplicator dependencies would in theory make caches
more attractive because the invisible objects don't have to be updated
just because of the group.
However, the viewport and render starts to behave unpredictably without
these updates, because the dupli cache relies in many ways on the
objects it is supposed to override.
Following the initial action management commits for 2.74, blurrymind pointed out a
problematic workflow involving the "Browse Action" dropdown in the Action Editor
which would lead to actions being accidentally lost. Namely, it turns out that
game animators frequently flip between different actions from the Browse menu while
working.
While the new up/down operators and/or other NLA based tools are better suited to this
without the problems of actions getting lost, some additional precautions were needed
for the Browse menu as well. So now, if the active action will have no users as a result
of the switch (i.e. it was a new action, and the user is checking on a previous action
via the Browse menu), this action will now get stashed. This workflow is not perfect though,
as there is the problem of the stashed action strips not reflecting the actions they reference.
When a NLA strip is being tweaked, it should not be possible to use the Action Editor to change
the action that it uses. Instead of changing the action in tweakmode, it now exits tweakmode
first before doing so.
As reported by zeffi, the "show_points" option was not working in master.
It probably broke recently, after some changes meant that the point sizes
weren't geting set prior to drawing these points anymore. Since this was
originally added as a debugging tool (though it is now somewhat redundant
due to the stroke editing functionality, which uses/exposes the same points),
this option wasn't really that important. I have decided to add back a toggle
for this to the UI though, since it can be used for some interesting effects...
A new function (RunPythonCallBackList) to call all python functions
contained in a python list was developed.
This function has:
- first argument is the python list of callbacks
- second argument is a python list of arguments
- third argument is the minimum quantity of arguments
- forth argument is the maximum quantity of arguments
It improves flexibility and supports *args.
Reviewers: moguri, dfelinto, campbellbarton, sybren
Reviewed By: campbellbarton, sybren
Subscribers: sybren
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1102
Rename calc_flatten_center to calc_area_center,
since theres no 'flatten' spesific logic there.
Also refactor calc_area_center, calc_area_normal, calc_area_normal_and_center
so they're next to eachother - they're almost the same,
having them scattered about isn't helpful.
A Python API for the collision group / mask has been added:
```
KX_GameObject.collisionGroup
KX_GameObject.collisionMask
```
The maximum number of collision groups and masked has been increased from eight to sixteen.
This means that the max value of collisionGroup/Mask is (2 ** 16) - 1
EndObject will now activate objects that were sleeping and colliding with the removed object.
This means that, unlike now, if a rigid body starts sleeping on top of another object, when the latter is removed the rigid body will activate and fall, rather than float midair as before.
Collision groups that do not intersect used to collide on the first frame. Now this has been fixed so that they collide appropriately.
Thanks to agoose77 for his help.
Reviewers: scorpion81, hg1, agoose77, sergof
Reviewed By: agoose77, sergof
Subscribers: sergof, moguri
Projects: #game_physics, #game_engine
Differential Revision: https://developer.blender.org/D1243
Flush edits only when saving global undo. This will stop freeing of PBVH
in sculpt mode, which introduces some pretty severe freezes, especially
in dyntopo. For global undo we flush the contents of the global undo
buffer which does not include localized edits of sculpt/edit mode, so
those data will not get saved anyway.
New Check option "Show Shadow Box" in shadow panel of sun lamp to get
feedback about which objects project shadows.
Minor tweaks by Campbell Barton and Jorge Bernal
Reviewers: moguri, sybren, kupoman, dfelinto, lordloki, campbellbarton
Reviewed By: lordloki, campbellbarton
Subscribers: sergey, lordloki
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1149
This option makes it so BVH does not use pre-aligned storage for triangle vertex
coordinates which was originally needed for faster coordinate lookup when doing
triangle intersection test. This array gives up to 10% performance comparing to
fetching individual coordinates but it also used 12 floats per BVH primitive,
which might translate to quite huge array in a complex scene.
Intention of this option is to investigate if this is a right direction to make
gooseberry files being able to render on local farm which is not totally great
in memory.
Current approach is not totally cheap, meaning even the case with the storage
enabled might be slower, but currently it's within 1%.
The layers in Blender are using a bit field for the 20 layers. The light layer value was limited to 20, so the highest usable light layer was five.
The patch modify the range and add layer out of range error messages.
Reviewers: sybren, hg1, moguri
Reviewed By: hg1, moguri
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1238
Combine all the highpoly pixel arrays into a single array with a lookup
object_id for each of the highpoly objects.
Note: This changes the Bake API, external engines should refer to the
bake_api.c for the latest API.
Many thanks for Sergey Sharybin for the complete review, changes
suggestion and feedback. (you rock!)
Reviewers: sergey
Subscribers: pildanovak, marcclintdion, monio, metalliandy, brecht
Maniphest Tasks: T41092
Differential Revision: https://developer.blender.org/D772
This was half-broken even in 2.74 (if you were using compositor), multiview did us the favour of breaking this for all cases (you are welcome).
It is all working now.
This approach gets rid of iuser->pass for good.
Also, I'm commenting out the pass increase/decrease. This was broken
since multiview. I will fix it later (before 2.75), but I didn't want to
get this patch mangled with that fix.
Thanks Sergey Sharybin for the review and feedbacks.
Reviewers: sergey
Differential Revision: https://developer.blender.org/D1232
This works like the existing effectors when using "surface" mode: It
selects the closest point on the mesh surface and creates a force based
on distance and falloff.
Unlike the old effectors it also supports signed distance, based on
the surface normal, which gives more control over the allowable distance
of strands to the mesh surface.
While investigating T44412, I noticed some weirdness going on when trying to
draw on frame 0 (i.e. strokes were getting added to frame 1 instead). Clearly,
this seemed like an off-by-one error related to clamping to prevent negative
frames which was also excluding frame 0.
This commit reverts the fixes made for T36831 in:
rBf18f2fbb33d90ecc91e6f3d063cb9f97f217e808
After thinking this over, I think these checks against drawing on negative
frames aren't needed. Even if the current userpref setting doesn't allow
navigating to negative frames, this may not be true for other users that
may work on the same file (in a team environment). Also, negative frame
values can get set via the dopesheet.
cached group itself.
This allows using the dupli group objects themselves as force fields,
in particular for collision objects in strand simulation. Without this
feature only the original objects of are recognized by the effectors
system, and even if duplis worked properly their settings would not be
accessible due to linking and dupli group hiding. The cache modifier
circumvents this issue by providing a new force field system, separate
from the current effectors.
A few weeks ago, I got a random crash while testing som edge cases
(IIRC, it was trying to assign an action with no active object),
which I haven't been able to reproduce since then. This commit though
adds some extra sanity checks here, as a user may try to assign an
action to an animdata block which did not have an action already.
Increased the upper bound for the "Rest Length" property to cope with metric
units, especially when large (i.e. > 2 m) distances are involved. It may be
necessary to increase this again in the future, if even larger distances get
used (though it then starts getting a bit difficulty to justify such setups).
Looks like the droidsans hebrew font we used back in the days had some kerning bug or so...
Updated with latest version from Debian Testing repo, works nice now.
These classes were used previously to write parts of the Blender DNA
directly to Alembic. Their code is shared with other classes that are
still in use, so none of the really substantial parts have been deleted.
This only removes trivial C function wrappers for parts of the C++ code
that are not used directly any more from outside the bl_pointcache
library. Some internal parts may be removed later, this cleanup is
mostly to reduce code noise.
Using two full scene nodes for render/realtime data creates a lot of
duplication in both storage and processing time. Instead storing
specific data types like meshes in different versions keeps duplication
to the necessary minimum and allows easier fallback where available.
"Frequency" parameter is renamed to "Skip" in the LogicBricks sensors as it represents skipped frames between pulses.
Naming something (frequency) the exact opposite of what it represents (period) was the worst choice.
Also, a new BGE python attribute 'skippedTicks' was introduced. 'frequency' attribute is maintained but deprecated.
Internally, freq variable is used yet at DNA_Sensor to maintain compability and to avoid do_versions.
Thanks to Sybren for the investigation.
{F162440}
Reviewers: campbellbarton, sybren, moguri, hg1
Reviewed By: sybren, hg1
Differential Revision: https://developer.blender.org/D1229
Logical predicates AndUP1D and OrUP1D were instantiated even with an empty
list of unary 1D predicates, causing an exception in the constructors of
the logical predicate classes.
This is a regression made in b408d8af31.
Tessellation data isn't used for drawing or sculpting.
This frees up some memory ~approx 10% in own tests.
Also slight spee-up since it avoids calculating it in the first place.
There used to be quite huge 3D arrays stored in memory which are only needed for
simulation steps and not used at all if the smoke is baked to file. That memory
is unmanaged by blender and not visible in the info space header and in practice
they could easily be gigabytes for hires smoke.
This commit only addressed hires smoke since it's the more important at this
point, and non-hires smoke wouldn't have such noticeable benefit.
In the case of tornado file it gives around 20% memory saving (which is about
26GB vs. 33GB on later frames of 01.03.02.A3 shot.
In the BGE you can't create a subclass with more than 1 argument like : "player = Player(owner, 10)"
I have modified the py_base_new to check only the first argument of args tuple.
Now we can do :
class Player(types.KX_GameObject):
def __init__(self, gameobj, life):
print("create new player :", self, ", life :", life)
player = Player(own, 50)
This means no motion state data is generated for render mode, this
requires some larger changes to the way render/realtime data is stored
in the caches.
Before this the hair sim would be applied indiscriminately to all the
strands in the cache data. Now an object/psys combination from the dupli
cache must be selected. Note that this is not the actual target of the
hair simulation, which still operates on the cache overrides instead.
The Object/Psys only functions as a selectable key, if no matching data
is found in the cache no hairsim will be applied.
Pinch would give a flat result on either side of the stroke,
because points were dragged towards a single point.
Now pinch is projected on the sculpt plane, which gives a tighter crease.
The reverse is true too - blob brush which shares the code is also more curved.
This time roll back to originally discussed in the code review page approach
with simply bumping UI range for the property.
It's still not totally free from forward compatibility breaking (which is
already broken comparing to previous release) but at least it'll keep files
working inbetween of git blender versions in cases random factor was not
set above 2.0.
Differential Revision: https://developer.blender.org/D1214
This way we can get rid of inefficient memory usage caused by BVH boundbox
part being unused by leaf nodes but still being allocated for them. Doing
such split allows to save 6 of float4 values for QBVH per leaf node and 3
of float4 values for regular BVH per leaf node.
This translates into following memory save using 01.01.01.G rendered
without hair:
Device memory size Device memory peak Global memory peak
Before the patch: 4957 5051 7668
With the patch: 4467 4562 7332
The measurements are done against current master. Still need to run speed tests
and it's hard to predict if it's faster or not: on the one hand leaf nodes are
now much more coherent in cache, on the other hand they're not so much coherent
with regular nodes anymore.
Reviewers: brecht, juicyfruit
Subscribers: venomgfx, eyecandy
Differential Revision: https://developer.blender.org/D1236
when not needed.
The pathcache data is only required in the first frame to construct the
child strand shapes. For subsequent frames the children are calculated
using the initial shape and parent deformation, so particles don't need
to recalculate all the time.
This gives a significant performance increase of the baking process when
using a lot of complicated child hairs.
The basis for this optimization is that child strands have a shape that
does not actually change over time: the particle code does not enforce
this formally, but in fact all the clump/kink/roughness algorithms take
great care to not introduce changes of shape over time.
The final look of child hairs is achieved only by following the parent
hair deformation, i.e. by applying the offset of the matching parametric
position on the parent strand.
This means that for caching child strands it is sufficient to store the
full vertex data only in the first sample, and then apply the parent
deformation on subsequent frames using only the animated root matrices.
In test cases this seems to reduce the cache size to something between
10-20 % of the original size (down to some hundred MB from some 10 GB).
Further optimizations could be achieved by using smaller data types,
such as quaternions instead of 3x3 or 4x4 matrices for the remaining
child data.
Use tagging to avoid re-evaluating the same edges while sculpting.
While gives only minor speedup,
it allows for changes to the queue without additional redundant checks.
There should be no functional changes visible from this change, but this commit
should make it easier to code tools which need to check on tweeakmode status,
by making it easier to figure out which NLA Track contains the strip which
owned the action being edited. (The strip is already saved, so this commit just
adds the track alongside it).
For now there is no version patch for this. The worst that happens is that an
extra refresh is needed in the NLA editor to get these to show up.
With multiple strips in tweakmode, only the one tagged as being "active"
would get drawn in the correct colours, while all the others would just
get drawn as a selected strip instead.
When entering tweakmode on multiple strips (from different AnimData blocks)
simultaneously, only the track containing the last selected strip would be
shown. All the other tracks with strips being tweaked would not appear at
all.
To help make it more convenient to edit stashed actions, Shift-Tab
(i.e. holding down the Shift key, which "tabbing" into tweakmode as
usual to edit the action referenced by the active NLA strip) now flags
the NLA Track that the strip occupies as being "solo" too.
This allows you to use the NLA to select a stashed action, then Shift-Tab
to start editing it without any other actions in the NLA stack interfering.
Like the "Next/Previous Layer" tools in the Action Editor, this is designed
to help with checking on stashed actions.
editors.
Reporter used a hacky work-around by placing cursor at end of keyframe
range and doing ctrl-C ctrl-V repeatedly. This was working on 2.73 but
not anymore since the old selection is not kept.
Much better is to have duplication operator be repeatable. This commit
takes care of that.
Normal dragging now uses a precision of 0.01 instead of 0.1, shift+dragging now uses 0.001. (0.1 steps can still be done using ctrl)
Requested by @venomgfx
Transforming the center after transforming a handle would continuously
flush an extra offset to the handles.
Also use normalization range of -1.0 to 1.0 instead of -0.5 to 0.5 (not
really important, just for better comparisons)
Dyntopo can currently create skinny faces,
especially when the faces are much larger then the resolution.
To get the old behavior, set debug value to 1234
Use actual available number of threads now, which will make it easier
to increase max number of threads, without having some sloppy memory
usage and without doing some redundant checks on thread data which was
never used.
Allocate statistics array dynamically, so increasing max number of threads does
not increase sloppyness of the memory usage.
For the further cleanups: we can try alloca-ing this array, but it's also not
really safe because we can have quite huge number of threads in the future.
Plus statistics will allocate memory for each individual entry, so using alloca
is not going to give anything beneficial here.
The issue was caused by phase being limited from 0 to 1, which gave only
0..M_PI distribution which is not good enough for good randomness.
Now the phase is being randomized across full 0..2*M_PI range.
Particles use 0..100 range for parent particle "times" (curve parameter)
and 0..1 for children. For caches this is now uniformly calculated in
the 0..1 range to avoid breaking child interpolation.
Using ctrl+LMB to collapse all panels except of the clicked one resulted
in an empty area if done from a view that is scrolled down to some
degree. Resetting the view makes this much better, although it still
doesn't work that well if the area is really small, but I don't think
it's worth over-complicating things here.
"Feature-Request" by @maxon ;)
Added keyword arguments to createConstraint.
Changed initial values for the pivod XYZ form 1 to 0.0.
Changed initial values for the axis Z form 1 to 0.0.
Delete the parsing for 4 parameters, because parsing only the X pivot is not necessary, also it was not working correctly (int instead of float).
Reviewers: brita_, sybren, lordloki, campbellbarton, moguri
Reviewed By: lordloki, campbellbarton
Subscribers: campbellbarton
Differential Revision: https://developer.blender.org/D705
In quad-buffer stereo mode, the GE render pass ends with the right eye on the right buffer, but we need to draw on the left buffer to capture the render.
Reviewed By: agoose77, HG1
Was using pointer hashing when the keys are in fact uint's.
Since they're well distributed from the rangetree,
no need to do bit-shifting tricks. just use int as hash.
Gives ~8% speedup in own tests.
caches.
This allows child strands to follow the motion of parent strands as
calculated by the hair simulation. Unlike the particle system path
caching, this method does not regenerate all the children every frame.
Instead, it relies on an initial child setup that defines the base
shape, then applies the parent motion as a weighted linear deformation.
The result is in fact the same as with regular particle clumping, kink,
roughness etc.. Particles also take care to not change the child shape
when the parent moves, but this is not formalized anywhere (which makes
changing particle code quite difficult). So ignoring the particle code
is both permissible and efficient.
The getScreenVect(), getScreenPosition() and modelview_matrixmethod returns an incorrect results if called after the camera has been translated on the same frame.
The model view matrix will be update only once per frame with Cam->SetModelviewMatrix in KX_KetsjiEngine::RenderFrame.
Using GetWorldToCamera as model view matrix to get an actual view matrix even if the camera is moved.
Reviewers: sergey, dfelinto, brita_, sybren, hg1, campbellbarton
Reviewed By: hg1, campbellbarton
Projects: #game_engine
Differential Revision: https://developer.blender.org/D1170
The idea is to avoid having original BVH and BVH packed into scene BVH and hence
reduce memory footprint.
This change doesn't give any measurable differences on it's own, but together
with D1215 and D1217 it gives quite nice results.
Reviewers: campbellbarton, brecht, juicyfruit
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D1218
This way memory overhead caused by the BVH building is not so visible and peak
memory usage will be reduced.
Implementing this idea is not so straightforward actually, because we need to
synchronize images used for true displacement before meshes. Detecting whether
image is used for true displacement is not so striaghtforward, so for now all
all displacement types will synchronize images used for them.
Such change brings memory usage from 4.1G to 4.0G with the 01_01_01_D scene
from gooseberry. With 01_01_01_G scene it's 7.6G vs. 6.8G (before and after
the patch).
Reviewers: campbellbarton, juicyfruit, brecht
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D1217
The idea is to give artists a simplier way to control memory usage in such
scenes as grass fields by doing automatic object culling based on whether
they're visible in the frame or not.
This is controlled on per-object level. In order to use this option few
steps are required:
- Allow renderer to use camera culling (Performance panel of render settings)
- Set camera cull margin (measured in relative value to the render resolution)
- Enable Camera Cull for objects which are desired to be culled
(object culling option could be found in Option panel in object buttons).
Interface decisions are not final for sure and to be refined if this
option is considered good enough for production.
Reviewers: juicyfruit, brecht, campbellbarton
Subscribers: venomgfx, eyecandy
Differential Revision: https://developer.blender.org/D1230
Another one of those assert crashes when passing values != than 1 and 0
(in this case the value is -1)
Notes from reviewer:
--------------------
These should really be enums. since valid values are KM_ANY,
KM_MOD_FIRST, KM_MOD_SECOND.
But can see at some point this was changed from an enum so... I guess
this is the only way.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1227
Not much to say, this is pretty straightforward.
We just have to add current locale to thumbnails 'signature', so that
previews get re-generated when we change locale...
Tested with Japanese and French.
Btw, I do not really understand why using BLF in ImBuf is badlevel... :/
BLF_lang_get() shall return 'default' Blender locale (en_US) when translations
are completely disabled!
Also, add BLF_translate() and BLF_translate_do() to allow translating some strings
outside of label/tip context, but still only when i18n global flag is enabled.
(Partial) backport from asset-experiments branch.
Reorganization: previously we could recompute name/path of thumb file two or three times,
now added lower-level internal functions that take those as parameters, so in most case
they are computed only once. Very minor optimization, but simple too.
Also, path of file to preview is now decoupled from path used to generate its URI
(and hence thumbnail path). In asset-experiments branch this is needed because
we also handle datablock previews in/as thumbnails (file_path is .blend path,
URI is .blend path + datablock 'path').
Here this will be needed for same kind of reason - once translated, font thumbnails
need to be re-generated when we change current language...
popup and clipboard output.
For a production-size archive the info string can become really large,
and putting it into a buffer takes a long time. As a debugging tool the
stdout printing is sufficient for now and can be done as a stringstream.
This commit fixes two different issues actually:
* When view name is unknown/irrelevant, you should pass a NULL str pointer to
`RE_RenderLayerGetPass()`, not an empty string!
* `render_result_rescale()` would unconditionnaly free re->result (at the end),
even if it did not replaced it at all, leading to freed memory access later.
This is only a partial fix though, "CacheBuffer" (i.e. saving tiles in EXR files)
shall not be used in 3DView rendering, and yet it is here...
Arbitrary wind force "density" factor has been moved out of the force
function now, so cloth simulation can do this on it's own without
affecting the strand sim.
In addition to the original particle hair sim settings the parameters
for strand sim have a curve to define the strength of goal springs along
strands. This useful because currently there is no way to override the
weights of strands. This would require a new particle edit mode that can
work with non-particle data in a sane way ...
This was causing glitches when switching from/to fullscreen modes (e.g.,
side by side to anaglyph).
As for the quadbuffer errors this is part of a more complete solution to
be committed later.
This takes an arbitrarily large amount of space in the UI and does
currently not have a good purpose.
Eventually this information could be displayed in a dedicated part of
the UI, with proper scrolling.
That was really crappy indeed. Now we have a separate API
for low level OpenGL programs, plus a nice interface for GPU, also
removes some GL calls from main code as a plus :)
The source for the programs is also moved to nice external .glsl files
(not sure which extension convention GPU assemply uses)
This code works much like the main object drawing code and has to take
the same precautions regarding replacing the derivedFinal pointer in
Objects. This pointer may be replaced during drawing calls, regardless
of the "ownership" indicated by needsFree.
Trying to access rl's from full samples in non-full-OSA context (with uninitialized
sample index even :P ).
Caused by rBd5f1b9c2, probably a copy/paste typo or so.
Issue here is simple and has been fixed in other places such as
texpainting: Basically if face has different winding, do not calculate
it as adjucent to the other face, even if UV is identical.
This allows us to stack islands of symmetrical closed meshes on top of
one another and still be able to select the two identical island halfs
(provided the normals are correct of course).
Reading from an empty object in Alembic will throw an exception, which
is not easily handled yet. So rather avoid annoying crashes the clumsy
way for now.
The code for syncing Strands and StrandsChildren data to Cycles curves
is almost identical, so to avoid code duplication a little templated
traits type has been defined, which provides the appropriate accessors
for both cases. This is very local and should not be too confusing.
This creates child strands along with the parents. These are not yet
deformed by parents or simulation, and are also not written back into
subsequent caches yet.
data.
Child strands have their own struct type for vertices and curves to
avoid unnecessary overhead (parent curves store a full 3x3 matrix after
all).
Child strands may be constructed from particle pathcaches, or read from
curves data in alembic files.
These are dummy values currently. The UV and vcol values will be stored
in strands directly, unlike particles which evaluate them every time;
this is a much safer and more efficient approach that makes strand data
truely independent from the "emitter" mesh. Such data will be made
available later, primarily for child curves.
On windows empty dirs are completely empty - no par or current entries
are listed either, in those cases artificially add those.
Furthermore, stat on UNC paths do not support current/parent 'shortcuts'
(i.e. things like '\\SERVER\foo\bar\..' do not work), so we have to hack
around that mess...
This should ensure us we always do have valid parrent entry...
Still buggy, but the basic workflow is there:
When a cache library is used in conjunction with a group duplicator and
it has strands that match the particle systems, Cycles will use the
new Strands structure to construct its internal curves.
This is not strictly needed because the strands data is only created
at runtime at this point. However, it might be useful to later include
this in blend files.
Also the C++ RNA API has a bug that makes non-DNA collection properties
difficult (the length function is not implemented properly).
The issue was introduced in rB4b685e1 and it appears some crazy area still
accesses particles for render after deleting it's render data, which broke
viewport/render behavior.
This commit restores previous G.is_rendering logic and adds corresponding
checks to cache construction, so counting is all consistent.
Goes to the TODO list to either replace G.is_rendering with eval_ctx or to
make it so psys->renderdata always exists during render sync.
The issue was caused by bevel object being automatically added to the scene graph
by dag_get_node() and had no incoming relations, even form the scene. This confused
scene update flush logic.
Now there'll be a scene relation added to such nodes, so they're always reachable
from the root node.
Issue was caused by MSVC not being able to optimize some code out in the same
way as GCC/Clang does, so now that parts of code are explicitly unfolded in
order to help compilers out.
This makes speed loss much less drastic on my laptop. That's probably as good
as we can do with MSVC without investing infinite amount of time looking trying
to workaround the optimizer.
Was only handling failures in video thumbnails, was confusing (giving two different types
for video files, *sigh*), and... useless, since thumbnail code already handles smartly
failures in preview generation!
particles.
This is currently the same as the ParticlePathcache writer class, but
will be modified somewhat later to store additional information such as
parent weights. The purpose of this cache object is not to populate the
particle child caches, but to store renderable data associated to dupli
cache strands.
This is a separate struct to avoid storing unnecessary data (this means
a bit of code duplication for iterators). The child strands can be used
as the actual render data, while the parent strands usually would be
used only for simulation/deformation purposes.
We need to avoid passing a NULL string here, and also we need to pass
the correct suffix we used to pass view string directly which is
probably not what we want.
Fix of T36285, I just invalidate projection matrix when a camera switch
to viewport mode, because we need to rewrite the projection matrix in
RenderFrame.
It worked with old blender version because when you use viewport render
one camera is added in the camera list and initialize its projection
matrix for the first time. But when we used several cameras + viewport
for splitscreen we had issues.
Reviewers: dfelinto, hg1, ben2610, lordloki, moguri
Reviewed By: moguri
Projects: #game_rendering, #game_engine
Differential Revision: https://developer.blender.org/D1202
* The breakdowner tool will no longer operate directly on properties
of type "enum", as this doesn't make sense most of the time. This
is still not much use though when custom properties (ints) are used
to drive some underlying enum property though (as in blenrig)
* The breakdowner no longer tries to perform any blending if the
start and end values are the same, to avoid float precision issues.
D1002 by @plasmasolutions, with own refactoring.
Note, needed to do a bad-level call here (IMB -> BLF)
Also can't use the BLF API directly because its not thread-safe.
So keep the function isolated (blf_thumbs.c).
* Don't grey multiview options in file browser and in Node Editor Properties out if multi-view is disabled, hide them completely (I think greying out single buttons is fine, but in case of entire blocks we should just hide to save space)
* Move multiview settings in Node Editor Properties above alpha settings to prevent the alpha buttons from appearing above multiview settings if multiview is enabled and Stereo 3D format is chosen (making them appear below is much nicer)
I found this while investigating why the backdrop shows 'blank' while I
update a node influence factor. This problem still persist, but maybe it
was there before multiview. In release it is not noticeable, but in my
debug build is quite evident.
There are a few things here which are not so nice:
* Position of proportional edit circle is not centered on data
(difficult to predict positions here since those are completely custom,
will probably be positioned at center of area later instead)
* Result is flushed to curve handles only at the end of the transform,
so if people have the graph editor open they will see handles lagging behind.
This matrix is needed to create a stable and smooth coordinate system
along the strands, for things such as bending forces and child hair
deformation. The base matrix is defined on the "scalp" mesh and should
be stable wrt. deformation and animation of the mesh. For any point on
the strand a matrix is then calculated using parallel transport, i.e.
by rotating the base matrix successively along each curve corner.
This patch adds a new API function to get the actual display dimensions in pixels.
Reviewers: dfelinto, sybren, lordloki, moguri
Reviewed By: lordloki, moguri
Differential Revision: https://developer.blender.org/D648
The overall world space matrix for dupli sims has to be the combined
obmat of the cached object as well as the duplicator for the dupligroup
instance. The cached strand data is generally in object space, so the
matrix has to be applied to get all the forces and interactions right.
This compensates the transformation of the dupli instance being cached,
so that forces such as gravity are in the correct reference frame.
Note that this does not yet generate fictitious forces resulting from
a moving and/or accelerated frame of reference. For this we would also
have to calculate linear/angular velocity and acceleration of the dupli
object.
stupidity casting from Scene to Editing in RNA)
Move versioning for proxy storage to multiview version check (not really
correct but it was orphaned before and it doesn't hurt either).
This is the first actual drawing/display setting for smoke, so a new
panel "Display" has been added to give it a home in the UI.
The name "thickness" has been chosen deliberately to distinguish it from
density, since the parameter only affects OpenGL drawing but not the
actual physical density values.
The strong stretch forces lead to awkward lengthening of segments when
the damping factor is too high.
In fact, in a natural hair strand the stretching usually means the hair
itself is curly and stretches as a helical spring. In that case
the damping is quite small compared to the stiffness, and little energy
is lost to the stretching (the hair becomes "bouncy"). When the hair is
very stiff the damping should also be small in order to avoid extreme
forces resulting from the hair root location constraint.
Our current keymap doesn't give us enough room to make such changes in
the event system. To fix small issues caused by this, we would need to do
drastic changes in Blender's keymaps and internal handling. It was worth
a try, but it didn't work.
I can write down a more descriptive statement in a few days, but for now
I need a break of this stuff.
The solver can calculate the de-facto velocity of the root using the
difference of the already-updated vertex location and the state from the
previous step.
Issue was caused by mismatched logic in counting child/parent particles in
job initialization and actual job execution. Confusion here came from mixed
usage of psys->renderdata and G.is_rendering.
We need to get rid of G.is_rendering and use eval_ctx if it's really needed,
but we also might just use psys->renderdata check since it's expected psys
to have this structure anyway.
Speedup is non-linear, 2x-10x faster is quite normal.
Patch T43678.
- Switched from an Octree to BVH.
- Finding first points of surface no longer "wastes" density function evaluation: every result is cached.
- Use MemArena instead of using own memory management.
- Correct calculation of metaelem bounding box.
- Remove mball_count(): mballs are now counted "on the go".
* Revert 776bfa64a5 and c3dad7953a (some X11 systems are doing
stupid things forcing me to do an extra check that completely breaks the
click type handling on other systems using the slightly changed
implementation from those commits - see T44278)
* Fix sample lines in Compositor+VSE
(And yes, this time I tested on both of my systems to make sure
everything is fine)
Originally we thought it's needed in order to distinguish builtin file from
filename which starts with '@', but the filepath is actually full path there
and it's unlikely to have file system where '@' is a proper root character.
Surprisingly this does not give visible speed differences, but it's still
nice to get rid of redundant check.
KX_Scene::addObject: Changed the parameter "other" to "reference", as "other" doesn't mean anything.
KX_Scene::AddReplicaObject: Changed the parameter "parentobject" to "referenceobject", as the parameter did NOT contain a parent object in any way.
Now both functions use the same kind of name for the same thing.
Thanks to panzergame / Porteries Tristan.
There were two major problems with the interactivity of material previews:
- Beckmann tables were re-generated on every material tweak.
This is because preview scene is not set to be persistent, so re-triggering
the render leads to the full scene re-sync.
- Images could take rather noticeable time to load with OIIO from the disk
on every tweak.
This patch addressed this two issues in the following way:
- Beckmann tables are now static on CPU memory.
They're couple of hundred kilobytes only, so wouldn't expect this to be
an issue. And they're needed for almost every render anyway.
This actually also makes blackbody table to be static, but it's even smaller
than beckmann table.
Not totally happy with this approach, but others seems to complicate things
quite a bit with all this render engine life time and so..
- For preview rendering all images are considered to be built-in. This means
instead of OIIO which re-loads images on every re-render they're coming
from ImBuf cache which is fully manageable from blender side and unused
images gets freed later.
This would make it impossible to have mipmapping with OSL for now, but we'll
be working on that later anyway and don't think mipmaps are really so crucial
for the material preview.
This seems to be a better alternative to making preview scene persistent,
because of much optimal memory control from blender side.
Reviewers: brecht, juicyfruit, campbellbarton, dingto
Subscribers: eyecandy, venomgfx
Differential Revision: https://developer.blender.org/D1132
Official Documentation:
http://www.blender.org/manual/render/workflows/multiview.html
Implemented Features
====================
Builtin Stereo Camera
* Convergence Mode
* Interocular Distance
* Convergence Distance
* Pivot Mode
Viewport
* Cameras
* Plane
* Volume
Compositor
* View Switch Node
* Image Node Multi-View OpenEXR support
Sequencer
* Image/Movie Strips 'Use Multiview'
UV/Image Editor
* Option to see Multi-View images in Stereo-3D or its individual images
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
I/O
* Save/Open Multi-View (OpenEXR, Stereo3D, individual views) images
Scene Render Views
* Ability to have an arbitrary number of views in the scene
Missing Bits
============
First rule of Multi-View bug report: If something is not working as it should *when Views is off* this is a severe bug, do mention this in the report.
Second rule is, if something works *when Views is off* but doesn't (or crashes) when *Views is on*, this is a important bug. Do mention this in the report.
Everything else is likely small todos, and may wait until we are sure none of the above is happening.
Apart from that there are those known issues:
* Compositor Image Node poorly working for Multi-View OpenEXR
(this was working prefectly before the 'Use Multi-View' functionality)
* Selecting camera from Multi-View when looking from camera is problematic
* Animation Playback (ctrl+F11) doesn't support stereo formats
* Wrong filepath when trying to play back animated scene
* Viewport Rendering doesn't support Multi-View
* Overscan Rendering
* Fullscreen display modes need to warn the user
* Object copy should be aware of views suffix
Acknowledgments
===============
* Francesco Siddi for the help with the original feature specs and design
* Brecht Van Lommel for the original review of the code and design early on
* Blender Foundation for the Development Fund to support the project wrap up
Final patch reviewers:
* Antony Riakiotakis (psy-fi)
* Campbell Barton (ideasman42)
* Julian Eisel (Severin)
* Sergey Sharybin (nazgul)
* Thomas Dinged (dingto)
Code contributors of the original branch in github:
* Alexey Akishin
* Gabriel Caraballo
It is still possible to free a bit more memory by detecting buildin images
which are not used by shaders, but that's not going to improve memory usage
that much to bother about this now.
Such change brings peak memory usage from 4.1GB to 3.4GB when rendering
01_01_01_D layout scene from the Gooseberry project. Mainly because of
freeing memory used by rather huge environment map in the viewport.
Reviewers: campbellbarton, juicyfruit
Subscribers: eyecandy
Differential Revision: https://developer.blender.org/D1215
Seems like a fix that is needed for some X11 systems causes this bug on
others :| Not sure if the systems that needed this fix are now still
fine (since I did a slight change to the click type check procedure),
but I need to check that on my system in the institute in a bit.
This attribute is not really supported for volumes, so it get's converted to
constant 0 at shader compile time.
TODO: We should consider doing the same for tangent attribute in order to save
some annoying checks at tracing time.
Our own implementation is in fact the same performance as in fast_math from
OpenShadingLanguage, but implementation from fast_math is using explicit madd
function, which increases chance of compiler deciding to use intrinsics.
Just add KM_CLICK to the already sent KM_RELEASE, don't send a new one
for this.
This might help us to get rid of quite some glitches and workarounds \o/
(why didn't this come earlier to my mind? :S)
extruding
More practical description of the bug: extruding with ctrl to use
snapping and confirming the action added another extrusion to the mouse
position.
This was caused from the second event that is now sent if a key release
happens within the click timeout. It triggers the "Extrude to Cursor"
operator since it is called by CTRL+LMB wich is exactly the event that
is sent in this case.
I'm not totally happy with this workaround since it changes the Confirm/
Abort event for all transformation actions to key release which *might*
result in more conflicts (fingers crossed this isn't the case). If this
happens we might need to write some special transformation handling for
extrusion.
This is an example of the difficulties we get from loading too much
functions on the same keys - we need to be careful with that!
This patch is based on some work done in D788 and re-formulation from Beckmann
implementation in OpenShadingLanguage.
Skipping texture lookup helps a lot on GPUs where it's more expensive to access
texture memory than to do some extra calculation in threads.
CPU code still uses lookup-table based approach since this seems to be still
faster (at least on computers i've got access to).
This change gives about 2% speedup on BMW scene with GTX560TI.
It did not preserve stratification too well and lookup-table approach was
working much better. There are now also some more interesting forumlation
from Wenzel and OpenShadingLanguage which should work better than old code.
This will allow debug visualization data to be stored inside caches
along the actual simulation state.
While the regular simulation allows examining simulation data on-the-fly
by stepping through the regular timeline, the new baking mechanism used
for caches does not easily allow simulation data to be visualized frame
by frame. Caching this data will allow adding it to the global sim debug
data.
This would also still be very handy if the baking process itself becomes
more interactive again. Unlike the current simulation progression, the
cached data can be accessed randomly, so scrubbing throught the timeline
becomes possible.
The character motion actuator local movement does not taking account of the object rotation.
It is necessary to rotate the motion vector before adding the local movement.
Reviewers: sybren, lordloki, moguri
Reviewed By: lordloki, moguri
Maniphest Tasks: T42709
Differential Revision: https://developer.blender.org/D1206
For KM_ANY I've filtered out every event that has a click type, although
that was only needed for the additional event sent on KM_HOLD. A bit weird
that this only happened on a few machines though.
This color is currently only displayed in the viewport (when enabling
"Texture" color mode in the Display settings). It will be used for
controlling the smoke color when using particles for smoke emission.
Conflicts:
source/blender/blenkernel/intern/particle.c
source/blender/editors/space_view3d/drawobject.c
source/blender/makesdna/DNA_particle_types.h
source/blender/makesdna/DNA_texture_types.h
source/blender/makesrna/intern/rna_particle.c
After looking into this more carefully, I've found that we do in fact need a dedicate
operator to add some custom logic when trying to unlink an action from the editor/datablocks.
Specifically, this new operator does the following:
1) When in Tweak Mode, it shouldn't be possible to unlink the active action,
or else, everything turns to custard.
2) If the Action doesn't have any other users, the user should at least get
a warning that it is going to get lost.
3) We need a convenient way to exit Tweak Mode from the Action Editor
4) If none of the above apply, we can just unlink normally
This commit implements this for the Action Editor, with stubs for the NLA Editor too.
Those will be fixed next.
This extends the point density evaluation to also store RGB color values
in the array provided by Cycles.
Since internally all Cycles textures are 4-float RGBA textures anyway,
it does not make a lot of sense to store density and color separately.
This could eventually be preferable to avoid unnecessary storage.
Design task: T42339
Differential Revision: D840
Initial implementation proposal: T41867
Short description:
With this we can distinguish between holding and tabbing a key. Useful
is this if we want to assign to operators to a single shortcut. If two
operators are assigned to one shortcut, we call this a sticky key.
More info is accessible through the design task and the diff.
A few people that were involved with this:
* Sean Olson for stressing me with this burden ;) - It is his enthusiasm
that pushed me forward to get this done
* Campbell and Antony for the code and design review
* Ton for the design review
* All the other people that gave feedback on the patch and helped to
make this possible
A big "Thank You" for you all!
Only basic fix, the whole 'dir' field handling needs rework to correctly support
lib stuff (will be done as part of asset-experiment rewriting work)...
All this code is doing way too much filesystem inspection by itself, instead of
reusing flielist.c work - this is stupid, and will completely break with future
asset engines!
We now have a specific flag for that, use it! Note that for all 'search menu' buttons,
there is already a similar behavior, so there is no need to force apply butt in this case
anyway, which means in practice this change only has effect in the single place
it is needed currently - file browser dir/file fields.
In this case (dir field), applying button even on partial matches leads code
to ask to create a new dir, which breaks completely the expected behavior of
completion. And we do not need immediate apply at all here.
Note this is the only 'autocomplete' button not using search menu, so this change
does not affect anything else in UI.
This is basically copied from existing cloth sim settings, with a good
deal of cleanup and sanitization.
Unlike cloth parameters, the damping values are described as relative
to their associated stiffness values for springs. This is much easier
to use in practice and less prone to lead to unstable simulations.
Damping simply works best when the force is in the same order of
magnitude as the stiffness, so having a relative factor requires much
less adjustment on the user side.
When renaming animation channels, the old names are no longer drawn behind the
text boxes anymore. This used to cause problems if the names were long, or
if text boxes were set to have transparent backgrounds.
Thanks to kopias for reporting on IRC.
Made all action management operators use the AnimData-local flag instead of the scene
global one. Technically, this is more accurate and results in less blocking
situations (i.e. another object may be in tweakmode, but because of that, the active
object's action couldn't be stashed).
The main impetus for this though was that the Action Up/Down feature doesn't clear
the global flag, since it is not in a position to do so (since it can't load up
everything to clear it).
TODO:
I'll need to review how this global flag works and/or potentially ditch it (or
perhaps add some better ways to ensure that it stays valid), since while thinking
this over, I've noticed a few problems here. But, for the meantime, this commit
at least makes things more usable here in the short term.
It turned out that the constantly changing width of the datablock selector
made it a pain to use these to quickly toggle between different actions,
as the buttons would keep jumping around, thus leading to errors when
quickly toggling between actions. This way doesn't look quite as great,
but should be more usable.
Now marking NLA Tracks as Solo'd and muting the NLA stack are linked together
when using the Action Layer Up/Down tools. That is, when switching from a NLA strip
to the active action, if the track was solo'd, then the NLA stack will get muted;
and when switching from the active action to a NLA track, if the stack was muted,
the track will get solo'd. This linkage means that we ensure that when moving up
and down the stack, we can continue to check the actions in isolation without things
messing up when you switch to and from the active action.
Also fixed a bug where this wasn't getting applied when going in the other direction.
TODO:
- When we get the rest/reference track support, we're going to need to insert
some calls to flush the restpose values so that values from the previously
used action do not pollute the pose for the new action (if not all the
same controls get keyed across both). For now, it's best to only do this
switching from the first frame.
With this feature, it is now possible to quickly switch between different actions
stacked/stashed on top of each other in the NLA Stack without having to go to the
NLA Editor and doing a tab-select-tab dance, thus saving quite a few clicks. It
was specifically designed with Game Animation / Action Library workflows in mind,
but also helps layered animation workflows.
Usage:
Simply click on the up/down arrow buttons (between the action datablock selector
and the pushdown/stash buttons) to go to the action in the NLA Track above/below
the NLA Strip being whose action is being tweaked in the Action Editor.
Notes:
- These still work when you're not editing the action used by a NLA Strip.
If you're just animating a new action normally, it is possible to use the "down arrow"
to temporarily jump down to the previous action without losing the new action you're
working on, and then use the "up arrow" to get back to it once you're done checking
the other action(s).
- If there are multiple actions/strips on the same layer/track, then only the one
closest to the current frame will be used.
Also renamed StrandSimParams to HairSimParams, since strands are only
the agnostic data structure, while these parameters are specifically
used to simulate hair-like behavior. Other simulations could use strands
but implement completely different kinds of physics (e.g. grass, ropes).
Added translation there, also fixed a stupid bug which was leading most internal
operators to have 'dual' i18n_context (default NULL one and default 'Operator' one).
Halo is not possible when using 'deep' buffer shadow - reflect that in UI.
When not using buffered shadows, switch lamp bufftype to 'regular' on render, as already
done with 'halfway' method.
Allows mattieu's masterplan to keep overdrop at higher sequencer space
and all strips lower.
This won't align text so well though, but will leave it simple and he
can give feedback later.
A nice bug combining all the broken features of blender:
Particles, duplis and multiple scene dependencies.
Fortunately this was solvable: Basically, we need to
make sure derivedmesh for dupli instance is generated before
obmat is overriden. This also makes sense, since no instance
has "true" obmat apart from original. Lazy initialization of
derivedmesh just does not work here (or it -does- work but first
use should be before instance drawing).
Fingers crossed nothing else breaks after this...
This commit is an experiment exploring the relationship between the action
management buttons (i.e. action selector + pushdown/stash, and soon a few others)
and the filtering stuff (i.e. summary, only selected, etc.)
The old ordering meant that the filtering stuff was consistently in the same
place beside the mode selector, meaning that the order was "common stuff, then
editor specific stuff", this was not that great on smaller windows, where there
important stuff was often out of view.
This new order places greater emphasis on the parts which are likely to be more
important. It also allows us to have a better hierarchy/flow; this is especially
because we'll soon introduce a way to specify which datablock "level" the
action comes from, so going from "level -> action -> filters within action" will
make more sense.
sequencer.
Missing snap callback case. Quick patch is to use the sequencer specific
operator instead of generic translate. We really need to support proper
snap/snap options at some point though.
The function to get a list of markers was not clearing the list before it exited
early, and with no way to tell that the method failed, callers could make the
mistake of trusting that the list was now valid (i.e. either full of marker
frames or empty, vs being invalid)
From the various forum threads and the fact that a new addon has cropped up,
it appears that it is not that well known that this tool exists, and that it
can be used solve a very common problem that animators face. Namely:
When you've gone through blocking out your key poses and then realise
that you need to adjust parts of the rig which don't change much, this
tool solves the problem of needing to go through doing grunt-work to
fix all the other keyframes which now need to change as well.
So, this tool is now available in the following two places (in addition to
the existing Pose -> Propagate menu):
* Toolbar - The "Propagate" button will use the default mode (or the last
used mode for each subsequent invocation).
The arrow-button beside this will allow choosing between the different
modes. (NOTE: The UI team may have different thoughts on this, but,
let's give this a try for a while first, to see if this sort of thing works)
* Alt-P - In Pose Mode, this will now bring up a menu allowing you to choose
which mode is used. Since this sort of thing is something that does
get run several times in a row when you need it, having this hotkey
will make it a bit more convenient.
This commit adds a new mode for the Propagate Pose tool. With this new option,
the Propagate Pose will copy the current pose over to all selected keyframes
after the current frame.
For reference, some of the other/existing options are: to copy it to each subsequent
keyframe with the same value (WHILE_HELD - the default), to the next keyframe,
or to the last keyframe.
When in Stroke Edit Mode, an indicator/warning message is now shown in the top-right
corner to make it easier to notice that operations will apply to Grease Pencil
strokes instead.
This function is used in every part of the code, and has been causing
great pain when deleting 15 hours worth of baking in an instant.
The complexity of the code makes it unfeasible to fix this selectively,
so for now simply disallow the code from deleting any of the files.
For selected well-defined cases the deleting can be reenabled later,
e.g. when the user presses the `Bake` button and confirms deletion in
a popup.
* Moved the context handling stuff into gpencil_utils.c
* Moved the datablock and layer operators out into their own file too. Again,
these weren't related to the other stuff that much
* Split the GPencil to Curves operator out into its own file (gpencil_convert.c).
This was quite a massive blob of code (48kb) that was not that related to the
other operators still in that file (gpencil_edit.c)
Caused by changes in 31e26bb83b. This makes it fall back to the old
method if we can't find a screen.
Patch is actually by @LazyDodo with minor edits by me.
This argument was unused and got nicely optimized out. But once it
starts to be using registers are getting stressed really crazy,
causing slow down of render.
Seems like there is currently now way to get the full data path
reliably. So instead of the old "..." this patch just displays
(null) which also isn't really useful.
modification.
The bake operator will now generate output based on the 'source_mode'
setting:
* When the source is SCENE it uses the basic object data as stored in
the Object ID datablocks (DerivedMesh, particle hair strands etc.)
* When the source is CACHE it fills a temporary DupliCache with data
from the cache archive (like it would for the display dupli_cache,
but also supporting render data). This dupli cache is carried over
between frames during baking, which allows modifiers to act as
simulations and sequentially advance motion states.
This commit implements point density texture for Cycles shading nodes.
It's done via creating voxel texture at shader compilation time, Not
totally memory efficient, but avoids adding sampling code to kernel
(which keeps render time as low as possible), In the future this will
be compensated by using OpenVDB for more efficient storage of sparse
volume data.
Sampling of the voxel texture is happening at blender side and the
same code is used as for Blender Internal's renderer.
This texture is controlled by only object, particle system and radius.
Linear falloff is used and there's no turbulence. This is because
falloff is expected to happen using Curve Mapping node. Turbulence
will be done as a distortion on the input coordinate. It's already
possible to fake it using nose textures and in the future we can add
more proper turbulence distortion node, which then could also be used
for 2D texture mapping.
OSL is not currently supported. There's no actual stoppers for support
it, but so far it's not really a priority at this point.
Reviewers: campbellbarton, juicyfruit, brecht
Subscribers: campbellbarton, dingto, eyecandy
Differential Revision: https://developer.blender.org/D1208
It's not that bad because this typo could only caused not really
efficient BVH traversal, causing higher render times. Not as if
it was causing render artifacts.
This works by using the distance in the x axis only (usually artists want to influence nearby
keyframes based on timing, not value). Tweaking handles is the same as tweaking
the central handle. It's a bit ambiguous if proportional editing is really meaningful
for handles but will leave that for artists to decide.
Note that the fixed-function OpenGL pipeline does not support true
strand normals. The shading model used copies the method implemented for
particles, using the edge directions as normals. This is totally
unphysical but at least gives some indication of direction. Viewport
refactor and programmable shaders are needed to make this work nicer.
This is used to prevent empty dupli lists when reading the cache fails.
In that case the duplilist function will now revert to default scene
evaluation.
The issue has been here since we changed drawing code for meshes to use
vertex arrays instead of immediate mode when VBO was off. Basically we
should now always invalidate the GPU objects regardless of the VBO
setting in the preferences.
The bug has been there since 2.73 at least, but what made it apparent
now is that new version resets preferences and as an extension the VBO
flag.
Should be included in final 2.74 release
libraries.
Having a cache archive output in each modifier is not really practical.
Now the cache library has at most 2 file paths. These are used based on
2 associated settings: source mode/path and display mode/path.
* The SOURCE mode determines whether the original scene data is used as
input or a cache archive. If the scene input is used the dupli group
objects will be evaluated as usual with Mesh data, modifiers, proxy
armatures, etc.. With cache input the data stored in a cache is used to
override the scene data instead.
* The DISPLAY mode is essentially a toggle for the whole cache modifier
stack. If it is set to 'source' the respective source data is used
without further modification. If set to 'result' the data from the
output cache archive is used, which can be generated using the bake
operator. During baking the data will be passed through the cache
modifiers to create a variation of the original source data.
Typical error using '->next' member of a freed linked list item. A bit trickier
even here, since we have some recursion...
Trivial fix for nasty crasher, safe for 2.74 imho?
The return type of raise_exc_wheel() is bool, but the method return -1. The compiler will change the return type type to an int. This can cause some problems on 64bit systems.
Reviewers: lordloki, sybren
Reviewed By: lordloki, sybren
Differential Revision: https://developer.blender.org/D1204
It was an issue with what bounds to use for BVH node during construction.
Also corrected case when there are all 4 primitive types in the range and
also there're objects in the same range.
Now the filtering is simply based on the data types that should go into
the cache, instead of selecting each object and component individually.
This is slightly more limited and may need to be revisited again later,
but for the time being it is much less confusing and clumsy. Filtering
by objects can be accomplished by creating groups accordingly. Making
groups specifically for caching is totally acceptable.
ATI driver does not like declaration of gl_FragColor and glFragData in
the same source file (even though only one of the two is ever
referenced), just use one of the two.
and on screen rendering.
Aaaaah, the beauty of driver implementations of OpenGL!
Turns out the problem here is that drivers calculate df/dy differently
in some cases (probably because OpenGL counts y reverse to how the
window system does, so drivers can get confused).
Fixed this for the ATI case based on info we have so far, there's also
the Intel case which will be handled separately (missing info on Intel's
renderer string etc).
Unfortunately we can't really fix this for the general case so we'll
have to haldle cases as they come in our tracker and by adding silly
string comparisons in our GPU initialization module <sigh>.
The draw code was restoring the derivedFinal mesh unconditionally after
drawing duplis. However, the drawing code can in some cases replace the
derivedFinal pointer during drawing (bad!). This then leads to invalid
pointer access.
Fix is to only touch the derivedFinal when it's actually a dupli cache
mesh.
The job invocation should happen only in editors/. Also it makes sense
to modify the bake operator such that it supports both the basic cache
library and an optional modifier output.
The design for this area is in progress anyway, probably the cache
library archive paths will be changed so that there is always one input
and optionally an output path, with all the modifiers working in
sequence.
Theoretically we could write a stitcher that writes only the parts of
the data affected by a modifier and simply copies the rest, but this
is much more involved and not necessary at this point.
Unlike the particle hair writer this one does not work with the particle
system data but the new Strands data. This will allow successive
manipulations of cached hair data by first storing the initial particle
grooming data ("hair edit"), read this data from the cache into a
Strands instance, then apply hair simulation and write the result back
into a second Strands cache.
Cache baking means the cache modifier should read input caches over the
given frame range and produce the correct output for writing into the
output cache file.
Cache modifiers can optionally implement a 'bake' function. This is used
through a bake operator from the cache modifier panel. Baking is
executed in a job, which will help with cancelling bakes and displaying
status info.
Still not ideal but getting closer. Main annoying thing so far is
dependency of Render structure for now. It is used to switch particles
to render mode and could probably also be eliminated.
* Insert Keyframe tool for Dopesheet/Graph Editors needed to be modified to
not try to resolve the paths for NLA Control Curves
* For now, the poll callback to get the "Active FCurve" also works when given
a NLA control curve. They're really the same in most cases, and this should
be fine until one of the channels does something funky.
* Clicking anywhere on the expander collapses it (like for the gpencil one)
* Deleting these curves works now (but has the side effect of turning off
the animated influence/time options too, as it is assumed that when those
are enabled there is a corresponding fcurve)
Using the standard "FCurve" animchannel type didn't work that well for
the control FCurves on NLA Strips, as the paths would not resolve correctly,
and the indentation was wrong. Also, there would likely be issues down the
track with applying NLA mapping. Hence, it's easier to just create a separate
type for this case, and adapt the rest of the code to also consider these (todo).
The "Nla Strip Controls" channel is used to house the per-strip
FCurves for controlling the strip_time and influence properties.
It sits above the active action's first group, at the same level
in the hierarchy as other groups.
TODO: It looks like a dedicated FCurve channel is needed for these
control FCurves, so that we won't accidentally apply NLA mapping
or have these FCurves disabled by the path lookups failing.
Reshuffled order that in which NLA Strip's F-Curves vs its automatic settings are
evaluated so that the automatic settings can always override the custom settings,
since it's not that easy to get things working correctly the other way around.
Logically, it makes sense that this parameter only gets used to describe the action
that the F-Curve actually belongs to (if it belongs to one). Otherwise, it should not
be set at all.
This commit implements proper evaluation + keyframing support for animating influence
and time on NLA Strips (among other properties) by resolving a few long standing issues
which prevented the original design for this from working.
The original design for animating these properties (and/or some of the other settings
on NLA Strips) is that NLA Strips actually have some of their own F-Curves that are
used for animating settings which will affect how they are evaluated. As seen in this
bug report, the alternative of having these animated as part of the stack (which the
strips work above/outside/on-top of) means that glitches can occur.
Although one of the original considerations for why this wasn't implemented earlier
was that introducing keyframes there isn't so clean cut, and causes UI design issues
for how we expose these via the animation editors for editing (NOTE: support for that
is still to come). Another concern is that this sets a precedent for how FModifiers
might get evaluated.
The "Layered" option for auto keyframing will create a new NLA strip if playback
reaches the end of the frame range and jumps back again. The idea is that instead
of overwriting the keyframes you've already made, it will make a new animation
layer. However, this does not work with the "Insert Available Only" option
(which can either be set in the User Prefs, or in the active keyingset), as that
option needs some existing FCurves to tell what it can insert keyframes into.
The "fix" here is to simply not show the offending button in situations where it
cannot be used!
When the active object had no shapekey data, trying to create a new action from the
Shape Keys mode of the DopeSheet would crash. The segfault here was a silly regression
caused by my earlier Action Stashing work.
However, the old (pre-Action Stashing) code here also wasn't that great either.
While it didn't crash, it would still silently create a new action, even if that
could not get assigned/used anywhere. To prevent both of these problems from
happening again, I've added additional null checks, as well as beefing up the poll
callback here to forbid keyframing
This inconsistency drove me totally crazy, it's really confusing
when it's inconsistent especially when you work on both Cycles and
Blender sides.
Shouldn;t cause merge PITA, it's whitespace changes only, Git should
be able to merge it nicely.
This is implemented badly: when using disk caches i reads the *entire*
cache from the disk to create the trail. In the process it also clears
the cached_frames array, which makes it look like the cache was deleted.
Previously makesrna would have generated code expecting DNA structure from
RNA_def_struct_sdna_from() to be passed to it. This was wrong because actual
PointerRNA points to a "parent" structure, making it impossible to add
functions to certain RNA structures.
It so far never needed and we didn't notice this issue, but it's needed for
some ongoing development now.
Input constants are to be connected before removing proxies,
otherwise node groups might give totally different result.
This is a regression and to be put into final release.
dupli cache.
This makes the cache modifier stack work more like actual modifiers:
Each will take the previous result and write it into its own output
file. The last output is the final result used for viewport display.
The functionality was got lost when new compositor system was landed
and it wasn't always clear what's causing the hicucps. Now it's nicely
reported to the stats line.
When using a particle inflow object, there is now an option "Set Color"
which uses particle texture color to override the uniform smoke emission
color.
Particles must have one or more textures with the "Color" influence
enabled (the resulting color can be visualized in the viewport using the
"Texture" display option). The color will then replace the default smoke
flow setting and allows variable color per particle.
Combined with "Strand/Particle" texture mapping this can also be used
to change the particle emission color over the lifetime of particles or
make variable colors for each particle in the system.
Note that this currently does not work with child particles.
This color is currently only displayed in the viewport (when enabling
"Texture" color mode in the Display settings). It will be used for
controlling the smoke color when using particles for smoke emission.
This is a new KX_GameObject attribute that it increments the
possibilities of optimization during the game
Additionally the unused m_bSuspendDynamics variable is removed.
Reviewers: moguri, agoose77, lordloki
Reviewed By: agoose77, lordloki
Subscribers: agoose77, lordloki
Differential Revision: https://developer.blender.org/D1091
For me, weird characters are drawn if IME is enabled but translation
is not set to a supported language.
Could become an utility function if needed later.
AFAIK a few IMEs were affected by this so I guess we can now add a
few more IMEs to the "officially supported" list.
Patch by @randon (thanks again!), minor edits by me.
There are two per-editor settings now, the Per-Strip setting (default)
and the Project setting.
The per strip setting basically uses the previous, per-strip options for
storing the proxies.
The project setting though will use a specified directory for -all-
proxies, or the blend file directory if no directory is given.
This reverts commit ec03ab021f.
Changing this since it looks like Mattieu does not really like the change.
Will be adding another way to tweak the directories
range and extra frames.
Issue here is that the movie backend would unconditionally use the start
frame of the scene instead of the preview frame. Solved by passing an
explicit "preview" argument.
Strictly speaking, the preview argument is part of the renderdata
struct, that is also passed to the code, but when rendering the final
result we want to unconditionally render the full range regardless of
the preview setting of the render structure.
However, OpenGL rendering does use the preview range so we need to
account for that when making those exports.
This is also a nice chance to correct the filenames, which still used
the full range.
The rationale here is that we don't try to replace particle data
temporarily like we do with DerivedMesh. This would be needed for
drawing cached data overrides in the viewport and pass them to renderers
(unless these read Alembic directly) and later for performing dupli
simulation.
This data will be used for dupli simulations later on. Child path
generation could also be done based on this data without involvement of
particle systems.
This feature is mostly useful for the "view selected" operator. It is
also used in the "set origin to geometry" operator, but since the
cache overrides the object geometry anyway the effect may not be what
users expect (which is acceptable).
Note that Cycles currently only supports tessellated triangle/quad
meshes. Alembic PolyMesh generally has ngons, so external tessellation
is required until cycles gets a proper tessellation implementation of
its own.
standalone.
The cycles XML files now can refer to Alembic (.abc) files. This will
call the default alembic reader to read in scene data. Currently it
simply prints the Alembic file structure.
Eventually a proper schema needs to be defined for both xml and abc.
Also care has to be taken to handle potential conflicts between settings
both within xml/abc and between them.
This adds Alembic to the standalone application version of cycles.
Files can be specified as XML or Alembic, or use automatic detection
based on the filename extension.
Currently the Alembic reader just dumps the file structure to stdout
as a test.
This means we don't bluntly store all the data in a group, but use the
selection from the cache library. It also helps to avoid issues with
object visibility which is not yet stored in the cache.
overriden data that is owned by the cache.
This is not at all nice ... Hopefully it doesn't get too complicated to
work around all these drawing code and depsgraph issues, so the code
can be understood and replaced at some point in the future.
Caches now create 2 new roots below the main 'top' object of Alembic:
root and root_render for realtime and render data respectively.
This makes it easy to switch the whole archive to either of the modes
during baking and for constructing dupli caches.
Alternatively individual objects could store hires versions of their
data. This would also be more efficient if the cache contains many
simple objects which don't have 2 different variants. However, such
design decisions are difficult to make at this point and the
implementation can be modifier later.
This is the default now. It should make workflow a lot more foolproof
and convenient, since having only one of these modes active at a time
very easily leads to broken renders and confusing situations.
The problem is mostly due to the complicated way the depsgraph layer
feature is used to handle duplicator visibility. The duplicator is
declared as a child of its group's objects (even though no real
dependency exists!), so that a visible duplicator triggers updates of
invisible group objects, making instances of hidden groups possible.
However, dupli caches have to disable this dependency in order to avoid
unnecessary costly updates in hidden layers which are overridden by
cached data anyway. At the point where these dependencies are created
the evaluation context is unknown though, which means we cannot
distinguish between render and realtime evaluation for the purpose of
cache reading ...
duplis.
Particle systems can not be overridden from caches easily, there are too
many strings attached to the data and code to make this reliable.
Instead, a new simplified data structure for reading hair from caches
will be added, which replaces drawing and rendering of particle data.
The original particle data is not updated through duplis, so is usually
out of sync and should not be displayed.
pointers.
Relationship between CacheLibrary, duplicator Objects and Groups is
difficult. There are a number of somewhat conflicting goals:
- CacheLibraries write out data for objects and dupli groups. Multiple
objects can be stored in the same cache: CL *->* GR
- Objects can override a dupli group with different caches: OB *->1 CL
- As before, each object can be the duplicator for one group: OB *->1 GR
To combine these requirements, the first relationship will be made
indirect. Only the Object -> Group/CacheLib relations are explicit
pointers in the DNA. For finding all objects contained in a cache
library the usual recursive DNA tagging system must then be used.
unnecessary dependencies.
This flag will replace the current "read" mode on cache libraries.
Beside enabling cache reading, it also disables the current "fake"
dependencies between duplicators and their group objects. This is
exploiting the layer visibility mechanism in depsgraph to ensure that
animated group objects get evaluated when used by a visible duplicator,
even when they are not themselves visible. These dependencies cause
group object updates even if the duplicator is using cached results.
To avoid this unnecessary overhead and make caching worthwhile we
rebuild depsgraph without these relations when using the cache instead.
If a duplicator has cached data it will now replace the derivedFinal
mesh of objects with the cached version for drawing.
This is a compromise atm: It would be better to actually draw derived
meshes directly, so that we don't have to modify objects. Then we could
also have multiple different instances of the same orignal object
(in whatever way these might be defined). DNA Objects would then be
totally separate from duplis, but at this point the drawing and render
code makes this unfeasible.
The layout of the Alembic files resembles the DNA structure in Blender:
- On the top level (under the top/root node) there are Abc::Objects for
Blender ID datablocks (currently Object and Group)
- Objects store final data (DerivedMesh) and later simulation results
etc.
- Groups store their full duplilists for instancing. Currently there is
no recursive nesting of groups, since this would limit duplis to
dupligroups and exclude e.g. duplifaces.
On reading the duplilist gets reconstructed and stored in the DupliCache
for a duplicator empty (the group instance). DerivedMesh data is stored
in a hash table for each instanciated object and can later replace
finalDM in drawing and rendering.
Now the base types for readers/writers are not nominally forming the
interface any more (they may be removed entirely later). This makes
possible a cleaner init method directly in the Abc Writer/Reader
classes.
Further work may be required in this area.
This is more in line with how readers work in the Blender Alembic
implementation elsewhere.
Generally, readers are less persistent than writers: they are created
whenever cache results need to be updated (e.g. on frame changes) and
discarded afterward. Writers OTOH stay alive during the whole baking
job, since they keep the references to Alembic Writer instances and can
only be deleted once the writing for that part is done.
Note that the cache stores dupli matrices without the final parent
transform, since it only knows about the group itself. The duplicator
obmat is applied to the duplis after reading the cache.
Now we store duplilists entirely inside a single alembic object for the
group. This allows using all the generated duplis, which would be
difficult if the alembic file had to define all the possible recursive
dupli relations that Blender allows, beside straightforward Group duplis.
Uses the duplilist generated by Blender to define instances, instead of
recreating the group layout. This omits some information about actual
structure of the DNA, which might be useful later on. The main problem
is that the duplilist itself does not encode this, so it's a tradeoff
between either including the Group structure or omitting the other
dupli types, like face, vertex, particle duplis.
creation call.
This is executed *a lot* (even for simple things such as viewport
panning), so the code is probably not suitable in this form. At least
it could do a frame comparison to avoid unnecessary updates.
This is necessary for the current viewport drawing and rendering code,
which expected each dupli instance to represent a copy of data in the
DNA.
The code maps base-level objects in the cache to DNA Objects inside the
dupligroup by name. Only objects that can be found in the blend data
will be allowed for DupliObjects.
This is a placeholder for proper depsgraph integration. Eventually frame
changes and some other updates should rebuild dupligroup caches
automatically using the depsgraph. Until then this operator is a quick
way to test the IO from caches and the further drawing and rendering
(TODO).
BKE (DerivedMesh, particles, cloth).
The new cache implementation will be used for constructing dupli data
instead, bypassing the complexities of the modifier stack.
Conflicts:
source/blender/blenkernel/intern/cloth.c
source/blender/blenkernel/intern/particle.c
source/blender/blenkernel/intern/particle_system.c
Conflicts:
source/blender/blenkernel/intern/particle.c
source/blender/blenkernel/intern/particle_system.c
Alembic caches.
This creates representations (Abc::Object) for Blender Object and Group
datablocks in the Alembic files and uses Alembic instancing to define
the dupligroup hierarchy. This leads to a relatively flat hierarchy in
Alembic files:
Top -> Object/Group -> DerivedMesh/Particles/Hair/Cloth/Smoke/...
The dupligroup structure can not be represented by a hierarchical
structure such as the Alembic object nesting, because of the
many-to-many relationship between objects and groups (a group can
contain multiple objects, multiple objects can instance the same group).
Instead we use the instancing feature of Alembic to represent
dupligroups. This is created in 2 stages to ensure all the main ID
blocks have been serialized before creating references.
This is not clearly documented for Alembic, but apparently properties
inside compounds still need to be name uniquely for the whole object.
This is somewhat involved for Blender's CustomData, because we have
5 different customdata elements for meshes (vert, edge, face, poly,
loop) and each of these can have the same types and multiple layers of
the same type ...
CustomData layers are pruned by the CDDM_copy function when they have
CD_FLAG_NOCOPY set. This is based on later modifiers in the stack, which
can specify that they require certain data layers - but the caching
modifier itself should store only what is needed by later modifiers.
It means we cannot easily keep a full copy of the DM in the cache
modifier to writing into caches later.
For now the hackish solution is to temporarily disable NOCOPY flags when
copying the DM. This is really not nice and needs a better solution.
This is a skeleton feature that provides a general way of storing
CustomData types. Currently only ORIGINDEX layers are implemented, the
code is designed to make extension easy.
Storing CustomData layers in Alembic is a bit involved because the
complex structs often used as customdata need to be de-interleaved for
Alembic into a set of POD (plain-old-datatype) array properties.
In addition the property names should be unique, so that mapping abc
properties back to customdata layers is safe. This works by using 2
levels of compound properties: the first level stored per CD type
properties, with a number of properties for each layer of this type,
using either a name or index (for unnamed layers). The internal
properties can then in turn be compounds, if structs need to be
serialized into PODs.
Abc property readers/writers are created dynamically for the CustomData
compounds. This is necessary because we don't know in advance what kind
of data layers a DerivedMesh or other CD user will have, and this can
change each frame in theory. Alembic is easier with state data schemes,
but using it this way is possible (if somewhat cumbersome).
This is totally weird and convoluted, no idea if correct.
Conflicts:
source/blender/blenkernel/intern/particle_system.c
Conflicts:
source/blender/blenkernel/intern/particle_system.c
This creates a string with information about all the objects and
properties contained within a (Alembic) archive, used by a cache
library.
The operator has 3 modes of presenting the info string:
- stdout, ie. printing to the terminal
- popup window (not very useful usually due to size limits and lack of
scrolling)
- clipboard copy
result read from the cache.
Mixing this with the output_dm used for writing leads to undefined
situations where the DM was released but should actually be passed on.
This designates a cache library to be used either for the viewport or
for renders. A "Render" cache library will evaluate modifiers with
render settings and a "Viewport" cache library will use viewport
(realtime) settings.
When reading the cache, the library will only be
used for the assigned purpose, i.e. a Render cache does not work for
viewport caching and vice-versa (although a cache can be baked for one
setting and then switched afterward).
Note that render results will never be visible in the realtime viewport
due to the way object evaluation is handled in Blender at this point
(render settings are only evaluated explicitly during renderer sync).
Conflicts:
source/blender/blenkernel/intern/particle_system.c
Conflicts:
source/blender/blenkernel/intern/particle_system.c
out of pointcache into blenkernel.
This is quite simple and repetitive and there is not need to have this
in the main pointcache/Alembic API. The code is mostly concerned with
logic of DNA data, so pointcache shouldn't have to deal with it.
The pointcache library is now pretty much independent from ID blocks and
should not be responsible for handling file paths. The path construction
is also fairly straightforward now compared to the old point cache
system, with only basic conversion of relative to absolute paths for
loading archive files.
python code to unify symbols.
This is necessary because the operator for adding new items (as opposed
to the enable/disable button) cannot be shown with the same checkbox
button. The UI template function can display a custom button for the
operator, so the look becomes less confusing.
This now appends a default extension based on the cache backend used.
At this point this is always Alembic (.abc) but would allow other
backend formats in the future.
In addition to the object name filtering, items in cache library groups
can now be filtered by type as well.
Existing items in the cache are always displayed, so as to not hide
important information (what gets stored in the cache). The filtering
is primarily a utility to simplify searching inside the group for things
that should be added to the cache.
This requires a better design and is not so easy to implement properly
within the limits of RNA definition. These collections don't physically
exist in the DNA, they are mainly utilities for looping over
//potential// items in a cache library. For now the python code has to
be adapted to only show valid items, until the RNA provides a good
solution.
This is also used during the bake process to avoid confusion: The read
flag gets disabled for the baking cachelib, so that objects don't try
to read cache data that is supposed to be generated.
CacheLibrary datablock has a generic unlink function now, but currently
nothing actually links to cache libs themselves, so it's empty. Still
good to keep this in mind for the future.
The `bf_pointcache_alembic` code is a separate library, to avoid
muddling up core code with alembic includes and preprocessor defines.
Alembic stuff only belongs strictly into alembic code and can be
disabled cleanly.
The `bf_pointcache` and `bf_pointcache_alembic` libraries had a circular
dependency, because the alembic implementation functions were called
directly. Now there is a "Factory" class to abstract the creation of
concrete implementations for readers and writers.
`bf_pointcache_alembic` defines this factory and is registered
//outside// of the core `bf_pointcache` lib, so there is no linker
circularity.
This was an artifact from the previous way of mapping non-0 start frame
to time 0.0. Now we start at times > 0.0 to match with the start frame.
Both ways are possible, can be changed later if needed.
Writers were always starting at time 0.0, which means that for start
frames > 1 the readers would always be off. Now match the writer start
frame to the actual Blender start frame.
cache library system.
The Cache modifier is now an optional "break point" of the modifier
stack:
- Without a cache modifier the stack works as before. Baking will write
the final stack result. After baking the cache replaces the whole
stack.
- With a cache modifier the stack result at the modifier's position is
stored. The cache is then applied as the output of that modifier,
skipping preceding modifiers. That way additional modifiers can be
applied on top of the cache.
- When using multiple cache modifiers, only the last (active) one will
be used, since all previous cache results would be discarded anyway.
This can happen if an object gets deleted or isn't loaded for some
reason. The item should just be ignored in that case and removed at the
next opportunity (cleanup function).
of constructing names internally.
This helps prevent name collisions and guarantees a consistent naming
scheme for putting multiple items in the same cache.
refactoring simpler.
Since the new approach is not tied to the old set of point cache data
types there is really no need to carry their empty husks around. Once
the new caching system is defined in detail we can add back whatever
makes sense.
Now instead of each reader/writer creating its own archive, the archive
is created by the caller in advance and passed as a constructor
argument. This means that multiple items can be stored together in the
same archive.
iterating over all objects eligible for caching in the group.
This allows for nested dupligroup instances as well. All objects that
are instantiated at least once by any group can be included in the
respective cache, but get represented only once because the cached data
is the same anyway.
subtype/index.
This omits possible instancing and recursion by dupli groups, but since
the data of instances is always the same in Blender at this point, there
is little need to take them into account for caching.
At some point in the future it may become desirable to store full dupli
hierarchies in the cache, but it doesn't make sense to try to design a
fully-fledged path descriptor for this hypothetical case now.
object group.
This is somewhat experimental, eventually we may want to link to Objects
instead, or allow multiple cache targets for the same cache, etc.
and files.
At it's core this is just a file path, but many different cache users
may refer to this, so having a dedicated ID block helps. It can be
compared to Image datablocks, which also primarily are used for data
on storage, but can be packed with the blend file, and carry some
additional information that would be cumbersome to keep sync'ed
otherwise.
The name 'CacheLibrary' deliberately resembles the 'Library' datablock:
just as a Library stores ID blocks in a physical file, a CacheLibrary
stores cached data (in Alembic HDF5/Ogawa or other formats).
Conflicts:
source/blender/blenkernel/BKE_pointcache.h
source/blender/blenkernel/intern/pointcache.c
source/blender/makesdna/DNA_pointcache_types.h
Conflicts:
source/blender/makesrna/intern/rna_main_api.c
When writing DerivedMesh data, the modifier result at the point of the
modifier will be used for writing to the cache. If this modifier is not
used the derivedFinal mesh is used instead.
The pointcache API is designed to keep the general concept of caching
separate from the concrete Alembic implementation. Other types of file
export/import would be possible, e.g. for OpenVDB data.
Adds Alembic as a dependency and build support in cmake and scons.
Also extends the install_deps.sh script with a temporary installation
procedure for the Alembic libraries. This is still very hackish and
needs to be improved.
Simply check and early return in case we have no source or destination items
(verts/edges/loops/polys) available...
Also, fix an assert in `BKE_mesh_calc_normals_poly()`, when called with no poly.
Basically same as 581afa9da3, but I guess we can assume that scopes added in future
to the image preview may also want to use the viewrect from the original ibuf.
Added some guards to prevent clumping to non existing particles. Also, adjusted threaded child path evaluation, so each child is evaluated once - previously virtual parents were done twice.
This lets users set a start frame at which a cached smoke simulation
starts. This offset is simply subtracted from the current scene frame
for evaluating the cache.
directory is used.
This is done by appending the name of the file as extra folder. Existing
projects may need to regenerate their proxies but it should be possible
now to have all proxies nicely in the same custom folder.
Next commits will include operators to copy directory settings between
selected strips, making the process faster.
Issue was caused by accident in c8a9a56 which not only disabled glossy
reflection if Glossy visibility is disabled, but also Diffuse reflection.
Quite safe and should go to final release branch.
Issue was caused by cycles in shader graph confusing it's
simplification stage. Now we're ignoring links which are
marked as invalid from blender side so we don't run into
such cycles and keep graph code simple.
Issue was introduced in 01ee21f where i didn't notice *_setup()
function only doing partial initialization, and some of parameters
are expected to be initialized by callee function.
This was hitting only some setups, so tests with benchmark scenes
didn't unleash issues. Now it should all be fine.
This is to go to the 2.74 branch and we actually might re-AHOY.
The rationale here is that we don't try to replace particle data
temporarily like we do with DerivedMesh. This would be needed for
drawing cached data overrides in the viewport and pass them to renderers
(unless these read Alembic directly) and later for performing dupli
simulation.
This data will be used for dupli simulations later on. Child path
generation could also be done based on this data without involvement of
particle systems.
For some reason recent change in avoiding non-aligned eigen vectors
was behaving differently for cmake and scons. Made it a bit different
now by storing scalars. This is more robust approach anyway, because
it's not really guaranteed Mat.col() gives a pointer inside data,
depending on column-major vs. row-major storage.
This is to be backported to 2.74 branch.
Transformed 'OrientationHelper' class into 'orientation_helper_factory' function,
which returns an OrientationHelper customized class with specified default axes.
Internal change only,
use UI_BTYPE_SEARCH_MENU with an unlink flag instead.
They are really the same button type, one just happens to have the option to unlink.
This patch will update the 3D viewport if a word value has changed.
This patch does not depends on an other patch, but should applied after https://developer.blender.org/D151 otherwise the the word value viewport update is be slow.
Reviewers: brecht
Reviewed By: brecht
Subscribers: thelasthope, darkxiv
Differential Revision: https://developer.blender.org/D159
This patch can be used to remove the old world bge.render API if the new world API D157 is used.
If the new world API is applied we can remove the old API because the old has newer worked.
The patch keep the two old working methods for backward compatibility.
Reviewers: campbellbarton, moguri
Reviewed By: campbellbarton, moguri
Subscribers: brecht
Differential Revision: https://developer.blender.org/D158
This Patch will add a the world API (mist, background, ambient) to KX_WorldInfo.
The new API uses now attributes.
Reviewers: campbellbarton, moguri
Reviewed By: moguri
Subscribers: klauser, brecht
Differential Revision: https://developer.blender.org/D157
This patch will remove the BlenderWorldInfo and move the source into KX_WorldInfo.
Reviewers: brecht, moguri
Reviewed By: brecht, moguri
Differential Revision: https://developer.blender.org/D156
This patch will fix the color management for the mist and global ambient color.
It will remove the old "Color Management" switch in the BGE "Render > Shading" panel and will use the "Display Device" setting in the "Scene > Color Management" panel instead.
Reviewers: moguri, brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D154
Code clean up for BGE world mist, background and global ambient color.
Move mist render update to BlenderWolrdInfo
Reviewers: moguri, brecht
Reviewed By: moguri, brecht
Differential Revision: https://developer.blender.org/D152
This patch will fix the world GLSL (mist, background, ambient) update for the BGE.
Reviewers: moguri, brecht
Reviewed By: moguri, brecht
Subscribers: panzergame
Differential Revision: https://developer.blender.org/D151
This patch fixes the world (mist, background, ambient) F-Curve for for the BGE.
Reviewers: moguri, brecht
Reviewed By: moguri, brecht
Differential Revision: https://developer.blender.org/D150
This patch adds the missing setMistType() and setMistIntensity() to the API
Reviewers: campbellbarton, brecht, moguri
Reviewed By: campbellbarton, brecht, moguri
Subscribers: campbellbarton, dingto
Differential Revision: https://developer.blender.org/D149
This patch fix the existing word API for mist and global ambient lighting.
Add deprecated message to disableMist()
Add setUseMist(enable).
Reviewers: dfelinto, campbellbarton, moguri
Reviewed By: moguri
Subscribers: solarlune, jta, brecht
Projects: #bf_blender:_next
Differential Revision: https://developer.blender.org/D148
mode.
Yes it will, because those modes stay active. So on user side, expose
depth of field option always (I don't see why not), but disable SSAO in
wireframe/bounding box mode. It is a known limitation that compositing
does not support antialiasing yet, but better give users some more
control.
This could be included in final release but it's not that serious
either.
340b76b42c
Reported by formerly Old_Demon on blenderartists.
Apparently this caused old files to lose their links to material sockets
(noob own mistake from inexperience with node system).
This should either be included in release with version checking being
set to version 2.73 and subversion 10, without tweaking the
BKE_blender.h file
OR
340b76b42c should be reverted for this
release.
Thanks to Lukas for checking this out.
Count line from beginning of the whole shader source instead of each
string sepatately since it helps with finding out the error line in most
tested platforms
This feature is mostly useful for the "view selected" operator. It is
also used in the "set origin to geometry" operator, but since the
cache overrides the object geometry anyway the effect may not be what
users expect (which is acceptable).
Note that Cycles currently only supports tessellated triangle/quad
meshes. Alembic PolyMesh generally has ngons, so external tessellation
is required until cycles gets a proper tessellation implementation of
its own.
standalone.
The cycles XML files now can refer to Alembic (.abc) files. This will
call the default alembic reader to read in scene data. Currently it
simply prints the Alembic file structure.
Eventually a proper schema needs to be defined for both xml and abc.
Also care has to be taken to handle potential conflicts between settings
both within xml/abc and between them.
This adds Alembic to the standalone application version of cycles.
Files can be specified as XML or Alembic, or use automatic detection
based on the filename extension.
Currently the Alembic reader just dumps the file structure to stdout
as a test.
This means we don't bluntly store all the data in a group, but use the
selection from the cache library. It also helps to avoid issues with
object visibility which is not yet stored in the cache.
overriden data that is owned by the cache.
This is not at all nice ... Hopefully it doesn't get too complicated to
work around all these drawing code and depsgraph issues, so the code
can be understood and replaced at some point in the future.
Caches now create 2 new roots below the main 'top' object of Alembic:
root and root_render for realtime and render data respectively.
This makes it easy to switch the whole archive to either of the modes
during baking and for constructing dupli caches.
Alternatively individual objects could store hires versions of their
data. This would also be more efficient if the cache contains many
simple objects which don't have 2 different variants. However, such
design decisions are difficult to make at this point and the
implementation can be modifier later.
This is the default now. It should make workflow a lot more foolproof
and convenient, since having only one of these modes active at a time
very easily leads to broken renders and confusing situations.
The problem is mostly due to the complicated way the depsgraph layer
feature is used to handle duplicator visibility. The duplicator is
declared as a child of its group's objects (even though no real
dependency exists!), so that a visible duplicator triggers updates of
invisible group objects, making instances of hidden groups possible.
However, dupli caches have to disable this dependency in order to avoid
unnecessary costly updates in hidden layers which are overridden by
cached data anyway. At the point where these dependencies are created
the evaluation context is unknown though, which means we cannot
distinguish between render and realtime evaluation for the purpose of
cache reading ...
duplis.
Particle systems can not be overridden from caches easily, there are too
many strings attached to the data and code to make this reliable.
Instead, a new simplified data structure for reading hair from caches
will be added, which replaces drawing and rendering of particle data.
The original particle data is not updated through duplis, so is usually
out of sync and should not be displayed.
pointers.
Relationship between CacheLibrary, duplicator Objects and Groups is
difficult. There are a number of somewhat conflicting goals:
- CacheLibraries write out data for objects and dupli groups. Multiple
objects can be stored in the same cache: CL *->* GR
- Objects can override a dupli group with different caches: OB *->1 CL
- As before, each object can be the duplicator for one group: OB *->1 GR
To combine these requirements, the first relationship will be made
indirect. Only the Object -> Group/CacheLib relations are explicit
pointers in the DNA. For finding all objects contained in a cache
library the usual recursive DNA tagging system must then be used.
unnecessary dependencies.
This flag will replace the current "read" mode on cache libraries.
Beside enabling cache reading, it also disables the current "fake"
dependencies between duplicators and their group objects. This is
exploiting the layer visibility mechanism in depsgraph to ensure that
animated group objects get evaluated when used by a visible duplicator,
even when they are not themselves visible. These dependencies cause
group object updates even if the duplicator is using cached results.
To avoid this unnecessary overhead and make caching worthwhile we
rebuild depsgraph without these relations when using the cache instead.
If a duplicator has cached data it will now replace the derivedFinal
mesh of objects with the cached version for drawing.
This is a compromise atm: It would be better to actually draw derived
meshes directly, so that we don't have to modify objects. Then we could
also have multiple different instances of the same orignal object
(in whatever way these might be defined). DNA Objects would then be
totally separate from duplis, but at this point the drawing and render
code makes this unfeasible.
The layout of the Alembic files resembles the DNA structure in Blender:
- On the top level (under the top/root node) there are Abc::Objects for
Blender ID datablocks (currently Object and Group)
- Objects store final data (DerivedMesh) and later simulation results
etc.
- Groups store their full duplilists for instancing. Currently there is
no recursive nesting of groups, since this would limit duplis to
dupligroups and exclude e.g. duplifaces.
On reading the duplilist gets reconstructed and stored in the DupliCache
for a duplicator empty (the group instance). DerivedMesh data is stored
in a hash table for each instanciated object and can later replace
finalDM in drawing and rendering.
Now the base types for readers/writers are not nominally forming the
interface any more (they may be removed entirely later). This makes
possible a cleaner init method directly in the Abc Writer/Reader
classes.
Further work may be required in this area.
This is more in line with how readers work in the Blender Alembic
implementation elsewhere.
Generally, readers are less persistent than writers: they are created
whenever cache results need to be updated (e.g. on frame changes) and
discarded afterward. Writers OTOH stay alive during the whole baking
job, since they keep the references to Alembic Writer instances and can
only be deleted once the writing for that part is done.
Note that the cache stores dupli matrices without the final parent
transform, since it only knows about the group itself. The duplicator
obmat is applied to the duplis after reading the cache.
Now we store duplilists entirely inside a single alembic object for the
group. This allows using all the generated duplis, which would be
difficult if the alembic file had to define all the possible recursive
dupli relations that Blender allows, beside straightforward Group duplis.
Uses the duplilist generated by Blender to define instances, instead of
recreating the group layout. This omits some information about actual
structure of the DNA, which might be useful later on. The main problem
is that the duplilist itself does not encode this, so it's a tradeoff
between either including the Group structure or omitting the other
dupli types, like face, vertex, particle duplis.
creation call.
This is executed *a lot* (even for simple things such as viewport
panning), so the code is probably not suitable in this form. At least
it could do a frame comparison to avoid unnecessary updates.
This is necessary for the current viewport drawing and rendering code,
which expected each dupli instance to represent a copy of data in the
DNA.
The code maps base-level objects in the cache to DNA Objects inside the
dupligroup by name. Only objects that can be found in the blend data
will be allowed for DupliObjects.
This is a placeholder for proper depsgraph integration. Eventually frame
changes and some other updates should rebuild dupligroup caches
automatically using the depsgraph. Until then this operator is a quick
way to test the IO from caches and the further drawing and rendering
(TODO).
BKE (DerivedMesh, particles, cloth).
The new cache implementation will be used for constructing dupli data
instead, bypassing the complexities of the modifier stack.
Conflicts:
source/blender/blenkernel/intern/cloth.c
source/blender/blenkernel/intern/particle.c
source/blender/blenkernel/intern/particle_system.c
Alembic caches.
This creates representations (Abc::Object) for Blender Object and Group
datablocks in the Alembic files and uses Alembic instancing to define
the dupligroup hierarchy. This leads to a relatively flat hierarchy in
Alembic files:
Top -> Object/Group -> DerivedMesh/Particles/Hair/Cloth/Smoke/...
The dupligroup structure can not be represented by a hierarchical
structure such as the Alembic object nesting, because of the
many-to-many relationship between objects and groups (a group can
contain multiple objects, multiple objects can instance the same group).
Instead we use the instancing feature of Alembic to represent
dupligroups. This is created in 2 stages to ensure all the main ID
blocks have been serialized before creating references.
This is not clearly documented for Alembic, but apparently properties
inside compounds still need to be name uniquely for the whole object.
This is somewhat involved for Blender's CustomData, because we have
5 different customdata elements for meshes (vert, edge, face, poly,
loop) and each of these can have the same types and multiple layers of
the same type ...
CustomData layers are pruned by the CDDM_copy function when they have
CD_FLAG_NOCOPY set. This is based on later modifiers in the stack, which
can specify that they require certain data layers - but the caching
modifier itself should store only what is needed by later modifiers.
It means we cannot easily keep a full copy of the DM in the cache
modifier to writing into caches later.
For now the hackish solution is to temporarily disable NOCOPY flags when
copying the DM. This is really not nice and needs a better solution.
This is a skeleton feature that provides a general way of storing
CustomData types. Currently only ORIGINDEX layers are implemented, the
code is designed to make extension easy.
Storing CustomData layers in Alembic is a bit involved because the
complex structs often used as customdata need to be de-interleaved for
Alembic into a set of POD (plain-old-datatype) array properties.
In addition the property names should be unique, so that mapping abc
properties back to customdata layers is safe. This works by using 2
levels of compound properties: the first level stored per CD type
properties, with a number of properties for each layer of this type,
using either a name or index (for unnamed layers). The internal
properties can then in turn be compounds, if structs need to be
serialized into PODs.
Abc property readers/writers are created dynamically for the CustomData
compounds. This is necessary because we don't know in advance what kind
of data layers a DerivedMesh or other CD user will have, and this can
change each frame in theory. Alembic is easier with state data schemes,
but using it this way is possible (if somewhat cumbersome).
This creates a string with information about all the objects and
properties contained within a (Alembic) archive, used by a cache
library.
The operator has 3 modes of presenting the info string:
- stdout, ie. printing to the terminal
- popup window (not very useful usually due to size limits and lack of
scrolling)
- clipboard copy
result read from the cache.
Mixing this with the output_dm used for writing leads to undefined
situations where the DM was released but should actually be passed on.
This designates a cache library to be used either for the viewport or
for renders. A "Render" cache library will evaluate modifiers with
render settings and a "Viewport" cache library will use viewport
(realtime) settings.
When reading the cache, the library will only be
used for the assigned purpose, i.e. a Render cache does not work for
viewport caching and vice-versa (although a cache can be baked for one
setting and then switched afterward).
Note that render results will never be visible in the realtime viewport
due to the way object evaluation is handled in Blender at this point
(render settings are only evaluated explicitly during renderer sync).
Conflicts:
source/blender/blenkernel/intern/particle_system.c
out of pointcache into blenkernel.
This is quite simple and repetitive and there is not need to have this
in the main pointcache/Alembic API. The code is mostly concerned with
logic of DNA data, so pointcache shouldn't have to deal with it.
The pointcache library is now pretty much independent from ID blocks and
should not be responsible for handling file paths. The path construction
is also fairly straightforward now compared to the old point cache
system, with only basic conversion of relative to absolute paths for
loading archive files.
python code to unify symbols.
This is necessary because the operator for adding new items (as opposed
to the enable/disable button) cannot be shown with the same checkbox
button. The UI template function can display a custom button for the
operator, so the look becomes less confusing.
This now appends a default extension based on the cache backend used.
At this point this is always Alembic (.abc) but would allow other
backend formats in the future.
In addition to the object name filtering, items in cache library groups
can now be filtered by type as well.
Existing items in the cache are always displayed, so as to not hide
important information (what gets stored in the cache). The filtering
is primarily a utility to simplify searching inside the group for things
that should be added to the cache.
This requires a better design and is not so easy to implement properly
within the limits of RNA definition. These collections don't physically
exist in the DNA, they are mainly utilities for looping over
//potential// items in a cache library. For now the python code has to
be adapted to only show valid items, until the RNA provides a good
solution.
This is also used during the bake process to avoid confusion: The read
flag gets disabled for the baking cachelib, so that objects don't try
to read cache data that is supposed to be generated.
CacheLibrary datablock has a generic unlink function now, but currently
nothing actually links to cache libs themselves, so it's empty. Still
good to keep this in mind for the future.
The `bf_pointcache_alembic` code is a separate library, to avoid
muddling up core code with alembic includes and preprocessor defines.
Alembic stuff only belongs strictly into alembic code and can be
disabled cleanly.
The `bf_pointcache` and `bf_pointcache_alembic` libraries had a circular
dependency, because the alembic implementation functions were called
directly. Now there is a "Factory" class to abstract the creation of
concrete implementations for readers and writers.
`bf_pointcache_alembic` defines this factory and is registered
//outside// of the core `bf_pointcache` lib, so there is no linker
circularity.
This was an artifact from the previous way of mapping non-0 start frame
to time 0.0. Now we start at times > 0.0 to match with the start frame.
Both ways are possible, can be changed later if needed.
Writers were always starting at time 0.0, which means that for start
frames > 1 the readers would always be off. Now match the writer start
frame to the actual Blender start frame.
cache library system.
The Cache modifier is now an optional "break point" of the modifier
stack:
- Without a cache modifier the stack works as before. Baking will write
the final stack result. After baking the cache replaces the whole
stack.
- With a cache modifier the stack result at the modifier's position is
stored. The cache is then applied as the output of that modifier,
skipping preceding modifiers. That way additional modifiers can be
applied on top of the cache.
- When using multiple cache modifiers, only the last (active) one will
be used, since all previous cache results would be discarded anyway.
This can happen if an object gets deleted or isn't loaded for some
reason. The item should just be ignored in that case and removed at the
next opportunity (cleanup function).
of constructing names internally.
This helps prevent name collisions and guarantees a consistent naming
scheme for putting multiple items in the same cache.
refactoring simpler.
Since the new approach is not tied to the old set of point cache data
types there is really no need to carry their empty husks around. Once
the new caching system is defined in detail we can add back whatever
makes sense.
Now instead of each reader/writer creating its own archive, the archive
is created by the caller in advance and passed as a constructor
argument. This means that multiple items can be stored together in the
same archive.
iterating over all objects eligible for caching in the group.
This allows for nested dupligroup instances as well. All objects that
are instantiated at least once by any group can be included in the
respective cache, but get represented only once because the cached data
is the same anyway.
subtype/index.
This omits possible instancing and recursion by dupli groups, but since
the data of instances is always the same in Blender at this point, there
is little need to take them into account for caching.
At some point in the future it may become desirable to store full dupli
hierarchies in the cache, but it doesn't make sense to try to design a
fully-fledged path descriptor for this hypothetical case now.
object group.
This is somewhat experimental, eventually we may want to link to Objects
instead, or allow multiple cache targets for the same cache, etc.
and files.
At it's core this is just a file path, but many different cache users
may refer to this, so having a dedicated ID block helps. It can be
compared to Image datablocks, which also primarily are used for data
on storage, but can be packed with the blend file, and carry some
additional information that would be cumbersome to keep sync'ed
otherwise.
The name 'CacheLibrary' deliberately resembles the 'Library' datablock:
just as a Library stores ID blocks in a physical file, a CacheLibrary
stores cached data (in Alembic HDF5/Ogawa or other formats).
Conflicts:
source/blender/blenkernel/BKE_pointcache.h
source/blender/blenkernel/intern/pointcache.c
source/blender/makesdna/DNA_pointcache_types.h
Conflicts:
source/blender/makesrna/intern/rna_main_api.c
When writing DerivedMesh data, the modifier result at the point of the
modifier will be used for writing to the cache. If this modifier is not
used the derivedFinal mesh is used instead.
Basically out of range could happen when opening files made in 2.72 when
the new icons for texture painting were added. Apparently some more
caution is needed here.
The pointcache API is designed to keep the general concept of caching
separate from the concrete Alembic implementation. Other types of file
export/import would be possible, e.g. for OpenVDB data.
Adds Alembic as a dependency and build support in cmake and scons.
Also extends the install_deps.sh script with a temporary installation
procedure for the Alembic libraries. This is still very hackish and
needs to be improved.
Fix T44007: Cycles Volumetrics: block artifacts with overlapping volumes
The issue was caused by uninitialized parameters of some closures, which
lead to unpredictable behavior of shader_merge_closures().
This change introduces a new hysteresis parameter that it will be added
or subtracted to/from the LOD distance to avoid popping when a LOD
object moves close to the LOD transition continuously.
Then, we have the following:
- a new LOD Hysteresis setting per scene (default 10%) which is located
in Scene context --> Level of Detail panel. This scene parameter also
will active/deactive the scene hysteresis.
- and a new LOD Hysteresis setting per object (default 10%) which is
located in Object context --> Levels of Detail panel. The LOD hysteresis
setting per object (if active) will overwrite the hysteresis setting per
scene value.
For the new blends: the hysteresis setting per scene would be active by
default and the per object would be inactive by default.
For the old blends: both hysteresis settings (per scene and per object)
would be inactive by default. A quick way to take advantage of this
feature for old blends would be to activate the hysteresis parameter in
the scene context -> Level of Detail panel
Reviewers: campbellbarton, kupoman, moguri
Reviewed By: kupoman, moguri
Subscribers: nonamejuju, lordodin
Differential Revision: https://developer.blender.org/D957
This patch will add a physics constraints replication for group instances
(dupli group).
It also fix crashing when when a group instance is made from a linked
group instance and both are on the active layer.
Initial patch T31443 from moerdn (Martin Sell).
Reviewers: lordloki, sergof, moguri, sybren
Reviewed By: moguri, sybren
Differential Revision: https://developer.blender.org/D658
- Correct logic converting radius to view distance.
- Wasn't taking view-zoom into account converting lens to angle.
- Support framing the selection in the camera bounds (for camera locked views).
Add ED_view3d_radius_to_dist to handles these details.
Quite a few things wrong here:
* Mac did not support EXT_draw_instanced, only ARB_draw_instanced
* Draw instanced did not work unless data came from vertex buffer, which
is second time we see weird things with vertex arrays in mac
* There were a few stupid mistakes by me as well, such as binding to
uniform locations for the wrong shaders (it's a wonder it ever worked
:p)
Is was possible that interface will be refreshed at thesame time
as render engine will start freeing render parts.
Not sure if we can get away without RW mutex here, seems we need
one way of synchronization or another..
Now mask animation is offset to start of strip, instead of staying at frame 1!
Warning: this may break existing files, in case some would be using (hacking around!)
current bad behavior...
Added an utility function which performs vertex split based on the loop
normal so now backing API matches to what's happening in Cycles and BI
in terms of autosplit.
Reviewers: dfelinto, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1174
New 'strip' snapping was simply not computed in case of constrained transform, hence init
'0' value was used as frame offset in this case.
This commit reorganizes a bit that snapping, to keep it more 'confined' into `snapSequenceBounds()`
dedicated function. It still needs a minor hack (setting snapping mode to something else than
defualt `SCE_SNAP_MODE_INCREMENT`, to avoid this snapping to be called by contraint code).
Thanks to Antony for review and enhancements.
This fix should be backported to 2.74.
We could likely add much more, but those already covers basic behavior and should be able
to catch most errors when editing this code.
Also added some performances tests as well (timing ghash insert/lookup under heavy loads,
for different kinds of keys).
This patch is the root of the GHash rework, all other diff will be based on it:
Reduce average load from 3.0 to 0.75
----------------------------------
This is the big performance booster part, e.g. makes tracing a dyntopo stroke between 25% and 30% faster.
Not much to say about it, aside that it obviously increase memory footprint (about 25% - 30% too).
Add optional shrinking
----------------------------------
I.e. ghashes/gsets can now shrink their buckets array when you remove enough entries. This remains optional and OFF by default.
Add code to use masking instead of modulo
----------------------------------
Buckets indices are obtained from hashes by “reducing” the hash value into the valid bucket range. This can be done either by bit-masking, or using modulo operation.
The former is quicker, but requires real hashes, while the later is slower (average 10% impact on ghash operations) but can also be used as a 'fake' hashing on raw values, like e.g. indices.
In Blender currently not all ghash usages actually hash their keys, so we stick to modulo for now (masking is ifdef’ed out), we may however investigate the benefits of switching to masking with systematic very basic hashing later…
Add various missing API helpers
----------------------------------
I.e. a way to deep-copy a ghash/gset, and a way to (re-)reserve entries (i.e. manually grow or shrink the ghash after its creation).
Various code refactoring
----------------------------------
* Get rid of the 'hack' regarding ghash size when used as gset (it’s simpler and safer to have two structs defined here, and cast pointers as needed).
* Various re-shuffle and factorization in low-level internal code.
* Some work on hashing helpers, introducing some murmur2a-based hashing too.
Thanks a bunch to Campbell for the extensive review work. :)
Reviewers: sergey, campbellbarton
Subscribers: psy-fi, lukastoenne
Projects: #bf_blender
Maniphest Tasks: T43766
Differential Revision: https://developer.blender.org/D1178
A new checkbox "High quality" is provided in camera settings to enable
this. This creates a depth of field that is much closer to the rendered
result and even supports aperture blades in the effect, but it's more
expensive too. There are optimizations to do here since the technique is
very fill rate heavy.
People, be careful, this -can- lock up your screen if depth of field
blurring is too extreme.
Technical details:
This uses geometry shaders + instancing and is an adaptation of
techniques gathered from
http://bartwronski.com/2014/04/07/bokeh-depth-of-field-going-insane-http://advances.realtimerendering.com/s2011/SousaSchulzKazyan%20-
%20in%20Real-Time%20Rendering%20Course).ppt
TODOs:
* Support dithering to minimize banding.
* Optimize fill rate in geometry shader.
General idea is to avoid actual calculation from property update()
callback and tag things for update later instead.
That said, pose constraint flags are now tagged for update and
handled as a part of object update. In the new depsgraph it'll
be a nice dedicated operation node.
Also avoid updating disabled flags for all the modifiers. This
part of the path is not totally optimal since it'll still need
to iterate over bones in order to get pchan, but to optimize it
further would be nice to find a way to avoid pchan requirement
all together.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1191
It was actually an old issue with wrong conversion happening for muted
nodes, which wasn't visible before memory optimization commit.
This is to be backported to the final release.
D1147 by @julien, with fixes/improvements
Duplicate bones where needed, otherwise use existing.
Keeps parent relations intact, can operate on parts of an armature.
This adds back rgb_to_grayscale,
not all color is managed or depends on the current loaded blend file's CM options.
Noted in comments that this is only to be used outside the CM pipeline.
off.
GPUs need a full tree of mipmaps up to dimension 1xn to work. This will
make it so for all imbufs but cost is negligible and it's unlikely that
something could break due to that.
The way we were getting diff to apply to vcos from target object was just bad!
Also, fixed another related issue - negated scale would be clamped to nearly zero,
now only consider absolute version of size (we do not care about its sign here anyway).
This should be backported to 2.74 (with previous commit too).
Bump result was passed to set_normal node and then set_node was connected
to all unconnected Normal inputs, including the one from original Bump
node, causing cycles.
Using bool when we're asking yes/no questions such as whether some GPU
feature is supported.
Consolidated these simple functions into gpu_extensions.c and grouped
them in the header.
Const-ified some args where the functions don't modify the pointed-to
data.
Code here is a bit weird/simpler than GPU_draw, but we can reuse the API
here, albeit with a few restrictions (no high resolution, custom
filtering mode - which will probably get lost next time blender reloads
textures)
Two areas of the BGE use a hard-coded 60 Hz as frame rate. However, this 60 Hz is just a default setting, and can be changed in the Blender interface.
This setting is now used instead of the hard-coded 60 Hz.
CcdPhysicsEnvironment::SetFixedTimeStep() is actually never called, as we don't even support a true fixed-timestep simulation.
This patch would reassign the relative of all keyblocks to the relative
of the deleted keyblock. And it fixes the misalignement of the index values
after the keyblock is deleted.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1176
When the multisegment profile joins two unbeveled edges, all in the same
plane, users desire that rather than the current behavior of linear
interpolation between those edges, the profile should curve.
This changes behavior to do that. The old behavior can be obtained
by setting the profile parameter to 0.25, if desired.
Added Shift + Tab for Snap and Ctrl + Shift + Tab for Snap Element Menu (consistent to
3D View)
NOTE: Exit Group is now Ctrl + Tab instead of Shift + Tab
I noticed our version code and subversion got out of sync in the past, maybe
that's what the issue was here.
Deleting the entries from the .xml makes it fall back to the default values.
Added a new "current_lod_level" property to the python api of
KX_GameObject. The property returns the current lod level of the game
object. The purpose of the property is activate logic routines only when
an object is at a certain lod-distance from the camera, avoiding to
separately recomputing the same distance in the logic script. Usage in
python script might look like:
owner = bge.logic.getCurrentController().owner
lod_level = owner.currentLodLevel
if lod_level == 0: ...do something
else: ... object might be too distant
Reviewers: dfelinto, kupoman, moguri
Reviewed By: kupoman, moguri
Subscribers: lordloki
Projects: #game_engine
Differential Revision: https://developer.blender.org/D978
overlay scene
GetGameObjectType is overwritten in KX_FontObject to differentiate a
font object into AddNodeReplicaObject function. Now, in this function,
we add fonts in the appropriate list.
Reviewers: campbellbarton, moguri, dfelinto, lordloki
Reviewed By: lordloki
Subscribers: lordloki
Projects: #game_logic, #game_engine
Differential Revision: https://developer.blender.org/D1130
The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the
mesh.
This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion
anyway.
Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1127
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
This commit makes some preliminary fixes and tweaks aimed to make blender
compilable with C++11 feature set. This includes:
- Build system attribute to enable C++11 featureset.
It's for sure default OFF, but easy to enable to have a play around with
it and make sure all the stuff is compilable before we go C++11 for real.
- Changes in Compositor to use non-named cl_int structure fields.
This is because __STRICT_ANSI__ is defined by default by GCC and OpenCL
does not use named fields in this case.
- Changes to TYPE_CHECK() related on lack of typeof() in C++11
This uses decltype() instead with some trickery to make sure returned type
is not a reference.
- Changes for auto_ptr in Freestyle
This actually conditionally switches between auto_ptr and unique_ptr since
auto_ptr is deprecated in C++11. Seems to be not strictly needed but still
nice to be ready for such an update anyway/
This all based on changes form depsgraph_refactor branch apart from the weird
changes which were made in order to support MinGW compilation. Those parts of
change would need to be carefully reviewed again after official move to gcc49
in MinGW.
Tested on Linux with GCC-4.7 and Clang-3.5, other platforms are not tested and
likely needs some more tweaks.
Reviewers: campbellbarton, juicyfruit, mont29, lukastoenne, psy-fi, kjym3
Differential Revision: https://developer.blender.org/D1089
The issue was caused by missing relations between smoke domain and flow/source
objects. This happened because smoke's modifier only iterated base objects and
ignored cases when flow/source could be linked to scene via dupli-group and
does not have real base.
The same seems to be still needed for fluid and dynamic paint modifiers,
will do it as a separate commit.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1172
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
This patch avoids looping over bhead's linked list when looking up values by name.
Used during appaned and library loading.
Gives noticeable overall speedup loading files that used libraries. (nearly 2x on some Mango files)
The fix was really flacky, in terms during speed benchmarks i had
abort() in the fallback block to be sure it never runs in production
scenes, but that affected on the optimization as well. Without this
abort there's quite bad slowdown of 5-7% on the renders even tho
the Pleucker fallback was never run.
This is all weird and for now reverting the change which affects on
all the production scenes and will look into alternative fixes for
the original issue with precision loss on huge planes.
This reverts commit 9489205c5c.
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
This merges consecutive empty steps in the decoupled record function,
which can lead to fewer iterations in the scatter functions.
Only helps slightly though (1%), but doesn't hurt to have this.
Differential Revision: https://developer.blender.org/D873
Use multiple threads for building the MIS table, if the
resolution is higher than 512.
Also replace division by cdf_total, with a inverse multiplication by
cdf_total_inv. This gives further speedup.
On my Macbook (8 CPU threads) this improves the time to build the table:
Resolution 4096: From 0.16s to 0.03s
Resolution 8096: From 0.61s to 0.11s
This especially helps to reduce the scene update time, when tweaking world
shader while viewport rendering is running.
Patch by Sergey and myself.
Differential Revision: https://developer.blender.org/D1159
This reverts commit 91d0f6f113.
Artists here seem to dislike the interface being stuck after a change to
modifiers, reverting until an interactive solution is coded.
This is not limited to normal maps, it's just that normal maps cause a
mix of interleaved vertex arrays + non interleaved vertex arrays + GLSL,
which could confuse the GL. Possible explanation is that it may be
clobbering the vertex index of the shader somehow but this is difficult
to know without extensive tests and the Mac is needed by Francesco in
the morning :).
Do brute force solution instead, just force legacy drawing on Macs when
VBOs is off. On the plus side VBOs work fine, so we should be fine when
we update.
Issue was caused by b62c2a9 and root of it goes to the fact that text
info is stored in the "main" scene, not the currently rendering one.
This is a bit annoying but making it so text and result are coming
from the same scene is a bit dangerous to do now. Will re-visit this
change after the release and see if it might be done in a more clear
fashion.
Forbid add quick fur operator from adding fur to objects in edit mode.
Fur is not visible for them anyway and because of local undo stack used
in edit mode tweaking values of this operator does not lead to proper
operator redo.
The smoke obstacle detection was using a maximum distance for BVH
checks to find mesh elements that define boundary cells in the grid.
This BVH test was using an arbitrary value of 0.6 cell units. It should
be `sqrt(3)*0.5` to account for the maximum possible distance of mesh
elements inside a cell. Otherwise some cells that should form the
boundary are not detected as such (no closest mesh element found inside
the radius), so you get gaps in the smoke obstacle.
The issue seems to be caused by the integer overflow. It's actually
still needed to investigate why exactly buffer contained such a huge
value, but the patch is still legit and seems to be solving the issue
just nicely.
The issue was caused by mismatch in how aligned triangles storage was
filled in during BVH construction and how it was used during rendering.
Basically, i was leaving uninitialized storage for triangles when
there was deformation motion blur detected for the mesh. Was likely
some sort of optimization, but in fact it's still possible that regular
triangles would be needed for rendering.
So now we're storing aligned storage for all triangle primitives and
only skipping motion triangles (the deformation motion blur flag from
mesh is now ignored).
This was a regression caused by attempts to fix T42844 and there were
some red-herrings which lead me to the wrong way to fix it. It's some
deeper issue than just interpolation offset, it's mainly how the node
resolution is being mapped to each other.
It could be actually a part of canvas awareness project..
Removed all references of deprecated texture shader. Also deleted
several lines of dead code.
Since texture_shader.py no longer does what it was supposed to do,
the file itself was removed.
Patch reviewed by Tamito Kajiyama (kjym3).
This is a regression introduced by rBd8b00a3bf5c1 (Freestyle: memory
consumption optimization in stroke rendering).
The issue was caused by uninitialized MPoly::mat_nr values. Before the
stroke rendering optimization, individual Freestyle strokes were
represented by distinct mesh objects, and thus MPoly::mat_nr was left
unset (i.e., was always zero). Now that the stroke rendering optimization
has been done and mesh objects may represent multiple strokes of different
materials, MPoly::mat_nr had to be properly set to the material index that
refers to the material of the poly face.
Now we have an helper that will generate local/global paths and ensure they are valid.
Note: We currently have no way to 'generate' a valid extension in these cases, so just
using raw (file-safe) ID name.
**Warning: WIP!** Basic functionality works fine and there shouldn't be any crashes, however, if you occur issues, feel free to report them to me (not in the bug tracker!)
Some more effort is needed to get this ready for master, but I thought it would be nice as a little present for the Gooseberry-team (I heard some of you were requesting this?) and the ones using the Gooseberry-builds :)
Oh, and better not look at that code, it's ugly and a lot of changes are planned, I just wanted to get something working before getting into details.
screen.
Apparently the screen on the given file did not have a scene attached.
Not sure how this is possible exactly, but for now just guard against it
at load time by assigning default scene in that case.
It was only happening on 32bit platforms because of alignment
differences when allocating class.
Now got rid of copy of eigen matricies stored by value in the
residual block which solves aligment issues and should also
give some unmeasurable speedup.
This hit animators already, basically when using sound sync we can
hit negative frames. This happens because we always subtracted the full
range of the triple buffer size from the timing, even when buffers were
flushed.
Also, old code read the offset from the offset of the reader. The
problem here, is that due to threading there is a time offset between
the when this offset is set and when it is offloaded to the buffers,
which means that we could get quite some variance between time
reporting.
Now sounds keep a private byte offset which is incremented right before
invalidating old buffers. This should make the combination of OpenAL
time report + byte offset more accurate. For even more accuracy we might
spinlock while updating those values but for now left it as is for fear
of the lock interfering with frame update performance. We can try to be
smarter here, storing old value while update is happening, and use
trylock and the old values if it fails but for now commit the simple
version.
screen.
Apparently the screen on the given file did not have a scene attached.
Not sure how this is possible exactly, but for now just guard against it
at load time by assigning default scene in that case.
It was only happening on 32bit platforms because of alignment
differences when allocating class.
Now got rid of copy of eigen matricies stored by value in the
residual block which solves aligment issues and should also
give some unmeasurable speedup.
This patch make it possible to export and import shadeless material.
Reviewers: sergey, sauraedron
Subscribers: sergey
Projects: #collada
Differential Revision: https://developer.blender.org/D1094
The issue was caused by AO operation reporting it's a color operation
(which means it's expected to output RGBA) but internally it's RGB
only in the render engine, which caused some memory to be uninitialized.
The issue was caused by numerical instability whrn having ray origin close to a huge
triangle, which could have aused bad ray distance check.
Watertight Woop intersection isn't really addressing such cases, it's dealing with
small triangles far away from the ray origin instead, so it's a bit tricky yo make
it working reliably.
While we're quite close to the release it's safer to do check in Pleaucker coordinates
if ray close to a huge triangle. Likely this additional check combined with some other
tweaks to the code doesn't cause measurable slowdown in the scenes tested here.
After the release we can play a bit more with this code in order to make it more
stable without Pleucker fallback.
Blender allows you to create a constraint without specifying its reference
object, even when the constraint requires such a reference. The BGE would
crash on this. This change simply ignores such a constraint.
The issue was caused by recent DM to mesh conversion which was taking ownership,
and it was failing if there are any referenced layers in the custom data.
Now disable passing ownership if there are any referenced layers.
Seems it's just another issue with the compiler, worked around by explicitly
telling not to inline some function.
In theory we can unify this with CPU, but we're quite close to the release
so better be safe than sorry.
We need to register the exception handler slightly differently here, as
well as adding DbgHelp as a library, but according to docs it should be
supported in recent Windows editions (Win XP included even).
We can try it first and revert if there are issues.
The issue was caused by particles using billboard distribution, which
requires either object to be specified or camera in the scene to be
existing.
This commit prevents backing from crash, but bake result might not be
totally expected because of the thing mentioned above.
as complicated as before cloth solver changes.
Still doesn't solve the collapsing cloth cube issue mentioned in T43406,
probably the bending springs work somewhat differently now.
Face islands furthest faces could face towards the center point when connected to sharp edges.
Now check the furthest edge of the furthest face, to test for face winding.
This was disabled during the course of hair dynamics work. The cloth
collision solution is based on a secondary velocity-only solver step.
While this approach is usable in general, the collision response
calculation still does not work well for hair meshes. Better contact
point generation is needed here (Bullet) and preferably an improved
solver for unilateral constraints.
* Strips in muted tracks are also drawn with dotted borders now to make it clearer
that they are not contributing.
TODO:
* Perhaps dotted should be used for protected, and opacity for muted instead?
* Do not make Action Stash Tracks or their strips active/selected
* Lock the track to prevent accidental editing/adding of other strips
* Prevent strips from being added into locked tracks by the pushdown operator.
This is mainly to prevent pushdown actions from getting into the stash tracks.
This commit modifies the "New Action" operator to always stash the old action
before it creates a new one. As a result, the old active action will now have
a proper user of sorts after the new one is created, preventing previously
created actions from being lost.
Now that the New operator does this, it can be used for the Action Editor header AND
NLA Editor (Animation Data Panel -> Active Action) again. The "stash and create"
operator is somewhat redundant at this point as a result.
In constrast to the old "new" operator, this operator will stash the existing action
in the stack to prevent it from being lost. This situation isn't totally ideal yet,
since the NLA Editor still calls the old method.
I'm still not sure which version is better, but I suspect that with the labels,
this might help users figure this out more than if they were just unlabelled
icon buttons...
This operator (the snowflake icon, beside the pushdown button on the Action Editor
header) adds the currently active action to the NLA stack in a muted track, then
creates + loads a new action ready to be populated with new keyframes.
Since the NLA is being used to hang on to all the actions here, no actions are
getting lost.
Usage Notes (there will be some additional tweaks to make this nicer):
* To preview different actions that have been "stashed", simply click the "Solo"
toggle for the track containing the action in question. Playing back the NLA will
now show the stashed track
* To edit a previously stashed action - simply enter tweakmode on it in the NLA
while the "Solo" toggle is enabled.
Todo:
* Add some more operators here to polish up the Action <-> NLA bridge to make the
layered and stash workflows smoother. Examples include some tools to easily
switch between the different actions layers in the stack, as well as making it
easier to get out of tweakmode (and sync up the action lengths)
* Review and cleanup the behaviour of the "new" operator here to avoid the old
problems that users were running into
* After the next release - Implement the full Action Libraries functionality, with
ways to bridge the stashed strips over to a full-blown library.
The Solo and Mute functionality for the NLA system should really be mutually
exclusive features. They both affect whether a given track applies or not.
The only difference is that the Solo option mutes all the others, while the Mute
only does this on a per track basis.
Before this fix, muting a strip and then making it solo meant that the solo'd
track would not play at all, which isn't really what we want.
This commit exposes the "Push Down" button/functionality found in the NLA Editor
to the Action Editor, so that actions can be added NLA Stack from here too. The
main point of this for now is to make the whole layered-animation workflow nicer
more efficient, but not requiring the second editor be visible in common cases.
It also conveniently sets things up for the next few changes (already hinted at
here)...
(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())
* There was no real default value for this parameter (neither "" nor None would work the same as
not specifying that parameter). Now, 'None' is considered as default value, and you get
exact same behavior with this value and if not specifying it. This is important at least for
consistency, and potentially too in some esoteric cases (like generated code or so).
* Add a warning about the fact that 'default' parameter shall not be psecified when items
are given a callback function.
Own mistake in refactoring of `BLI_strncpy_wchar_as_utf8()`, if given size was exactly
the one needed, we'd lost last char (off-by-one error).
Many thanks to plasmasolutions (Thomas Beck) who found the issue and did
all the investigation work here!
This is still not so correct, to make it work we really have to do a
blurring pass based on the real coc (currently we are just blending 3
levels of blur)
The idea is pretty simple: instead of making temporary copy of all the
related custom data layers just pass the ownership from the DM to the
mesh.
This is really handy in cases when you've got DM which you need to
convert to Mesh datablock and wouldn't need that DM after conversion
anyway.
Foe example, render database conversion, exporters and even Modifier
Apply will benefit from this option.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D1127
`enforce_locks()` would reset weights of non-locked modified vgroups if it could not
find any other non-modified non-locked vgroup to 'distribute' weights into.
Sounds rather stupid, yet I hope I did not break something else, this code
is rather convoluted to say the least.
Side-reported by zeauro (ronan ducluzeau) in T43814, thanks!
Removed window arg from key conversion functions.
Removed processModifierKeys declaration since that function was
apparently never implemented.
Using Win32-specific classes instead of their generic superclass -- this
helps in a few cases like WinTab.
* m_hDC was always included after m_hWnd in all the constructors and other functions,
but the order was reversed in the struct, meaning that they would not get initialised
correctly
* Got rid of the gotos for the error handling case in initializeDrawingContext()
This was causing "jump to label ... crosses initialisation" errors for the calls
to get GL version string info (i.e. const char *vendor = ...; etc.) I wasn't sure
if those glGetString calls needed the rest of the context to be defined first, so
I decided to leave them where they are now, and got rid of the gotos (which were
making this particular piece of code a bit confusing) instead.
TODO:
There are still a bunch of warnings about around 660, which I haven't managed to solve
(but at least they won't prevent Blender from compiling)
narrowing conversion of '(stereoVisual ? 1063 : 1061)' from 'int' to
'DWORD {aka long unsigned int}' inside { } is ill-formed in C++11 [-Wnarrowing]
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
This patch fix two bugs related to CreateConstraint().
1. Disable linked collision only working with 6DoF constraints.
2. If all pivot axis rotations setted to zero the linked object disappears.
{F101374}
Reviewers: moguri, sybren, brita_, lordloki
Reviewed By: lordloki
Subscribers: p9ablo
Differential Revision: https://developer.blender.org/D704
Things here are simple, selected bone joint could have same priority as
unselected bone, so bone would always win. Gave joints a little more
priority than bones, usually user will be more precise just to select
the joint anyway.
frame start.
Issue here is that if we failed to get an image from the cache, we would
try to load from file. This would fail when the queried frame was less
than the animated sequence start frame, and invalidate the OK state of
the image.
Solution is that when loading from cache succeeds, we also reset the OK
state of the image for animated textures.
The fix might be relevant elsewhere too, but kept it isolated just in
case.
loading 'readline' module could crash blender if 'libedit' was already linked (via LLVM).
Workaround the problem for now since we don't even need readline,
a _real_ fix likely involves changing how LLVM or Python are built.
for clumping instead of deformed location.
The orco location must be used for roughness to ensure a stable shape,
but for moving child keys toward the parent (clumping) the deformed
location must be used.
We need to use 'W' widechar variants of win funcs and convert wchar to utf8-encoded bytes
in those cases, sigh...
Note: theoritical fix only, need org reporter to test it...
- 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?
Two issues in this report:
* Shift-F key conflict between painting and selecting mirrored bone
(moved select mirrored to ctrl-shift-F)
* It was possible to display texture overlay in weight painting, even
though the mode does not support textures yet.
Naming here is slightly misleading. We have:
* Number of elements (objects) that can be picked
* Buffer size
* Number of integers in buffer.
Interestingly enough, bufsize in OpenGL (as far as I could find in
examples on the web) and in most of the code refers to the latter and
actual buffer size is only used whenever we do allocations on the heap.
Added an extra defines here to make things a bit clearer:
* MAXPICKELEMS refers to the number of objects that can be picked
* MAXPICKBUF refers to the number of integers in the selection buffer
Also made all buffers use MAXPICKBUF where some used MAXPICKBUF * 4.
That means that some parts of blender will use less space for selection
now. MAXPICKBUF is set to 10000 for 2500 object selection, which can be
changed at any time, but I think 10000 integers on the stack touches the
borders of uglyland anyway.
This randomisation was using the deformed parent coordinates for
calculating noise vectors, which causes unwanted movement as the parent
hair deforms. Instead the `orco` coordinates must be used for all noise
vectors, since these are from the undeformed mesh.
Was returning NULL, auto-completing:
bpy.types.Material.bl_rna.properties["type"].
Would crash, accessing 'default_flag', thanks to @lukastoenne for investigating.
This was still the known issue with pixel center, original commit didn't cover all the
cases by the looks of it.
Should be all fine now, but much more intense testing is welcome.
The following commits were supposed to add anti-alias and help with OSL
baking:
7b16fda3791b92dfa961
However they introduced other issues (artifacts mostly), see T43550 .
Leaving the code ifdef'ed for now.
Show World will now influence if world is rendered in opengl rendering.
This is a little undefined according to blender history, since sky used
to always be drawn when offscreen rendering, as if "Only Render" was
ticked. Since if we don't draw sky in that case there's no valid color
really (and using theme colors is not so nice) we just draw transparent
background.
internal api Consistency.
For the records, I suspect there are still a few cases of this. I found
this by chance (moving an object to a different layer), and I ran into
the previous one (fixed by Campbell) as well (by adding a cube).
Anyways, since it only happens when building with crash on asserts is
not a big issue. But by the time we change RNA to use bool instead of
int it would be nice to do a call for test to prevent those breaks.
patch number D706 with changes:
- WITH_GPU_DEBUG just creates a debug context (and enables the debug messaging
system functions) but leaves the checks we had intact. Old patch
added the debug functionality only if we had the flag on to save some
performance.
Rationale here is that we might not want to recompile blender just to get
the extra information, and having users start blender with a -d flag to
get the extra information is also useful for bug reports. Those checks already
existed and most expensive ones are hidden behind a debug mode check
so performance should not be that bad.
- Did some cleanup of existing functionality:
When things go wrong blender side, just print the error,
don't check for GL errors first.
- Did not port changes needed for GLES to regular glew.h
- Got rid of duplicate or very similar new functionality.
Generally, code is more moving things around/cleanup and should work exactly
as before apart from the debug context, so it's safe to add even now.
It also provides a nice substitute function for glu error descriptions
Rationale for this feature goes like this:
In meshes the influence of shape keys can be limited to certain vertex
groups. This allows shapes to be applied selectively on parts of the
mesh and possibly even be animated by changing vertex group weights over
time.
With hair shape keys there is no equivalent feature to vertex groups
(defining a vertex group on hair keys would be rather tedious anyway).
It would be possible to use the emitter mesh vgroups to assign a
per-strand blending weight, but since hairs usually are much more dense
than mesh vertices this would sacrifice accuracy.
A better option is to allow textures to influence the hair shape key
blending. For this purpose there is now a new texture influence.
A shape key name needs to be assigned to the MTex in addition to a
factor. It will then act as a multiplier for the shape key weight,
i.e. the base shapekey value still works as an overall control.
ED_area_data_swap would put the screen in an invalid state and crash.
(SpaceLink.spacetype didn't match ScrArea.type)
However behavior is still odd in the instance of the report.
`CustomData_bmesh_interp_n` was expecting the 'dest' arg not to have its offset applied.
This was a bit confusing since the source args have it applied,
and in some cases we only have the destination with the offset.
Fix for T43768
This way it works consistent with cloth, softbodys, etc.
Reviewers: lukastoenne
Differential Revision: https://developer.blender.org/D1134
Strokes containing only a single point are now drawn so that they respect the
pressure values too. Previously, they were getting drawn at a fixed size based
on the thickness of strokes. Thanks to @kekeljevic for posting a screenshot which
made the problem here easy to identify!
(On a side note: Perhaps it's a combination of the drivers I'm using, or the
multisampling goodness at work, but after applying this change, the dots are
now appearing as round circles as originally intended, and can also be scaled
up quite a bit too. And that's for 3D points which couldn't be affected like
this earlier! I'm not sure what's going on here, but whatever it is, I like it ;)
This attribute missed derivatives calculation.
Not totally sure what's the proper approach for algebraic derivative
calculation, so calculating them by definition. This isn't fastest
way to do it in this case and could be replaced with some smarter magic
in the wireframe calculation loop.
At least currently implemented approach is better than nothing.
It was complaining about explicit __constant to __private memory conversion,
which is now worked around using implicit conversion.
It's not a real fix i'm afraid and i'm still failing to build OpenCL kernel
with latest Linux drivers, but maybe it'll let someone else to investigate
what causes compiler to run out of memory?
Deleting an object was deleting all rigidbody constraints in the scene.
Bug was introduced with D701.
Reviewers: agoose77, sergof, moguri, lordloki, sybren
Reviewed By: lordloki, sybren
Subscribers: sybren, hbar, blueprintrandom, sergof, agoose77
Differential Revision: https://developer.blender.org/D1007
Issue was caused by the changes in 7b16fda which changed the initial
state for rng. This commit makes it so the same initial hash is used
(which solves the regression without distorting AA-looking image.
It also makes it so OpenCL compiler is happy about this code (before
this change it'll complain about trying to cast private variable to
global one).
We are now guarding against some divisions by small values.
There are still issues here but they are not on boundary faces
anymore so they must be related to some other issue such as
the triangle intersection test.
Previous text could make think this func was checking whether a point was
inside and on the face, while it actually checks whether the projection
of that point onto the face is inside its boundary...
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 b1191e5caf.
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.
Draw motionpaths after scene. They are not really XRays since they don't
require any depth info so add separate list for them. Feature could be a
little more polished to avoid too many state changes but for now just
commit something that works (tm)
problematic (still!)
It seems due to floating point precision issues we have to account for
even more cases.
Added colinear check for one more triangle edge-vertex and assumed that
if no collision test is found then triangle is completely inside box.
Such cases are mostly from float precision not catching triangle just
outside bucket. Now tests are much better for simple tests (paint/flood
fill cube from ortho view, paint sphere), however there are still some
rare cases of stray pixels.
problematic (still!)
It seems due to floating point precision issues we have to account for
even more cases.
Added colinear check for one more triangle edge-vertex and assumed that
if no collision test is found then triangle is completely inside box.
Such cases are mostly from float precision not catching triangle just
outside bucket. Now tests are much better for simple tests (paint/flood
fill cube from ortho view, paint sphere), however there are still some
rare cases of stray pixels.
Ideally we should get rid of those temporary vectors anyway, but
it's not so trivial because of the alignment. For untl then we'll
just have a bit worse solution. This part of code is not the root
of the issue of memory spikes for now anyway.
But since we're getting rid of temporary memory earlier actual spike
is a bit smaller as now. For example in franck_sheep file it's now
5489.69MB vs. previously 5599.90MB.
Simple change: just get rid of intermediate data a bit earlier, before
final pixels array is being allocated. This gives around 30% of memory
save during light update (this is about 60meg in the frank sheep file
i'm using here).
This isn't really visible by artists a lot, because actual spike happens
on BVH construction. But it doesn't mean we shouldn't be accurate with
memory usage in other areas.
OpenCL doesn't let you to get address of vector components, which
is kinda annoying. On the other hand, maybe now compiler will have
more chances to optimize something out.
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
We don't like when NULL is send to MEM_freeN(), but there was some
differences between lockfree and guarded allocators:
- Lockfree would have silently crash, in both release and debug modes
- Guarded allocator would have printed error message, abort in debug
but keep working in release build.
This commit makes lockfree allocator behavior to match guarded one.
Title pretty says it all actually. Can only briefly mention that we're
indeed entering that state when after applying some WIP patches having
much fuller statistics about memory usage would help giving exact memory
benefit.
Null check to verify that parent has a character controller. Otherwise (i.e empty) it will crash.
Reviewers: moguri, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1115
Move physicsid type to unsigned long long to avoid crashes on Windows 8.1 64bits.
Other systems also modified to put them inline with this solution.
Reviewers: dfelinto, brita_, moguri, juicyfruit, campbellbarton
Reviewed By: juicyfruit, campbellbarton
Subscribers: juicyfruit
Differential Revision: https://developer.blender.org/D1122
bounds indices of vertices.
Issue here is that if we copy edge customdata the MEdge data that were
previously written get overwritten, solution is to write indices and
flags last (probably writing flags is superfluous here).
This flag is global for all the sessions and never changes. so it doesn't
really make sense to pass it around to all sessions and synchronization
routines.
Switched to a static member of BlenderSession now, but it's probably more
logical to introduce some sort of BlenderGlobals. Doesn't currently worth
a hassle for a single boolean flag tho.
By default a surface-based force will push things away from the surface
in both directions, regardless of whether a point is "inside" or
"outside" (judging by the surface normal). The new option makes a force
field always push things away in the direction of the normal, so that
it becomes less likely to get points "trapped" inside a mesh object.
Adds bpy.app.sdl to expose SDL version information.
When SDL is not available on a Linux system, certain Blender features
are silently disabled (like joystick support in the BGE). This change
is the first step towards making it more obvious why something isn't
working.
SDL information is exposed to Python via bpy.app.sdl, in the same way
as OCIO and OIIO information is exposed.
Generated system-info.txt contains SDL loading method (linked or
dynamically loaded by Blender) and SDL version number.
Reviewed by: sergey, campbellbarton
Differential Revision: https://developer.blender.org/D1112
building the BVH.
A long long time ago (rB3816554cbc1a40dc5199c8e56e45817ec09128d5) it
was coded such that edges would be used instead of faces for surface
distance calculation. This is pretty much never what you actually want.
There was a problem with the copy/paste functionality, where it would be possible to
paste 3d strokes into 2D editors, or 2D strokes into the 3D view. The problem with
that though is that these will not show up, and because there's no feedback at the
time, users may end up doing this pasting several times.
It could have happened with really long rays and small steps.
Step size will be adjusted to the clamped number of steps in order
to preserve render result compatibility as much as possible.
We should probably reformulate this a bit, so it will give the
same looking results without step tweaks. But this new behavior
should already be much better that it was before.
Basically, before drawing X-Rays, we now bind a second depth buffer.
After drawing XRays, we do an extra resolve pass where we overwrite the
non-XRay depth buffer in pixels where the depth is not maximum (which
means background pixel, since depth is cleared before drawing X-Ray
objects).
This ensures both scene and X-Rays keep their depth values and are ready
for compositing. Well, the odd effect due to depth discontinuities can be
expected, and X-Rays are a bit more expensive (extra buffer + resolve pass)
but at least X-Rays won't invalidate depth values anymore. Whee!
Real issue is that temp area used to draw modal filebrowser is never saved,
so non of UI 'edits' (like UIList resize, regions resize, panels reorder, etc.)
are ever saved. Should be addressed, but no time for that currently.
It is now possible to switch between drawing and erasing strokes when in
the modal "Continous Drawing" sessions. This makes the drawing experience
just a little more fluid, saving some unncessary steps to get out of
the editing mode to activate the intended tool.
TODO: Is there interest for tablet support for this too?
= 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
This reverts commit 4ca4f04c75.
Was running an fs-stat on redraw, on every file! (every mouse motion!).
Could become very slow on network-fs
also caused crash (T43631)
Our new guarded allocator implementation has much smaller memory
block size overhead and doesn't have any locks now. So in order
to make fuller track of what's happening in blender and avoid
confusion why certain circumstances reports much less memory than
others we'll now switch to guarded allocator.
This was actually one of the biggest reasons of the confusion in
the recent memory usage investigation. There's still some overhead
is happening due to non-freeing nature of arena allocator but the
things are not nearly as bad as they looked before: memory overhead
is measured in tens of megabytes, not hundreds as it looked before.
Plus with some smarter allocation policy we can almost eliminate this
overhead.
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).
background.
For SSAO supporting this is no problem, for DOF we would ideally do
blurred alpha, but alpha channel in blurred buffers is occupied by coc
field, so use original color alpha instead. It's not entirely correct
but it's better than nothing.
modifiers, for use in shaders.
The particle instance modifier can now store 2 custom data layers:
- Index: the integer index of the particle
- Value: a randomized floating point number for shader variation
These layers have user-defined names, so multiple particle instance
modifiers can be used without overwriting customdata layers. In Cycles
the data can be accessed using an Attribute node with the same names.
Not totally happy with this, but it's better than nothing for until
we've got real outlier detection. Also made it more cleat how exactly
filtering happens, so users don't expect something the operator is not
intended to do.
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.
CMake 2.8 doesn't search /usr/include/SDL2, which is the include directory
for SDL 2.x on Ubuntu Linux (and possibly others). This results in SDL 1.2
headers being found when WITH_SDL_DYNLOAD=OFF, and our shipped SDL 2.0
headers when WITH_SDL_DYNLOAD=ON. This patch ensures that in both
cases the correct SDL headers are used.
Reviewers: sergey, campbellbarton
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D1112
Could connect a pair of verts previously,
now connect all vertices along the path, running a second time closes the loop.
Can also be used for without faces to connect edges between selected points.
The issue was actually affecting all data types that are not regular CDLayer ones, since by default
DerivedMesh references mesh data (verts, edges, etc. - modifying custom normals often implies
modifying edges' sarpness too).
Modfying edge/face sharpness etc. could directly affect the mesh in this case, **bad**!
So we detect whether we are copying data types that may affect non-CDlayers data, and whether
verts array of org dm is same as mesh one - in which case we copy the DM. This avoids
useless copying in most cases.
Note Edit Normals was quite obviously suffering the same issue.
Many users have been requesting a way to remove unused datablocks from the file/session
"without closing and reopening" Blender (or at least that's the impression I'm getting).
This commit adds a new operator (exposed as the "Purge All" button in the header of
the "Orphaned Datablocks" mode in the Outliner, which seems to be the logical
place for this) for doing so. It does so by wrapping up the save and "revert"
(i.e. reload the saved file from disk, without needing to quit Blender) operators
along with a confirmation prompt for good measure.
Caveats:
* Ultimately, we still cannot really cleanly delete any datablocks from the current
session outright without reloading the file/data at some point. Thus, we do need
to reload the file again before it can be used.
* This does mean that this operation is irreversible. Notably, Undo history is lost
is doing this operation. Hence the warnings... (Then again, undo/redo actually
reloads the entire scene DB from memory, so it's not anything uncommon ;)
Other Notes:
* The addition of this operator brings this mode more into line with being a kind of
"Trashcan" place, with this new operator being the manual "Empty Trash" button.
If the "Orphaned Datablocks" name is too obscure, maybe we could rename this
mode to "Trash" or something similar?
When in "Orphaned Datablocks" mode, the restriction columns are used to display
usercount indicators and toggles to manage whether datablocks get saved or not.
* The first column shows an icon to indicate whether that datablock is going to get
saved. A tick indicates the datablock will be saved, while a cross indicates the
opposite. Clicking on this changes whether the datablock will get saved.
* The second column shows the usercount.
* The third column shows whether the datablock has a fake user.
Notes:
* The second and third columns are pretty much redundant (functionally speaking).
While it is possible to also toggle fake users by clicking in the third column,
its role here is more as information for power users (and hopefully to allow others
to connect the relationship between the saved/not saved status and fake users)
* I'm not sure whether the use of the X here for the "not saved" state stands out enough
to draw user's attention to items which are "in the danger zone".
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.
- all mathutils types
- only works on frozen data (so vectors can be used in sets/dict keys)
- uses same method as CPython, (matches hashing a tuple)
D1104 by @juicyfruit with own modifications
Due to changes in the way animation updates were handled,
BL_ArmatureObjects were no longer registering to KX_Scene as animated.
Moguri says: It might have been relying on the deformer update which
moved rom being called on every object in the render step. Now
armature deformers are only updated if they need to be.
Fix T42919 & Fix T42218
The workaround for generated texture coordinates is to be done before
calculating number of elements for attribute, otherwise counter wouldn't
include those attributes.
The idea behind the change is to pre-allocate attribute arrays in advance,
which avoids re-allocation of arrays later for each of meshes being handled.
This reduces peak memory used by Cycles database from 1.3G to 0.9G for
victor.blend from Gooseberry.
It doesn't mean every file will benefit from this change since peak memory
usage is happening in the different places of the rendering code.
Also, unfortunately, attributes export might not cause the peak of render
preparation stage. That said, it's actually object_to_mesh() which causes
the memory to peak in the same test file. So we really need to optimize that
part first in order to get visible results for artists. But in any case it's
now quite easy to track hotspots in Cycles itself which is good.
It's actually a bad level call, but it's inside ifdef block and disabled by
default and only intended to be used for development purposes.
Main idea of this change is to combine statistics coming from Cycles and
Blender during scene synchronization step, to see if further changes are
actually reducing memory footprint.
The method is called vector::free_memory(). Use with care since it'll invalidate
all the pointers to vector memory, all iterators and so on.
Currently unused, but might become handy when clearing unused data.
The commit implements a guarded allocator which can be used by STL classes
such as vectors, maps and so on. This allocator will keep track of current
and peak memory usage which then can be queried.
New code for allocator is only active when building Cycles with debug flag
(WITH_CYCLES_DEBUG) and doesn't distort regular builds too much.
Additionally now we're using own subclass of std::vector which allows us
to implement shrink_to_fit() method which would ensure capacity of the
vector is as big as it should be (without this making vector smaller will
still use all previous memory allocated).
This replaces our own implementation of aligned malloc with system calls,
which depends on which operation system you're on.
This is probably really minor noticeable change, but in the same time it
might reduce amount of wasted memory.
This reverts the change made in 8872cba7e9
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
It's really handy to have blender linked against jemalloc because of
much better memory fragmentation handling by that library.
To be noted: if jemalloc library is not found it'll be disabled with
message about that, no compilation error should happen.
This way both BLI_assert() and abort() called directly shouldn't
leave any files in the temp folder.
Previously it was really possible to have gadzillions of files
left over because of assert failures and debug aborts during the
development process.
Draw the grid last with depth masking disabled. That should have no ill
effects otherwise as far as I can tell except from some exceptional
cases (axis lines over grid) but this is hardly annoying.
Generally to properly solve such issues we need to have a better render
pipeline with wire objects/materials being drawn after compositing. This
is not impossible but for now doing it the simple way.
Yes, for me tablets (both wacom and no-name) were again broken - curse X11!
So now, we want ButtonPress, Button1Motion does not work anymore...
Anyway, this patch makes things much cleaner, storing each event type
in its own variable!
Patch by cedricp (Cédric PAILLE) from T43367, thanks a bunch!
Originally the files are coming from ancient early-2.4x epoch, but in
theory such setups might have been re-saved multiple times already with
more recent blender versions.
So the verisoning code is applied on all the files, including very
recent ones.
Bumped subversion, because this check si not really cheap.
We make sure that good values are passed to GetPolygon() and we check that the visual mesh doesn't have a wrong displacement when it passes over a object which has a mesh triangle as compound bound.
Reviewers: dfelinto, sergof, agoose77, moguri
Reviewed By: moguri
Subscribers: agoose77
Differential Revision: https://developer.blender.org/D979
The translation and rotation locks subpanel was not used by dynamic physics type to avoid inestability in the application of forces and/or torques. Therefore it is better to remove it from UI (for dynamics) to avoid misunderstandings.
Reviewers: moguri, dfelinto, campbellbarton
Reviewed By: campbellbarton
Subscribers: panzergame
Differential Revision: https://developer.blender.org/D1090
This allows using the same particle system for multiple objects without
creating too much repetitiveness. Each instance object can select a
range of the particles to actually use for instancing (default 1.0 means
all particles are used). To further avoid overlap with multiple
instancing objects, the offset value can be used to make each system
use a specific range of particles.
This commit introduces a few ready made effects for the 3D viewport
and OpenGL rendering.
Included effects are Depth of Field, accessible from camera view
and screen space ambient occlusion. Those effects can be turned on and
tweaked from the shading panel in the 3D viewport.
Off screen rendering will use the settings of the current camera.
WIP documentation can be found here:
http://wiki.blender.org/index.php/User:Psy-Fi/Framebuffer_Post-processing
This was rather annoying, since if you were script-editing a .blend file in background
mode, opened through this commandline option system, and wanted to save over,
a mere `bpy.ops.wm.save_mainfile()` *would not* overwrite expected file,
but instead write/replace the dummy `untitled.blend` one!
This feature has been totally broken for a long time. It was added
originally because negative frames were not supported.
Giving simulations (cloth and others) time to settle before animation
starts needs to be solved in a much better and more generic way.
As brought up in T43595, the Grease Pencil layers list could sometimes end up
taking up too much space when there are no layers. Another issue raised there
was that the up/down buttons are redundant when there is only a single layer.
This commit makes some changes to get these a bit more compact for the case where
you have an empty GPencil datablock left over from previous work.
This commit adds a few generalizations to the VBO
code so that modifiers can create and populate their own GPU objects.
The VBO code originally supported CDDerivedMesh only. The design moves slightly
towards the viewport refactor where the rendering system requests data from the
modifiers.
In this commit only basic support for vertices and normals is provided and
some features from blender's VBO system, suchs as mapping to original faces,
unique element indices for vertices and loose vertex/edge support are missing.
Also, the quick navigation feature of the subsurf modifier won't be supported
for now.
What we do have is full support for solid shading with multiple materials,
flat/smooth shading and a big performance boost.
It's a bit messy, but that is to be expected: all of the areas involved
(particles, shapekeys, depsgraph, drivers) are badly designed and
supposed to get major refactoring ...
Auto View automatically adjusts the view based on selection, so that the view is
always focused on the current selection.
A checkbox in the header is used to access it and it works for the following
selection methods: Toggle All, Border, Circle, Lasso, Left, Right, More, Less,
Linked, Column (so all except of single selection, in which this can be a bit
annoying)
Reviewed by @Aligorith (thanks for that :) )
Only recompute if cost is below -FLT_EPSILON, we can get cases where both cases generate
very tiny negative costs (see 'Cylinder.004' mesh in .blend attached to report).
space the particle data should be interpreted in.
By default the space will now be `Local`, meaning that copies of the
mesh are made with the offset of the respective particle in the particle
object's local space, rather than using the world space offset of the
particle //inside the modified object space//. This behavior is much
more intuitive and consistent with true duplicators, such as face duplis.
Old files will still have `World` setting, so existing blend files are
not changed.
This is obviously total madness, this feature is totally unusable when
the coder is not sitting next to you ... But so are the rest of particle
settings, the only solution is a future node system.
The internal cloth modifier effector weights get replaced temporarily
to make the cloth sim use the particle weight settings instead. But
the particle sim was not putting back the original weights, which can be
non-NULL in case the cloth sim allocated these already. Messy design ...
between stroke and single-add mode.
This was requested especially for use with tablets. With a pen it is
difficult to set a precise point and the tool ends up making multiple
hairs close together all the time. Disabling the stroke option helps
adding individual hairs.
Avoid opening the file when doing uncached reading because ffmpeg takes
quite a long time to read the first frame. Instead, avi jpeg is almost
instantaneous here.
This will leave the anim struct without an Imbuf and that can cause
other unexpected issues elsewhere so commiting on gooseberry first
to try.
Speedup is quite impressive though.
Needless to say, code here quickly becomes a mess and the proxy system
should be made saner but for now just commit to keep things working at
the studio.
This is incompatible with particle data structures in their current form.
Hull drawing requires sorting child particles based on the distance from
their primary parent. However, this changes the order of children, which
is the main method of generating random numbers for them. In the
viewport this is not a problem, but when rendering the children are
constantly recreated, using the respective deformed emitter mesh each
time. This leads to changing child orders when using the convex hull
sorting, and therefore different randomisation values.
To properly implement child hull drawing we would have to generate a
stable parent-child offset metric as well as avoiding any resorting in
the actual data arrays. This in turn requires terribly inefficient
drawing iteration, which could become a bottleneck by itself even before
taking cache coherence or OpenGL optimization requirements into account
(collecting child data into a dedicated buffer for drawing).
Failed proxies will now attempt to fetch a smaller proxy first before
fetching the full resolution. This might allow us to see if we are
hitting a bandwidth issue (due to high res) or a file query issue (due
to more file queries)
to the hair dynamics input DM.
Also this calculation has to happen before caching paths, otherwise
there is a 1-update lag because parent paths still use old values.
and when switching the active key during edit mode.
This is different from how shape key editing works on meshes: there the
edit data (BMEditMesh) stores customdata layers for shape keys, then
writes them back to the mesh. The hair edit mode is a lot more messy and
confusing, it has to update the base data immeditately (with potential
consequences for undo ...)
The code was assuming that child 0 is always valid, but in fact has to
be treated like all others that can be disable due to preview percentage,
virtual parents, etc.
The current algorithm generates a triangle strip to fill the end of
each child bundle. This is not quite ideal, because even though the
base child groups are constructed to be convex, the resulting child
paths can become concave again by clumping, roughness, hair dynamics
etc.. This can create face inversion as well as ugly shading artifacts,
so a nicer algorithm may be desirable.
child hulls.
Note that the perpendicular direction around the hair bundles is not
smooth-shaded. Smooth shading doesn't make as much sense there because
large angles are common in this direction and give awkward shading
results.
This was used as part of the "sim preview" feature, where some amount of
vertices were tagged as disabled in the particle system. Due to the
mind twisting complexity of using the nested cloth modifier to simulate
hair strands indirectly it became necessary to still store all the
vertices, but then disable them again on the solver level ... If this
ever gets reimplemented it must be done in a sane way, avoiding the
cloth step altogether.
mode.
This was caused by variation of the number of keys on child hairs due
to shortening of hair curves based on euclidian distances. The other
kink modes also shorten hairs, but use the parametric distance instead,
which does not vary with deformation of hairs.
By default this now copies from one object's local space to another
object's local space (instead of the previous world space). This is
more useful when transferring particles between objects, because it
doesn't require moving objects on top of each other, as long as they
have similar shapes.
another, including edit data (grooming).
This uses basically the same method as the existing connect/disconnect
feature. The main difference is that it allows working with multiple
objects and transferring the //particle/hair data// instead of the
//mesh// data (which is what connect/disconnect expects). This is a much
more realistic workflow when rigging, topology etc. changes and
groomed hair has to be transferred to the changed model.
This is BAD code, but the particle kinking does not make it easy to
write a non-local modifier that requires neighboring positions,
curvature, etc. The feature is needed for Gooseberry.
This adds another level of clumping on child hairs. When enabled, child
hairs chose a secondary clumping target using a Voronoi pattern. This
adds visual detail on a smaller scale, which is useful particularly when
the number of parents is relatively small.
Natural fibres behave in a similar way when they become sticky and
intertwined. Hairs close to each other form a first twisted strand, then
combine into larger strands. Similar features can be found in ropes:
http://en.wikipedia.org/wiki/Hair_twistshttp://en.wikipedia.org/wiki/Rope
Scope update is very slow for high resolutions, and currently blocks
the UI thread(!). This is especially terrible in paint modes, where
each stroke causes a scope update and unacceptable freezing.
The scopes update method tries to avoid this somewhat by skipping if the
toolbar is disabled, but this doesn't help when painting where brush
tools etc. are frequently needed. It's also a bad-level poll, with the
core system accessing a UI element.
Eventually scope updates should become a low-priority background job,
as well as becoming threaded. Until then this polling provides a usable
workaround to the most outrageous cases.
This is an alternative method to the current fixed function with a
clump factor and "shape" parameter. This function is quite limited and
does not give the desired result in many cases (e.g. long, parallel
rasta strands are problematic). So rather than trying to add more
parameters there is now a fully user-defined optional curve for setting
the tapering shape.
This contains a few pieces of code for a future "modifier" system that
would allow more flexible combination of effects. Eventually a node
system is the way to go, but the current code makes that impossible.
to prevent double-freeing/invalid mem access.
This can happen with the "virtual parents" feature, which generates both
parent and child paths. Each task free function also freed the shared
context, leading to double freeing.
and graph editor.
This was a tricky commit that was not so straightforward to make work.
The information for bones is not easy to come by in the animation curves,
however we do have some string manipulation tricks to make it happen.
For now committing to gooseberry branch for testing, it will be ported
to master after most usual use cases have been confirmed as working.
(Current test with all rotation modes and translation seems to work, but
Not sure how well this will hold up with drivers etc)
Cloth data is used both for hair and actual cloth, which makes things
really difficult. The face number was used for distinguishing the two
types (no faces == hair mesh), but the extra hair data necessary for
hair sim is generated by particles and not available for edge-only cloth
meshes. This really needs to be sanitized ...
Now simply add a flag to the armature modifier to use facemaps. Facemaps
on the mesh object with the same name as the armature bones will get
displayed as widgets.
This is necessary because the hair dynamics settings are not part of the
ParticleSettings datablock, but part of the convoluted cloth modifier
inside the particle system struct. In the future this will be recoded
properly, but in the meantime presets provide a simple an unobtrusive
way to have reusable dynamics settings for hair.
approach does not work very well.
Using a cross section estimate still causes large oscillations due to
varying hair force based on angles. It also requires a sensible hair
thickness value (particle radius) which is difficult to control and
visualize at this point.
The new model is based purely on per-vertex forces, which seems to be
much more stable. It's also somewhat justified by the fact that each
hair vertex represents a certain mass.
* Test display code that displays the active facemap. Will not work on
subsurf modifier yet (crash)
* Fix loading of files with facemaps
* Facemap data now reside on polys instead of tessfaces.
The previous calculation was modulated with the angle between the wind
direction and the segments, which leads to very oscillating behavior.
Now the formula includes an estimate for the geometric cross section
of a hair segment based on the incident angle and the hair thickness
(currently just the particle size). This gives a more stable behavior
and more realistic response to wind.
This commit adds a few generalizations to the VBO
code so that modifiers can create and populate their own GPU objects.
The VBO code originally supported CDDerivedMesh only. The design moves
slightly towards the viewport refactor where the rendering system
requests data from modifiers.
What we do have is support for solid shading with multiple
materials, flat/smooth shading and a big performance boost.
Performance could
In this commit only basic support for vertices and normals is provided
and some features from blender's VBO system, such as mapping to
original faces, unique element indices for vertices and loose vertex/
and can be added later. The one feature that is missing now is the quick
navigation feature of the multires modifier (which uses the same code).
- Why this commit is made on the widget branch -
Facemap widgets need to avoid drawing the whole mesh when we do
collision detection on them. For subsurf drawing we need to iterate
through the whole mesh every time. What we need instead is sort
indexed elemet drawing according to the facemap each face belongs to.
This screams VBOs but since I was going to add that, I thought that
I could push it a bit further and add proper solid shading support.
This commit adds a few generalizations to the VBO
code so that modifiers can create and populate their own GPU objects.
The VBO code originally supported CDDerivedMesh only. The design moves
slightly towards the viewport refactor where the rendering system
requests data from modifiers.
In this commit only basic support for vertices and normals is provided
and some features from blender's VBO system, such as mapping to
original faces, unique element indices for vertices and loose vertex/
and can be added later. The one feature that is missing now is the quick
navigation feature of the multires modifier (which uses the same code).
What we do have is full support for solid shading with multiple
materials, flat/smooth shading and a big performance boost.
Performance could
- Why this commit is made on the widget branch -
Facemap widgets need to avoid drawing the whole mesh when we do
collision detection on them. For subsurf drawing we need to iterate
through the whole mesh every time. What we need instead is sort
indexed elemet drawing according to the facemap each face belongs to.
This screams VBOs but since I was going to add that, I thought that
I could push it a bit further and add proper solid shading support.
This module will contain mirrored functions for calculating and applying
weights for points on a mesh. This includes barycentric and UV weighting
and possibly more advanced global weighting such as harmonic weights.
The naming should follow this scheme:
<type>_{2d,3d}_{calc,apply}
e.g.
poly_2d_calc
poly_2d_apply
uv_3d_calc
...
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D939
A bone using a facemap will not be displayed at all, rather it will use
the facemap of the mesh as an interaction area. The facemap still does
nothing since it's not yet hooked up to the customdata and widget code.
That will come next.
They are set when a highlighted widget intersection is detected and on
area level.
There's a discussion about using owners and a stack or array for cursors
but that needs some more thought and design.
Due to this we -obviously- rename this to overdrop
I am not sure if others would agree here, but it's pretty safe to do
this on a branch first. Rationale is that it's much nicer to work on
full screen with this.
backdrop is now functional.
The widget could communicate with the sequencer properties directly, but
here we set it to control the operator properties as a demonstration.
After some minor stress testing, time to give this to gooseberry team.
Areas support more than one widgetmap - will be useful to partition area
in different transform regions like data, pixel, 3D (will be done in a
separate refactor).
Also get rid of the context widget hack in favour of adding the
widgetmap handler to the operator handler itself, so handling will
be unified when the widget controls a property or spawns an operator
Handle events for widgetmap first when and pass to operator when
operator is active.
This is still a pretty confusing design, working on a simpler one now.
This commit makes it possible to use scenes as a kind of
multi-user metastrip (with their own time).
Currently this supports rendering & drawing nested strips,
but no convenient way to tab-enter into a scene strip.
* Minor cleanup - propname does not need to be stored anymore.
* Code to support modal widgetmap registration for operators - still
untested, but will be tested soon on sequencer cage widget
* Widgets take parameters to initialize property slots that are used for
feedback or control.
Cage now uses this to feed offset/scale to different properties.
* Initialize common properties during widget registration.
remove and add widgetgroup types from the system.
Start operator that will control sequencer backdrop. Architecture here
still needs a little work so good compatibility with Add-ons can be
ensured.
commit and operators to set faces in a group in edit mode.
Face maps are groupings of faces, similar to vertex groups, however,
each face can only belong to one face map.
They will be used for widget interaction, but there will possibly be
more uses for them in the future.
Code needs some cleanup still here, will apply as work is being done.
There is some code here for object mode interaction but it hasn't been
tested yet. This will probably be done with the widgets themselves.
The file wasn't being comiling by CMake, remove it from SCons compilation as well.
Not sure if the same is required in original branch, maybe it'll be redone anyway.
For now let's make it so gooseberry branch is compiling nicely on the buildbot.
transform the x direction of the backdrop in sequencer when a viewer
node is active.
There are still some issues with property transform not being a proper
operator, but we can fix that easily.
To make full 2D transform work we need positions stored in one property.
* Get rid of invalid flag (we avoid drawing widgets by dereferencing RNA
now so it should be OK)
* Add intersect function for 2D widgets (still needs correct mapping to
be any useful though)
A stupid hack is needed here, changing the way the factor is applied to
angular bending springs. In cloth sim the bending factor of individual
springs is applied as a mix value between the bending stiffness and a
max value, but this max value isn't even used in hair sim so that
approach becomes useless.
This helps to create some variation in a hair system, which can
otherwise become very uniform and boring. It's yet another confusing
setting in a system that should have been nodified, but only option for
now (broken windows ...)
Fix interaction when pivot is beside the camera. basically we now do all
calculations in 3D space and we do not scale correct the offset in 3D -
this creates a nasty dependency loop between drawing and calculation for
widgets bound to properties - ie offset depends on scale but scale
depends on screen position - ie offset.
Also added an extra callback to get the final position of the widget in
3d space and use that to calculate the scale. This takes care of
bringing a close to the camera widget to the background and the widget
keeping its initial size. The final position can be different from the
initial position, especially when the widget is offset from the original
position.
framing method instead of the Frenet frame.
The Frenet frame is very succeptible to sudden twists along straight
sections of a curve where the second derivative (curvature) becomes 0.
We now use plane/line intersection which seems to work quite well and
agrees to great extent with the transform system as well. There still
some small discrepancy but may also be related to scaling.
to support multiple hash identifiers.
Using explicit hashing functions for every sim debug call defeats the
purpose of having a quick feedback system. Now this can be done simply
by passing an arbitrary number of hash inputs (integers) at the end of
the function calls, which are then combined by a system of variadic
macros (based on the ELEM feature). Up to 8 identifiers are supported
currently, but more could be added easily if needed.
solver input and output.
This uses the central difference method (instead of combined forward/
backward difference), which makes it easier to correctly account for
grid borders.
samples.
This is just an intermediate method to make sure the density is valid.
Eventually the closest-point method should be used, but for testing
the poisson solver this is easier to debug.
This allows setting a target density which the fluid simulation will
take into account as an additional term in the pressure Poisson
equation. Based on two papers
"Detail Preserving Continuum Simulation of Straight Hair" (McAdams et al. 2009)
and
"Two-way Coupled SPH and Particle Level Set Fluid Simulation" (Losasso et al. 2008)
Currently the target pressure is specified directly, but it will be
a lot more convenient to define this in terms of a geometric value such
as "number of hairs per area" (combined with hair "thickness").
It may be better to use transform code for widgets but this will cause
nested operators for widget/operator and needs some consideration.
For transform e.g. we would have one transform operator taking care of
transformation of the widget, then feeding this back to regular object
transform.
Now widgetmaps get created and destroyed with the area. Not sure if it's
the best design but it avoids too many creations and recreations.
arrow offset now calculated at property binding time - no RNA access
during interaction means no chance of crash during undo.
There are several more or less new customdata layers that currently cannot be accessed via Python (or some are exposed via BMesh API but not via Mesh API). This patch aims to expose one of those layers - CD_PAINT_MASK.
It'd be pretty useful for existing and future addons targeting sculpt workflow. Currently to get some access to the mask we employ a hackish approach via hiding/revealing masked vertices, this adds mode switches and doesn't allow to get actual mask values which could be useful if converted into vertex group weights for later use in e.g. modifiers. With this patch we'd be able to access mask data directly.
Reviewers: campbellbarton
Reviewed By: campbellbarton
Subscribers: radcapricorn
Projects: #bf_blender
Differential Revision: https://developer.blender.org/D782
on the grid.
This uses the Eigen conjugate-gradient solver to solve the implicit
Poisson equation for the pressure Laplacian:
div(grad(p)) = div(v)
As described in "Detail Preserving Continuum Simulation of Straight Hair"
(McAdams, Selle, 2009).
To make this work, we need separate type/instance for the widgets. This
is a bit ugly but it is necessary if we want widgets on each editor to
depend of per editor-options or visibility state.
This is a bit more awkward for artists to use, but necessary for
a stable solution of the hair continuum calculation. The grid size is
defined by the user, the extent of the grid is then calculated based on
the hair geometry. A hard upper limit prevents bad memory allocation
in case too small values are entered.
This is a leftover from previous approach of hair collisions (with
insufficient results). The hair volumetrics actually implements
"collision" with solid objects as well, but uses a Neumann boundary
condition on the main grid for this purpose.
This is based on the paper
"Detail Preserving Continuum Simulation of Straight Hair"
(McAdams, Selle, Ward, 2009)
The main difference is that hair line segments are used rather than only
rasterizing velocity at the vertices. This gives a much better coverage
of the hair volume grid, otherwise gaps can be produced at smaller grid
cell sizes and the distribution is uneven along the hair curve.
The algorithm for rasterizing is a variation of Bresenham's algorithm
extended onto 3D grids.
Still pretty much exploring the best way to move here but currently this
works by wrapping objects in RNA pointers, pretty much like buttons do.
Also modified the arrow widget for lamps to use the new code. The new
"unmbrella" widget works now as expected for lamps - of course fine
tuning is also needed.
* Add gpu options for depth of field to camera - still inactive.
* GPUFXOptions now passed to the compositing system startup
so users can swap options if they wish to
This commit changes read-write data again, people should reset their
values again (sorry for that but this is still WIP)
* Add gpu options for depth of field to camera - still inactive.
* GPUFXOptions now passed to the compositing system startup
so users can swap options if they wish to
This commit changes read-write data again, people should reset their
values again (sorry for that but this is still WIP)
This is working mostly from the 3D viewport currently, rendering from
the render buttons or the sequencer will not use the FX yet. Still it's
a solid step towards that direction. Also moved options out of the v3d
struct. Old options will be lost and people may get some warnings,
however simply enableing and disabling one of the compositing settings
will bring the controls back.
Algorithm used is now a full implementation of
"Practical Post-Process depth of field", presented here [1],
with a few modifications as to how circle of confusion is
applied at the final pass.
[1] http://http.developer.nvidia.com/GPUGems3/gpugems3_ch28.html
solver step.
Calculating forces and jacobians from linearly interpolated grid values
is problematic due to discontinuities at the grid boundaries. The new
approach of modifying velocities after the backward euler solver step
was suggested in a newer paper
"Detail Preserving Continuum Simulation of Straight Hair"
(McAdams, Selle 2009)
more intuitive.
Also removed a couple of unused or useless features from the UI:
* collider friction is unused and replaced in favor of true collision
* spring damping refers to structural springs (stretch), which is
not noticable in hair due to extreme stiffness atm.
* pressure factors are not sure since this feature is too unstable atm.
Interpolating hairs in a meaningful way is a quite difficult problem.
It works ok-ish for child hairs as long as they don't move, but with
motion the direction of interpolated hairs can become quite nonsensical
quickly.
Probably a better way to create simulation previews is to limit
simulation to a particular well-defined area (like render preview
borders), but run it in full detail in that area. The error from
omitting some interaction should still be much less than orientation
errors from interpolation.
easier.
This code is badly broken and needs to be replaced, but at least having
a workable code structure might help with quick hacks to fix the worst
cases.
shape instead of a brush tool.
The brush cutting tool for hair, while useful, is not very accurate and
often requires rotating the model constantly to get the right trimming
on every side. This makes adjustments to a hair shape a very tedious
process.
On the other hand, making proxy meshes for hair shapes is a common
workflow. The new operator allows using such rough meshes as boundaries
for hair. All hairs that are outside the shape mesh are removed, while
those cutting it at some length are shortened accordingly.
The operator can be accessed in the particle edit mode toolbar via the
"Shape Cut" button. The "Shape Object" must be set first and stays
selected as a tool setting for repeatedly applying the shape.
more intuitive.
Also removed a couple of unused or useless features from the UI:
* collider friction is unused and replaced in favor of true collision
* spring damping refers to structural springs (stretch), which is
not noticable in hair due to extreme stiffness atm.
* pressure factors are not sure since this feature is too unstable atm.
Interpolating hairs in a meaningful way is a quite difficult problem.
It works ok-ish for child hairs as long as they don't move, but with
motion the direction of interpolated hairs can become quite nonsensical
quickly.
Probably a better way to create simulation previews is to limit
simulation to a particular well-defined area (like render preview
borders), but run it in full detail in that area. The error from
omitting some interaction should still be much less than orientation
errors from interpolation.
* Scons builds correctly
* Separate vertex shader file for DOF, will make handling main easier
* Downsample color buffer + blur it. Circle of confusion is calculated
from zplane instead of length of distance from camera.
* Cleanup compositing buffers better when not needed.
* Support passes for the dof effect through defines in main - easy
solution to allow not having too many files for one shader effect.
easier.
This code is badly broken and needs to be replaced, but at least having
a workable code structure might help with quick hacks to fix the worst
cases.
Issue here was position reconstruction could use depths from pixels off
the initial position. Using linear filtering here eliminates the issue.
Usually this is not correct however given that for depth discontinuities
we will get different depths anyway, the cases where we get smooth
interpolation of depths helps a lot in image quality.
Basically change the way SSAO samples the screen by using a circular
filter instead. This is inspired by HBAO though we still don't use this.
The quality settings change the number and density of samples. We can
definitely improve things here though.
We also jitter the sampling locations per pixel. Generally this adds a
kind of noise. Some banding is, unfortunately still apparent and small
distances will introduce noise. This can be fixed but I will have to see
if it can be done without much of a cost.
shape instead of a brush tool.
The brush cutting tool for hair, while useful, is not very accurate and
often requires rotating the model constantly to get the right trimming
on every side. This makes adjustments to a hair shape a very tedious
process.
On the other hand, making proxy meshes for hair shapes is a common
workflow. The new operator allows using such rough meshes as boundaries
for hair. All hairs that are outside the shape mesh are removed, while
those cutting it at some length are shortened accordingly.
The operator can be accessed in the particle edit mode toolbar via the
"Shape Cut" button. The "Shape Object" must be set first and stays
selected as a tool setting for repeatedly applying the shape.
explicit attenuation control (by using just max distance).
Also it now supports orthographic cameras properly. The maximum distance is
now defined in world space units so it should be slightly easier to understand
and uniform across perspective and orthographic cameras.
The optimizations can be generalized for orthographic cameras but the code is
more complex and the runtime advantage is questionable in that case
(in the end a matrix transform is 4 dot products which are not that terrible)
so commented out the code there for now.
This needed some adjustments from the formula I found on the article on
view space reconstruction, since OpenGL makes different assumptions about its
projection matrix.
SSAO does not work yet correctly under new model assumptions but we are going
to substitute with nice horizon based ambient occlusion.
* highlighted vs active widget.
Active widget takes all input and basically highjacks drawing of all
other widgets in the widgetmap.
* operator names for widgets. Now widgets will spawn operators based on
names that are passed on them. They will also modify a named property of
the operator and pass it on, after which operator can process it.
The sound system really needs better design for the sequencer and
patching it up now won't really help us in the long run.
Also the sequencer kept leaking file descriptors when preserving
the audio handlles on undo making the branch unusable on mac and
windows.
It's almost certain patching over this will lead to more trouble, better
handle it separately and keep the system working for now.
Kept threaded loading of waveforms since we control the file input
directly there and leads to nice speedup, but we still clear the whole
sound + the waveform on undo, which is pretty bad.
* Move lamp operators to a proper place
* Store a list of widgets to avoid polling too many times
* Fix wrong indices when widgetgroup was not used.
* Lamp widget now uses an arrow widget. This will be refined to make a
nice prototype for operator/widget interaction.
Avoid moving the 'from' pointer around in DNA. This way files stay back-
as well as forward-compatible. Only the additional type enum and
sub-index is stored in a new from_extra struct in shape keys now.
This generates a somewhat believable overall look for the hair system
by blending simulated hairs. For small number of hairs and small
preview ratios this can get quite inaccurate, but that's the tradeoff
for getting preview functionality ...
This is still terribly messy, especially because every change of the
particle system has to be piped through the dummy cloth modifier somehow.
The automatic caching system also tends to get in the way a lot; after
changing the preview factor one basically always has to start at frame 1
currently because the cloth modifier has to be reconstructed and forgets
about all caching.
* Add option for shaded/non shaded widgets
* Normalize arrow widget size to 1.0 so size is predictable. Probably
will use the same scheme for other widgets as well
format (vertices + normals + triangle vertex indices)
This will allow us to create widgets in blender instead of defining them
programmatically.
May also support facegroups for different colors in the future though
they must be somehow tied to the UI colors.
Especially if we have many widgets on screen, sorting them will be
difficult and for mesh-armature widgets it will be unavoidable if we
want to avoid tweaking "back" surfaces.
There is first code for display of an arrow widget. The manipulator will
use those when they are ready.
Basically the manipulator is now a WidgetGroup. WidgetGroups are a new entity and
they manage a group of related widgets. They should be responsible for state update,
drawing and polling of their widgets and can be bound to specific rules.
There is a big design plan on a whiteboard beside me, it will take a few
big commits still to take shape though. One thing at a time, I am first making
reusable arrow widgets that will allow us replace the translate widgets properly.
There are a few reusable widgets planned, more to come later.
distribution and path caching for child particles.
This gives a significant improvement of viewport playback performance
with higher child particle counts. Particles previously used their own
threads and had a rather high limit for threading. Also threading
apparently was disabled because only 1 thread was being used ...
This is not necessary: the implicit solver data can keep track instead
of how many off-diagonal matrix blocks are in use (provided the
allocation limit is calculated correctly). Every time a spring is
created it then simply increments this counter and uses the block index
locally - no need to store this persistently.
Without this the particle system only shows the actual non-simulated
hairs ("guide hairs") during edit mode. These hairs are used for goals
as well, so showing them in the regular viewport is pretty important.
Also the usual hair curves are interpolated along the entire length,
which makes it very difficult to see exact vertex positions, unless
using exact powers of 2 for the segment number and match the display
steps.
too.
Rationale - widgets might be useful to have even on rendered scenes -
we'll have to see about how this will work
Also use area initialization code to register region specific widgets once.
lala
The curl radius for children in interpolated mode was calculated using
the total offset from the parent particle. This leads to very large
radii when the distance is large due to sparse parents. Such behavior is
also very unrealistic because the curl radius is mostly constant and
defined by the material properties.
All the child hairs are roughly parallel by default. To simulate the
agglomeration of children into hair wisps the "flatness" parameter is
now used to clump them together.
This should use an "active" system, similar to buttons to detect if last
widget has changed and act accordingly. Currently, when the active
widget changes, there is no change in highlights.
Code that handles 3D object intersection via GPU selection. We might
want to use raycasting here, but leaving that for when we have it.
Manipulator code now uses this API to do intersection testing
Widgets use a similar notification system as operators. It might be
worth using WM_BREAK messages like the rest of the handlers. For now
this should do.
With the default 5 substeps the simulation can otherwise still become
unstable. This is just a preliminary measure anyway until the length
variance can be fixed properly.
This is more involved than using simple straight bending targets
constructed from the neighboring segments, but necessary for restoring
groomed rest shapes.
The targets are defined by parallel-transporting a coordinate frame
along the hair, which smoothly rotates to avoid sudden twisting (Frenet
frame problem). The rest positions of hair vertices defines the target
vectors relative to the frame. In the deformed motion state the frame
is then recalculated and the targets constructed in world/root space.
This commit moves sound loading out of library linking. The approach
chosen here is to do lazy initialization by basically validating the
sound before attaching to the scene.
Loading the sound buffer requires a valid Main pointer, which means we
have to pass this around in many places. We might also consider caching
the waveforms in this way too, but for now we're still using the
threaded update.
We'll have to test this somewhat to see if it behaves well..There are
corner cases which might not be covered. Sounds are muted if we undo
during an animation, but this bug existed in master as well.
Sound loading can take too much so move it to a job and continue. This makes
interaction much better. A similar system should be usable for movie previews.
derivatives for stabilization.
The bending forces are based on a simplified torsion model where each
neighboring point of a vertex creates a force toward a local goal. This
can be extended later by defining the goals in a local curve frame, so
that natural hair shapes other than perfectly straight hair are
supported.
Calculating the jacobians for the bending forces analytically proved
quite difficult and doesn't work yet, so the fallback method for now
is a straightforward finite difference method. This works very well and
is not too costly. Even the original paper ("Artistic Simulation of
Curly Hair") suggests this approach.
This returns a general status (success/no-convergence/other) along with
basic statistics (min/max/average) for the error value and the number
of iterations. It allows some general estimation of the simulation
quality and detection of critical settings that could become a problem.
Better visualization and extended feedback can follow later.
waveform display.
Basically, we store the waveform. This is not really recommended but
until we have nice threaded creation for the strips that doesn't block
the interface it's a nice solution for gooseverry.
May be wise to limit the undo memory for people who use that because
basically each operation will store a copy of the waveform in the file.
This makes the bending a truely local effect. Eventually target
directions should be based in a local coordinate frame that gets
parallel transported along the curve. This will allow non-straight
rest shapes for hairs as well as supporting twist forces. However,
calculating locally transformed spring forces is more complicated.
This commit has first WIP code for widgets API.
Generally widgets should be registered similar to dropboxes, that is,
any code can query for a widgetmap for a certain space and area type
and the window manager will take care of initializing the handlers
automatically.
The owner will be able remove and readd widgets to a certain widgetmap
dynamically. Generally owners should cleanup their widgets though initial code
cleans up leftover widgets automatically.
All this is the theory still, some parts are in that commit, more to come
later, but it's a solid base to build from for an initial commit.
These are much better suited for creating stiff hair. The previous
bending springs are based on "push" type spring along the hypothenuse
of 3 hair vertices. This sort of spring requires a very large force
in the direction of the spring for any angular effect, and is still
unstable in the equilibrium.
The new bending spring model is based on "target" vectors defined in a
local hair frame, which generates a force perpendicular to the hair
segment. For further details see
"Artistic Simulation of Curly Hair" (Pixar technical memo #12-03a)
or
"A Mass Spring Model for Hair Simulation" (Selle, Lentine, Fedkiw 2008)
Currently the implementation uses a single root frame that is not yet
propagated along the hair, so the resulting rest shape is not very
natural. Also damping and derivatives are still missing.
single transform matrix.
Dynamic properties of the transformation are only needed during the
setup phase when they should be read from external data (hair system
roots) and generate fictitious forces on each point.
This is part of the original method from "Volumetric Methods for
Simulation and Rendering of Hair". The current filter is a simple box
filter. Other energy-preserving filters such as gaussian filtering
can be implemented later.
The filter size is currently given as a cell count. This is not ideal,
rather it should use a geometrical length value, but this is too
abstract for proper artistical use. Eventually defining the whole grid
in terms of spatial size might work better (possibly using an external
object).
at a the margin distance ("outer" softbody margin).
This has to be clamped arbitrarily unfortunately, otherwise the
repulsion force can add too much energy into the system. A factor of
4 * restitution impulse seems to give good results for now, this can
be refined later on if necessary.
This is now also decoupled from the internal solver data. The grid is
created as an opaque structure, filled with vertex or collider data
(todo), and then forces can be calculated by interpolating the grid at
random locations. These forces and derivatives are then fed into the
solver.
The hair solver needs sane input to converge within reasonable time
steps. In particular the spring lengths must not be too difference
(factor 0.01..100 or so max, this is comparable to rigid body simulation
of vastly different masses, which is also unstable).
The basic hair system generate strands with equally spaced points, which
is good solver material. However, the hair edit operators, specifically
the cutting tool, can move points along the strands, creating tightly
packed hair points. This puts the solver under enormous stress and
causes the "explosions" observed already during the Sintel project.
The simple solution for now is to exclude very short hairs from the
simulation. Later the cutting tool should be modified such that it
keeps the segments roughly at the same length and throws away vertices
when the hair gets too short (same goes for the extension tool).
The hair system should have a general mechanism for making sure that
situations such as this don't occur. This will have to be a design
consideration for replacements in any future hair system.
Also avoid recreating the framebuffers and gpu/color textures each
frame.
Happiness :)
There are still some glithes when scaling the areas, I'll look at those
next.
* Expose attenuation value - allows to change influence of far objects
* Change influence of far objects to quadratic, eliminates some extreme
fringing from far occluding surfaces.
This works by using the calculated view space normal and accumulating
coverage of a certain area by nearby pixels. There are two sliders to
control the effect:
* Scale controls the area around each pixel that the shader "collides"
against
* Darkening scales the occlusion effect.
The effect works, but due to the way the normals are calculated, the
normals are never smooth shaded (that would require a separate render
target to store them) and the edges or polygons can be too apparent.
This is not really fixable at the moment unless we move to deferred
pipeline.
The FX system is stll not well optimized and rendering does not always
work correctly, but it's good to have this out for people to play with.
moving hair root reference frames.
This calculates Euler, Coriolis and Centrifugal forces which result
from describing hair in a moving reference frame.
http://en.wikipedia.org/wiki/Fictitious_force
frames.
These forces don't have to be calculated for each individual
contribution. Rather they can be split off and be calculated on top of
the basic force vector rotation (todo).
There are currently 3 types of springs: basic linear springs, goal
springs toward a fixed global target (not recommended, but works) and
bending springs.
These are agnostic to the specific spring definition in the cloth system
so hair systems can use the same API without converting everything to
cloth first.
code.
The implicit solver itself should remain agnostic to the specifics of
the Blender data (cloth vs. hair). This way we could avoid the bloated
data conversion chain from particles/hair to derived mesh to cloth
modifier to implicit solver data and back. Every step in this chain adds
overhead as well as rounding errors and a possibility for bugs, not to
speak of making the code horribly complicated.
The new subfolder is named "physics" since it should be the start of a
somewhat "unified" physics systems combining all the various solvers in
the same place and managing things like synchronized time steps.
This commit introduces offscreen rendering for the 3D viewport.
There is test code that calculates depth and normal data
in screen space.
Currently just DOF is supported with a few parameters to control the
effect
This code recreates the framebuffer and texture objects every frame
which will make it -slow-. Use at your own risk.
handle only one collision contact at a time.
Collision still randomly explodes, even with differing results on the
same file. This could indicate a threading issue, possibly also related
to the dependency graph since multiple objects are involved in
collisions.
This reverts commit c52b8ae818.
Sadly, at this point solver convergence is an exception rather than the
rule... Individual hairs can "explode" easily and thus disable the whole
simulation, which isn't helpful either.
This helps keep the simulation stable as long as there are only a few
substeps that become too constrained for the solver.
Eventually we need better feedback about these solver results, so that
artists can tweak situations specifically to resolve bad solver results.
This is somewhat similar to the camera tracker, which also can run into
cases that cannot be resolved and have to be fixed manually.
The Eigen solver is not quite stable currently (possibly due to
incorrect porting of force calculations). It also still lacks threading
support and optimized matrix construction, making it slower in
comparison. Eventually would still like to switch, but fixing these
issues takes time.
This adds transformations for each hair from world to "root space".
Currently positions and velocities are simply transformed for the solver
data and inverse-transformed when copying the results back to the cloth
data. This way the hair movement becomes independent from the movement
of the emitter object. Eventually the "fictitious" forces originating
from emitter movement can be added back in a controlled way.
http://en.wikipedia.org/wiki/Fictitious_force
Ignoring these fictitious forces or scaling their effect is physically
correct, because in the absence of external forces the hair will always
return to rest position in this root frame.
External forces currently are not yet transformed into the root space.
mode.
Eigen can become very slow in debug mode, which is a bit of a problem.
It relies heavily on compiler optimizations to remove function calls
etc. More optimizations may be desirable, possibly putting the implicit
solver into its own little library and enabling optimizations in debug
mode there could help.
This will allow us to implement moving reference frames for hair and
make "fictitious" forces optional, aiding in creating stable and
controllable hair systems.
Adding data in this place is a nasty hack, but it's too difficult to
encode as a DM data layer and the whole cloth modifier/DM intermediate
data copying for hair should be removed anyway.
This is not nice at all, but for some reason (possibly time scale) the
old force values are much too high and cause the solver to become
unstable. These will be revisited later anyway, so for now such scaling
should be fine.
constraining.
The algorithm is described in the paper "Large Steps in Cloth Simulation"
(Baraff/Witkin 1998). The same method was (incorrectly) implemented in
the old cloth solver.
It is based on restricting the degrees of freedom (ndof) of vertices
using a block matrix and a vector of target velocity deltas.
See chapter 5 of the paper for details.
Note that goal springs currently are really bad ... They have a factor
on hairs that "fades" goal influence from the root to the tip. The last
point on the hair is completely free, which makes the goal springs
pretty much useless on their own without supporting bend stiffness.
Can only assume this was added to compensate unphysical behavior of
goal springs when using uniform weight, but it's a poor replacement for
true localized bending forces ...
a custom built solver.
The old cloth solver is broken unfortunately. Eigen is a designated
linear algebra library and very likely their implementation is a lot
better (can't compare until it's implemented though).
Only basic gravity is active atm, spring forces, external force fields,
damping and volumetric friction have to be added back by converting
the data into the Eigen format.
responses.
The S matrix together with the z Vector encodes the degrees of freedom
of a colliding hair point and the target velocity change. In a collision
the hair vertex is restricted in the normal direction (when moving
toward the collider) and the collision dynamics define target velocity.
This simply uses the position above the triangle instead of the
intersection point of the vertex path. The other method was broken
anyway, but also has a problem catching all the contacts reliably. The
new method might have a few false positives but that is acceptable.
the contents of the strip around.
Only tested with movie strips now, metastrips won't work. Also there
might be some lingering bugs. Sonetimes refresh is needed to get
contents showing up correctly.
solver that properly supports constraints with some degrees-of-freedom.
The previous solver implementation only used the S matrix (constraint
filter matrix) for pinning vertices, in which case all elements are
zero and the error doesn't show up. With partial constraints (useful for
collision contacts) the matrix has non-zero off-diagonal elements and
the algorithm easily diverges.
There are also initial steps for implementing collision prevention as
described in the Baraff/Witkin paper "Large Steps in Cloth Simulation"
(http://www.cs.cmu.edu/~baraff/papers/sig98.pdf).
This is a first test, the contacts are very explosive atm because they
basically pin hair vertices globally on collision, which leads to
stretching of the springs which is then suddenly released in the next
frame.
Instead of handling contact tests and collision response in the same
function in collision.c, first generate contact points and return them
as a list, then free at the end of the stepping function. This way the
contact response can be integrated into the conjugate gradient method
properly instead of using the hackish and unstable double evaluation
that is currently used.
The original BLI method for line/triangle intersection returns false
in case the line does not actually intersect, but in order to generate
repulsion forces we need to also handle contacts inside the margin.
timestep segment.
This ensures the distance for a collision pair is the one of the current
point position, and the response gets calculated accordingly.
simulation.
Note that this currently generates an extreme amount of points, by
making a edit pathcache curve for each hair in every frame! But at least
doesn't simply crash now.
This implements a penalty force as well as a repulsion force to avoid
further penetration, as suggested in
"Simulating Complex Hair with Robust Collision Handling"
(http://graphics.snu.ac.kr/publications/2005-choe-HairSim/Choe_2005_SCA.pdf)
Friction forces are still missing. More problematic is handling of
moving colliders, when face swap places with the hair vertex and a
collision is missed, putting the vertex inside the mesh volume. Larger
margins might help, but ultimately using Bullet collision detection is
probably more reliable and failsafe.
as forces, velocities, contact points etc.
This uses a hash table to store debug elements (dots, lines, vectors at
this point). The hash table allows continuous display of elements that
are generated only in certain time steps, e.g. contact points, while
avoiding massive memory allocation. In any case, this system is really
a development feature, but very helpful in finding issues with the
internal solver data.
This is still using the old BVH tree collision methods to generate
contact points, similar to what cloth does. This should be replaced
by a Bullet collision check, but generating contacts in this way is
easier for now, and lets us test responses and stability (although in
more complex collision cases the BVH method fails utterly, beside being
terribly inefficient with many colliders).
on itself.
This uses the same voxel structure as the hair smoothing algorithm.
A slightly different method was suggested in the original paper
(Volumetric Methods for Simulation and Rendering of Hair), but this is
based on directing hair based on a target density, which is another
way of implementing global goals. Our own approach is to define a
pressure threshold above which the hair is repelled in the density
gradient direction to simulate internal pressure from collisions.
This is an important hair interaction feature that simulates friction
between hairs in an efficient way. The method is based on the paper
"Volumetric Methods for Simulation and Rendering of Hair"
( http://graphics.pixar.com/library/Hair/paper.pdf )
It was partially implemented already, but didn't work in this simplified
version. The same voxel structure can be used for implemeting repelling
forces on hair based on density, which can help a hair system maintain
volume instead of collapsing in on itself.
the suggested tent function from the original paper.
Plain float->int conversion for the grid location otherwise leads to
skewed data and unnecessary loss of information.
@@ -197,10 +197,10 @@ option(WITH_PYTHON "Enable Embedded Python API (only disable for develop
option(WITH_PYTHON_SECURITY"Disables execution of scripts within blend files by default"ON)
mark_as_advanced(WITH_PYTHON)# dont want people disabling this unless they really know what they are doing.
mark_as_advanced(WITH_PYTHON_SECURITY)# some distributions see this as a security issue, rather than have them patch it, make a build option.
set(WITH_PYTHON_SECURITYONCACHEBOOL"ON"FORCE)# temp force on.
option(WITH_PYTHON_SAFETY"Enable internal API error checking to track invalid data to prevent crash on access (at the expense of some effeciency, only enable for development)."OFF)
option(WITH_PYTHON_MODULE"Enable building as a python module which runs without a user interface, like running regular blender in background mode (experimental, only enable for development)"OFF)
mark_as_advanced(WITH_PYTHON_SAFETY)
option(WITH_PYTHON_MODULE"Enable building as a python module which runs without a user interface, like running regular blender in background mode (experimental, only enable for development), installs to PYTHON_SITE_PACKAGES (or CMAKE_INSTALL_PREFIX if WITH_INSTALL_PORTABLE is enabled)."OFF)
if(APPLE)
option(WITH_PYTHON_FRAMEWORK"Enable building using the Python available in the framework (OSX only)"OFF)
endif()
@@ -260,6 +260,10 @@ endif()
# (unix defaults to System OpenJPEG On)
option(WITH_SYSTEM_OPENJPEG"Use the operating systems OpenJPEG library"OFF)
if(UNIXANDNOTAPPLE)
option(WITH_SYSTEM_EIGEN3"Use the systems Eigen3 library"OFF)
@@ -78,6 +78,14 @@ base class --- :class:`SCA_IObject`
The object must have a physics controller for the mass to be applied, otherwise the mass value will be returned as 0.0.
..attribute:: isSuspendDynamics
The object's dynamic state (read-only).
:type:boolean
..seealso:::py:meth:`suspendDynamics` and :py:meth:`restoreDynamics` allow you to change the state.
..attribute:: linearDamping
The object's linear damping, also known as translational damping. Can be set simultaneously with angular damping using the :py:meth:`setDamping` method.
@@ -145,16 +153,28 @@ base class --- :class:`SCA_IObject`
..attribute:: groupMembers
Returns the list of group members if the object is a group object, otherwise None is returned.
Returns the list of group members if the object is a group object (dupli group instance), otherwise None is returned.
:type::class:`CListValue` of :class:`KX_GameObject` or None
..attribute:: groupObject
Returns the group object that the object belongs to or None if the object is not part of a group.
Returns the group object (dupli group instance) that the object belongs to or None if the object is not part of a group.
:type::class:`KX_GameObject` or None
..attribute:: collisionGroup
The object's collision group.
:type:bitfield
..attribute:: collisionMask
The object's collision mask.
:type:bitfield
..attribute:: collisionCallbacks
A list of functions to be called when a collision occurs.
@@ -432,6 +452,12 @@ base class --- :class:`SCA_IObject`
If true, the object's and children's debug properties will be displayed on screen.
:type:boolean
..attribute:: currentLodLevel
The index of the level of detail (LOD) currently used by this object (read-only).
:type:int
..method:: endObject()
@@ -647,13 +673,19 @@ base class --- :class:`SCA_IObject`
@@ -83,6 +83,12 @@ base class --- :class:`PyObjectPlus`
This can be set directly from python to avoid using the :class:`KX_SceneActuator`.
..attribute:: world
The current active world, (read-only).
:type::class:`KX_WorldInfo`
..attribute:: suspended
True if the scene is suspended, (read-only).
@@ -119,21 +125,27 @@ base class --- :class:`PyObjectPlus`
:type:list
..attribute:: pre_draw_setup
A list of callables to be run before the drawing setup (i.e., before the model view and projection matrices are computed).
:type:list
..attribute:: gravity
The scene gravity using the world x, y and z axis.
:type:Vector((gx, gy, gz))
..method:: addObject(object, other, time=0)
..method:: addObject(object, reference, time=0)
Adds an object to the scene like the Add Object Actuator would.
:arg object:The object to add
:arg object:The (name of the) object to add.
:type object::class:`KX_GameObject` or string
:arg other:The object's center to use when adding the object
:type other::class:`KX_GameObject` or string
:arg time:The lifetime of the added object, in frames. A time of 0 means the object will last forever.
:arg reference:The (name of the) object which position, orientation, and scale to copy (optional), if the object to add is a light and there is not reference the light's layer will be the same that the active layer in the blender scene.
:type reference::class:`KX_GameObject` or string
:arg time:The lifetime of the added object, in frames. A time of 0 means the object will last forever (optional).
@@ -8,19 +8,17 @@ This module wraps OpenGL constants and functions, making them available from
within Blender Python.
The complete list can be retrieved from the module itself, by listing its
contents: dir(bgl). A simple search on the net can point to more
contents: dir(bgl). A simple search on the web can point to more
than enough material to teach OpenGL programming, from books to many
collections of tutorials.
The "red book": "I{OpenGL Programming Guide: The Official Guide to Learning
OpenGL}" and the online NeHe tutorials are two of the best resources.
Here is a comprehensive `list of books <http://www.opengl.org/documentation/books/>`_ (non free). The `arcsynthesis tutorials <http://www.arcsynthesis.org/gltut/>`_ is one of the best resources to learn modern OpenGL and `g-truc <http://www.g-truc.net/post-tech-content-sample.html>`_ offers a set of extensive examples, including advanced features.
..note::
You can use the :class:`Image` type to load and set textures.
See :class:`Image.gl_load` and :class:`Image.gl_load`,
@@ -15,7 +15,7 @@ subject to the following restrictions:
/**
* @mainpage Bullet Documentation
* @page Bullet Documentation
*
* @section intro_sec Introduction
* Bullet is a Collision Detection and Rigid Body Dynamics Library. The Library is Open Source and free for commercial use, under the ZLib license ( http://opensource.org/licenses/zlib-license.php ).
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
