* 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.
*Added vbvh - Just a experimental tree type :)
Variable Way BVH - there is no hardcoded number of childs per each Tree Node
- idea is to optimize a tree to reduced the expected number of BB tests even after applying SAH (for that an hardcoded n-way is not enough)
- for now childs are stored on a linked list
Suposedly usefull for creating trees of objects (where objects have very diferent size-NumFaces and shape-BB)
Altought the implemented costs maybe not be very correct (for now), as i didnt cared about following a specific "corrected" model
I think its something like:
old was: 4*nlogn + 3*(n*6)
new is: (2*nlogn + 3*(n*6)) * f, with f<1
Still missing changing the sorting function to an introsort instead of qsort
Other options like bucketing sort may be worth trying (for very large trees)
only for 2childs splits
with "worse case heuristic" means each child is considered to have a cost linear on the number of leafs
no termination criteria
number of BB test/hits expected to "reduced" by some factor
tree building is also expected to be slower as previous split was "object mean", which is quite fast to evaluate
point is that other structures like trees can then distiguish between other nodes or rayobject primitives
withouth needing any other variable.
(Note yet used but will reduce memory by a nice factor (linear to the number of primitives))
* Added support for additional file types in the voxel data texture. I added
support for 8 bit raw files, but most notably for image sequences.
Image sequences generate the voxel grid by stacking layers of image slices on top
of each other to generate the voxels in the Z axis - the number of slices in the
sequence is the resolution of the voxel grid's Z axis.
i.e. http://mke3.net/blender/devel/rendering/volumetrics/skull_layers.jpg
The image sequence option is particularly useful for loading medical data into
Blender. 3d medical data such as MRIs or CT scans are often stored as DICOM
format image sequences. It's not in Blender's scope to support the DICOM format,
but there are plenty of utilities such as ImageMagick, Photoshop or OsiriX that
can easily convert DICOM files to formats that Blender supports, such as PNG or JPEG.
Here are some example renderings using these file formats to load medical data:
http://vimeo.com/5242961http://vimeo.com/5242989http://vimeo.com/5243228
Currently the 8 bit raw and image sequence formats only support the 'still'
rendering feature.
* Changed the default texture placement to be centred around 0.5,0.5,0.5, rather
than within the 0.0,1.0 cube. This is more consistent with image textures, and it
also means you can easily add a voxel data texture to a default cube without
having to mess around with mapping.
* Added some more extrapolation modes such as Repeat and Extend rather than just clipping
http://mke3.net/blender/devel/rendering/volumetrics/bradybunch.jpg
* Changed the voxel data storage to use MEM_Mapalloc (memory mapped disk cache)
rather than storing in ram, to help cut down memory usage.
* Refactored and cleaned up the code a lot. Now the access and interpolation code
is separated into a separate voxel library inside blenlib. This is now properly
shared between voxel data texture and light cache (previously there was some
duplicated code).
* Made volume light cache support non-cubic voxel grids. Now the resolution
specified in the material properties is used for the longest edge of the volume
object's bounding box, and the shorter edges are proportional (similar to how
resolution is calculated for fluid sim domains).
This is *much* more memory efficient for squashed volume regions like clouds
layer bounding boxes, allowing you to raise the resolution considerably while
still keeping memory usage acceptable.
*Octree works nicely on hierarchic trees
*the old code was quite destructive at the Isect variable
changing isec->start, end, vec..now it only changes isec->labda (and hit results)
Currently rendering a BVH of all objects, where each object has it own octree.
*Adapted octree to a more generic raytrace API
*ray shadow works (other untested stuff disabled atm)
On the scene tested the user-cpu time got from 1:24 to 1:19/20
probably because of removed callbacks or sligtly diferente memory usage
This adds a header to the voxel data texture's data file format, to
auto-fill the resolution settings upon loading a file. I don't have a data
file of the right format to test with, so I'll trust it works and wait for
confirmation!
It also adds a 'still frame' setting, to pause the voxel data sequence on a
specified frame, throughout the course of the rendered animation.
Safe method to move render results to the displayed image.
It now allocates a single image for display, and on each
refresh callback from render, it copies the refreshed
section over to this image, in 32 bits. While rendering
that image then only shows progress updates, as usual.
This also now works for scenes in composte and results
for composite.
This should solve reported crashes for MBlur or SSS.
This is mostly a contribution from Raul 'farsthary' Hernandez - an approximation for
multiple scattering within volumes. Thanks, Raul! Where single scattering considers
the path from the light to a point in the volume, and to the eye, multiple scattering
approximates the interactions of light as it bounces around randomly within the
volume, before eventually reaching the eye.
It works as a diffusion process that effectively blurs the lighting information
that's already stored within the light cache.
A cloudy sky setup, with single scattering, and multiple scattering:
http://mke3.net/blender/devel/rendering/volumetrics/vol_sky_ss_ms.jpghttp://mke3.net/blender/devel/rendering/volumetrics/sky_ms.blend
To enable it, there is a menu in the volume panel (which needs a bit of cleanup, for
later), that lets you choose between self-shading methods:
* None: No attenuation of the light source by the volume - light passes straight
through at full strength
* Single Scattering: (same as previously, with 'self-shading' enabled)
* Multiple Scattering: Uses multiple scattering only for shading information
* Single + Multiple: Adds the multiple scattering lighting on top of the existing
single scattered light - this can be useful to tweak the strength of the effect,
while still retaining details in the lighting.
An example of how the different scattering methods affect the visual result:
http://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.jpghttp://mke3.net/blender/devel/rendering/volumetrics/ss_ms_comparison.blend
The multiple scattering methods introduce 3 new controls when enabled:
* Blur: A factor blending between fully diffuse/blurred lighting, and sharper
* Spread: The range that the diffuse blurred lighting spreads over - similar to a
blur width. The higher the spread, the slower the processing time.
* Intensity: A multiplier for the multiple scattering light brightness
Here's the effect of multiple scattering on a tight beam (similar to a laser). The
effect of the 'spread' value is pretty clear here:
http://mke3.net/blender/devel/rendering/volumetrics/ms_spread_laser.jpg
Unlike the rest of the system so far, this part of the volume rendering engine isn't
physically based, and currently it's not unusual to get non-physical results (i.e.
much more light being scattered out then goes in via lamps or emit). To counter this,
you can use the intensity slider to tweak the brightness - on the todo, perhaps there is a more automatic method we can work on for this later on. I'd also like to check
on speeding this up further with threading too.
Added WM Jobs manager
- WM can manage threaded jobs for you; just provide a couple
of components to get it work:
- customdata, free callback for it
- timer step, notifier code
- start callback, update callback
- Once started, each job runs an own timer, and will for
every time step check necessary updates, or close the
job when ready.
- No drawing happens in jobs, that's for notifiers!
- Every job stores an owner pointer, and based on this owner
it will prevent multiple jobs to enter the stack.
Instead it will re-use a running job, signal it to stop
and allow caller to re-initialize it even.
- Check new wm_jobs.c for more explanation. Jobs API is still
under construction.
Fun: BLI_addtail(&wm->jobs, steve); :)
Put Node shader previews back using wmJobs
- Preview calculating is now fully threaded (1 thread still)
- Thanks to new event system + notifiers, you can see
previews update even while dragging sliders!
- Currently it only starts when you change a node setting.
Warning: the thread render shares Node data, so don't delete
nodes while it renders! This topic is on the todo to make safe.
Also:
- bug in region initialize (do_versions) showed channel list in
node editor wrong.
- flagged the channel list 'hidden' now, it was really in the
way! This is for later to work on anyway.
- recoded Render API callbacks so it gets handlers passed on,
no globals to use anymore, remember?
- previewrender code gets now so much nicer! Will remove a lot
of stuff from code soon.
soc-2008-nicholasbishop branch.
Note: any old code with multires_test() or multires_level1_test() can
just be deleted, not needed by the multires modifier.
