Issue was caused by rare cases when camera move happens just after
last sample was finished, this would lead to missing delay reset
because render cycle will go to pause_cond.wait(). No reset will
happen at this point because of some kind of optimization which
checks whether camera is tagged for update and wouldn't do reset
in this case.
Talked to Brecht and seems this optimization is not actually needed
and removing it will solve issue with frozen preview.
Issue was caused by couple of circumstances:
- Normal Map node requires tesselated faces to compute tangent space
- All temporary meshes needed for Cycles export were adding to G.main
- Undo pushes would temporary set meshes tessfaces to NULL
- Moving node will cause undo push and tree re-evaluate fr preview
All this leads to threading conflict between preview render and undo
system.
Solved it in way that all temporary meshes are adding to that exact
Main which was passed to Cycles via BlendData. This required couple
of mechanic changes like adding extra parameter to *_add() functions
and adding some *_ex() functions to make it possible RNA adds objects
to Main passed to new() RNA function.
This was tricky to pass Main to RNA function and IMO that's not so
nice to pass main to function, so ended up with such decision:
- Object.to_mesh() will add temp mesh to G.main
- Added Main.meshes.new_from_object() which does the same as to_mesh,
but adds temporary mesh to specified Main.
So now all temporary meshes needed for preview render would be added
to preview_main which does not conflict with undo pushes.
Viewport render shall not be an issue because object sync happens from
main thread in this case.
It could be some issues with final render, but that's not so much
likely to happen, so shall be fine.
Thanks to Brecht for review!
When using triangle primitives this fix enables 'closed tip'.
UVs and vertex colours are added when using triangle primitives for hair.
Two new preset modes have also been included to allow easy access to curves and triangle planes.
Issue was caused by cycles trying to find builtin images in a main
database and in case of preview render images are not in database,
they're just referenced by shader node tree.
Now builtin images in cycles have got void* pointer to store data
needed to load builtin images.
In case ob blender session, this pointer will store pointer from
PointerRNA for image datablock and used later to construct Image
class based on this pointer.
This also saves database lookup for final render which is nice :)
Reviewed by Brecht.
Addition of a RNA function to toggle between the hair settings and rebuild the cache. This enables the usage of the render step, child number and full display percentage with f12 rendering.
A scaling to the strand radius has also been added for the static bvh. This only matches up with dynamic for uniform scaling.
A very small fix is included for multiple uvs/vertex colours when using child particles.
Patch by Sergey, .blend by Thomas and some further tweaks by me.
Still to solve later: allow external engines to specify own preview .blend, for
now the code here is doing too much magic hacking on the preview scene still.
Added export of multiple UV coordinates and vertex colour attributes.
A debugging option to export the strands without using the cache has also been removed.
Add operators to add/remove rigid body world and objects.
Add UI scripts.
The rigid body simulation works on scene level and overrides the
position/orientation of rigid bodies when active.
It does not deform meshes or generate data so there is no modifier.
Usage:
* Add rigid body world in the scene tab
* Create a group
* Add objects to the group
* Assign group to the rigid body world
* Play animation
For convenience the rigid body tools operators in the tools panel of the 3d view
will add a world, group and add objects to the group automatically so you only have
to press one button to add/remove rigid bodies to the simulation.
Part of GSoC 2010 and 2012.
Authors: Joshua Leung (aligorith), Sergej Reich (sergof)
This adds support of movie textures for Cycles rendering.
Uses the same builtin images routines as packed/generated images,
but with some extra non-rna hookups from blender_session side.
Basically, it's not so clear how to give access to video frames
via C++ RNA -- it'll require exposing ImBuf to API, doing some
threading locks and so. Ended up adding two more functions which
are actually bad level call, but don't consider it's so much bad
-- we have few bad calls already, which are actually related.
Changed a bit how builtin images names are passing to image
manager. Now it's not just an ID datablock name, but also a frame
number concatenated via '@' character, which makes itpossible to
easily know frame number to be used for movie images, without
adding extra descriptors to image manager.
Decoding of builtin name is a bit slower now, but it should be
still nothing in comparison with rendering complexity.
Also exposed image user's frame_current to python API, which
is needed to get absolute frame number of movie from node's
image user.
P.S. Generated/packed images are also using bad level call but
only does it to make things more clear here. Either all images
are using C++ RNA here or no images does. That's the most clear
for now.
The curve segment primitive has been added. This includes an intersection function and changes to the BVH.
A few small errors in the line segment intersection routine are also fixed.
* CUDA: Make it more clear that sm_12 and below is not supported.
* OpenCL: __KERNEL_SHADING__ was declared twice for nvidia opencl device.
* Some reshuffle of defines in kernel_types.h. No functional changes.
precompiled cubins instead,
Logic here is following now:
- If there're precompiled cubins, assume CUDA compute is available,
otherwise
- If cuda toolkit found, assume CUDA compute is available
- In all other cases CUDA compute is not available
For windows there're still check for only precompiled binaries,
no runtime compilation is allowed.
Ended up with such decision after discussion with Brecht. The thing
is, if we'll support runtime compilation on windows we'll end up
having lots of reports about different aspects of something doesn't
work (you need particular toolkit version, msvc installed, environment
variables set properly and so) and giving feedback on such reports
will waste time.
makes CPU kernel compilation much faster when using MSVC.
Sideeffect of this change is that CPU rendering is few percent
faster now. CUDA rendering is the same speed.
