Hair render: using strand "Blender Unit" size didn't correctly
clip for larger/wider strands. Now code clips strands based
on the maximum width.
Also found bad code for using clipping flags, which was mixed up,
and probably caused hair strands to be missing in cases.
* Particle age can now be used as the texture x-coordinate, and location in a particle trail as the y-coordinate.
* This finally enables particles in 2.5 to change their color (or any other texturable material property) by their age.
* In 2.4x this was accomplished with the "100 frames == particle age", but this was both non-intuitive and slow as the animation system had to be recalculated for every particle.
* Currently these are 2d coordinates (age/lifetime == x-coordinate, trail particle index/number of trail particles == y-coordinate), but other particle properties or possibly even a user definable property can be added as coordinates in the future.
* On the code side this uses the same coordinate definition number (for halo materials) as strand coordinates (for surface materials). This is also nice as they intuitively mean nearly the same thing, i.e. along strand or during particle life.
large render sizes could cause an the threaded tile processor to hang because winx * winy wrapped into a negative value.
also convert winx/winy to floats before multiplying for vector passs.
Now the bounding box for the light cache's voxel grid is calculated in
global space, rather than camera space as it was previously. This fixes
flickering lighting on static volumes with camera motion, caused by
the camera space bounding box changing from frame to frame.
* Fractional frames support has been changed to use a new var, scene->r.subframe.
This is a 0.0-1.0 float representing a subframe interval, used in generating a final float
frame number to evaluate animation system etc.
* Changed frame_to_float() and some instances of bsystem_time() into a convenience function:
float BKE_curframe(scene) which retrieves the floating point current frame, after subframe
and frame length corrections.
* Removed blur_offs and field_offs globals. These are now stored in render, used to
generate a scene->r.subframe before render database processing.
Now, rather than the bit-too-alarming stop sign, threaded wmJobs
display a progress indicator in the header. This is an optional feature
for each job type and still uses the same hardcoded ui template
(could use further work here...).
Currently implemented for:
Render - parts completed, then nodes comped
Compositor - nodes comped
Fluid Sim - frames simulated
Texture Bake - faces baked
Example: http://mke3.net/blender/devel/2.5/progress.mov
Implementation note: this was done by giving each Render a slot number,
and for every slot a new Render will be created. Not sure if this is
ideal, but it ensures that all passes, render info, etc are separate so
you can also compare render layers and passes, in 2.4x only whatever it
was currently displaying was backed up.
Ambient occlusion: multiplied with direct lighting by default, add
is also still available and more blending methods might be added if
they are useful. This is fundamentally a non physical effect.
Environment lighting: always added as you would expect (though you can
subtract by specifying negative energy). This can be just white or take
colors or textures from the world.
Indirect lighting: only supported for AAO at the moment (and is still
too approximate), and also is always added. A factor is available to
specify how much is added, though value 1.0 is correct.
Also:
* Material ambient value now defaults to 1.0.
* Added Environment, Indirect and Emit pass.
* "Both" blending method is no longer available.
* Attenuation, sampling parameters are still shared, some could be split
up, though if they are different this would affect performance.
This brings back the single bounce indirect diffuse lighting for AAO,
it's not integrated well but that will be tackled later as part of
shading system refactor and subdivision changes. The caveats are the
same as AAO, with one extra thing, the diffuse lighting is sampled once
per face, so it will not be accurate unless faces are subdivided.
I'm committing this now so we can start testing it for Durian, and
since changes need to make it work properly are planned.
Since the deep shadow buffer summer of code project is not actively under
development anymore, I decided to build my own DSM implementation from
scratch, based on reusing as much existing shadow buffer code as possible.
It's not very advanced, but implements the basic algorithm. Just enough so
we can do shading tests with it, optimizations and other improvements can
be done later.
Supported:
* Classical shadow buffer options: filter, soft, bias, ..
* Multiple sample buffers, merged into one.
* Halfway trick to support lower bias.
* Compression with user defined threshold.
* Non-textured alpha transparency, using Casting Alpha value.
* Strand render.
Not Supported:
* Tiling disk cache, so can use a lot of memory.
* Per part rendering for lower memory usage during creation.
* Colored shadow.
* Textured color/alpha shadow.
* Mipmaps for faster filtering.
* Volume shadows.
Usage Hints:
* Use sample buffers + smaller size rather than large size.
* For example 512 size x 9 sample buffers instead of 2048 x 1.
* Compression threshold 0.05 works, but is on the conservative side.
* mingw almost compiles again cleanly, except for a linking error when linking blender http://www.pasteall.org/8297
* win64 should compile again too to a similar degree?
* silenced warnings about no newlines...
* Rendering twice or more could crash layer/pass buttons.
* Compositing would crash while drawing the image.
* Rendering animations could also crash drawing the image.
* Compositing could crash
* Starting to rendering while preview render / compo was
still running could crash.
* Exiting while rendering an animation would not abort the
renderer properly, making Blender seemingly freeze.
* Fixes theoretically possible issue with setting malloc
lock with nested threads.
* Drawing previews inside nodes could crash when those nodes
were being rendered at the same time.
There's more crashes, manipulating the scene data or undo can
still crash, this commit only focuses on making sure the image
buffer and render result access is thread safe.
Implementation:
* Rather than assuming the render result does not get freed
during render, which seems to be quite difficult to do given
that e.g. the compositor is allowed to change the size of
the buffer or output different passes, the render result is
now protected with a read/write mutex.
* The read/write mutex allows multiple readers (and pixel
writers) at the same time, but only allows one writer to
manipulate the data structure.
* Added BKE_image_acquire_ibuf/BKE_image_release_ibuf to access
images being rendered, cases where this is not needed (most
code) can still use BKE_image_get_ibuf.
* The job manager now allows only one rendering job at the same
time, rather than the G.rendering check which was not reliable.
After code review and experimentation, this commit makes some changes to the way that volumes are shaded. Previously, there were problems with the 'scattering' component, in that it wasn't physically correct - it didn't conserve energy and was just acting as a brightness multiplier. This has been changed to be more correct, so that as the light is scattered out of the volume, there is less remaining to penetrate through.
Since this behaviour is very similar to absorption but more useful, absorption has been removed and has been replaced by a 'transmission colour' - controlling the colour of light penetrating through the volume after it has been scattered/absorbed. As well as this, there's now 'reflection', a non-physically correct RGB multiplier for out-scattered light. This is handy for tweaking the overall colour of the volume, without having to worry about wavelength dependent absorption, and its effects on transmitted light. Now at least, even though there is the ability to tweak things non-physically, volume shading is physically based by default, and has a better combination of correctness and ease of use.
There's more detailed information and example images here:
http://wiki.blender.org/index.php/User:Broken/VolumeRendering
Also did some tweaks/optimisation:
* Removed shading step size (was a bit annoying, if it comes back, it will be in a different form)
* Removed phase function options, now just one asymmetry slider controls the range between back-scattering, isotropic scattering, and forward scattering. (note, more extreme values gives artifacts with light cache, will fix...)
* Disabled the extra 'bounce lights' from the preview render for volumes, speeds updates significantly
* Enabled voxeldata texture in preview render
* Fixed volume shadows (they were too dark, fixed by avoiding using the shadfac/AddAlphaLight stuff)
More revisions to come later...
#define RE_RAYCOUNTER (/source/blender/render/extern/include/RE_raytrace.h)
*Some other small organization on code
(will be disable as this only matters for testing and developping)
* Fix for plane material preview render. Now, light cache aborts if there isn't enough volume, and falls back on non-cached single scattering. It still doesn't make much sense to render a plane as a volume, but for now in the preview it will shade the region in between the plane and the checker background.
Also, made the Outliner's horizontal scrollbar work better for keymaps view. It's still using an approximation of the width, but at least you can scroll now.
Integration is still very rough around the edges and WIP, but it works, and can render smoke (using new Smoke format in Voxel Data texture) --> http://vimeo.com/6030983
More to come, but this makes things much easier to work on for me :)
if theres very few faces its not worth it to create a separated tree for beinng reused.
should speedup some particle renders.
This "fixes" a bug relationed with a arithmetic precision on instances and raytrace of very close objects
which usually happens on rendering (almost) overlapping alpha-enabled leafs/feathers
- 1st stage: Linear Workflow
This implements automatic linear workflow in Blender's renderer. With the
new Colour Management option on in the Render buttons, all inputs to the
renderer and compositor are converted to linear colour space before
rendering, and gamma corrected afterwards. In essence, this makes all
manual gamma correction with nodes, etc unnecessary, since it's done
automatically through the pipeline.
It's all explained much better in the notes/doc here, so please have a look:
http://wiki.blender.org/index.php/Dev:Source/Blender/Architecture/Colour_Management
And an example of the sort of difference it makes:
http://mke3.net/blender/devel/rendering/b25_colormanagement_test01.jpg
This also enables Colour Management in the default B.blend, and changes the
default lamp falloff to inverse square, which is more correct, and much
easier to use now it's all gamma corrected properly.
Next step is to look into profiles/soft proofing for the compositor.
Thanks to brecht for reviewing and fixing some oversights!
It creates a tree cut after knowing that a given point will pass on a BB.
This tree cut is used to accelarate the rays casted from a given BB, eliminating unnecessary BB tests from root till the tree cut.
