[Bf-committers] Need ideas on COLLADA improvement for GSoC

[Arystanbek Dyussenov]

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 <gaia.clary at machinimatrix.org> 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
> > <arystan.d at gmail.com>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
> >> Bf-committers at blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> >>
> > _______________________________________________
> > Bf-committers mailing list
> > Bf-committers at blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Best regards,
Arystanbek Dyussenov