patch from Masaru Nemoto (mnemoto)
Made some modifications to the patch, use reduce() to get total face verts and some speedup for face vcol looping, also don't write vcol alpha since its used by brushes internally and has no useful meaning.
AGAIN PLEAST USE TABS, lost quite some time with mixed tab/space adjustments alone.
Other then that, patch is very useful ;)
---Text from patch submission ---
Using a slightly revised BPy_Armature, this script takes any non-armature object type and creates an Action that keys
the object location (by default, for every frame). If it is an Armature, it goes into each bone and keys the locrot
of the bone. You can now edit the armature, but the motions still rotate the bones. This enables the next step, re-targeting,
which changes bone lengths to fit a mesh. High-level, we are working toward:
1. import mocap (bvh or c3d)
2. bake to make an action library (using this script)
3. re-target and use the actions to drive/deform any character mesh (theeth)
c3d importer for motion capture data
This could do with some improvements but for now its acceptable.
- Note, could people please not mix tabs and spaces.
-Text copied from the patch submission-
The c3d_import with 2.46 was able to import a mocap cloud for some c3d files. I have improved it:
Version History:
0.4: PERIN Released under Blender Artistic Licence
0.5: WICKES used marker names, fixed 2.45 depricated call
0.6: WICKES creates armature for each subject
0.7: WICKES constrains armature to follow the empties (markers). Verified for shake hands s
0.8: WICKES resolved DEC support issue
see also http://wiki.blender.org/index.php/Tutorials%5CMoCap-Section_3 for how this program gets the mocap data into
Blender and creates an armature, like the BVH script does.
I'd like someone to test and verify, and if accepted, replace the current c3d_import.py
--- See patch url for example files http://projects.blender.org/tracker/index.php?func=detail&aid=14392&group_id=9&atid=127
Faulty indentation of a line sometimes caused a bunch of empty lines to
be printed into the TextureCoordinate and texCoodIndex fields
(benign error, just ugly).
Patch #10569 from Michalis Kamburelis (sorry for the delay).
This patch adds a popup menu that lets the user choose whether
they want to export selected, whether thay wanted to export
compressed, and whether they want to export the file from
blender's "Z up" coordinates to VRML's "Y up".
I'm not too crazy about the caching to disk of these options
via GetRegistry/SetRegistry, but since this seems to occur
in many of the other export scripts I'll leave it as is.
---------------------------------------------------
Snappy stuff
* Align rotation with snapping target: rotate the object, aligning it with the target (object mode only - temporarily) (New icon in the header when snap is turned on)
* Snap to different mesh elements (face, edge, vertice): snapping target slide on faces and edge or use exact position of vertice. When using Align rotation with edge snapping, the normal is interpolated as you slide along.
Snaps correctly to derived mesh (sculpt, modifiers, ...) and duplis. In object and edit mode.
NOTE: The snapping code is now based on faces, so even if you're snapping to vertices or edges, it will not work on meshes without faces. This might change if needed.
New faceweld code broke the import of meshes with loose
vertices. Also added exception handling to the importer
and exporter so that UI doesnt quite when errors are encountered.
Instead traceback is printed to stderr and control returns to
the script UI
for running these scripts outside blender.
The error looked like this.
SyntaxError: Non-ASCII character '\xe4' in file ./3ds_export.py on line 10, but no encoding declared; see http://www.python.org/peps/pep-0263.html for details
1) Bug #6692 is actually a feature request. While I do think that
Michalis' patch is a worthy change, we don't have time to test
this at this stage in the release cycle (and svn is supposedly
closed to new features anyways). I'm sorry Michalis, this will
have to wait until after release.
2) I have looked at bug #8814 a while ago, but I have not yet found
a good solution (and perhaps the solution is to *not* export faces
without materials assigned). I don't have time to assess whether
revision 14774 presents a worthwhile change or not, and I have no
time to test before release. Also I don't like that the 'fix' for
#8814 is mixed with a fix for a previous faulty commit.
3) Again, another commit to a script I maintain without consulting
me first. Not cool!
Chris
null materials were not exported, but would also mess up the assignment of materials for any valid materials after the empty slots.
also made a mistake last recently that Michalis Kamburelis pointed out, changing the default orientation incorrectly. this is now set
back to what it was in Michalis's patch.
* option to export modifier applied objects
* option to export quads as tri's
* added back compress option (will default to enabled if you use .x3dz as the extension)
[bf-blender-Bug Tracker][6693] x3d export bug in V2.44 release
[bf-blender-Bug Tracker][7773] .x3d exporter problems (moving meshes away)
Updated how objects are transformed, and use Mesh rather then NMesh.
also removed vertex color saving since it was really slow and vcolors are stored per face in blender.
slight change to the fix suggested, the svg imported was assuming that
"fill:" and "#" being in a string meant there was "fill:#", but the # could be used for other properties.
This means when moving large projects with many images/videos/sounds is possible with 'File, External Data, Find Missing Files'.
- needed so we can put peach animatic, glrenders & testrenders on the dvd.
also datatoc.c - brecht's fixes from apricot.
This replaces the hard-coded '%PROFILE%\Application Data\..." path
with the correct language-dependant CSIDL_APPDATA.
PLEASE NOTE!
Checks for the previous location have now been REMOVED. Any data
saved in the old hard-coded location will no longer be found by
Blender (this will only affect users of non-english windows.)
The installer has been updated to help the user to migrate their data
to the new location of their choice, if necessary.
Order of preference for .blender on windows is now the following:
1) %HOME% environment var
2) Installation Directory (location of blender.exe)
3) "Current User" (CSIDL_APPDATA)
4) "All Users" (CSIDL_COMMON_APPDATA)
[#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
