| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
|
|
Original patch by Stefan with modifications by Brecht.
|
|
It seems to be useful still in cases where the particle are distributed in
a particular order or pattern, to colorize them along with that. This isn't
really well defined, but might as well avoid breaking backwards compatibility
for now.
|
|
These are used for randomization, so it's convenient if the index is already
hashed and consistent with the Object Info node.
|
|
* Remove tex_* and pixels_* functions, replace by mem_*.
* Add MEM_TEXTURE and MEM_PIXELS as memory types recognized by devices.
* No longer create device_memory and call mem_* directly, always go
through device_only_memory, device_vector and device_pixels.
|
|
|
|
The idea is to make include statements more explicit and obvious where the
file is coming from, additionally reducing chance of wrong header being
picked up.
For example, it was not obvious whether bvh.h was refferring to builder
or traversal, whenter node.h is a generic graph node or a shader node
and cases like that.
Surely this might look obvious for the active developers, but after some
time of not touching the code it becomes less obvious where file is coming
from.
This was briefly mentioned in T50824 and seems @brecht is fine with such
explicitness, but need to agree with all active developers before committing
this.
Please note that this patch is lacking changes related on GPU/OpenCL
support. This will be solved if/when we all agree this is a good idea to move
forward.
Reviewers: brecht, lukasstockner97, maiself, nirved, dingto, juicyfruit, swerner
Reviewed By: lukasstockner97, maiself, nirved, dingto
Subscribers: brecht
Differential Revision: https://developer.blender.org/D2586
|
|
separate some arrays.
Differential Revision: https://developer.blender.org/D2016
|
|
Mainly makes logging less verbose when doing progressive sampling in viewport.
Such kind of verbosity is not really possible to be filtered out with `grep`
so let's reshuffle few lines of code.
|
|
Covers number of entities in the scene (objects, meshes etc), also reports
sizes of textures being allocated.
|
|
|
|
This was already mixed a bit, but the dot belongs there.
|
|
More information in this post:
http://code.blender.org/
Thanks to all contributes for giving their permission!
|
|
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.
|
|
systems. The device texture always contains at least one dummy particle in case particle info node is used for non-instance objects, this must be initialized in any case.
|
|
|
|
info node:
* Location: Basically the same as the location from Object Info node for object instances on particles, but in principle there could be additional offsets for dupli objects, so included for completeness.
* Size: Single float scale of the particle. Also directly translates to object scale for current dupli objects, but handy to have as a single float to start with instead of a scale vector (currently not even exposed in Object Info).
* Rotation: This is a quaternion, which are not yet supported by Cycles nodes. The float4 is copied to internal Cycles data and stored in the particles texture data, but the node doesn't have a socket for it yet and the data is not yet written to the stack. Code is just commented out so could be enabled quickly if/when rotation support is added to cycles.
* Velocity: Linear velocity vector of particles.
* Angular Velocity: Angular velocity around principle axes.
The texture data is currently packed tightly into the particles texture, which saves a few bytes, but requires an additional texture lookup for some vector attributes which spread over two float4s. Could also add another float4 to particle size to avoid this.
|
|
The particle data used by the Particle Info node was stored in cycles as a list in each object. This is a problem when the particle emitter mesh is hidden: Objects in cycles are only intended as instances of renderable meshes, so when hiding the emitter mesh the particle data doesn't get stored either. Also the particle data can potentially be copied to multiple instances of the same object, which is a waste of texture space.
The solution in this patch is to make a completely separate list of particle systems in the Cycles scene data. This way the particle data can be generated even when the emitter object itself is not visible.
|
