| Age | Commit message (Collapse) | Author |
|---|
|
http://markmail.org/message/fp7ozcywxum3ar7n
|
|
|
|
Volume pre-caching altered shared data simultaneously in multiple threads, causing invalid scattering results when "Asymmetry" value was used. The view vector is now passed as a function argument.
|
|
|
|
|
|
These should not have any effect on render results, except in some cases with
you have overlapping faces, where the noise seems to be slightly reduced.
There are some performance improvements, for simple scenes I wouldn't expect
more than 5-10% to be cut off the render time, for sintel scenes we got about
50% on average, that's with millions of polygons on intel quad cores. This
because memory access / cache misses were the main bottleneck for those scenes,
and the optimizations improve that.
Interal changes:
* Remove RE_raytrace.h, raytracer is now only used by render engine again.
* Split non-public parts rayobject.h into rayobject_internal.h, hopefully
makes it clearer how the API is used.
* Added rayintersection.h to contain some of the stuff from RE_raytrace.h
* Change Isect.vec/labda to Isect.dir/dist, previously vec was sometimes
normalized and sometimes not, confusing... now dir is always normalized
and dist contains the distance.
* Change VECCOPY and similar to BLI_math functions.
* Force inlining of auxiliary functions for ray-triangle/quad intersection,
helps a few percentages.
* Reorganize svbvh code so all the traversal functions are in one file
* Don't do test for root so that push_childs can be inlined
* Make shadow a template parameter so it doesn't need to be runtime checked
* Optimization in raytree building, was computing bounding boxes more often
than necessary.
* Leave out logf() factor in SAH, makes tree build quicker with no
noticeable influence on raytracing on performance?
* Set max childs to 4, simplifies traversal code a bit, but also seems
to help slightly in general.
* Store child pointers and child bb just as fixed arrays of size 4 in nodes,
nearly all nodes have this many children, so overall it actually reduces
memory usage a bit and avoids a pointer indirection.
|
|
|
|
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...
|
|
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.
|
|
|
|
* Fixed an old problem where if both the camera and a solid surface were
inside a volume, the volume wouldn't attenuate in front of the surface (was
visible in the blender conference art festival clouds animation:
http://mke3.net/blender/devel/rendering/volumetrics/vol_shade_cam_inside.mov
* Initial support for refracting solids inside volumes. I might be able to
make this work better, but not sure at the moment. It's a bit dodgy,
limited by the code that does the recursive ray shading - it's really not
set up for this kind of thing and could use a refactor very much.
|
|
|
|
nothing to see here, move along!
|
|
This is a first version and still has a couple of things undefined or
unimplemented, such as external objects casting shadows on or within volumes,
however volume->solid shadows are going ok.
http://mke3.net/blender/devel/rendering/volumetrics/shadows_test_02.mov
http://mke3.net/blender/devel/rendering/volumetrics/vol_test_shad3.blend
As with other transparent raytraced shadows in Blender ,in order to make it work,
you must enable 'TraShad' on the material *receiving* the shadow. It would be
nice to make this a bit easier to use, since there's not much chance you want a
volume material to be casting solid shadows, but that's a bigger issue in the
renderer outside this scope.
The volume shadows are working from the same physical basis of absorption, and
support coloured absorption:
http://mke3.net/blender/devel/rendering/volumetrics/vol_shad_absorption.png
They also work properly with multi-sampled (i.e. QMC) soft shadows:
http://mke3.net/blender/devel/rendering/volumetrics/vol_shad_sharp.png
http://mke3.net/blender/devel/rendering/volumetrics/vol_shad_soft.png
And by popular request the test file:
http://mke3.net/blender/devel/rendering/volumetrics/vol_test_shad_clouds.blend
|
|
This is an initial commit to get it in SVN and make it easier to work on.
Don't expect it to work perfectly, it's still in development and there's
plenty of work still needing to be done. And so no I'm not very interested
in hearing bug reports or feature requests at this stage :)
There's some info on this, and a todo list at:
http://mke3.net/weblog/volume-rendering/
Right now I'm trying to focus on getting shading working correctly (there's
currently a problem in which 'surfaces' of the volume facing towards or away
from light sources are getting shaded differently to how they should be),
then I'll work on integration issues, like taking materials behind the volume
into account, blending with alpha, etc. You can do simple testing though,
mapping textures to density or emission on a cube with volume material.
|
