rotation settings into account. Now if rotation is not set to None,
instead of automatically deriving it from the particle path (which
is useful for feathers), it uses the rotation settings (useful for
distributing twigs randomly).
Fixed the following problems with Bevel code
-meshes with 2 edged faces left over at the end would cause buffer
overrun whens converting from a Bmesh to a Derived Mesh. The
conversion process now checks for both double edges and faces
and removes them when present.
-BME_reverse_loop euler had a bug that was causing the corruption of
radial cycle. This would lead to the bevel tool hanging for a long time
and possibly crashing.
-Added optimization of BME_reverse loop so that it no longer does tiny
allocations but instead uses an area of 'scratch' memory. The same thing
will be done to the Make Face euler soon
-Added proper call to selection flushing for editmode.
-Some miscellaneous cleanups and removal of unneeded debug printfs.
* initial values I added in radialcontrol.c might need to be reviewed if they cause problems(I used 200, as it seems many tools were setting that)
* #pragma warnings are the only warnings I still get, so that means we have a clean slate again
platforms. Cause was a function(rng_getFloat(), rng_getFloat()),
apparently the order in which rng_getFloat() is evaluated is not
compatible between operating systems.
The following is a commit of Levi Schooley's bevel code and
the bmesh library it depends on. The current editmode bevel has
been replaced with a new per edge bevel function. Vertex beveling is
also availible.
To set weights for the modifier to use, use the ctrl-shift-e shortcut on either edges
or vertices.
Recursive beveling is turned of for the time being.
There was an extraneous line causing ID property groups
to have the wrong length, causing crashes in code that
relied on it.
This commit both fixes that and adds a version check to
fix group lengths for older .blends. The subversion
was incremented to 15 for this change.
Reversion of premul bugfix, as it was apparently not
working all that well.
Note that this brings back the bug where the erase alpha
paint tool won't display correctly, since the UV image
editor just draws images in key alpha now.
A new file could have its Blender.Get("filename") return "<memory>" after undo'ing on an open file.
Fix for own error with python sys.path, messed up game engine.
Without this, animating grass would either look like seaweed (with low freq texture)
Or the grass would wrinkle up and get kinks (high freq texture)
This lets you use a high frequency texture while having straight grass.
subsurf/derivedmesh mapping yet.
Also added int-to-pointer and back conversion function to solve warnings.
Note that it is only allowed to store an int in a pointer and then get
it back, but not a pointer in an int!
do_texture_effector assumed multitex_ext would assign r/g/b colors which isnt true for grey textures.
Fallback to PFIELD_TEX_GRAD with grey textures, node this in tooltip also.
This bug-report brought to light some problems with the transform constraint's handling of degrees+radians. Now, the input-range scaling is done in degrees (as the clamping factors ranges are in degrees) instead of having that done after this stage. The problems should now be fixed (and gears now seem to work ok), but I hope no other rigs have been broken.
commit. I still think this is a good idea, but needs more discussion.
Basically, the way the premul option worked before is it actually
changed the image data to be premul (for each pixel it multipled r,g,b by a) when
loading an image. So if a user wanted his image to be key, yet
still work in the renderer (which expects premul) he'd be stuck.
Also, it was kindof confusing how if you painted something in the image,
then saved it with premul on, when next you loaded the image it'd have
changed (especially since the image editor painting seems to paint in
key, not premul).
basically flagged the image so that on next load/reload, the image
data would be converted to premul. This was very confusing to the
user, as it meant premul wouldn't take effect will the image was
reloaded, and it would also change the image data, which the user
might've been painting.
To fix this, I've removed this behaviour and instead made the premul
option apply at render time. During render while evaluating an image
texture, if the image has the premul flag set then the premul operation
is done on the texture result data, thus not touching the image data
at all.
Also, I've made premul be turned on by default.