Previously the distance constraint actuator was always working
in local axis. The local flag allows to cast the ray along a
world axis (when the flag is not selected).
The N flag works differently in this case: only the object
orientation is changed to be parallel to the normal at the hit
point.
The linear velocity is now changed so that the speed along the
ray axis is null. This eliminates the need to compensate the
gravity when casting along the Z axis.
Fixed vertexs weights on simpledeform modifier (they weren't working if the modifier was the first on stack, since it wasnt receiving a DerivedMesh with vertex weights)
Submitted by: Lorenzo Pierfederici (lento)
This patch adds the CTRL-ALT-A hotkey to align bones in armature edit mode.
It works the same way as parenting: selected bones will be aligned with active bone, if only one bone is selected it
will be aligned with its parent (if any)
Thanks!
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.
Added Bullet/Gimpact concave collision detection to Blender. If your build system isn't updated yet, please add extern/bullet2/src/BulletCollision/Gimpact/*
This allows moving/dynamic concave triangle meshes (decomposing meshes into compound convex shapes, and using 'compound' shapes is still preferred)
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...
set a fake world transform for game soft bodies, based on center of the AABB, so visiblity and some game logic works. note: this world transform is not smooth.
- A check for getting the "better" dm was missing from the boids code. I plan on converting the boids code into using the collision modifier one of these days but hopefully this quick fix will do for now.
from Dalai Felinto (dfelinto)
would useually not encourage prints in these cases, except its often useful to know if an error happened since you last pressed Pkey and without this you end up needing to manually clear the terminal.
Just getting rid of license_key stuff.
The project files still need to be updated:
projectfiles_vc7/blender/src/BL_src_cre.vcproj
projectfiles_vc7/blender/blendercompactNG.vcproj
Just search for these files in them.
Kent
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.
This problem is caused by discontinuities in the conversion
orientation matrix -> euler angles: the angle sign can
switch and thus the direction of the rotation produced
by the dRot Ipo.
To avoid this bug, the matrix->euler conversion must be
avoided during the game. I took the following approach that
is compatible with Blender (identical effect in the game and
in the 3D view):
- no change in Add mode: Rot and dRot are treated as additional
rotation to the orientation at the start of the Ipo. There is
no matrix->euler conversion and thus no discontinuities.
- Rot Ipo are treated as absolute rotation. All 3 axis should
be specified but if they are not, the startup object orientation
will be used to set the unspecified axis. By doing a matrix->
euler conversion once at the start, the discontinuities are
avoided. If there are also dRot curves, they are treated as
delta of the corresponding Rot curve or startup angle.
- dRot Ipo are treated as Add mode in Local axis.
Note about Add mode: Rot and dRot curves are treated identically
during the game. However, only dRot curves make sense because
they don't interfere with the object orientation in the 3D view.
removed calc_curve_subdiv_radius(), curve radius is now calculated the same way as tilt.
Added radius interpolation menu matching tilt interpolation, needed to add "Ease" interpolation type to keep 2.47 curves looking the same.
- In practice this removes the dependency of particle simulations from the update order of objects and different particle systems inside objects.
- As a nice side effect out of this we also get fully correct birth positions for "near reactor particles" (previously for example smoke trail reactor particles were not born smoothly along the target particles path).
-The fix is that particle random size factor should never ever be bigger than 1.0, else negative sizes are possible! Don't know who to blame, but probably my self :)
-The second issue of passing through the deflection and rotating wildly around strange centers is not a bug, but for particles the group and object visualization objects have to be centered on the global origin. I'll probably make an option later to use the object center, but this is how things are for now.
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...
this way each edge/segment gets the same number of points matching the resolution value.
before, a nurbs curve would have the same number of points no matter if it was cyclic or not.
This will make slight changes to objects on an animated path, but only noticable if the path has a low resolution.
bug [#11744] NurbCurve Radius incorrect - now dosnt show bad results with order 4 on non-cyclic curve.
- 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.
Also since contraint uses BVHCache its now usable and fast.
Being possible to shrinkwrap constraint several objects to another
and only have one BVHTree being build.
