sure if this is 'correct' but so far in testing it's been working
pretty well.
This also exposes a new 'Nearest' value, to determine how many
nearby particles are taken into account when determining density.
A greater number is more accurate, but slower.
Initial commit for supporting rendering particles directly as
volume density. It works by looking up how many particles are
within a specified radius of the currently shaded point and using
that to calculate density (which is used just as any other
measure of density would be).
http://mke3.net/blender/devel/rendering/volumetrics/smoke_test01.mov
http://mke3.net/blender/devel/rendering/volumetrics/smoke_test01.blend
Right now it's an early implementation, just to see that it can
work - it may end up changing quite a bit. Currently, it's just a
single switch on the volume material - it looks up all particles
in the scene for density at the current shaded point in world
space (so the volume region must enclose the particles in order
to render them.
This will probably change - one idea I have is to make the
particle density estimation a procedural texture with options for:
* the object and particle system to use
* the origin of the co-ordinate system, i.e. object center, world
space, etc.
This would allow you in a sense, to instance particle systems for
render - you only need to bake one particle system, but you can
render it anywhere.
Anyway, plenty of work to do here, firstly on getting a nice
density evaluation with falloff etc...
solids, in front of other volumes, etc. Now there's a 'layer depth'
value that works similarly to refraction depth - a limit for how many
times the view ray will penetrate different volumetric surfaces.
I have it close to being able to return alpha, but it's still not 100%
correct and needs a bit more work. Going to sit on this for a while.
* Now it's possible to render with the camera inside a volume. I'm not sure how this goes with overlapping volumes yet, will look at it. But it allows nice things like this :)
http://mke3.net/blender/devel/rendering/volumetrics/clouds_sky.mov
* Sped up shading significantly by not doing any shading if the density
of the current sample is less than 0.01 (there's nothing to shade there anyway!) Speeds up around 200% on that clouds scene.
* Fixed a bug in global texture coordinates for volume textures
Now other objects (and sky) correctly render if they're partially
inside or behind a volume. Previously all other objects were ignored,
and volumes just rendered on black. The colour of surfaces inside or
behind the volume gets correctly attenuated by the density of the
volume in between - i.e. thicker volumes will block the light coming
from behind. However, other solid objects don't receive volume shadows
yet, this is to be worked on later.
http://mke3.net/blender/devel/rendering/volumetrics/vol_inside_behind.png
Currently this uses raytracing to find intersections within the volume,
and rays are also traced from the volume, heading behind into the
scene, to see what's behind it (similar effect to ray transp with IOR
1). Because of this, objects inside or behind the volume will not be
antialiased. Perhaps I can come up with a solution for this, but until
then, for antialiasing, you can turn on Full OSA (warning, this will
incur a slowdown). Of course you can always avoid this by rendering
volumes on a separate renderlayer, and compositing in post, too.
Another idea I've started thinking about is to calculate an alpha
value, then use ztransp to overlay on top of other objects. This won't
accurately attenuate and absorb light coming from objects behind the
volume, but for some situations it may be fine, and faster too.
Rather than a single absorption value to control how much light is absorbed as it
travels through a volume, there's now an additional absorption colour. This is
used to absorb different R/G/B components of light at different amounts. For
example, if a white light shines on a volume which absorbs green and blue
components, the volume will appear red.
To make it easier to use, the colour set in the UI is actually the inverse of the
absorption colour, so the colour you set is the colour that the volume will
appear as.
Here's an example of how it works:
http://mke3.net/blender/devel/rendering/volumetrics/vol_col_absorption.jpg
And this can be textured too:
http://mke3.net/blender/devel/rendering/volumetrics/vol_absorb_textured.png
Keep in mind, this doesn't use accurate spectral light wavelength mixing (just
R/G/B channels) so in cases where the absorption colour is fully red green or
blue, you'll get non-physical results.
Todo: refactor the volume texturing internal interface...
- Fixed a shading bug, due to issues in the raytrace engine where it would ignore
intersections from the starting face (as it should). Disabled this for single
scattering intersections, thanks to Brecht for a hint there. It still shows a
little bit of noise, I think due to raytrace inaccuracy, which will have to be
fixed up later.
before: http://mke3.net/blender/devel/rendering/volumetrics/vol_shaded_old.png
after: http://mke3.net/blender/devel/rendering/volumetrics/vol_shaded_correct.png
Now single scatttering shading works very nicely and is capable of things like this:
http://mke3.net/blender/devel/rendering/volumetrics/vol_shaded_clouds.mov
- Added colour emission. Now as well as the overall 'Emit:' slider to control
overall emission strength, there's also a colour swatch for the volume to emit
that colour. This can also be textured, using 'Emit Col' in the map to panel.
This animation was made using a clouds texture, with colour band, mapped to both
emit colour and emit (strength):
http://mke3.net/blender/devel/rendering/volumetrics/vol_col_emit.mov
- Added 'Local' mapping to 'map input' - it's similar to Orco
- Fixed texture 'map input', wasn't using the offsets or scale values.
Zbuffer error in render: when you render faces clipped by 'clip end' the
z values could wrap around, resulting in errors. Code not nicely clamps,
plus should be faster even!
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.
- Added blending mode and factor option, so it's more clear and
controllable what happens with it. Also nice for crazy effects
of course!
- Preview render now shows preview for it too
On the todos:
- have this in World buttons (as well) for quicker sky setups
- review math of color clamping and scaling, this is definitely
not good... but a fix will make old files look very different.
- Changed order for applying atmosphere, it does it now before alpha-adding
sky, giving correct transparency
- Added correction for de-premulling and premulling scatter color
Commit patch #7788, allow to set the render step, so it's
possible make render every N frames only.
The step is change in Scene buttons (F10), below start and
end frame buttons.
Also add a command line options (-j), so it's possible to
overwrite the file step (useful for renderfarm).
[ Brecht, this work with OpenGL renders and simulated
the skipped frames, please double check ]
Finally, after a long time new render candy for the non-game peoples! :)
Good doc is here: (url splits in two)
http://www.harkyman.com/2008/08/06/controllable-shadow-intensity-
and-color/
Note the colorpicker for shadow is in "Shadow and Spot" panel. A bit
hidden, could get more attention. For later. :)
not give a smooth fallof. there's no correct fix possible due
to a lack of information, but this manually adds a smoother
falloff, overestimating the contribution of foregroud pixels
instead of becoming transparent.
halo material attach to the object instead of the mesh.
Also for bug #13489: avoid a crash rendering with invalid
active vcol layer, most likely caused by a bug that was
already fixed.
FSA didn't support "key alpha", fixed it.
Also noticed edge-enhance didnt work for FSA, added warning for that,
fixing it is too clumsy, this option belongs in compositor.
the features that are needed to run the game. Compile tested with
scons, make, but not cmake, that seems to have an issue not related
to these changes. The changes include:
* GLSL support in the viewport and game engine, enable in the game
menu in textured draw mode.
* Synced and merged part of the duplicated blender and gameengine/
gameplayer drawing code.
* Further refactoring of game engine drawing code, especially mesh
storage changed a lot.
* Optimizations in game engine armatures to avoid recomputations.
* A python function to get the framerate estimate in game.
* An option take object color into account in materials.
* An option to restrict shadow casters to a lamp's layers.
* Increase from 10 to 18 texture slots for materials, lamps, word.
An extra texture slot shows up once the last slot is used.
* Memory limit for undo, not enabled by default yet because it
needs the .B.blend to be changed.
* Multiple undo for image painting.
* An offset for dupligroups, so not all objects in a group have to
be at the origin.
All of the reference to the original Material class were renamed to FrsMaterial to resolve a name collision with Blender. To keep the window context necessary to draw the strokes after RE_Database_FromScene has been called, the display_clear function is used.
Specular render in Blender still had terminator problems... only the diffuse
part got "phong correction" applied. I didn't fix this before to not change
rendering results just before the release. Now there's time I hope?
Render results should only differ minimal, and only visible for low spec
hardness values (like 1 or 2)
Ztransp OSA render did not include z values anymore in pass... this is
not good Z anyway (aliased), but at least it's back now.
Note: for composites using Z values: use FSA for superior results.
