* NLA scaling was being incorrectly handled with fractional values. This was caused by clamping to integers instead of floats when making sure the scale value was positive.
* Added checks to help prevent some weird cases that may sometimes occur and cause problems
removed frame numbering from BLI_convertstringcode into its own function (BLI_convertstringframe), many uses of BLI_convertstringcode were passing dummy frames values anyway.
in cases where adding the current frame number to a filename is needed run BLI_convertstringframe(...) after BLI_convertstringcode(...)
There are some cases Im not sure BLI_convertstringframe is needed, these have been commented as todo, but at least have the same functionality they used to.
from center of every metalement to 26 directions and try to find every place, where implicite function
crosses zero value. Size of step is size of polygonization cube. It can be proofed, that smaller size of step
is useless.
+control for normal projection direction (default,inverted,both)
There are some bugs on projection over quads.. it seems to work 100% on fully triangulized meshs
Bug #10104 reported by bebraw: missing check for how many node sockets were being created by a pynode script. Too many (more than MAX_SOCKET == 64) would crash Blender.
http://projects.blender.org/tracker/?func=detail&atid=125&aid=10104&group_id=9
Notes: moved the MAX_SOCKET define from node.c to BKE_node.h so I could use it in Node.c. Also improved error reporting in pynodes when errors occur in the init stage.
Thanks Juho (bebraw), Tom (assigned the bug to me) and Brecht (mentioned the MAX_SOCKET define).
Intel Xeon only), doing a lot of mutex locking is really slow. Getting
the image buffer for each texture read then made using more threads
actually slow down the render. Now I've split up the function in two
parts, one parts that checks if the image is available, and another
that does a mutex lock and loading if needed.
Changes quite a lot of code, so hopefully doesn't break stuff, but it
seemed to survive test with rendering a number of frames using all
image types and many threads, though this kind of threading problem
only happens once in a while .. so hard to test for.
* in scene.c in blenkernel, set_last_seq (defined in src - editseq.c) is called... this may/may not need some stubs for game-engine stuff
* removed unused vars due to old particle-effects stuff
* BPath sequencer strip looper was only operating on the active scene, now look through all scenes.
* The active sequence strip wasnt being reset when scenes switched, so you could see the previous scenes strip when switching to a new scene.
+ Nearest surface point
+ Normal projection
+ Nearest vertex (gives similar results to nearest surface if the target mesh has many vertexs and is a lot faster to calculate)
^^ all bruteforce calculation for now
+ fixed matrix order multiplication
+ request for CD_MDEDEFORMVERT
was calling screenmain() before executing the python script which meant it was never executed (therefore no crash :) )
Moved screenmain() back to the the end of main() and added a TESTBASELIB_BGMODE which checks for G.vd and uses the scene layer if its not there. Of course python should not be running stuff that uses G.vd :/
Also made python scripts stay attached to screens when LOAD UI is disabled. This means you can load a new blend file and the python console can stay open, has been tested for a while in the apricot branch.
Added BLI_split_dirfile_basic, that only splits the path into directory and file. without checking the dir exists or creating it, without changing the original string that is passed to it.
+vertex weights supported
+target object now saves to file: load/save works :)
for now simple moves objects vertexs to the nearest vertexs on target object
(so that I can test if its working correctly with the modifier API)
[#8067] external texture plugin thread-safe modifications
Submitted By: David Anderson (davywavy)
It makes it so the "result" array is passed in, instead of a global var.
I expanded the patch so it will play nice with older plugins that are not
thread safe as well.
I also updated the existing plugins in the release, so they are thread safe.
--------------- What do people think of this.... ------------------
This should maybe be talked about in the functionality board or something,
but what do people think of adding in default texture/sequence plugins.
or making a seperate tree like lib for plugins.
The reason I ask is we have had a couple of upgrades to the plugin system.
(supporting float buffers for sequencer, and this one for textures)
http://www.cs.umn.edu/~mein/blender/plugins does not store revisions of
plugins I just make sure they work with the latest version. This is
getting messy. I haven't upgraded a lot of them to use floats (I know,
I'm lazy, and now this will also make modifications to the plugins)
It would be nice to have some of the standard ones under revision control.
We also seem to be having an explosion of platforms supported. It would
be nice to have platform maintainers compiling plugins as well for releases.
(Its getting to be more work for me to keep up with things...)
I'll go back to my corner now and be quite. ;)
Kent
Unfortunately, my previous fixes here to get gears working resulted in this problem. The flip side of that was that gears worked for quite a few cases.
Alas, it is not to be... The bug is now fixed, but gears no longer work any more. Sadly, there is not much I can do about this.
Brecht Van Lommel
Joshua Leung
Andre Susano Pinto
Kent Mein
Campbell Barton
JLuc Peuriere
Jiri Hnidek
Willian Padovani Germano
Nicholas Bishop
Ken Hughes
Peter Schlaile
Daniel Genrich