before, but wasn't playing nice with the other force fields (was
overwriting the velocity rather than acting as a force). This version is
slightly different, but will work a lot better with other force fields too.
It works similarly to Vortex, but it's a more controllable - it
doesn't send the particles off accelerating into space, but
keeps them spinning around the Z axis of the force field object.
This is safe in the branch, but Jahka if you have any feedback,
I'd be curious to hear :)
Replaced 'Sharp' falloff with 'Soft'. This falloff type has
a variable softness, and can get some quite smooth results.
It can be useful to get smooth transitions in density when
you're using particles on a large scale:
http://mke3.net/blender/devel/rendering/volumetrics/pd_falloff_soft.jpg
Also removed 'angular velocity' turbulence source - it
wasn't doing anything useful atm
This was a bit complicated to do, but is working pretty well now, and can make shading significantly faster to render.
This option pre-calculates self-shading information into a
3d voxel grid before rendering, then uses and interpolates
that data during the main rendering phase, rather than
calculating shading for each sample. It's an approximation
and isn't as accurate as getting the lighting directly,
but in many cases it looks very similar and renders much faster.
The voxel grid covers the object's 3D screen-aligned bounding box
so this may not be that useful for large volume regions like a
big range of cloud cover, since you'll need a lot of resolution.
The render time speaks for itself here:
http://mke3.net/blender/devel/rendering/volumetrics/vol_light_cache_interpolation.jpg
The resolution is set in the volume panel - it's the resolution
of one edge of the voxel grid. Keep in mind that the higher the
resolution, the more memory needed, like in fluid sim. The
memory requirements increase with the cube of the edge
resolution so be careful. I might try and add a little memory
calculator thing like fluid sim has there later.
The voxels are interpolated using trilinear interpolation -
here's a comparison image I made during testing:
http://mke3.net/blender/devel/rendering/volumetrics/vol_light_cache_compare.jpg
There might still be a couple of little tweaks I can do to
improve the visual quality, I'll see.
- modified point density so that it returns a more consistent
density with regards to search radius. Previously larger radii
would give much higher density but this is equalised out now.
- Added a new volume material option 'density scale'. This is an
overall scale multiplier for density, allowing you to (for
example) crank down the density to a more desirable range if
you're working at a large physical scale. Volume rendering is
fundamentally scale dependant so this lets you correct to get the
right visual result.
- Also tweaked a few constants, old files won't render exactly
the same, just minor things though.
Enable soft body collision clusters by default.
Add option to 'disable collision' button between soft body and rigid body connected by constraint (option was already available between two rigid bodies)
Definitely one of the oldest bugs ever (1995 or so).
Case is a path (child on path, or deformer, or motion modifier) where the
child is far away from path (300 units or so). In that case you can see
the path jumping to another position a bit after a few frames.
Reason:
For interpolating path positions, I was using bspline code still having a
very ancient constant 0.1666f.
Floats have higher precision, like 0.16666666. That solved it :)
Playanim now works for:
- tiff, cineon, dpx, hdr, exr
Only multilayer not, that's too much for a bugfix. Multilayer is a totally
different image format, handled separately.
ALso removed redundant printing for dpx/cineon.
And fixed crash in cineon when G.scene doesnt exist. Bad bad, should
not be there!
This addition allows you to perturb the point density with noise, to give
the impression of more resolution. It's a quick way to add detail, without
having to use large, complex, and slower to render particle systems.
Rather than just overlaying noise, like you might do by adding a secondary
clouds texture, it uses noise to perturb the actual coordinate looked up
in the density evaluation. This gives a much better looking result, as it
actually alters the original density.
Comparison of the particle cloud render without, and with added turbulence
(the render with turbulence only renders slightly more slowly):
http://mke3.net/blender/devel/rendering/volumetrics/pd_turbulence.jpg
Using the same constant noise function/spatial coordinates will give a
static appearance. This is fine (and quicker) if the particles aren't
moving, but on animated particle systems, it looks bad, as if the
particles are moving through a static noise field. To overcome this, there
are additional options for particle systems, to influence the turbulence
with the particles' average velocity, or average angular velocity. This
information is only available for particle systems at the present.
Here you can see the (dramatic) difference between no turbulence, static
turbulence, and turbulence influenced by particle velocity:
http://mke3.net/blender/devel/rendering/volumetrics/turbu_compare.mov
- the number of segments was always 1 too many on cyclic curves.
- [#17739] - normals were not being calculated when rendering curves.
Replaced macro DL_SURFINDEX with a function. it that assumes variable names and could break from the loop that called it.
Added optional OGG / theora / vorbis support.
(OGG-format encoding is currently disabled, since the bundled ffmpeg version
is broken here)
Fixed a bug with PTS-encoding, to make theora work.
You have to explicitly enable it and currently only scons is supported.
Otherwise: enjoy! :)
Curve deform did not work yet on Text and Curve objects, this because it
was not providing the entire array of vertices, for a proper detection of
min/max bounds of the full input.
object message actuators needed the prefix OB when sending a message to a specific object.--This line, and those below, will be ignored--
M source/gameengine/Converter/KX_ConvertActuators.cpp
M source/blender/blenkernel/BKE_blender.h
M source/blender/src/buttons_logic.c
M source/blender/blenloader/intern/readfile.c
Replaced the previous KD-tree (for caching points) with a
BVH-tree (thanks to Andre 'jaguarandi' Pinto for help here!).
The bvh is quite a bit faster and doesn't suffer some of the
artifacts that were apparent with the kd-tree.
I've also added a choice of falloff types: Standard, Smooth, and
Sharp. Standard gives a harder edge, easier to see individual
particles, and when used with a larger radius, Smooth and Sharp
falloffs make a much cloudier appearance possible. See the image
below (note the settings and render times too)
http://mke3.net/blender/devel/rendering/volumetrics/pointdensity_bvh.jpg
limit ray intersections like as for ray transparency). It
remains to be seen if it's even that useful, and was
preventing refracting materials behind volumes from
working easily.
