IK-chain im/export support is in demand in the robotics field. I've been contacted by Herman Bryuninckx (Herman.Bruyninckx at mech.kuleuven.be), a person interested in this feature, who can help a student develop the requirements for IK-chain im/export.
On Wed, Mar 21, 2012 at 6:06 PM, Jass <[email protected]> wrote: > I mentioned one idea a few weeks ago regarding organization of > exporter/importer development. Here is an update: > > 1.) Create a "Blender Collada Core" which is built in c and which > builds on top of the openCollada libraries. This core would support all > features that Blender WANTS to expose to Collada (allows to export). > Ideally the importer/exporter pair should allow lossless round trip. > I believe that it CAN be done because the Collada specifications allow > insertion of tool dependent data. Of course the lossless roundtrip > would only work reliably for blender -> collada -> blender round trips. > > 2.) Add the ability to "inject" preparation scripts and post processing > scripts into the export or import. These scripts could keep target specific > adjustments. The script injection would be doable via a python API, > such that... > > 3.) Now each target (such as Second Life, Maya, 3DS max, ...) can be > supported by adding target specific exporters/importer addons. > These addons can do anything starting from just presetting or fixing > the exporter options (that's what i would do for the hypothetical > Second Life exporter right now), or add more elaborate changes > like adding an XSL Transformation to the exported .dae or whatever. > > in my opinion such an approach would help a lot to keep target > dependencies out of the Blender Collada implementation. It would > also help less skilled programmers to keep hands off blender code :) > and separate target specific development into python scripts. > > cheers, > Gaia > > On 21.03.2012 12:00, Daniel Balster wrote: > > Hi Arystanbek, > > > > ...I just started a new COLLADA feature at home a few weeks ago: > > profile_GLES. Since it goes beyond a small set of bug fixes it should go > > into a review/approval process. > > > > Problem description: > > > > profile_COMMON does not make me happy. Normally you write your "cool" > > shaders manually and feed them with parameters - but in profile_COMMON > > everything is hard-wired: > > - it's hard to match blender's current material+textures into a > > profile_COMMON effect > > - if you want to use COLLADA with custom shaders, you're missing a lot of > > parameters > > - just have a look at the<bump> hack > > - normally you have a shader (ie "skinning") that can be used for > multiple > > different models that only differ in a specific material setting (ie > > textures). Currently it's not possible to create a material/effect with > > exchangable samplers. > > > > My current COLLADA feature: > > > > profile_GLES (or Cg, GLSL,...) is much more versatile since it lets you > > spit out a lot of generic parameters, passes and even the actual shader > > sources. > > > > - via #ifdef I'm exporting<profile_GLES> instead of<profile_COMMON> > > - I'm just spitting out a lot of<newparam> for everything I'm aware of. > > - by convention, I'm splitting blender's material name into "prefix-" and > > "shader", ie "Material.001-skinning" > > - if the current blender document contains text scripts called > > "skinning.fs" and "skinning.vs", they're exported in the<code> section > of > > profile_GLES > > - otherwise an external reference to "skinning" is written. > > - additionally, I tried to hijack the current GLSL renderer to use these > > shaders to mimic my intended game effects (not working so far) > > > > So, if you like the idea I could write a clear feature design document > and > > contribute some code as a starting point. Since this is a very specific > > workflow it will need some reviews - especially how to interpret all of > > this in the import case (ie load shaders as text documents and bind them > to > > the GLSL renderer? convert to node graph? ...) > > > > > > Another not yet finished feature/bugfix is support for exporting > > binormals/tangents in meshes. Currently I'm doing this as a post process > > after importing a COLLADA file in my engine, checking for<bump> and > > regenerating normals and tangents by myself. Would be great if blender > > could do this as well. > > > > > > best regards, > > daniel > > > > > > On Wed, Mar 21, 2012 at 7:47 AM, Arystanbek Dyussenov > > <[email protected]>wrote: > > > >> Hi, > >> > >> This year I want to take part in improving the situation with collada > >> im/export as a part of GSoC. I plan to fix priority issues, currently > faced > >> by collada users. I will post my proposal to this mailing list, after I > >> prepare it. > >> > >> I am not the only student, who would like to work on collada this year > and > >> there's a possibility of other student or me adding new functionality to > >> collada support. > >> > >> Do you have ideas what collada im/export is currently missing? > >> > >> I think that carefully planned export of constrainted animations (in the > >> baked form) is something that users could benefit from. > >> > >> -- > >> Best regards, > >> Arystanbek Dyussenov > >> _______________________________________________ > >> Bf-committers mailing list > >> [email protected] > >> http://lists.blender.org/mailman/listinfo/bf-committers > >> > > _______________________________________________ > > Bf-committers mailing list > > [email protected] > > http://lists.blender.org/mailman/listinfo/bf-committers > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > -- Best regards, Arystanbek Dyussenov _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
