It was possible to have issues in cases when several child dependencies
goes to IDs with different layers. In this case order of flushing was not
really well defined, which could lead to cases when indirect dependency
via invisible object wouldn't work.
Need some sort of barrier to prevent scheduling of parent nodes for until
all children are done, but that's becoming quite nasty thing to implement.
Added a temp field to component for now. maybe it's not so crazy actually
and we might use it for evaluation as well, so we wouldn't flush updates
to components which does not affect visible stuff.
Note that this only removes the actual dependencies of Cycles on the
particle code in Blender, but not the internal "particle" definition
or the curve type handling inside Cycles. These structures may be in need
of some improvement themselves, but that is out of scope here.
Basically the idea is to make code robust against extending
enum options in the future by falling back to a known safe
default setting when RNA is set to something unknown.
While this approach solves the issues similar to T47377,
but it wouldn't really help when/if any of the RNA values
gets ever deprecated and removed. There'll be no simple
solution to that apart from defining explicit mapping from
RNA value to Cycles one.
Another part which isn't so great actually is that we now
have to have some enum guards and give some explicit values
to the enum items, but we can live with that perhaps.
Reviewers: dingto, juicyfruit, lukasstockner97, brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D1785
This way we avoid passing structures which could be up to
few hundred bytes by value to the utility functions.
Ideally we'll also have to add `const` qualifier in majority
of the calls, but C++ RNA does not allow us to do that because
it does not know if some function modifies contents or not.
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.
There were several issues involved into triangle ribbons hair:
- Even for the viewport rendering the blender scene camera was
used for orientation. This made hair triangles oriented to
the scene camera, not to the viewport camera.
- Triangle orientation was actually supposing the camera is
perspective. Triangles weren't oriented properly for the
orthographic camera resulting in different hair width across
it's length.
This issues are solved now, but there are some related TODOs:
- Rotating viewport doesn't re-orient the triangles, so after
viewport navigation hair might not look correct. However,
with this fix toggling viewport render (to force hair sync)
makes viewport render correct.
This isn't so much trivial fix, would require making BVH
aware of the dynamic triangle orientation, so they get
properly oriented without full hair re-sync.
- Panorama camera behavior didn't change but looks like it
should, however not really sure atm what's the right thing
to do here.
* Added support for uchar4 attributes to Cycles' attribute system.
* This is used for Vertex Colors now, which saves some memory (4 unsigned characters, instead of 4 floats).
* GPU Texture Limit on sm_20 and sm_21 decreased from 95 to 94, because we need a new texture for the uchar4 attributes. This is no problem for sm_30 or newer.
Part of my GSoC 2014.
This now supports multiple steps and subframe sampling of motion.
There is one difference for object and camera transform motion blur. It still
only supports two steps there, but the transforms are now sampled at subframe
times instead of the previous and next frame and then interpolated/extrapolated.
This will give different render results in some cases but it's more accurate.
Part of the code is from the summer of code project by Gavin Howard, but it has
been significantly rewritten and extended.
* UI: Remove deprecated condition (CURVE_RIBBONS) and hide backface property, when it's hardcoded in C (Curve/Line segments && Ribbons).
* Remove "use_tangent_normal" and "CURVE_KN_TANGENTGNORMAL" as its unused (follow up for last commit).
* Remove dead code from line segments BVH refine.
CURVE_KN_TANGENTGNORMAL and CURVE_KN_TRUETANGENTGNORMAL are either both true, or both false. Therefore a true/false condition is impossible.
This was a leftover of CURVE_CUSTOM, which was removed in r59234.
* Use "else if" in blender_curves.cpp.
- add missing headers from cmake (own omission)
- quiet rna_test.c unused define warnings.
- minor style edits
- spelling corrections and ignore all uppercase words with spell checking script.
- Removed the cycles subdivision and interpolation of hairkeys.
- Removed the parent settings.
- Removed all of the advanced settings and presets.
- This simplifies the UI to a few settings for the primitive type and a shape mode.
* Revert r57203 (len() renaming)
There seems to be a problem with nVidia OpenCL after this and I haven't figured out the real cause yet.
Better to selectively enable native length() later, after figuring out what's wrong.
This fixes [#35612].
* Rename some math functions:
len -> length
len_squared -> length_squared
normalize_len -> normalize_length
* This way OpenCL uses its inbuilt length() function, rather than our own. The other two functions have been renamed for consistency.
* Tested CPU, CUDA and OpenCL compile, should be no functional changes.
Code is added to restrict the pixel size of strands in cycles. It works best with ribbon primitives and a preset for these is included. It uses distance dependent expansion of the strands and then stochastic strand removal to give a fading. To prevent a slowdown for triangle mesh objects in the BVH an extra visibility flag has been added. It is also only applied for camera rays.
The strand width settings are also changed, so that the particle size is not included in the width calculation. Instead there is a separate particle system parameter for width scaling.
Bastien Montagne