Age | Commit message (Collapse) | Author |
|
|
|
There was some extra linearization happening in such cases.
|
|
It's not like every debug build is benefiting from this print..
|
|
|
|
This patch adds support for coloring point density textures based on several mesh vertex attributes.
* Vertex Color: Use a vertex color layer for coloring the point density texture
* Vertex Weight: Use a weights from a vertex group as intensity values. (for Blender Render engine the additional color band is used)
* Vertex Normals: Use object-space vertex normals as RGB values.
The vertex color source enum is stored separately from the particle color source, to avoid invalid values when switching.
Note that vertex colors are technically "corner colors" (MLoop), so each vertex can have as many colors as faces it is part of.
For the purpose of point density the mloop colors are simply averaged, which is physically plausible because corners can be viewed
as multiple points in the same location.
|
|
Useful when BLI_bvhtree_range_query callback calculates a new position to measure from.
|
|
|
|
This patch adds a new `falloff_type` ('Inverse Coefficients') for Lamps in
Blender-Internal and GLSL.
The current falloff modes use a formula like this inverse-square one:
`I = E × (D^2 / (D^2 + Q × r^2))`
While such a formula is simple for 3D-artists to use, it's algebraically
cumbersome to work with. Game-designers authoring their own shaders
could benefit much more by having direct control of falloff-coefficients:
`I = E × (1.0 / (coefC + coefL × r + coefQ × r^2))`
In this mode, the `distance` parameter is unused (except for 'Sphere'
mode); instead relying on the designer to mathematically-model the
falloff-behavior.
The UI has been patched like so:
{F153843}
Reviewers: brecht, psy-fi
Reviewed By: psy-fi
Subscribers: brita_, antidote, campbellbarton, psy-fi
Differential Revision: https://developer.blender.org/D1194
|
|
This reverts commit cd6442f7d4b56cb40102d86404fbaeae30dd2d32.
Broke workflow for incrementally saving versions of a render.
|
|
D1729 fixed 'View' projection but broke 'Equirectangular'.
This commit also changes equirectangular projection to match Cycles and the viewport.
|
|
This is a new option for panorama cameras to render
stereo that can be used in virtual reality devices
The option is available under the camera panel when Multi-View is enabled (Views option in the Render Layers panel)
Known limitations:
------------------
* Parallel convergence is not supported (you need to set a convergence distance really high to simulate this effect).
* Pivot was not supposed to affect the render but it does, this has to be looked at, but for now set it to CENTER
* Derivatives in perspective camera need to be pre-computed or we shuld get rid of kcam->dx/dy (Sergey words, I don't fully grasp the implication shere)
* This works in perspective mode and in panorama mode. However, for fully benefit from this effect in perspective mode you need to render a cube map. (there is an addon for this, developed separately, perhaps we could include it in master).
* We have no support for "neck distance" at the moment. This is supposed to help with objects at short distances.
* We have no support to rotate the "Up Axis" of the stereo plane. Meaning, we hardcode 0,0,1 as UP, and create the stereo pair related to that. (although we could take the camera local UP when rendering panoramas, this wouldn't work for perspective cameras.
* We have no support for interocular distance attenuation based on the proximity of the poles (which helps to reduce the pole rotation effect/artifact).
THIS NEEDS DOCS - both in 2.78 release log and the Blender manual.
Meanwhile you can read about it here: http://code.blender.org/2015/03/1451
This patch specifically dates from March 2015, as you can see in the code.blender.org post. Many thanks to all the reviewers, testers and minor sponsors who helped me maintain spherical-stereo for 1 year.
All that said, have fun with this. This feature was what got me started with Multi-View development (at the time what I was looking for was Fulldome stereo support, but the implementation is the same). In order to make this into Blender I had to make it aiming at a less-specic user-case Thus Multi-View started. (this was December 2012, during Siggraph Asia and a chat I had with Paul Bourke during the conference). I don't have the original patch anymore, but you can find a re-based version of it from March 2013, right before I start with the Multi-View project https://developer.blender.org/P332
Reviewers: sergey, dingto
Subscribers: #cycles
Differential Revision: https://developer.blender.org/D1223
|
|
Was printing to console, but UI didn't show error message.
|
|
|
|
Quite trivial idea -- just pass tread ID to the texture sampling function.
Implemented as a TLS to avoid passing huge amount of extra contexts around.
Should be working on all platforms, but compilation test is required.
Reviewers: juicyfruit, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1831
|
|
|
|
|
|
The issue was caused by some code accessing R from a functions which
are marked as safe for use from outside of render pipeline.
Now those functions are safe(er) for use.
|
|
|
|
|
|
|
|
|
|
|
|
Thanks Bastien for finding this out!
|
|
It should be all fine to sample same point density from multiple threads,
this is something what Blender Internal is doing actually.
|
|
The issue was happening when having unconnected point density which
will cache data but will not free it because there's no actual call
to the actual sampling.
Now the idea is to make sure cache is zeroed on file load and undo
and then caching via RNA will free the data if any exists. This could
leave us with a single copy of cache in the node if it's not used,
but it's quite small amount of memory and it's not leaking.
|
|
|
|
variables.
|
|
|
|
original mesh.
|
|
The differentials were incorrect, now they are properly transferred from the
low to the high poly mesh.
|
|
|
|
BKE_main_id_tag_/BKE_main_id_flag_ were horrible naming now that we split those
into flags (for presistent one) and tags (for runtime ones).
Got rid of previous 'tag_' functions behavior (those who were dedicated shortcuts
to set/clear LIB_TAG_DOIT), so now '_tag_' functions affect tags, and '_flag_'
functions affect flags.
|
|
|
|
|
|
Also remove null checks from args with non-null attribute.
|
|
|
|
rendered since opening
|
|
|
|
Failed reads didn't update the voxel 'ok' tag,
making successive reads fail (even on existing frames).
|
|
Such configuration used to cause quite confusing situation when
stamp will use actual scene's statistics but metadata from strip
will be used for the saved file (basically, causing different
information stamped and saved as metadata).
Don't think it was desired behavior and it's something what
artists here in the studio wants to be fixed.
|
|
|
|
no functional changes
|
|
Use more conventional API word-ordering for RE_render_ext
|
|
Make sure z-mask layers aren't excluded for animation evaluation.
|
|
density input
The issue was caused by different AABB used by Cycles and texture sampler.
Instead of trying to keep this two functions in sync we now do have an
utility call in the point density node to query the AABB.
|
|
|
|
The Vector Transform node is a useful node which is present in the Cycles renderer.
{F144283}
This patch implements the Vector Transform node for GLSL mode and the internal renderer.
Example: {F273060}
Alexander (Blend4Web Team)
Reviewers: brecht, campbellbarton, sergey
Reviewed By: campbellbarton, sergey
Subscribers: psy-fi, duarteframos, RobM, lightbwk, sergey, AlexKowel, valentin_b4w, Evgeny_Rodygin, yurikovelenov
Projects: #bf_blender:_next
Differential Revision: https://developer.blender.org/D909
|
|
Skipping computing of shadow pass when diffuse color is pitch black is fine... unless
you actually need/want that shadow pass!
The 'noisy' issue with picture texture remains a bit mysterious to me currently. :/
|
|
part.
Problem is actually similar in both engines - in some cases, we changed
'natural' quad splitting order to alternative one, without properkly 'notifying'
UV/VCol/other tessface data about it.
So code would use a 'wrong' triangle of UVs etc.
Fix for Cycles was committed by sergey as rBa6eae7339190d1.
|
|
Reviewers: brecht
Differential Revision: https://developer.blender.org/D1731
|