This commit introduces a new texture ('Voxel Data'), used to load up saved voxel
data sets for rendering, contributed by Raúl 'farsthary' Fernández Hernández
with some additional tweaks. Thanks, Raúl!
The texture works similar to the existing point density texture, currently it
only provides intensity information, which can then be mapped (for example) to
density in a volume material. This is an early version, intended to read the
voxel format saved by Raúl's command line simulators, in future revisions
there's potential for making a more full-featured 'Blender voxel file format',
and also for supporting other formats too.
Note: Due to some subtleties in Raúl's existing released simulators, in order
to load them correctly the voxel data texture, you'll need to raise the
'resolution' value by 2. So if you baked out the simulation at resolution 50,
enter 52 for the resolution in the texture panel. This can possibly be fixed in
the simulator later on.
Right now, the way the texture is mapped is just in the space 0,0,0 <-> 1,1,1
and it can appear rotated 90 degrees incorrectly. This will be tackled, for now,
probably the easiest way to map it is with and empty, using Map Input -> Object.
Smoke test: http://www.vimeo.com/2449270
One more note, trilinear interpolation seems a bit slow at the moment, we'll
look into this.
For curiosity, while testing/debugging this, I made a script that exports a mesh
to voxel data. Here's a test of grogan (www.kajimba.com) converted to voxels,
rendered as a volume: http://www.vimeo.com/2512028
The script is available here: http://mke3.net/projects/bpython/export_object_voxeldata.py
* Another smaller thing, brought back early ray termination (was disabled
previously for debugging) and made it user configurable. It now appears as a new
value in the volume material: 'Depth Cutoff'. For some background info on what
this does, check:
http://farsthary.wordpress.com/2008/12/11/cutting-down-render-times/
* Also some disabled work-in-progess code for light cache
void bicubic_interpolation(struct ImBuf *in, struct ImBuf *out, float u, float v, int xout, int yout);
void neareast_interpolation(struct ImBuf *in, struct ImBuf *out, float u, float v, int xout, int yout);
void bilinear_interpolation(struct ImBuf *in, struct ImBuf *out, float u, float v, int xout, int yout);
Added...
void bicubic_interpolation_color(struct ImBuf *in, unsigned char *col, float *col_float, float u, float v);
void neareast_interpolation_color(struct ImBuf *in, unsigned char *col, float *col_float, float u, float v);
void bilinear_interpolation_color(struct ImBuf *in, unsigned char *col, float *col_float, float u, float v);
This is needed so for projection painting but generally useful if you want to get the interpolated color of a pixel in an image without having a destination imbuf.
While editing these I noticed the functons are a bit dodgy, they assume the input ImBuf has matching float/chr buffer to the output.
Tested overall speedup is about 5x when scaling 4096x4096 -> 4000x4000 in the sequencer.
There were some artifacts in the resulting image but double checked and the old code gives the same problems.
Added back old code with #if 0's since its a bit more readable.
* Use a slightly better (but still not exact) approximation for the view
vector when pre-shading the light cache. This still doesn't give exactly the
same results as non-light-cache shading, but it's better. Will investigate
getting a better view vector when there's more time - or if anyone has a
simple formula to derive shi->view from shi->co that would be great to
hear about too :)
Grease Pencil crashed after duplicating a screen-area, and deleting a layer from the original screen-area. The duplication code was not reassigning some pointers.
Fix the roll mess in transform. Since roll is based on an automatically calculated up axis, transforming bones would mess up bone orientation. This code automatically adjusts the roll value to keep bone orientation as consistant as possible. That works all around in transform for all transformations.
Doesn't work with x-axis mirror though as that doesn't use transform elements (fixing it would be nice for later)
Most interesting is that it works with the mirror tool (obviously), so you don't have to fix all the rolls after mirroring one side of an armature.
It could be made an option if someone presents a good enough point for that, but I can't see why you'd want the previous mess instead.
NB: this also ports a utility fonction from etch-a-ton to set bone roll from an up axis.
* BLI_linklist_index() - to get an items index in a LinkList
* BLI_memarena_use_malloc() - BLI_memarena_use_calloc alredy existed but there was no way to switch back to malloc.
also added texnodes to cmake
Robin (Frrr) Allen did a decent job on this, so we can also welcome him
as a member in the svn committers team to maintain it!
I do the first commit with some minor fixes:
- get Makefiles work
- fix rounding issue with tiles on unit faces
- removed UI includes from tex node
A nice doc in wiki is here:
http://wiki.blender.org/index.php/User:Frr/TexnodeManual
On the todo for Robin is:
- When using one or more Texture-input nodes, you cannot edit them by activating
(as works now for Material nodes).
- The new "output node" option fails on the default case, when only one
output node is active. It then shows often a blank menu. Will get fixed asap.
- When using a NodeTree-Texture as input node, the menu for 'active output'
should not show. NodeTree should ignore other nodetrees to keep things sane
for now.
- On a future todo is proper usage of "Dxt" and "Dyt" texture vectors for
superior antialising of checkers/bricks.
General note; I know people are dying to get a full integrated shader system
with nodes. In theory we could merge this with Material Nodetrees... but I
rather wait for a solid and very well thought out design proposal for this,
also including design ideas for unifying with a shader language (GPU, CPU).
For the time being this is a nice extension of current textures. :)
alpha channel based on the volume's transmission properties, allowing you
to use it in comp etc.
I'd rather not have this button at all, and make it just work properly
by default, however it causes problems with overlapping volumes when
'premul' is on (stoopid thing..) so for the time being, there's the
button. I'll try and fix this up later on when I have more time.
This commit adds an exception for rotations (standard rotation and tracball) to still work on children of transformed objects and bones in an expected fashion. That is, you can select a chain of finger bones and rotate to flex them all at once.
Notes:
[1] This could be expended to other transformations if needed.
[2] Center of transformation is determined using the same principle as hinge bones (transformed children aren't taken into account)
* Fixed a stupid crash caused by last commit that worked fine on the mac
(but never should have...)
* Fix for using child particles with the new particle age color options
This introduces a few new ways of modifying the intensity and colour output
generated by the Point Density texture. Previously, the texture only output
intensity information, but now you can map it to colours along a gradient
ramp, based on information coming out of a particle system.
This lets you do things like colour a particle system based on the individual
particles' age - the main reason I need it is to fade particles out over time.
The colorband influences both the colour and intensity (using the colorband's
alpha value), which makes it easy to map a single point density texture to
both intensity values in the Map To panel (such as density or emit) and colour
values (such as absorb col or emit col). This is how the below examples are
set up, an example .blend file is available here:
http://mke3.net/blender/devel/rendering/volumetrics/pd_test4.blend
The different modes:
* Constant
No modifications to intensity or colour (pure white)
* Particle Age
Maps the color ramp along the particles' lifetimes:
http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_partage.mov
* Particle Speed
Maps the color ramp to the particles' absolute speed per frame (in Blender
units). There's an additional scale parameter that you can use to bring this
speed into a 0.0 - 1.0 range, if your particles are travelling too faster or
slower than 0-1.
http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_speed.mov
* Velocity -> RGB
Outputs the particle XYZ velocity vector as RGB colours. This may be useful
for comp work, or maybe in the future things like displacement. Again, there's
a scale parameter to control it.
http://mke3.net/blender/devel/rendering/volumetrics/pd_mod_velrgb.mov
Modified to work in linux too, on my system subprocess.Popen(appstring) only works when appstring is a list.
Blenders __import__ didnt support keywords like pythons causing the subprocess module to fail for me.
added keywords to blenders c/api import to match pythons.
You can specify a image name (starting with 'IM') instead of a material
name in VideoTexture.materialID() and return the material ID matching
this texture.
The advantage of this method is that is works with blender material
and UV texture. In case of UV texture, it grabs the internal material
corresponding to the faces that are assigned to this texture. In case
of blender material, it grabs the material that has an image texture
matching the name as first texture channel.
In both cases, the texture id used in VideoTexture.Texture() should be 0.
Ex:
matID = VideoTexture.materialID(obj,'IMvideo.png')
GameLogic.video = VideoTexture.Texture(obj, matID, 0)
