Mist option and "Ray Transp" didn't work together yet. Transparency
during tracing should not be influenced with mist though (as is for
Ztransp), so for this case an extra color blending after raytrace is
added. Still pretty primitive... mostly because mist isn't volumetric
in Blender at all... just an alpha trick.
Autosmooth didn't copy additional texture coordinates such as sticky
correctly. This was part of the vertex struct in 2.41 and older, but it
became dynamic in 2.42.
Irregular shadow buffer, for solid OSA case, suffered aliasing. This caused
by optimized storage of shadow factors in 1 pixel (averaged for all sub
samples). That didn't work well really...
Now the code uses same method as for transparent faces, storing results for
each sample.
Radiosity tool or render was using an uninitialized variable, causing clip
to work incorrect. (black lines in radiosity).
Error caused by commit in august, after 2.42a release.
Made nice crashes that way... but not in !@%@$ OSX because it seems to
clear memory unwanted. Solve dit with adding API call in MemArena to default
to callocs.
Also removed malloc() from MemArena, replaced with MEM_mallocN().
In some cases faces were skipped from rendering, when using multiple
RenderLayers. Was caused by a "don't render" flag hanging. Error was
introduced with the "All Z" RenderLayer option.
* Add WITH_BF_YAFRAY, which per default is 'true', so no visible changes for developers (and users).
Set WITH_BF_YAFRAY to 'false', and you'll save some major compile time :) Also handy if you're strapped for memory and compilation fails on yafray compilation due
to this.
- this commit also has a few whitespace changes and
- made BF_NO_ELBEEM a proper BoolOption. This will be renamed to WITH_BF_ELBEEM in the near future...
http://www.blender3d.org/cms/Shadow_buffer__Halfway.786.0.html
Simply said: by using the average of the nearest and 2nd nearest Z value
in Shadowbuffers you can reduce bias errors very well.
For backwards compatibility it is a new buffer type though.
Full log:
http://www.blender3d.org/cms/Irregular_Shadow_Buffe.785.0.html
In short: this is a shadow buffer approach that always results in crispy
shadows, independent of lamp buffer size or zoom level. This shadow buffer
system also supports transparent shadow.
This is part of work on refreshing Shadow Buffers in Blender. You now can
choose of two types (Classical, Irregular). More types will follow. Also
quality issues for Classical shadow buffers are going to be reviewed,
especially to solve the lousy Biasing.
For the CVS log record; it is based on articles:
Gregory Johnson et al, University of Texas, Austin. (Regular grid method).
Timo Aila and Samuli Laine, Helsinki University of Technology. (BSP method).
When using new Shadowbuffer option "Auto clip", the clipping planes could
become so narrow that sampling code - using ints - could result in
overflows (sign flip). This especially for small shadow buffers with high
bias values.
This fix adds an extra check in shadow sampling for such overflows.
If you define multiple RenderLayers with different view-layers, these
view-layers are rendered entirely, not looking at the faces that are
invisible. This allows layered composite, but only when geometry does
not intersect or overlap partially.
This new Renderlayer option "All Z values" will fill in the Z of not
visible faces (in the Scene view-layers) as well, which then allows
masking out as if these faces were set to Material option "Env".
Here's an example composite to show the effect:
Two cubes, in view-layers 1 and 2, and rendered in 2 RenderLayers:
http://www.blender.org/bf/all_z0.jpg
Same scene, but with both RenderLayers set to "All Z values":
http://www.blender.org/bf/all_z.jpg
module itself, replacing the special MEM_mallocT/MEM_freeT functions.
Mutex locking is only enabled when threads are running.
There was no good reason to have these separate, it just led to ugly
hacks when calling functions with non-threadsafe malloc from threads.
- Tangent vectors now can also be derived from orcos (No UV needed)
- Normalmaps now properly support tangent space as well
(Patch provided by Alfredo de Greef)
Full log is here:
http://www.blender3d.org/cms/New_Render_features.774.0.html
Auto-clip Lamp Buffer
Setting a good range for clipping start/end for Lamp buffers is important
for good quality shadow (depth details). That can be quite a hassle, when
many lamps or animated objects are involved.
This option allows to have the clipping range calculated based on the
visible vertices in the spotbundle. For clip start and clip end it can
be set individually. Typically the clip start defines quality most.
The shadow buffer 'bias' value is corrected for this automatic clipping
too, to ensure that ranges that differ give same biasing appearance.
(If this wasn't done, you would see lighted areas become darker or
lighter, or even artefacts, when the range changes suddenly
NOTE: since it only checks for vertices, be aware that large planes can
give errors.
Implementation note: zbuffer values are non-linear (1/z) because that
allows linear interpolation while filling scanlines. That's the main
reason for the precision to be highest close to the eye (or lamp).
It's even a useful feature, since you want details to be precise
when they're closeby.
Since these values are also in the -1 to 1 range, using floats here
wouldn't solve problems a lot. Maybe trying a 64 bits Z once might
be an interesting coding job.
images (like used for rendering icons).
When working during Orange on new render pipeline, I've left this topic
alone for a while... subpixel precision testing is very time consuming and
needs concentration for a while. :)
This commit brings back precision as it was for 2.41. Below a short
explanation of the solved issues.
- the window matrix for rendering is kept constant during all OSA passes,
this to ensure clipping happens for each pass identically.
- a subpixel offset is only applied on filling in the z-buffer
- this offset is inverse corrected for shadepixel code, only on 2 places
Another nasty issue is that for filtered rendering (gauss etc), the tiles
(or entire image) is temporally increased 2 pixel in size. This caused a
'dark' (or sky color) edge on the rendering. During Orange that was solved
with a hardcoded clipping offset value, which only corrected for larger
pictures (like > 500 pixels in size).
Now this clipping offset is correctly calculated, based on render size.
Last issue: the view border in 3d window was calculated using integers,
giving small errors in display too. Now it uses float, so visually the
view border is more close to what a render shows.
When a sequencer has mixed use of 32 bits and float images (note, Scene
strip returns float image too), the old 32 bits image should be freed,
otherwise it keeps saving that image.
- It saves a file with indicated type on each change, with number
appended denoting the current frame (like ANIM saving).
- Output filename button supports relative paths ("//")
- Shows optional preview image too
- For now, added a print on each file save as feedback
To make this option work nicely, changed the BKE_makepicstring() function
to have less globals inside, so it is more generic. Todo: allow amount of
digits in filenames to be set (to support files like tmp_123456.jpg)
Preview render in 3d window: when window type changes (like 3d window to
UV window), and you change the window size, and restore to 3d view, the
rendered preview had to be re-initialized.
texture.c: a return was added without value.
- ImagePaint now uses ImBuf directly, and the rect blending functions
were moved into the imbuf module.
- The brush spacing, timing and sampling was abstracted into brush.c, for
later reuse in other paint modes.
Float ImagePaint support.
Textured Brushes:
- Only the first texture channel is used now.
- Options for size and offset should be added, but need to find some space
in the panel, or add a second one ..
N_T: the implementation of this feature isn't 100% nice, it currently does
a full recalc on each redraw, and it doesn't work properly unless it is
recalculated for each frame.
Repeat Image texture was broken... the repeat value for Y was accidentally
multiplied twice, typo... had to change a 1 into 2 :)
Error introduced in 2.41 btw, 2.40 and older were OK.
Render non-osa, with mblur, did not jitter the zbuffering, so it did not
result in basic AA for non moving parts.
Note to self: this now works on < 2.42 level again: it doesn't use
the correct subsampling, which can cause slight errors in rendering image
textures.
- thread render stores per thread and per lamp the last intersected
shadow face
- the Isect struct, for intersections, could use a couple of extra
zeros on start.
The raytracer wasn't calling node shaders yet, so results showed only
shading for the base material.
This now works, but there's a conflict in the internal Blender shader that
makes recursive raytracing with nodes unpredictable. Basicaly the conflict
is that when a ray wants to shade a point, it should be able to check the
material for mirror properties, but this is undefined for node trees...
Probably we need to separate raytrace entirely from material shading. Is
a good topic for NodeShader 2.0, when we really split up materials in
shading components.
I'll add a note in the release log about this. Best results you get now
when you don't include mirror/ray-transp insde a node tree, in that case
a regular material mirror can render that material perfectly.
In december, when testing material layering, I've removed the check that
prevented specular and diffuse to become negative, this because it could
work nice for layering.
However, this breaks quite some cases too. For example negative lamps are
only used to cancel out other lights in same material, and should not give
negative (invisible!) peaks that work on a node system. Same goes for
negative diffuse from AO 'subtract' mode.
In fraka the error happened for AO on a translucent material. The inside
of the mesh got a negative AO, cancelling out the positive AO on the
outside.
Anyhoo; this commits ensures that a 'shade_lamp_loop' call will never
return negative values again!
- AO "Use Distances" can not use 'sky texture' for colors, that bug was
fixed in UI (prevent settings to combine), but better also gets fixed
on reading files.
- Backbuf render, when not existed, didn't initialize backdrop color to 0.
Hurmf, then you bring back old backbuffer, and they want to have fields
work on that!
OK... here it is. Although using Compositor features will make this much
easier and advanced to control. :)
