This commit makes BKE_image_acquire_ibuf referencing result, which means once
some area requested for image buffer, it'll be guaranteed this buffer wouldn't
be freed by image signal.
To de-reference buffer BKE_image_release_ibuf should now always be used.
To make referencing working correct we can not rely on result of
image_get_ibuf_threadsafe called outside from thread lock. This is so because
we need to guarantee getting image buffer from list of loaded buffers and it's
referencing happens atomic. Without lock here it is possible that between call
of image_get_ibuf_threadsafe and referencing the buffer IMA_SIGNAL_FREE would
be called. Image signal handling too is blocking now to prevent such a
situation.
Threads are locking by spinlock, which are faster than mutexes. There were some
slowdown reports in the past about render slowdown when using OSX on Xeon CPU.
It shouldn't happen with spin locks, but more tests on different hardware would
be really welcome. So far can not see speed regressions on own computers.
This commit also removes BKE_image_get_ibuf, because it was not so intuitive
when get_ibuf and acquire_ibuf should be used.
Thanks to Ton and Brecht for discussion/review :)
Initial support of OSL builds using SCons build system. Only tested on Linux now.
No changes to configuration files themselves -- for now check how it's configured
for linux buildbot (it was already horror to make all this changes and verify them,
changes to linux-config.py could easily be done later).
Currently WITH_BF_STATICOSL and WITH_BF_STATICLLVM are more like rudiments because
linking against oslexec requires special trick with --whole-archive. We woul either
need to find a way dealing with this oslexec less hackish or drop STATICOSL and
STATICLLVM flags. Will keep dropping this flags for until we have "final" build
rules for OSL.
Still can not make 32bit linux rendering with OSL -- blender simply crashes when
starting rendering. So for time being this issues are solving disabled OSL for
32bit build slaves.
problem is that the curved interpolation is not constant speed which leads to
mismatches. Turns out this is really hard to solve and implement efficiently, so
curved motion blur is disabled for now, until I can find a solution.
compute_device_list is using static vector of device information which
had pointers (identifier and name) to values from device information
structures. That structures are also stored in static vector and being
refreshed every 5 seconds.
The issue is, as soon as device information is being updated, pointers
in vector from compute_device_list became incorrect.
Seems it was the reason of issues with sudden switching from CUDA to
OpenCL on my desktop and from CUDA to CPU on my laptop, It was also
seems to be making persistent images behaves instable.
Made it so device identifier and name are copied from device info
to structures used by RNA (CCLDeviceInfo).
Alternative could be avoid cacheing CCLDeviceInfo and always use actual
list of device information by RNA. It shouldn't be so much slow.
was added for cycles.
This fixes the case where the option is disabled. I moved the option now to
Blender itself and made it keep the engine around only when it's enabled. Also
fixes case where there could be issues when switching to another renderer.
r = lens * theta
Thanks for Adriano Oliveira for reporting this and chasing down the right formula.
Now fulldome works no longer need to use equisolid + a specific lens+sensor size.
And happy birthday to me. And yes, that's how I celebrate it ;)
This option enables keeping loaded images in the memory in-between
of rendering.
Implemented by keeping render engine alive for until Render structure
is being freed.
Cycles will free all data when render finishes, optionally keeping
image manager untouched. All shaders, meshes, objects will be
re-allocated next time rendering happens.
Cycles cession and scene will be re-created from scratch if render/
scene parameters were changed.
This will also allow to keep compiled OSL shaders in memory without
need to re-compile them again.
P.S. Performance panel could be cleaned up a bit, not so much happy
with it's vertical alignment currently but not sure how to make
it look better.
P.P.S. Currently the only way to free images from the device is to
disable Persistent Images option and start rendering.
There were a bunch of other issues with dupli motion blur and syncing, the problem
being that there was no proper way to detect corresponding duplis between frames
or updates. As a solution, a persistent_id was added to the DupliObject. It's an
extension of the previous index value, with one index for each dupli level. This
can be used to reliably find matching dupli objects between frames. Works with
nested duplis, multiple particle systems, etc.
for now subtype is not defined, but once we start parsing the metadata we can set texture inputs as FILEPATH
also, it takes relative strings and convert to absolute for all strings (which is arguably a good solution, but
should work for now)
rays from the OSL shader. The "shade" parameter is not supported currently, but
attributes can be retrieved from the object that was hit using the
getmessage("trace", ..) function.
As mentioned in the OSL specification, this function can't be used instead of
lighting, the main purpose is to allow shaders to "probe" nearby geometry, for
example to apply a projected texture that can be blocked by geometry, apply
more “wear” to exposed geometry, or make other ambient occlusion-like effects.
http://wiki.blender.org/index.php/Doc:2.6/Manual/Render/Cycles/Nodes/OSL#Trace
Example .blend and render:
http://www.pasteall.org/blend/17347http://www.pasteall.org/pic/show.php?id=40066
