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
That was more like workaround which solved particular issue with freestyle
rendering, but introduced some more uncontrollable issues, main of which is
recursive fracture would likely suffer from non-manifolds results of previous
step.
Boolean operation is not the only way to generate zero-area face, it could
also happen with character animation and it's indeed better be solved from
freestule side.
This should fix: #33041 Boolean difference sometimes produces meshes with holes
Issue was caused by changed order of texture slots -- float textures
have got lower slots indices than byte textures. OpenCL was still assuming
byte textures goes before float.
Now tile size is setting up explicitly instead of using number of tiles.
This allows better control over GPU performance, where having tiles aligned
to specific size makes lots of sense.
Still to come: need to update startup.blend to make tiles size 64x64.
This commit adds memory usage information while rendering.
It reports memory used by device, meaning:
- For CPU it'll report real memory consumption
- For GPU rendering it'll report GPU memory consumption, but it'll
also mean the same memory is used from host side.
This information displays information about memory requested by Cycles,
not memory really allocated on a device. Real memory usage might be
higher because of memory fragmentation or optimistic memory allocator.
There's really nothing we can do against this.
Also in contrast with blender internal's render cycles memory usage
does not include memory used by scene, only memory needed by cycles
itself will be displayed. So don't freak out if memory usage reported
by cycles would be much lower than blender internal's.
This commit also adds RenderEngine.update_memory_stats callback which
is used to tell memory consumption from external engine to blender.
This information is used to generate information line after rendering
is finished.
"interface" appeared to be a shadowed var (or even a macro/define elsewhere)
which was causing errors like:
intern\cycles\blender\blender_mesh.cpp:124:23: error: multiple types in one
declaration
intern\cycles\blender\blender_mesh.cpp:124:23: error: declaration does not
declare anything [-fpermissive]
Windows systems: text editor, text object, doesn't allow to input the standard
set of ALT+key characters (the ones coming from the OS).
- Reverted fix january 2012 - that meant to use text object ALT+keys
- Removed old (90ies) feature for hardcoded special characters in Text object.
(OS delivers this now)
Will wait for confirmation by windows compiler :)
