[Bf-committers] Collada importer/exporter kickout

[Sergey Sharybin]

Hi,

As everybody noticed current collada importer/exporter is very buggy which
seems to make this format almost useless in Blender. And what's much worse
-- we don't actually have developer who maintains this area.

We discussed this already with Campbell and found that OpenCollada itself
isn't actually maintaning -- there are only few commits in several months.
Ofcourse it doesn't mean this library is useless and all bug from our
tracker is related on that issues, but still.. Maybe the time have come to
re-think this importer/exporter (investigate if it's possible to fix issues
in clear way, check if design is good enough -- not sure, haven't touched
this code deep myself)?

Here's our proposal:
- Move all collada-related issues into it's own tracker. Like it was done
with BGE, it might help finding volunteer to fix them. Also, people will
see that it's not actually core stuff and that it's community-supported.
- Disable collada in release builds. It's not useable and only seems to be
making artists disappointed.

More optimistic targets would be find volunteer to pick up this stuff who
will make it usable (maybe rewritting this stuff from scratch..)

-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada importer/exporter kickout

[Francesco Zoffoli]

I'm just curious: why can't an external library be used?

I know about Assimp, i double checked and it seams that it supports collada
import/export(at least they say so on their site, and i think it is full
support since it isn't marked with an * [2][3]). It also has a C or C++ API.
The licence is (a kind of [4])BSD, is this a problem?
This would offload main devs from format support. In addition blender would
be able to import/export all the format the external library already
handles. And in case specific files must be supported, this can be archived
with python or a specific imp/exporter.

Is there a reason why blender shouldn't rely on an existing library, or
it's a licence/features problem with the existing ones?


[1] http://assimp.sourceforge.net/index.html
[2] http://assimp.sourceforge.net/main_features_formats.html
[3] http://assimp.sourceforge.net/main_features_export.html
[4] http://assimp.sourceforge.net/main_license.html
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada importer/exporter kickout

[Sergey Kurdakov]

Hi All,

just noticed commit
http://code.google.com/p/opencollada/source/detail?r=867 to
OpenCOLLADA rep

which resolves the mentioned problem with OpenCOLLADA, that library to
generate code from XSD schema is absent.

the issue, at least, starts to be adressed.

Regards
Sergey
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada importer/exporter kickout

[Sebastian]

Erwin already announced it: I've contributed the code generation 
libraries under the MIT license and committed it to our Subversion 
repository.

You should see this as our commitment to the future of OpenCOLLADA. 
OpenCOLLADA is and was a lot of work, it's far away from being perfect 
or even error free but I would not suggest to develop yet another DAE 
importer/exporter specifically for Blender or even drop support for it. 
For the COLLADA community Blender is definitely one of the most 
important stakeholders to stop supporting COLLADA would make things in 
DCC exchange even worse.

We are currently discussing further financing of OpenCOLLADA and will 
spend more time the next months on bugfixing and conformance tests.

Sebastian



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada importer/exporter kickout

[spatial]

> For the COLLADA community Blender is definitely one of the most
> important stakeholders to stop supporting COLLADA would make things in
> DCC exchange even worse.
I agree. Not to mention all those who co use it alongside LW , all of 
DAZ productsetc.

I actually tried to avoid a discussion here since a long time,
but topic is too important.

First, kicking out collada from blender doesn't help anyone. None of the 
"common" interexchange formats is that reliable / support all features. 
To have at least a second format as a backup strategy,  if a certain 
features arent't supported / have some unreliable results, is a "must 
have" in every cross application enviroment.

And btw, blenders FBX import is, from my experience, still not as 
reliable as it should be, to actually replace collada. (sorry, this is 
no actual bashing... its already great what has been archived... 
especially if you consider that it is allways pain in the ass, to 
support such a complex exchange format)

> We are currently discussing further financing of OpenCOLLADA and will
> spend more time the next months on bugfixing and conformance tests.
>
Sorry to say this, but this is one of the mayor reasons I have to post this:

Conformance tests do only help a little to 0
The big _advantage_ fbx has, is a working reference application called maya.

No conformance test can actually be that foolproof to support all 
features and variations. So by this simple unoffical agreement,"if it 
doesn't work in maya - it is broken", users and developers have an ideal 
platform to discuss errors / find workarounds.  This greatly avoids the 
"picking in the dark" situation all developers currently face with 
collada. Even if a dev doesn't have access to it, in a lot of cases, he 
can track down problems reported by users who do provide a simple 
screenshot.

Could this collada reference application be Blender ?
For me this is a very attractive idea, but also, I'm very aware of the fact,
that I'm opening a can of worms I'm actually in no way in the right 
position to touch.

Anyway just my 2 cents on this.
chris




___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

[Bf-committers] Collada importer/exporter kickout

[spatial]

> Is anyone using collada successfully for interchange character
> animations between content creation applications?
> (not export to game engine but actually move mesh+rig data between
> apps for further editing).

Ok an example:
Its currently the only way to import LW scenes in a reliable way into 
blender,  the only problem I do face is a different camera orientation 
axis wich can be solved by exporting the camera motion mapped on a null 
object with a non animated camera parented to  it.  (ANd reroriented in 
blender)

As for importing additional vertex deformations inside blender, I do 
usually rely on an additional mdd file , to avoid the problems from the 
beginning,  wich is, from my perspective, a common strategy.
(And btw a reason I do use the existing mdd modifier patch, since it 
allows a non destructive workflow between both applications...)

I also used it to import some daz characters.

> again, would be nice to hear some example, even anecdotal as to what
> isn't working in FBX (assume you mean exporter since we don't have a
> stable importer).
Nope _I am_ talking about the importer. FBX export is great.. this is 
really well done . And yes, its defintively a lot more reliable than dae.
But the original idea discussed here was about kicking both.

> FBX was written for Kaydara Motionbuilder, which I used as a
> reference,
Ok, could be, but I think you get the point:
You do have an application wich you can use as a reference, wich collada 
actually hasn't.  If I do send you an fbx wich seems to be correct and 
it doesn't show up correctly in motionbuilder, you can actually blame me 
or my program... or better, even find a solution to satisfy me without 
breaking the big scheme.
As for a dae, you can'tt nothing to rely on such a thing.


> Otherwise having overly specific blender/collada format runs the risk
> of nobody adopting it and looses a lot of blender developer time.
Yes, but thats a general issue developers of all applications trying to 
implement dae
currently have to face. Point is, they can't even use market share or 
popularity as an actual
guideline, since this is actually well covered by... yes fbx.
So the only logical alternative they do have, is trying to cope with as many as 
possible dialects
as possible, and as a result, creating a new one: We got the Houdini dae,
the Autodesk dae, the c4d dae.. and so on.

So this isn't that much about getting actually more mantime into the 
exporter/importer or
into opencollada but first more about getting Khronos making a public statement 
that
"application X is 90% conformal to dae. (Stating wich parts aren't)".

There a several reasons why I do think blender is an ideal candidate for it :

a) all collada devs can access it
b) it contains a broad range of the dae features.
c) changes are documented,
d) unconformal behaviours can be identified and corrected.

On the other hand, this _is_ very ambitious. So a different program might be
really a better option.



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Thomas Dinges]

Hi,
I can only agree with this, the amount of bugs related to Collada is 
really heavy in our bug tracker.

It's a bit sad though, as much energy has been put into that by Nathan 
and in the GSOC project, but as you said, it's unmaintained for months.

+1 for the proposal.

Regards,
Thomas

Am 04.01.2012 20:57, schrieb Sergey Sharybin:
> Hi,
>
> As everybody noticed current collada importer/exporter is very buggy which
> seems to make this format almost useless in Blender. And what's much worse
> -- we don't actually have developer who maintains this area.
>
> We discussed this already with Campbell and found that OpenCollada itself
> isn't actually maintaning -- there are only few commits in several months.
> Ofcourse it doesn't mean this library is useless and all bug from our
> tracker is related on that issues, but still.. Maybe the time have come to
> re-think this importer/exporter (investigate if it's possible to fix issues
> in clear way, check if design is good enough -- not sure, haven't touched
> this code deep myself)?
>
> Here's our proposal:
> - Move all collada-related issues into it's own tracker. Like it was done
> with BGE, it might help finding volunteer to fix them. Also, people will
> see that it's not actually core stuff and that it's community-supported.
> - Disable collada in release builds. It's not useable and only seems to be
> making artists disappointed.
>
> More optimistic targets would be find volunteer to pick up this stuff who
> will make it usable (maybe rewritting this stuff from scratch..)
>


-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Nathan Letwory]

Hi,

I currently have not much time to put into this, but please drop into
#blendercollada to check status of efforts there too.

There are many possibilities being worked on (an importer/exporter by skrat
based on pycollada, and there was at some point a user who wanted to donate
some personal code, but that is I think also WIP. Further the company
Mixamo has been in contact about COLLADA support) , so if you or someone
else can step up to guide the process that'd be great.

/Nathan

On Wed, Jan 4, 2012 at 9:57 PM, Sergey Sharybin wrote:

> Hi,
>
> As everybody noticed current collada importer/exporter is very buggy which
> seems to make this format almost useless in Blender. And what's much worse
> -- we don't actually have developer who maintains this area.
>
> We discussed this already with Campbell and found that OpenCollada itself
> isn't actually maintaning -- there are only few commits in several months.
> Ofcourse it doesn't mean this library is useless and all bug from our
> tracker is related on that issues, but still.. Maybe the time have come to
> re-think this importer/exporter (investigate if it's possible to fix issues
> in clear way, check if design is good enough -- not sure, haven't touched
> this code deep myself)?
>
> Here's our proposal:
> - Move all collada-related issues into it's own tracker. Like it was done
> with BGE, it might help finding volunteer to fix them. Also, people will
> see that it's not actually core stuff and that it's community-supported.
> - Disable collada in release builds. It's not useable and only seems to be
> making artists disappointed.
>
> More optimistic targets would be find volunteer to pick up this stuff who
> will make it usable (maybe rewritting this stuff from scratch..)
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
Nathan Letwory
Letwory Interactive
http://www.letworyinteractive.com
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Peter Amstutz]

Hi Sergey,

When I looked last looked at OpenCollada, one critical issue preventing 
someone else from taking over maintenance is the fact that it relied 
heavily on autogenerated code, but the code generator and the input file 
are not included in the online repository.

The ColladaDOM reference implementation uses an awful code generator 
written in PHP, but at least it is available.

The nature of the Collada spec is that generating code from the schema 
is the only reasonable way to go, as permutation of tags and schema 
rules mean that trying to code it all by hand would cause you to grind 
your fingers down to little stubs by the time you were done.  I've 
successfully used JAXB to generate an API from the Collada 1.4 schema, 
but that is Java so that won't work for Blender.  There are presumably 
be similar tools for C++ and Python (although at least one Python 
XML->code generator I tried failed spectacularly with an out of memory 
error after running for ten minutes).

There are also a lot of permutations of data formats (especially how 
vertex data is stored) which entail troublesome and buggy data conversion.

To have better Collada support in general would ideally start with a 
standalone Collada library that handles not just the basic parsing, but 
provides a comprehensive implementation of the Collada database 
including data conversion facilities so that the client application can 
request or write data in any reasonable format and have the library 
figure out how to translate it to/from the underlying Collada file. 
This would also manage/link the cross references automatically so a 
rendering engine could, for example, access the data as a scene graph 
and not have to deal with the library structure.  This would benefit 
lots of 3D software, not just in Blender.

There would also needs to be a set of test cases, ideally both unit and 
regression tests so users can reliably know which features are 
supported.  Buggy support is worse (certainly more frustrating) than no 
support.  (*cough*armatures*cough*)  Finally, an importer/exporter needs 
to be tested against itself; there is nothing more embarrassing than an 
exporter that produces a file that the corresponding importer cannot 
read properly.

I don't know if this necessitates starting over, although if OpenCollada 
can't be maintained that seems like a pretty fatal problem.

(In general, I suspect Collada support in most software is half assed, 
because a comprehensive implementation is so so much work, and most of 
the time a developer of application "X" just needs to import/export file 
"Y" for  application "Z", so they only support that particular need and 
if it works for other files, good luck.)

To tie this up - talk is cheap, I don't have the time/resources to work 
on Collada support presently, so take this all with a grain of salt.

- Peter

On 1/4/2012 2:57 PM, Sergey Sharybin wrote:
> Hi,
>
> As everybody noticed current collada importer/exporter is very buggy which
> seems to make this format almost useless in Blender. And what's much worse
> -- we don't actually have developer who maintains this area.
>
> We discussed this already with Campbell and found that OpenCollada itself
> isn't actually maintaning -- there are only few commits in several months.
> Ofcourse it doesn't mean this library is useless and all bug from our
> tracker is related on that issues, but still.. Maybe the time have come to
> re-think this importer/exporter (investigate if it's possible to fix issues
> in clear way, check if design is good enough -- not sure, haven't touched
> this code deep myself)?
>
> Here's our proposal:
> - Move all collada-related issues into it's own tracker. Like it was done
> with BGE, it might help finding volunteer to fix them. Also, people will
> see that it's not actually core stuff and that it's community-supported.
> - Disable collada in release builds. It's not useable and only seems to be
> making artists disappointed.
>
> More optimistic targets would be find volunteer to pick up this stuff who
> will make it usable (maybe rewritting this stuff from scratch..)
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Knapp]

If the bug tracker is getting a lot of bug reports, does that not mean
that the artists want it? I know I have been waiting years for it to
get working so I can export to panda3d. It has been some time since I
checked on the status of this problem so perhaps they at panda have
another way. So, I would really like to have a good way to export to
Panda3d and I bet I am not the only one. How much is it hurting
blender adoption by not having a  good exporter for this format?


-- 
Douglas E Knapp

Creative Commons Film Group, Helping people make open source movies
with open source software!
http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

Massage in Gelsenkirchen-Buer:
http://douglas.bespin.org/tcm/ztab1.htm
Please link to me and trade links with me!

Open Source Sci-Fi mmoRPG Game project.
http://sf-journey-creations.wikispot.org/Front_Page
http://code.google.com/p/perspectiveproject/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Tobias Kummer]

Panda3D export isn't really a problem without Collada, see here: 
http://www.panda3d.org/manual/index.php/Converting_from_Blender
I'd also be happy to be able to shove models around between different 
packages without much hassle, but I find myself almost always having to 
resort back on .3ds or .obj.
I never got Blenders Collada working correctly. 
My 2ct: as long as it doesn't work in a predictable way - don't include 
it in release builds.

Greets,
Tobi

On Wed Jan  4 22:43:00 2012, Knapp wrote:
> If the bug tracker is getting a lot of bug reports, does that not mean
> that the artists want it? I know I have been waiting years for it to
> get working so I can export to panda3d. It has been some time since I
> checked on the status of this problem so perhaps they at panda have
> another way. So, I would really like to have a good way to export to
> Panda3d and I bet I am not the only one. How much is it hurting
> blender adoption by not having a  good exporter for this format?
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

On Thu, Jan 5, 2012 at 6:57 AM, Sergey Sharybin  wrote:
> Hi,
>
> As everybody noticed current collada importer/exporter is very buggy which
> seems to make this format almost useless in Blender. And what's much worse
> -- we don't actually have developer who maintains this area.
>
> We discussed this already with Campbell and found that OpenCollada itself
> isn't actually maintaning -- there are only few commits in several months.
> Ofcourse it doesn't mean this library is useless and all bug from our
> tracker is related on that issues, but still.. Maybe the time have come to
> re-think this importer/exporter (investigate if it's possible to fix issues
> in clear way, check if design is good enough -- not sure, haven't touched
> this code deep myself)?
>
> Here's our proposal:
> - Move all collada-related issues into it's own tracker. Like it was done
> with BGE, it might help finding volunteer to fix them. Also, people will
> see that it's not actually core stuff and that it's community-supported.
> - Disable collada in release builds. It's not useable and only seems to be
> making artists disappointed.
>
> More optimistic targets would be find volunteer to pick up this stuff who
> will make it usable (maybe rewritting this stuff from scratch..)
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers


+1 for immediate creation of Collada tracker and move collada bugs
there (can help with this, it worked well for BMesh).

Other topics can be postponed closer to release, though I'd expect
2.62 would include collada, perhaps we could set some target for the
Collada tracker & call for developers to help out, or disable by
default (actual code removal can be checked on much later if we want
to phase out or move to something else).


My own experience with trying to fix collada bugs has not been great -
the few issues I ran into were either very hard to debug or bugs in
opencollada (which I forwarded to the collada tracker) - just to say
that ~5 or so times I seriously tried to fix some of our collada bugs
and didn't get far.

Maybe this is just bad luck or that I'm not familier enough in this
area, however with our other formats I help maintain - X3D, FBX, 3DS,
OBJ - we're mostly able to keep the tracker at 0 and have a good
history with users submitting fixes when they run into issues or want
better support for features.

OpenCollada issue tracker is at ~95, and only had a few commits in last months.
http://code.google.com/p/opencollada/issues/list
http://code.google.com/feeds/p/opencollada/svnchanges/basic


Since its useful to have basic mesh support for google earth for eg -
just loading models,
I'd be happy to write a python addon to support collada - basic
meshes/uvs/vcols and materials - this could be the basis for others to
add deeper support for the format too.

-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Sergey Sharybin]

Hi, Nathan

On Thu, Jan 5, 2012 at 2:12 AM, Nathan Letwory <
nat...@letworyinteractive.com> wrote:

> Hi,
>
> I currently have not much time to put into this, but please drop into
> #blendercollada to check status of efforts there too.
>

Will check that IRC room you told. Didn't know about this.

>
> There are many possibilities being worked on (an importer/exporter by skrat
> based on pycollada, and there was at some point a user who wanted to donate
> some personal code, but that is I think also WIP. Further the company
> Mixamo has been in contact about COLLADA support) , so if you or someone
> else can step up to guide the process that'd be great.
>

I'm not so familiar with this format and not so fan of digging into it deep
enough (wanted to concentrate on other things needed for mango and so). But
if it's just guiding through blender architecture or communicating people
together i can do that.

-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Domino Marama]

On Thu, 2012-01-05 at 13:59 +0600, Sergey Sharybin wrote:
> I'm not so familiar with this format and not so fan of digging into it deep
> enough (wanted to concentrate on other things needed for mango and so). But
> if it's just guiding through blender architecture or communicating people
> together i can do that.

You can count me in on the people to guide. Collada is a key feature for
people who use Blender for creating Second Life content. We've just
released a commercial script for that which relies on Collada, so I've
assigned a portion of the income from the script to fund my time fixing
Collada bugs.

I'm not yet skilled enough to volunteer as maintainer, but I can
volunteer for bug fixing with a long term view to becoming maintainer.
So Sergey, if you are happy to act as advisor and code checker for my
patches, hopefully we can get the bug count down.

I've made a small test file for exporting a rigged mesh that shows 5
seperate bugs in round tripping a Collada export and I'm currently
working on fixing these - the first patch from this process is here:

http://projects.blender.org/tracker/index.php?func=detail&aid=29705&group_id=9&atid=127

Once these are fixed, I was going to see if the changes fixed any
current bugs (I suspect the armature strangeness ones could be affected)
and move on from there.

The bugs my test file identified were issues with naming of armature and
skeleton, armature being exported with a new empty as a root object,
armature exported with world based matrix, all local transforms are
"applied".. The mesh naming problem the patch is for.. Oh and the
last bone in a chain also has odd rotation issues..

So I'm currently working on getting up to speed with the codebase with
those issues in mind.

Best Wishes,
Domino



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Brecht Van Lommel]

Hi,

> +1 for immediate creation of Collada tracker and move collada bugs
> there (can help with this, it worked well for BMesh).

Also agree on creating a Collada tracker.

> Other topics can be postponed closer to release, though I'd expect
> 2.62 would include collada, perhaps we could set some target for the
> Collada tracker & call for developers to help out, or disable by
> default (actual code removal can be checked on much later if we want
> to phase out or move to something else).

Right, I don't think we should throw it out or disable it for release just yet.

> My own experience with trying to fix collada bugs has not been great -
> the few issues I ran into were either very hard to debug or bugs in
> opencollada (which I forwarded to the collada tracker) - just to say
> that ~5 or so times I seriously tried to fix some of our collada bugs
> and didn't get far.

I've had the same experience, tried to fix bugs but found it very
difficult. I looked into armature bugs mostly, and it seems the
Collada and Blender models of those are quite different, but the code
doesn't properly address this issue and seems to need major
refactoring. I think good animation/armature support is critical,
otherwise you might as well use .obj/.3ds.

Now, as for the path forward, it's apparently a lot of work to get a
complete importer/exporter working, not only with basic test cases but
also compatible with other applications. Especially the importer for
different Collada versions seems difficult to implement well.

>From the point of view of attracting more developers, a python
importer seems the best solution, also since there's good python
utility code already there from other IO addons. However from what I
can see the bpycollada importer is still at prototype level. The c++
importer is further along but needs difficult code refactoring to fix
bugs.

Brecht.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Domino Marama]

On Thu, 2012-01-05 at 23:28 +0100, Brecht Van Lommel wrote:
> From the point of view of attracting more developers, a python
> importer seems the best solution, also since there's good python
> utility code already there from other IO addons. However from what I
> can see the bpycollada importer is still at prototype level.

One concern I have with the bpycollada importer is the use of numpy and
datetime modules by pycollada which it's based on. Particularly numpy as
it's use seems to be for things like matrix transforms and things that
are already possible with bpy. Having an extra dependancy to duplicate
features just seems wrong to me.. But the alternative is forking
pycollada and rewriting a large chunk to use blender specific features.

pycollada also uses pil for some features and that's not available for
python 3.. I've not looked closely at how much of a problem that would
cause though.


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Ton Roosendaal]

Hi,

I think it's a bad precedence to create a tracker for every feature we notice 
is badly supporting or failing. Just moving reports to another tracker is not 
solving anything of course.

I would rather tackle it more political & practical:

1) Official announcement that Blender drops Collada support
2) Move Collada support into a branch, out of trunk
3) Create a tracker "orphanage" or "branches" or so, where we put all reports 
that are not in support (anymore).

BTW: 

I've personally had it with Collada and its supporters. Next time we add this 
back in Blender it should be based on well defined and tested use cases, on a 
level we (or the branch team) can support it. In my opinion that's proven to be 
impossible, for reasons how Collada works, designed and has been organized.

Three months ago already I wrote this open letter:
http://code.blender.org/index.php/2011/10/collada-momentum/

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 4 Jan, 2012, at 20:57, Sergey Sharybin wrote:

> Hi,
> 
> As everybody noticed current collada importer/exporter is very buggy which
> seems to make this format almost useless in Blender. And what's much worse
> -- we don't actually have developer who maintains this area.
> 
> We discussed this already with Campbell and found that OpenCollada itself
> isn't actually maintaning -- there are only few commits in several months.
> Ofcourse it doesn't mean this library is useless and all bug from our
> tracker is related on that issues, but still.. Maybe the time have come to
> re-think this importer/exporter (investigate if it's possible to fix issues
> in clear way, check if design is good enough -- not sure, haven't touched
> this code deep myself)?
> 
> Here's our proposal:
> - Move all collada-related issues into it's own tracker. Like it was done
> with BGE, it might help finding volunteer to fix them. Also, people will
> see that it's not actually core stuff and that it's community-supported.
> - Disable collada in release builds. It's not useable and only seems to be
> making artists disappointed.
> 
> More optimistic targets would be find volunteer to pick up this stuff who
> will make it usable (maybe rewritting this stuff from scratch..)
> 
> -- 
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Gaia Clary]

Would it be an option to separate the current Collada implementation
into an addon module, which is disabled by default, but can be enabled
from the addon panel ? (with a text flagging it as "Experimental" for 
example)

This would keep it out of view for everybody who does not need it.
But people who actually work with the current Collada exporter
could still enable it easily.

-gaia-


Am 06.01.2012 11:58, schrieb Ton Roosendaal:
> Hi,
>
> I think it's a bad precedence to create a tracker for every feature we notice 
> is badly supporting or failing. Just moving reports to another tracker is not 
> solving anything of course.
>
> I would rather tackle it more political&  practical:
>
> 1) Official announcement that Blender drops Collada support
> 2) Move Collada support into a branch, out of trunk
> 3) Create a tracker "orphanage" or "branches" or so, where we put all reports 
> that are not in support (anymore).
>
> BTW:
>
> I've personally had it with Collada and its supporters. Next time we add this 
> back in Blender it should be based on well defined and tested use cases, on a 
> level we (or the branch team) can support it. In my opinion that's proven to 
> be impossible, for reasons how Collada works, designed and has been organized.
>
> Three months ago already I wrote this open letter:
> http://code.blender.org/index.php/2011/10/collada-momentum/
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 4 Jan, 2012, at 20:57, Sergey Sharybin wrote:
>
>> Hi,
>>
>> As everybody noticed current collada importer/exporter is very buggy which
>> seems to make this format almost useless in Blender. And what's much worse
>> -- we don't actually have developer who maintains this area.
>>
>> We discussed this already with Campbell and found that OpenCollada itself
>> isn't actually maintaning -- there are only few commits in several months.
>> Ofcourse it doesn't mean this library is useless and all bug from our
>> tracker is related on that issues, but still.. Maybe the time have come to
>> re-think this importer/exporter (investigate if it's possible to fix issues
>> in clear way, check if design is good enough -- not sure, haven't touched
>> this code deep myself)?
>>
>> Here's our proposal:
>> - Move all collada-related issues into it's own tracker. Like it was done
>> with BGE, it might help finding volunteer to fix them. Also, people will
>> see that it's not actually core stuff and that it's community-supported.
>> - Disable collada in release builds. It's not useable and only seems to be
>> making artists disappointed.
>>
>> More optimistic targets would be find volunteer to pick up this stuff who
>> will make it usable (maybe rewritting this stuff from scratch..)
>>
>> -- 
>> With best regards, Sergey Sharybin
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Sergey Sharybin]

Nope, it wouldn't be possible.

Collada is implemented in C, not in Py and so can't be used as
import/export addons.

On Fri, Jan 6, 2012 at 5:42 PM, Gaia Clary wrote:

> Would it be an option to separate the current Collada implementation
> into an addon module, which is disabled by default, but can be enabled
> from the addon panel ? (with a text flagging it as "Experimental" for
> example)
>
> This would keep it out of view for everybody who does not need it.
> But people who actually work with the current Collada exporter
> could still enable it easily.
>
> -gaia-
>
>
> Am 06.01.2012 11:58, schrieb Ton Roosendaal:
> > Hi,
> >
> > I think it's a bad precedence to create a tracker for every feature we
> notice is badly supporting or failing. Just moving reports to another
> tracker is not solving anything of course.
> >
> > I would rather tackle it more political&  practical:
> >
> > 1) Official announcement that Blender drops Collada support
> > 2) Move Collada support into a branch, out of trunk
> > 3) Create a tracker "orphanage" or "branches" or so, where we put all
> reports that are not in support (anymore).
> >
> > BTW:
> >
> > I've personally had it with Collada and its supporters. Next time we add
> this back in Blender it should be based on well defined and tested use
> cases, on a level we (or the branch team) can support it. In my opinion
> that's proven to be impossible, for reasons how Collada works, designed and
> has been organized.
> >
> > Three months ago already I wrote this open letter:
> > http://code.blender.org/index.php/2011/10/collada-momentum/
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > On 4 Jan, 2012, at 20:57, Sergey Sharybin wrote:
> >
> >> Hi,
> >>
> >> As everybody noticed current collada importer/exporter is very buggy
> which
> >> seems to make this format almost useless in Blender. And what's much
> worse
> >> -- we don't actually have developer who maintains this area.
> >>
> >> We discussed this already with Campbell and found that OpenCollada
> itself
> >> isn't actually maintaning -- there are only few commits in several
> months.
> >> Ofcourse it doesn't mean this library is useless and all bug from our
> >> tracker is related on that issues, but still.. Maybe the time have come
> to
> >> re-think this importer/exporter (investigate if it's possible to fix
> issues
> >> in clear way, check if design is good enough -- not sure, haven't
> touched
> >> this code deep myself)?
> >>
> >> Here's our proposal:
> >> - Move all collada-related issues into it's own tracker. Like it was
> done
> >> with BGE, it might help finding volunteer to fix them. Also, people will
> >> see that it's not actually core stuff and that it's community-supported.
> >> - Disable collada in release builds. It's not useable and only seems to
> be
> >> making artists disappointed.
> >>
> >> More optimistic targets would be find volunteer to pick up this stuff
> who
> >> will make it usable (maybe rewritting this stuff from scratch..)
> >>
> >> --
> >> With best regards, Sergey Sharybin
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Thomas Dinges]

It would also not keep people from reporting bugs.

Am 06.01.2012 12:49, schrieb Sergey Sharybin:
> Nope, it wouldn't be possible.
>
> Collada is implemented in C, not in Py and so can't be used as
> import/export addons.
>
> On Fri, Jan 6, 2012 at 5:42 PM, Gaia Clarywrote:
>
>> Would it be an option to separate the current Collada implementation
>> into an addon module, which is disabled by default, but can be enabled
>> from the addon panel ? (with a text flagging it as "Experimental" for
>> example)
>>
>> This would keep it out of view for everybody who does not need it.
>> But people who actually work with the current Collada exporter
>> could still enable it easily.
>>
>> -gaia-
>>
-- 
Thomas Dinges
Blender Developer, Artist and Musician

www.dingto.org

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

It can be done:
- Compile collada as C/Python module
- Add C/python module init hooks (we have this for blender as a py module)
- Export all symbols from blender which collada io uses
- make an addon which loads this c/python colada addon and adds menu items.

Possible but IMHO impractical, and we would need to sink even more
time into setting up the symbols to export, scons/cmake buildsystem
edits... just a hassle. Also think this is drifting off topic.


I'm happy with any suggestion that means we can allow interested devs
to continue development to a point where its acceptable to be enabled
in release again.

So +1 for Ton's suggestion to move into a branch & have its own
tracker. This also means we can give devs SVN commit access who are
keen to work on collada support (where we might be less likely to
grant them access to work in trunk)

On Fri, Jan 6, 2012 at 10:49 PM, Sergey Sharybin  wrote:
> Nope, it wouldn't be possible.
>
> Collada is implemented in C, not in Py and so can't be used as
> import/export addons.
>
> On Fri, Jan 6, 2012 at 5:42 PM, Gaia Clary 
> wrote:
>
>> Would it be an option to separate the current Collada implementation
>> into an addon module, which is disabled by default, but can be enabled
>> from the addon panel ? (with a text flagging it as "Experimental" for
>> example)
>>
>> This would keep it out of view for everybody who does not need it.
>> But people who actually work with the current Collada exporter
>> could still enable it easily.
>>
>> -gaia-
>>
>>
>> Am 06.01.2012 11:58, schrieb Ton Roosendaal:
>> > Hi,
>> >
>> > I think it's a bad precedence to create a tracker for every feature we
>> notice is badly supporting or failing. Just moving reports to another
>> tracker is not solving anything of course.
>> >
>> > I would rather tackle it more political&  practical:
>> >
>> > 1) Official announcement that Blender drops Collada support
>> > 2) Move Collada support into a branch, out of trunk
>> > 3) Create a tracker "orphanage" or "branches" or so, where we put all
>> reports that are not in support (anymore).
>> >
>> > BTW:
>> >
>> > I've personally had it with Collada and its supporters. Next time we add
>> this back in Blender it should be based on well defined and tested use
>> cases, on a level we (or the branch team) can support it. In my opinion
>> that's proven to be impossible, for reasons how Collada works, designed and
>> has been organized.
>> >
>> > Three months ago already I wrote this open letter:
>> > http://code.blender.org/index.php/2011/10/collada-momentum/
>> >
>> > -Ton-
>> >
>> > 
>> > Ton Roosendaal  Blender Foundation   t...@blender.org    www.blender.org
>> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>> >
>> > On 4 Jan, 2012, at 20:57, Sergey Sharybin wrote:
>> >
>> >> Hi,
>> >>
>> >> As everybody noticed current collada importer/exporter is very buggy
>> which
>> >> seems to make this format almost useless in Blender. And what's much
>> worse
>> >> -- we don't actually have developer who maintains this area.
>> >>
>> >> We discussed this already with Campbell and found that OpenCollada
>> itself
>> >> isn't actually maintaning -- there are only few commits in several
>> months.
>> >> Ofcourse it doesn't mean this library is useless and all bug from our
>> >> tracker is related on that issues, but still.. Maybe the time have come
>> to
>> >> re-think this importer/exporter (investigate if it's possible to fix
>> issues
>> >> in clear way, check if design is good enough -- not sure, haven't
>> touched
>> >> this code deep myself)?
>> >>
>> >> Here's our proposal:
>> >> - Move all collada-related issues into it's own tracker. Like it was
>> done
>> >> with BGE, it might help finding volunteer to fix them. Also, people will
>> >> see that it's not actually core stuff and that it's community-supported.
>> >> - Disable collada in release builds. It's not useable and only seems to
>> be
>> >> making artists disappointed.
>> >>
>> >> More optimistic targets would be find volunteer to pick up this stuff
>> who
>> >> will make it usable (maybe rewritting this stuff from scratch..)
>> >>
>> >> --
>> >> With best regards, Sergey Sharybin
>> >> ___
>> >> Bf-committers mailing list
>> >> Bf-committers@blender.org
>> >> http://lists.blender.org/mailman/listinfo/bf-committers
>> > ___
>> > Bf-committers mailing list
>> > Bf-committers@blender.org
>> > http://lists.blender.org/mailman/listinfo/bf-committers
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>>
>
>
>
> --
> With best regards, Sergey Sharybin
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinf

Re: [Bf-committers] Collada importer/exporter kickout

[Knapp]

If you read that page you see that Chicken is the current way to do it
and that is with 2.4! I want (and will likely not get) something as
good or better but for 2.5. Sadly this does not seem to be happening
any time soon. Sure there are lots of hacks that work part way and
this is good and maybe Yabee will be the answer but Collada was
supposed to be the new great replacement for Chicken. I guess we will
have to wait and see. AS ton points out, Collada is turning out to be
a really just empty words. :-(

On Thu, Jan 5, 2012 at 3:46 AM, Tobias Kummer  wrote:
> Panda3D export isn't really a problem without Collada, see here:
> http://www.panda3d.org/manual/index.php/Converting_from_Blender
> I'd also be happy to be able to shove models around between different
> packages without much hassle, but I find myself almost always having to
> resort back on .3ds or .obj.
> I never got Blenders Collada working correctly.
> My 2ct: as long as it doesn't work in a predictable way - don't include
> it in release builds.
>
> Greets,
> Tobi
>
> On Wed Jan  4 22:43:00 2012, Knapp wrote:
>> If the bug tracker is getting a lot of bug reports, does that not mean
>> that the artists want it? I know I have been waiting years for it to
>> get working so I can export to panda3d. It has been some time since I
>> checked on the status of this problem so perhaps they at panda have
>> another way. So, I would really like to have a good way to export to
>> Panda3d and I bet I am not the only one. How much is it hurting
>> blender adoption by not having a  good exporter for this format?




-- 
Douglas E Knapp

Creative Commons Film Group, Helping people make open source movies
with open source software!
http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

Massage in Gelsenkirchen-Buer:
http://douglas.bespin.org/tcm/ztab1.htm
Please link to me and trade links with me!

Open Source Sci-Fi mmoRPG Game project.
http://sf-journey-creations.wikispot.org/Front_Page
http://code.google.com/p/perspectiveproject/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

>
> 1) Official announcement that Blender drops Collada support
> 2) Move Collada support into a branch, out of trunk
> 3) Create a tracker "orphanage" or "branches" or so, where we put all
> reports that are not in support (anymore).
>
>
I just want to say though I am not up for the challenge of taking over on
this sub project I would be sad to see Collada support taken out of trunk.
I use it often also with skinning export. I know many users do and
eventhough I understand everyone's frustration I prefer the implementation
that is there now (which I use often) to no built-in version at all.

I am not disagreeing with any of the frustrating aspects of Collada which
you and others have mentioned.
Just saying personally I do use it and would very much like to keep it in.
With bugs and all :)

I have seen many other commercial tools with awful crappy .3ds importers
and exporters but bad as they were they didn't take them out
because people were still relying on them and using them. Despite the bugs
in them.


Cheers,

Morten.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[skoti]

Assimp only importer (exporter in blender is the most important), and 
even in assimp Collada importer is weak. Blender use external library 
for Collada (OpenCollada libs).

Collada format is an important and IMO it should not be removed. Collada 
is used in many game engine, engine Web3D (WebGL or flash engine), and 
everywhere, where we exchange information.

It seems to me that it is better to leave the exporter in the trunk than 
reduce the functionality of the program (for many it becomes useless - 
now an exporter / importer, blender works well with programs based on 
OpenCollada / FCollada / Collada DOM - works better than autodesk 
exporter (creates files "Collada-like ")).
> I'm just curious: why can't an external library be used?
>
> I know about Assimp, i double checked and it seams that it supports collada
> import/export(at least they say so on their site, and i think it is full
> support since it isn't marked with an * [2][3]). It also has a C or C++ API.
> The licence is (a kind of [4])BSD, is this a problem?
> This would offload main devs from format support. In addition blender would
> be able to import/export all the format the external library already
> handles. And in case specific files must be supported, this can be archived
> with python or a specific imp/exporter.
>
> Is there a reason why blender shouldn't rely on an existing library, or
> it's a licence/features problem with the existing ones?
>
>
> [1] http://assimp.sourceforge.net/index.html
> [2] http://assimp.sourceforge.net/main_features_formats.html
> [3] http://assimp.sourceforge.net/main_features_export.html
> [4] http://assimp.sourceforge.net/main_license.html
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

I agree, I could also live with ditching the importer if it meant keeping
the exporter.
But either way I'll take current collada version to no collada version at
all.



On Fri, Jan 6, 2012 at 5:11 PM, skoti  wrote:

> Assimp only importer (exporter in blender is the most important), and
> even in assimp Collada importer is weak. Blender use external library
> for Collada (OpenCollada libs).
>
> Collada format is an important and IMO it should not be removed. Collada
> is used in many game engine, engine Web3D (WebGL or flash engine), and
> everywhere, where we exchange information.
>
> It seems to me that it is better to leave the exporter in the trunk than
> reduce the functionality of the program (for many it becomes useless -
> now an exporter / importer, blender works well with programs based on
> OpenCollada / FCollada / Collada DOM - works better than autodesk
> exporter (creates files "Collada-like ")).
> > I'm just curious: why can't an external library be used?
> >
> > I know about Assimp, i double checked and it seams that it supports
> collada
> > import/export(at least they say so on their site, and i think it is full
> > support since it isn't marked with an * [2][3]). It also has a C or C++
> API.
> > The licence is (a kind of [4])BSD, is this a problem?
> > This would offload main devs from format support. In addition blender
> would
> > be able to import/export all the format the external library already
> > handles. And in case specific files must be supported, this can be
> archived
> > with python or a specific imp/exporter.
> >
> > Is there a reason why blender shouldn't rely on an existing library, or
> > it's a licence/features problem with the existing ones?
> >
> >
> > [1] http://assimp.sourceforge.net/index.html
> > [2] http://assimp.sourceforge.net/main_features_formats.html
> > [3] http://assimp.sourceforge.net/main_features_export.html
> > [4] http://assimp.sourceforge.net/main_license.html
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Przemyslaw Golab]

Removing Collada is a bad idea, better poor support than none.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Ton Roosendaal]

Hi,

I realize the proposal was harsh, but it was meant as a public statement as 
well (to khronos, opencollada team, etc). I don't want to blame it on the hard 
working devs here. We do have collada IO work at some level, and that has been 
proven useful in several cases. The job is just incredible hard to achieve.

To move forward:

- userts who successfully applied .dae could also check whether another 
exchange format would have done the job as good. Tried FBX?

- note that for basic mesh (+uv) export, a quite simple script could do the job 
already. It is probably a few days job for a py scripter. 

- we are currently including about 100 MB of opencollada libs to make a feature 
work that's meant to be able to exchange (I+O) full shots or game environments, 
with character animation and so on. That's what Collada was designed for, and 
that's a target we can't support.

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote:

>> 
>> 1) Official announcement that Blender drops Collada support
>> 2) Move Collada support into a branch, out of trunk
>> 3) Create a tracker "orphanage" or "branches" or so, where we put all
>> reports that are not in support (anymore).
>> 
>> 
> I just want to say though I am not up for the challenge of taking over on
> this sub project I would be sad to see Collada support taken out of trunk.
> I use it often also with skinning export. I know many users do and
> eventhough I understand everyone's frustration I prefer the implementation
> that is there now (which I use often) to no built-in version at all.
> 
> I am not disagreeing with any of the frustrating aspects of Collada which
> you and others have mentioned.
> Just saying personally I do use it and would very much like to keep it in.
> With bugs and all :)
> 
> I have seen many other commercial tools with awful crappy .3ds importers
> and exporters but bad as they were they didn't take them out
> because people were still relying on them and using them. Despite the bugs
> in them.
> 
> 
> Cheers,
> 
> Morten.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[skoti]

I know Collada importer / exporter is problematic (I wrote an importer 
for my engine and I know that everything in the Collada can be stored in 
N different ways).

- If you want to use the model in Second Life / Google Earth, you have 
to use Collada, if you want to use models in engines WebGL/Flash3D 
practically have to use Collada (is there any web engine with FBX 
importer?), Most game engines use Collada for importing data (support 
for FBX a few). FBX exporter also has bugs. Well, that FBX is in a 
blender, but it is not usually an option for people using Collada.

- If someone uses Collada it not for the base mesh + uv (then using *. 
obj) and for skeletal animation, lights, cameras and their animation 
(motion, color, light and their intensity), multiUV (uv for color, 
normalmap ... + uv for lightmap). And all this in current Collada 
exporter works well.

- No other exporter does not work here as well as Collada - ofc has 
bugs, but it has nothing what could replace the Collada in this task. In 
the future, Alembic can replace Collada, but not for several years.

IMO, better to leave Collada, until you will be able to replace it with 
success to other formats like Alembic (FBX is not popular in the 
software and you can not replace him Collada in most tasks).


On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
> Hi,
>
> I realize the proposal was harsh, but it was meant as a public statement as 
> well (to khronos, opencollada team, etc). I don't want to blame it on the 
> hard working devs here. We do have collada IO work at some level, and that 
> has been proven useful in several cases. The job is just incredible hard to 
> achieve.
>
> To move forward:
>
> - userts who successfully applied .dae could also check whether another 
> exchange format would have done the job as good. Tried FBX?
>
> - note that for basic mesh (+uv) export, a quite simple script could do the 
> job already. It is probably a few days job for a py scripter.
>
> - we are currently including about 100 MB of opencollada libs to make a 
> feature work that's meant to be able to exchange (I+O) full shots or game 
> environments, with character animation and so on. That's what Collada was 
> designed for, and that's a target we can't support.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote:
>
>>> 1) Official announcement that Blender drops Collada support
>>> 2) Move Collada support into a branch, out of trunk
>>> 3) Create a tracker "orphanage" or "branches" or so, where we put all
>>> reports that are not in support (anymore).
>>>
>>>
>> I just want to say though I am not up for the challenge of taking over on
>> this sub project I would be sad to see Collada support taken out of trunk.
>> I use it often also with skinning export. I know many users do and
>> eventhough I understand everyone's frustration I prefer the implementation
>> that is there now (which I use often) to no built-in version at all.
>>
>> I am not disagreeing with any of the frustrating aspects of Collada which
>> you and others have mentioned.
>> Just saying personally I do use it and would very much like to keep it in.
>> With bugs and all :)
>>
>> I have seen many other commercial tools with awful crappy .3ds importers
>> and exporters but bad as they were they didn't take them out
>> because people were still relying on them and using them. Despite the bugs
>> in them.
>>
>>
>> Cheers,
>>
>> Morten.
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

Yes that's a very relevant point. A collada solution with just positions,
UVs and normals
is not a solution. In that case you might as well use obj format.
I went through the hard work of writing a collada importer specifically to
get skinning and animation
into my tech frame-work.


On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:

> I know Collada importer / exporter is problematic (I wrote an importer
> for my engine and I know that everything in the Collada can be stored in
> N different ways).
>
> - If you want to use the model in Second Life / Google Earth, you have
> to use Collada, if you want to use models in engines WebGL/Flash3D
> practically have to use Collada (is there any web engine with FBX
> importer?), Most game engines use Collada for importing data (support
> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> blender, but it is not usually an option for people using Collada.
>
> - If someone uses Collada it not for the base mesh + uv (then using *.
> obj) and for skeletal animation, lights, cameras and their animation
> (motion, color, light and their intensity), multiUV (uv for color,
> normalmap ... + uv for lightmap). And all this in current Collada
> exporter works well.
>
> - No other exporter does not work here as well as Collada - ofc has
> bugs, but it has nothing what could replace the Collada in this task. In
> the future, Alembic can replace Collada, but not for several years.
>
> IMO, better to leave Collada, until you will be able to replace it with
> success to other formats like Alembic (FBX is not popular in the
> software and you can not replace him Collada in most tasks).
>
>
> On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
> > Hi,
> >
> > I realize the proposal was harsh, but it was meant as a public statement
> as well (to khronos, opencollada team, etc). I don't want to blame it on
> the hard working devs here. We do have collada IO work at some level, and
> that has been proven useful in several cases. The job is just incredible
> hard to achieve.
> >
> > To move forward:
> >
> > - userts who successfully applied .dae could also check whether another
> exchange format would have done the job as good. Tried FBX?
> >
> > - note that for basic mesh (+uv) export, a quite simple script could do
> the job already. It is probably a few days job for a py scripter.
> >
> > - we are currently including about 100 MB of opencollada libs to make a
> feature work that's meant to be able to exchange (I+O) full shots or game
> environments, with character animation and so on. That's what Collada was
> designed for, and that's a target we can't support.
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote:
> >
> >>> 1) Official announcement that Blender drops Collada support
> >>> 2) Move Collada support into a branch, out of trunk
> >>> 3) Create a tracker "orphanage" or "branches" or so, where we put all
> >>> reports that are not in support (anymore).
> >>>
> >>>
> >> I just want to say though I am not up for the challenge of taking over
> on
> >> this sub project I would be sad to see Collada support taken out of
> trunk.
> >> I use it often also with skinning export. I know many users do and
> >> eventhough I understand everyone's frustration I prefer the
> implementation
> >> that is there now (which I use often) to no built-in version at all.
> >>
> >> I am not disagreeing with any of the frustrating aspects of Collada
> which
> >> you and others have mentioned.
> >> Just saying personally I do use it and would very much like to keep it
> in.
> >> With bugs and all :)
> >>
> >> I have seen many other commercial tools with awful crappy .3ds importers
> >> and exporters but bad as they were they didn't take them out
> >> because people were still relying on them and using them. Despite the
> bugs
> >> in them.
> >>
> >>
> >> Cheers,
> >>
> >> Morten.
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Hi guys,

I made my own Collada exporter in Python and that's what I've been
using. It's less than 1k lines of code and does not depend upon any library
or anything, but it exports everything except morphs. I don't have much
time to work on it at the moment, but it's so simple and complete that if
anyone else want's to work on it, it should be really easy. I'm also not an
expert at Python or Blender API so someone more experience can probably
shape it up better. It's also much more stable than the official one (due
to it being so small).

Feel free to do anything with it or integrate it into Blender, just credit
me on the file. I would love to work more on it, or even make a proper
importer since I have a high level of expertise in Collada, but I have very
little time and must work to earn my meals.

Cheers!

Juan Linietsky


On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen wrote:

> Yes that's a very relevant point. A collada solution with just positions,
> UVs and normals
> is not a solution. In that case you might as well use obj format.
> I went through the hard work of writing a collada importer specifically to
> get skinning and animation
> into my tech frame-work.
>
>
> On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
>
> > I know Collada importer / exporter is problematic (I wrote an importer
> > for my engine and I know that everything in the Collada can be stored in
> > N different ways).
> >
> > - If you want to use the model in Second Life / Google Earth, you have
> > to use Collada, if you want to use models in engines WebGL/Flash3D
> > practically have to use Collada (is there any web engine with FBX
> > importer?), Most game engines use Collada for importing data (support
> > for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> > blender, but it is not usually an option for people using Collada.
> >
> > - If someone uses Collada it not for the base mesh + uv (then using *.
> > obj) and for skeletal animation, lights, cameras and their animation
> > (motion, color, light and their intensity), multiUV (uv for color,
> > normalmap ... + uv for lightmap). And all this in current Collada
> > exporter works well.
> >
> > - No other exporter does not work here as well as Collada - ofc has
> > bugs, but it has nothing what could replace the Collada in this task. In
> > the future, Alembic can replace Collada, but not for several years.
> >
> > IMO, better to leave Collada, until you will be able to replace it with
> > success to other formats like Alembic (FBX is not popular in the
> > software and you can not replace him Collada in most tasks).
> >
> >
> > On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
> > > Hi,
> > >
> > > I realize the proposal was harsh, but it was meant as a public
> statement
> > as well (to khronos, opencollada team, etc). I don't want to blame it on
> > the hard working devs here. We do have collada IO work at some level, and
> > that has been proven useful in several cases. The job is just incredible
> > hard to achieve.
> > >
> > > To move forward:
> > >
> > > - userts who successfully applied .dae could also check whether another
> > exchange format would have done the job as good. Tried FBX?
> > >
> > > - note that for basic mesh (+uv) export, a quite simple script could do
> > the job already. It is probably a few days job for a py scripter.
> > >
> > > - we are currently including about 100 MB of opencollada libs to make a
> > feature work that's meant to be able to exchange (I+O) full shots or game
> > environments, with character animation and so on. That's what Collada was
> > designed for, and that's a target we can't support.
> > >
> > > -Ton-
> > >
> > >
> 
> > > Ton Roosendaal  Blender Foundation   t...@blender.org
> www.blender.org
> > > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> > >
> > > On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote:
> > >
> > >>> 1) Official announcement that Blender drops Collada support
> > >>> 2) Move Collada support into a branch, out of trunk
> > >>> 3) Create a tracker "orphanage" or "branches" or so, where we put all
> > >>> reports that are not in support (anymore).
> > >>>
> > >>>
> > >> I just want to say though I am not up for the challenge of taking over
> > on
> > >> this sub project I would be sad to see Collada support taken out of
> > trunk.
> > >> I use it often also with skinning export. I know many users do and
> > >> eventhough I understand everyone's frustration I prefer the
> > implementation
> > >> that is there now (which I use often) to no built-in version at all.
> > >>
> > >> I am not disagreeing with any of the frustrating aspects of Collada
> > which
> > >> you and others have mentioned.
> > >> Just saying personally I do use it and would very much like to keep it
> > in.
> > >> With bugs and all :)
> > >>
> > >> I have seen many other commercial tools with awful crappy .3ds
> importers
> >

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

In my case I do not need morphs. I do need animation and skinning though.
And obviously
also geometries and materials. And it sounds like you have this covered?
I have no sense of loyalty toward OpenCollada so if this is a viable
solution
I am for it. Can you make it available somewhere with instructions on how
to install it so people can test it?

Cheers and thanks,

Morten


On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky  wrote:

> Hi guys,
>
>I made my own Collada exporter in Python and that's what I've been
> using. It's less than 1k lines of code and does not depend upon any library
> or anything, but it exports everything except morphs. I don't have much
> time to work on it at the moment, but it's so simple and complete that if
> anyone else want's to work on it, it should be really easy. I'm also not an
> expert at Python or Blender API so someone more experience can probably
> shape it up better. It's also much more stable than the official one (due
> to it being so small).
>
> Feel free to do anything with it or integrate it into Blender, just credit
> me on the file. I would love to work more on it, or even make a proper
> importer since I have a high level of expertise in Collada, but I have very
> little time and must work to earn my meals.
>
> Cheers!
>
> Juan Linietsky
>
>
> On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen  >wrote:
>
> > Yes that's a very relevant point. A collada solution with just positions,
> > UVs and normals
> > is not a solution. In that case you might as well use obj format.
> > I went through the hard work of writing a collada importer specifically
> to
> > get skinning and animation
> > into my tech frame-work.
> >
> >
> > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> >
> > > I know Collada importer / exporter is problematic (I wrote an importer
> > > for my engine and I know that everything in the Collada can be stored
> in
> > > N different ways).
> > >
> > > - If you want to use the model in Second Life / Google Earth, you have
> > > to use Collada, if you want to use models in engines WebGL/Flash3D
> > > practically have to use Collada (is there any web engine with FBX
> > > importer?), Most game engines use Collada for importing data (support
> > > for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> > > blender, but it is not usually an option for people using Collada.
> > >
> > > - If someone uses Collada it not for the base mesh + uv (then using *.
> > > obj) and for skeletal animation, lights, cameras and their animation
> > > (motion, color, light and their intensity), multiUV (uv for color,
> > > normalmap ... + uv for lightmap). And all this in current Collada
> > > exporter works well.
> > >
> > > - No other exporter does not work here as well as Collada - ofc has
> > > bugs, but it has nothing what could replace the Collada in this task.
> In
> > > the future, Alembic can replace Collada, but not for several years.
> > >
> > > IMO, better to leave Collada, until you will be able to replace it with
> > > success to other formats like Alembic (FBX is not popular in the
> > > software and you can not replace him Collada in most tasks).
> > >
> > >
> > > On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
> > > > Hi,
> > > >
> > > > I realize the proposal was harsh, but it was meant as a public
> > statement
> > > as well (to khronos, opencollada team, etc). I don't want to blame it
> on
> > > the hard working devs here. We do have collada IO work at some level,
> and
> > > that has been proven useful in several cases. The job is just
> incredible
> > > hard to achieve.
> > > >
> > > > To move forward:
> > > >
> > > > - userts who successfully applied .dae could also check whether
> another
> > > exchange format would have done the job as good. Tried FBX?
> > > >
> > > > - note that for basic mesh (+uv) export, a quite simple script could
> do
> > > the job already. It is probably a few days job for a py scripter.
> > > >
> > > > - we are currently including about 100 MB of opencollada libs to
> make a
> > > feature work that's meant to be able to exchange (I+O) full shots or
> game
> > > environments, with character animation and so on. That's what Collada
> was
> > > designed for, and that's a target we can't support.
> > > >
> > > > -Ton-
> > > >
> > > >
> > 
> > > > Ton Roosendaal  Blender Foundation   t...@blender.org
> > www.blender.org
> > > > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
> Netherlands
> > > >
> > > > On 6 Jan, 2012, at 21:21, Morten Mikkelsen wrote:
> > > >
> > > >>> 1) Official announcement that Blender drops Collada support
> > > >>> 2) Move Collada support into a branch, out of trunk
> > > >>> 3) Create a tracker "orphanage" or "branches" or so, where we put
> all
> > > >>> reports that are not in support (anymore).
> > > >>>
> > > >>>
> > > >> I just want to say though I am not up for the challenge of taking
> over
> > > on

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Ah, I tried to attach it to the e-mail, guess the mailing list does not
accept attachments?

Here's a dropbox link:

http://dl.dropbox.com/u/53086520/io_scene_dae.zip

Cheers

Juan Linietsky

On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsen wrote:

> In my case I do not need morphs. I do need animation and skinning though.
> And obviously
> also geometries and materials. And it sounds like you have this covered?
> I have no sense of loyalty toward OpenCollada so if this is a viable
> solution
> I am for it. Can you make it available somewhere with instructions on how
> to install it so people can test it?
>
> Cheers and thanks,
>
> Morten
>
>
> On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky  wrote:
>
> > Hi guys,
> >
> >I made my own Collada exporter in Python and that's what I've been
> > using. It's less than 1k lines of code and does not depend upon any
> library
> > or anything, but it exports everything except morphs. I don't have much
> > time to work on it at the moment, but it's so simple and complete that if
> > anyone else want's to work on it, it should be really easy. I'm also not
> an
> > expert at Python or Blender API so someone more experience can probably
> > shape it up better. It's also much more stable than the official one (due
> > to it being so small).
> >
> > Feel free to do anything with it or integrate it into Blender, just
> credit
> > me on the file. I would love to work more on it, or even make a proper
> > importer since I have a high level of expertise in Collada, but I have
> very
> > little time and must work to earn my meals.
> >
> > Cheers!
> >
> > Juan Linietsky
> >
> >
> > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen  > >wrote:
> >
> > > Yes that's a very relevant point. A collada solution with just
> positions,
> > > UVs and normals
> > > is not a solution. In that case you might as well use obj format.
> > > I went through the hard work of writing a collada importer specifically
> > to
> > > get skinning and animation
> > > into my tech frame-work.
> > >
> > >
> > > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> > >
> > > > I know Collada importer / exporter is problematic (I wrote an
> importer
> > > > for my engine and I know that everything in the Collada can be stored
> > in
> > > > N different ways).
> > > >
> > > > - If you want to use the model in Second Life / Google Earth, you
> have
> > > > to use Collada, if you want to use models in engines WebGL/Flash3D
> > > > practically have to use Collada (is there any web engine with FBX
> > > > importer?), Most game engines use Collada for importing data (support
> > > > for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> > > > blender, but it is not usually an option for people using Collada.
> > > >
> > > > - If someone uses Collada it not for the base mesh + uv (then using
> *.
> > > > obj) and for skeletal animation, lights, cameras and their animation
> > > > (motion, color, light and their intensity), multiUV (uv for color,
> > > > normalmap ... + uv for lightmap). And all this in current Collada
> > > > exporter works well.
> > > >
> > > > - No other exporter does not work here as well as Collada - ofc has
> > > > bugs, but it has nothing what could replace the Collada in this task.
> > In
> > > > the future, Alembic can replace Collada, but not for several years.
> > > >
> > > > IMO, better to leave Collada, until you will be able to replace it
> with
> > > > success to other formats like Alembic (FBX is not popular in the
> > > > software and you can not replace him Collada in most tasks).
> > > >
> > > >
> > > > On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
> > > > > Hi,
> > > > >
> > > > > I realize the proposal was harsh, but it was meant as a public
> > > statement
> > > > as well (to khronos, opencollada team, etc). I don't want to blame it
> > on
> > > > the hard working devs here. We do have collada IO work at some level,
> > and
> > > > that has been proven useful in several cases. The job is just
> > incredible
> > > > hard to achieve.
> > > > >
> > > > > To move forward:
> > > > >
> > > > > - userts who successfully applied .dae could also check whether
> > another
> > > > exchange format would have done the job as good. Tried FBX?
> > > > >
> > > > > - note that for basic mesh (+uv) export, a quite simple script
> could
> > do
> > > > the job already. It is probably a few days job for a py scripter.
> > > > >
> > > > > - we are currently including about 100 MB of opencollada libs to
> > make a
> > > > feature work that's meant to be able to exchange (I+O) full shots or
> > game
> > > > environments, with character animation and so on. That's what Collada
> > was
> > > > designed for, and that's a target we can't support.
> > > > >
> > > > > -Ton-
> > > > >
> > > > >
> > >
> 
> > > > > Ton Roosendaal  Blender Foundation   t...@blender.org
> > > www.blender.org
> > > > > Blender Institute   Entrepo

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Ah also, I think I wrote it for Blender 2.58 so I hope no API has changed
since then and stil works.

Cheers

Juan Liniesky

On Sat, Jan 7, 2012 at 12:49 PM, Juan Linietsky  wrote:

> Ah, I tried to attach it to the e-mail, guess the mailing list does not
> accept attachments?
>
> Here's a dropbox link:
>
> http://dl.dropbox.com/u/53086520/io_scene_dae.zip
>
> Cheers
>
> Juan Linietsky
>
> On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsen wrote:
>
>> In my case I do not need morphs. I do need animation and skinning though.
>> And obviously
>> also geometries and materials. And it sounds like you have this covered?
>> I have no sense of loyalty toward OpenCollada so if this is a viable
>> solution
>> I am for it. Can you make it available somewhere with instructions on how
>> to install it so people can test it?
>>
>> Cheers and thanks,
>>
>> Morten
>>
>>
>> On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky  wrote:
>>
>> > Hi guys,
>> >
>> >I made my own Collada exporter in Python and that's what I've been
>> > using. It's less than 1k lines of code and does not depend upon any
>> library
>> > or anything, but it exports everything except morphs. I don't have much
>> > time to work on it at the moment, but it's so simple and complete that
>> if
>> > anyone else want's to work on it, it should be really easy. I'm also
>> not an
>> > expert at Python or Blender API so someone more experience can probably
>> > shape it up better. It's also much more stable than the official one
>> (due
>> > to it being so small).
>> >
>> > Feel free to do anything with it or integrate it into Blender, just
>> credit
>> > me on the file. I would love to work more on it, or even make a proper
>> > importer since I have a high level of expertise in Collada, but I have
>> very
>> > little time and must work to earn my meals.
>> >
>> > Cheers!
>> >
>> > Juan Linietsky
>> >
>> >
>> > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen > > >wrote:
>> >
>> > > Yes that's a very relevant point. A collada solution with just
>> positions,
>> > > UVs and normals
>> > > is not a solution. In that case you might as well use obj format.
>> > > I went through the hard work of writing a collada importer
>> specifically
>> > to
>> > > get skinning and animation
>> > > into my tech frame-work.
>> > >
>> > >
>> > > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
>> > >
>> > > > I know Collada importer / exporter is problematic (I wrote an
>> importer
>> > > > for my engine and I know that everything in the Collada can be
>> stored
>> > in
>> > > > N different ways).
>> > > >
>> > > > - If you want to use the model in Second Life / Google Earth, you
>> have
>> > > > to use Collada, if you want to use models in engines WebGL/Flash3D
>> > > > practically have to use Collada (is there any web engine with FBX
>> > > > importer?), Most game engines use Collada for importing data
>> (support
>> > > > for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
>> > > > blender, but it is not usually an option for people using Collada.
>> > > >
>> > > > - If someone uses Collada it not for the base mesh + uv (then using
>> *.
>> > > > obj) and for skeletal animation, lights, cameras and their animation
>> > > > (motion, color, light and their intensity), multiUV (uv for color,
>> > > > normalmap ... + uv for lightmap). And all this in current Collada
>> > > > exporter works well.
>> > > >
>> > > > - No other exporter does not work here as well as Collada - ofc has
>> > > > bugs, but it has nothing what could replace the Collada in this
>> task.
>> > In
>> > > > the future, Alembic can replace Collada, but not for several years.
>> > > >
>> > > > IMO, better to leave Collada, until you will be able to replace it
>> with
>> > > > success to other formats like Alembic (FBX is not popular in the
>> > > > software and you can not replace him Collada in most tasks).
>> > > >
>> > > >
>> > > > On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
>> > > > > Hi,
>> > > > >
>> > > > > I realize the proposal was harsh, but it was meant as a public
>> > > statement
>> > > > as well (to khronos, opencollada team, etc). I don't want to blame
>> it
>> > on
>> > > > the hard working devs here. We do have collada IO work at some
>> level,
>> > and
>> > > > that has been proven useful in several cases. The job is just
>> > incredible
>> > > > hard to achieve.
>> > > > >
>> > > > > To move forward:
>> > > > >
>> > > > > - userts who successfully applied .dae could also check whether
>> > another
>> > > > exchange format would have done the job as good. Tried FBX?
>> > > > >
>> > > > > - note that for basic mesh (+uv) export, a quite simple script
>> could
>> > do
>> > > > the job already. It is probably a few days job for a py scripter.
>> > > > >
>> > > > > - we are currently including about 100 MB of opencollada libs to
>> > make a
>> > > > feature work that's meant to be able to exchange (I+O) full shots or
>> > game
>> > > > environments, with character animation and so 

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

On Fri, Jan 6, 2012 at 9:04 PM, Francesco Zoffoli wrote:

> I'm just curious: why can't an external library be used?
>
>

I think the biggest problem with Collada is that the specification seems
like something huge and complex, so most people resorts to a library, which
in turn ends up in something even more bigger and complex with several
layers of complexiity that is a nightmare to maintain.
In reality, Collada is a very simple format that is very easy to parse, but
it definitely takes some work to really grasp and understand all of it,
because it's very  flexible (way too much more than needed I think). I also
wish it was more mantained and better documented at this point, too because
most official examples are either broken or incompatible with the
specification.

Cheers

Juan Linietsky
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

As an example of people having problems with its complexity OpenCollada
doesn't drain collada sources correctly at all.
They make many assumptions such as data being non interleaved.



On Sat, Jan 7, 2012 at 8:23 AM, Juan Linietsky  wrote:

> On Fri, Jan 6, 2012 at 9:04 PM, Francesco Zoffoli  >wrote:
>
> > I'm just curious: why can't an external library be used?
> >
> >
>
> I think the biggest problem with Collada is that the specification seems
> like something huge and complex, so most people resorts to a library, which
> in turn ends up in something even more bigger and complex with several
> layers of complexiity that is a nightmare to maintain.
> In reality, Collada is a very simple format that is very easy to parse, but
> it definitely takes some work to really grasp and understand all of it,
> because it's very  flexible (way too much more than needed I think). I also
> wish it was more mantained and better documented at this point, too because
> most official examples are either broken or incompatible with the
> specification.
>
> Cheers
>
> Juan Linietsky
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Domino Marama]

On Sat, 2012-01-07 at 12:06 -0300, Juan Linietsky wrote:
> Feel free to do anything with it or integrate it into Blender, just credit
> me on the file. I would love to work more on it, or even make a proper
> importer since I have a high level of expertise in Collada, but I have very
> little time and must work to earn my meals.

One thing that would need changing is the handling of libraries. Empty
ones should not be included in the .dae - having them there causes
compliance errors.

Schema validation error: Error: ERROR_VALIDATION_MIN_OCCURS_UNMATCHED
Element: library_images, Line: 14, Additional: child: image

Best Wishes,
Domino

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

You are right that in some cases an exporter is better, but in many cases
a C/C++ .blend importer is a better to go.

I just wanted to remind anyone reading this thread that
there is an easy way to extract any data from Blender in C++,
including animation curves, skinning info, textures etc,
without the issues of COLLADA and FBX.

I'm not familiar with baking,
but you might be able to store the baked data in the .blend file.

Thanks,
Erwin



On 7 January 2012 09:10, Juan Linietsky  wrote:

> Erwin,
>That looks awesome and really useful, however the main advantage of an
> importer is the ability to bake everything (IK and other constraints) just
> like it's displayed in Blender.
>
> Cheers
>
> Juan Linietsky
>
> On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans  >wrote:
>
> > Instead of going through the COLLADA or other intermediate format
> > you can directly extract any data from a .blend using this C++ .blend
> > parser:
> >
> > http://tinyurl.com/6s7k9zw
> >
> > AnimKit with the .blend loader includes a small sample that loads a
> .blend
> > file,
> > extracts textures, meshes, animations, skinning and physics info.
> > It shows a skinned skeletal animated character using AnimKit and GLUT
> > (keeping dependencies to a minimum)
> >
> > Cheers,
> > Erwin
> >
> >
> > On 7 January 2012 07:38, Morten Mikkelsen  wrote:
> >
> > > In my case I do not need morphs. I do need animation and skinning
> though.
> > > And obviously
> > > also geometries and materials. And it sounds like you have this
> covered?
> > > I have no sense of loyalty toward OpenCollada so if this is a viable
> > > solution
> > > I am for it. Can you make it available somewhere with instructions on
> how
> > > to install it so people can test it?
> > >
> > > Cheers and thanks,
> > >
> > > Morten
> > >
> > >
> > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky 
> > wrote:
> > >
> > > > Hi guys,
> > > >
> > > >I made my own Collada exporter in Python and that's what I've been
> > > > using. It's less than 1k lines of code and does not depend upon any
> > > library
> > > > or anything, but it exports everything except morphs. I don't have
> much
> > > > time to work on it at the moment, but it's so simple and complete
> that
> > if
> > > > anyone else want's to work on it, it should be really easy. I'm also
> > not
> > > an
> > > > expert at Python or Blender API so someone more experience can
> probably
> > > > shape it up better. It's also much more stable than the official one
> > (due
> > > > to it being so small).
> > > >
> > > > Feel free to do anything with it or integrate it into Blender, just
> > > credit
> > > > me on the file. I would love to work more on it, or even make a
> proper
> > > > importer since I have a high level of expertise in Collada, but I
> have
> > > very
> > > > little time and must work to earn my meals.
> > > >
> > > > Cheers!
> > > >
> > > > Juan Linietsky
> > > >
> > > >
> > > > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen <
> > mikkels...@gmail.com
> > > > >wrote:
> > > >
> > > > > Yes that's a very relevant point. A collada solution with just
> > > positions,
> > > > > UVs and normals
> > > > > is not a solution. In that case you might as well use obj format.
> > > > > I went through the hard work of writing a collada importer
> > specifically
> > > > to
> > > > > get skinning and animation
> > > > > into my tech frame-work.
> > > > >
> > > > >
> > > > > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> > > > >
> > > > > > I know Collada importer / exporter is problematic (I wrote an
> > > importer
> > > > > > for my engine and I know that everything in the Collada can be
> > stored
> > > > in
> > > > > > N different ways).
> > > > > >
> > > > > > - If you want to use the model in Second Life / Google Earth, you
> > > have
> > > > > > to use Collada, if you want to use models in engines
> WebGL/Flash3D
> > > > > > practically have to use Collada (is there any web engine with FBX
> > > > > > importer?), Most game engines use Collada for importing data
> > (support
> > > > > > for FBX a few). FBX exporter also has bugs. Well, that FBX is in
> a
> > > > > > blender, but it is not usually an option for people using
> Collada.
> > > > > >
> > > > > > - If someone uses Collada it not for the base mesh + uv (then
> using
> > > *.
> > > > > > obj) and for skeletal animation, lights, cameras and their
> > animation
> > > > > > (motion, color, light and their intensity), multiUV (uv for
> color,
> > > > > > normalmap ... + uv for lightmap). And all this in current Collada
> > > > > > exporter works well.
> > > > > >
> > > > > > - No other exporter does not work here as well as Collada - ofc
> has
> > > > > > bugs, but it has nothing what could replace the Collada in this
> > task.
> > > > In
> > > > > > the future, Alembic can replace Collada, but not for several
> years.
> > > > > >
> > > > > > IMO, better to leave Collada, until you will be able to replace
> it
> > > with
> > > > > > success to other formats

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

Erwin I consider this irrelevant in the current discussion. Programmers
should they choose to can write .blend importers
but the current discussion is what to do about collada for blender. Telling
everyone to write .blend importers (incl artists) is not
a viable alternative.
That being said it sounds like Juan has a good start here.




On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans wrote:

> You are right that in some cases an exporter is better, but in many cases
> a C/C++ .blend importer is a better to go.
>
> I just wanted to remind anyone reading this thread that
> there is an easy way to extract any data from Blender in C++,
> including animation curves, skinning info, textures etc,
> without the issues of COLLADA and FBX.
>
> I'm not familiar with baking,
> but you might be able to store the baked data in the .blend file.
>
> Thanks,
> Erwin
>
>
>
> On 7 January 2012 09:10, Juan Linietsky  wrote:
>
> > Erwin,
> >That looks awesome and really useful, however the main advantage of an
> > importer is the ability to bake everything (IK and other constraints)
> just
> > like it's displayed in Blender.
> >
> > Cheers
> >
> > Juan Linietsky
> >
> > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans  > >wrote:
> >
> > > Instead of going through the COLLADA or other intermediate format
> > > you can directly extract any data from a .blend using this C++ .blend
> > > parser:
> > >
> > > http://tinyurl.com/6s7k9zw
> > >
> > > AnimKit with the .blend loader includes a small sample that loads a
> > .blend
> > > file,
> > > extracts textures, meshes, animations, skinning and physics info.
> > > It shows a skinned skeletal animated character using AnimKit and GLUT
> > > (keeping dependencies to a minimum)
> > >
> > > Cheers,
> > > Erwin
> > >
> > >
> > > On 7 January 2012 07:38, Morten Mikkelsen 
> wrote:
> > >
> > > > In my case I do not need morphs. I do need animation and skinning
> > though.
> > > > And obviously
> > > > also geometries and materials. And it sounds like you have this
> > covered?
> > > > I have no sense of loyalty toward OpenCollada so if this is a viable
> > > > solution
> > > > I am for it. Can you make it available somewhere with instructions on
> > how
> > > > to install it so people can test it?
> > > >
> > > > Cheers and thanks,
> > > >
> > > > Morten
> > > >
> > > >
> > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky 
> > > wrote:
> > > >
> > > > > Hi guys,
> > > > >
> > > > >I made my own Collada exporter in Python and that's what I've
> been
> > > > > using. It's less than 1k lines of code and does not depend upon any
> > > > library
> > > > > or anything, but it exports everything except morphs. I don't have
> > much
> > > > > time to work on it at the moment, but it's so simple and complete
> > that
> > > if
> > > > > anyone else want's to work on it, it should be really easy. I'm
> also
> > > not
> > > > an
> > > > > expert at Python or Blender API so someone more experience can
> > probably
> > > > > shape it up better. It's also much more stable than the official
> one
> > > (due
> > > > > to it being so small).
> > > > >
> > > > > Feel free to do anything with it or integrate it into Blender, just
> > > > credit
> > > > > me on the file. I would love to work more on it, or even make a
> > proper
> > > > > importer since I have a high level of expertise in Collada, but I
> > have
> > > > very
> > > > > little time and must work to earn my meals.
> > > > >
> > > > > Cheers!
> > > > >
> > > > > Juan Linietsky
> > > > >
> > > > >
> > > > > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen <
> > > mikkels...@gmail.com
> > > > > >wrote:
> > > > >
> > > > > > Yes that's a very relevant point. A collada solution with just
> > > > positions,
> > > > > > UVs and normals
> > > > > > is not a solution. In that case you might as well use obj format.
> > > > > > I went through the hard work of writing a collada importer
> > > specifically
> > > > > to
> > > > > > get skinning and animation
> > > > > > into my tech frame-work.
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> > > > > >
> > > > > > > I know Collada importer / exporter is problematic (I wrote an
> > > > importer
> > > > > > > for my engine and I know that everything in the Collada can be
> > > stored
> > > > > in
> > > > > > > N different ways).
> > > > > > >
> > > > > > > - If you want to use the model in Second Life / Google Earth,
> you
> > > > have
> > > > > > > to use Collada, if you want to use models in engines
> > WebGL/Flash3D
> > > > > > > practically have to use Collada (is there any web engine with
> FBX
> > > > > > > importer?), Most game engines use Collada for importing data
> > > (support
> > > > > > > for FBX a few). FBX exporter also has bugs. Well, that FBX is
> in
> > a
> > > > > > > blender, but it is not usually an option for people using
> > Collada.
> > > > > > >
> > > > > > > - If someone uses Collada it not for the base mesh + uv (then
> > using
> > > > *.
> > > > 

Re: [Bf-committers] Collada importer/exporter kickout

[skoti]

I wanted to test your exporter on my example scene, but there are errors 
and the files are not compatible with the specification - for example in 
"" you have a child "" ... in the specification have 
clarified that the "" may be only child of "".

On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote:
> Ah, I tried to attach it to the e-mail, guess the mailing list does not
> accept attachments?
>
> Here's a dropbox link:
>
> http://dl.dropbox.com/u/53086520/io_scene_dae.zip
>
> Cheers
>
> Juan Linietsky
>
> On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenwrote:
>
>> In my case I do not need morphs. I do need animation and skinning though.
>> And obviously
>> also geometries and materials. And it sounds like you have this covered?
>> I have no sense of loyalty toward OpenCollada so if this is a viable
>> solution
>> I am for it. Can you make it available somewhere with instructions on how
>> to install it so people can test it?
>>
>> Cheers and thanks,
>>
>> Morten
>>
>>
>> On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky  wrote:
>>
>>> Hi guys,
>>>
>>> I made my own Collada exporter in Python and that's what I've been
>>> using. It's less than 1k lines of code and does not depend upon any
>> library
>>> or anything, but it exports everything except morphs. I don't have much
>>> time to work on it at the moment, but it's so simple and complete that if
>>> anyone else want's to work on it, it should be really easy. I'm also not
>> an
>>> expert at Python or Blender API so someone more experience can probably
>>> shape it up better. It's also much more stable than the official one (due
>>> to it being so small).
>>>
>>> Feel free to do anything with it or integrate it into Blender, just
>> credit
>>> me on the file. I would love to work more on it, or even make a proper
>>> importer since I have a high level of expertise in Collada, but I have
>> very
>>> little time and must work to earn my meals.
>>>
>>> Cheers!
>>>
>>> Juan Linietsky
>>>
>>>
>>> On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen>>> wrote:
 Yes that's a very relevant point. A collada solution with just
>> positions,
 UVs and normals
 is not a solution. In that case you might as well use obj format.
 I went through the hard work of writing a collada importer specifically
>>> to
 get skinning and animation
 into my tech frame-work.


 On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:

> I know Collada importer / exporter is problematic (I wrote an
>> importer
> for my engine and I know that everything in the Collada can be stored
>>> in
> N different ways).
>
> - If you want to use the model in Second Life / Google Earth, you
>> have
> to use Collada, if you want to use models in engines WebGL/Flash3D
> practically have to use Collada (is there any web engine with FBX
> importer?), Most game engines use Collada for importing data (support
> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> blender, but it is not usually an option for people using Collada.
>
> - If someone uses Collada it not for the base mesh + uv (then using
>> *.
> obj) and for skeletal animation, lights, cameras and their animation
> (motion, color, light and their intensity), multiUV (uv for color,
> normalmap ... + uv for lightmap). And all this in current Collada
> exporter works well.
>
> - No other exporter does not work here as well as Collada - ofc has
> bugs, but it has nothing what could replace the Collada in this task.
>>> In
> the future, Alembic can replace Collada, but not for several years.
>
> IMO, better to leave Collada, until you will be able to replace it
>> with
> success to other formats like Alembic (FBX is not popular in the
> software and you can not replace him Collada in most tasks).
>
>
> On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
>> Hi,
>>
>> I realize the proposal was harsh, but it was meant as a public
 statement
> as well (to khronos, opencollada team, etc). I don't want to blame it
>>> on
> the hard working devs here. We do have collada IO work at some level,
>>> and
> that has been proven useful in several cases. The job is just
>>> incredible
> hard to achieve.
>> To move forward:
>>
>> - userts who successfully applied .dae could also check whether
>>> another
> exchange format would have done the job as good. Tried FBX?
>> - note that for basic mesh (+uv) export, a quite simple script
>> could
>>> do
> the job already. It is probably a few days job for a py scripter.
>> - we are currently including about 100 MB of opencollada libs to
>>> make a
> feature work that's meant to be able to exchange (I+O) full shots or
>>> game
> environments, with character animation and so on. That's what Collada
>>> was
> designed for, and that's a target we can't support.
>> -Ton-
>>
>>
>> ---

Re: [Bf-committers] Collada importer/exporter kickout

[Knapp]

On Sat, Jan 7, 2012 at 5:30 PM, Morten Mikkelsen  wrote:
> As an example of people having problems with its complexity OpenCollada
> doesn't drain collada sources correctly at all.
> They make many assumptions such as data being non interleaved.

Surely, if blender is having these problems then all the other open
source programs that work with collada are too. Perhaps blender could
come together with all the others and form a Collada team that can
solve these problems. Just an idea.


-- 
Douglas E Knapp

Creative Commons Film Group, Helping people make open source movies
with open source software!
http://douglas.bespin.org/CommonsFilmGroup/phpBB3/index.php

Massage in Gelsenkirchen-Buer:
http://douglas.bespin.org/tcm/ztab1.htm
Please link to me and trade links with me!

Open Source Sci-Fi mmoRPG Game project.
http://sf-journey-creations.wikispot.org/Front_Page
http://code.google.com/p/perspectiveproject/
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Gaia Clary]

I have done a couple of tests with Blender 2.61 to check if it exports 
correct for Second Life.
For some reason it takes a long time to export an animatin which 
actually does not exist.
Yes i have unchecked "export animation" :)
The import to Second Life yields import errors.
I havent tested in more depth. Maybe the script behaves wrong
because it was made for 2.58 ?

cheers,
Gaia

Am 07.01.2012 19:16, schrieb skoti:
> I wanted to test your exporter on my example scene, but there are errors
> and the files are not compatible with the specification - for example in
> "" you have a child"" ... in the specification have
> clarified that the "" may be only child of"".
>
> On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote:
>> Ah, I tried to attach it to the e-mail, guess the mailing list does not
>> accept attachments?
>>
>> Here's a dropbox link:
>>
>> http://dl.dropbox.com/u/53086520/io_scene_dae.zip
>>
>> Cheers
>>
>> Juan Linietsky
>>
>> On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsenwrote:
>>
>>> In my case I do not need morphs. I do need animation and skinning though.
>>> And obviously
>>> also geometries and materials. And it sounds like you have this covered?
>>> I have no sense of loyalty toward OpenCollada so if this is a viable
>>> solution
>>> I am for it. Can you make it available somewhere with instructions on how
>>> to install it so people can test it?
>>>
>>> Cheers and thanks,
>>>
>>> Morten
>>>
>>>
>>> On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky   wrote:
>>>
 Hi guys,

  I made my own Collada exporter in Python and that's what I've been
 using. It's less than 1k lines of code and does not depend upon any
>>> library
 or anything, but it exports everything except morphs. I don't have much
 time to work on it at the moment, but it's so simple and complete that if
 anyone else want's to work on it, it should be really easy. I'm also not
>>> an
 expert at Python or Blender API so someone more experience can probably
 shape it up better. It's also much more stable than the official one (due
 to it being so small).

 Feel free to do anything with it or integrate it into Blender, just
>>> credit
 me on the file. I would love to work more on it, or even make a proper
 importer since I have a high level of expertise in Collada, but I have
>>> very
 little time and must work to earn my meals.

 Cheers!

 Juan Linietsky


 On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen wrote:
> Yes that's a very relevant point. A collada solution with just
>>> positions,
> UVs and normals
> is not a solution. In that case you might as well use obj format.
> I went through the hard work of writing a collada importer specifically
 to
> get skinning and animation
> into my tech frame-work.
>
>
> On Sat, Jan 7, 2012 at 5:03 AM, skoti   wrote:
>
>> I know Collada importer / exporter is problematic (I wrote an
>>> importer
>> for my engine and I know that everything in the Collada can be stored
 in
>> N different ways).
>>
>> - If you want to use the model in Second Life / Google Earth, you
>>> have
>> to use Collada, if you want to use models in engines WebGL/Flash3D
>> practically have to use Collada (is there any web engine with FBX
>> importer?), Most game engines use Collada for importing data (support
>> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
>> blender, but it is not usually an option for people using Collada.
>>
>> - If someone uses Collada it not for the base mesh + uv (then using
>>> *.
>> obj) and for skeletal animation, lights, cameras and their animation
>> (motion, color, light and their intensity), multiUV (uv for color,
>> normalmap ... + uv for lightmap). And all this in current Collada
>> exporter works well.
>>
>> - No other exporter does not work here as well as Collada - ofc has
>> bugs, but it has nothing what could replace the Collada in this task.
 In
>> the future, Alembic can replace Collada, but not for several years.
>>
>> IMO, better to leave Collada, until you will be able to replace it
>>> with
>> success to other formats like Alembic (FBX is not popular in the
>> software and you can not replace him Collada in most tasks).
>>
>>
>> On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
>>> Hi,
>>>
>>> I realize the proposal was harsh, but it was meant as a public
> statement
>> as well (to khronos, opencollada team, etc). I don't want to blame it
 on
>> the hard working devs here. We do have collada IO work at some level,
 and
>> that has been proven useful in several cases. The job is just
 incredible
>> hard to achieve.
>>> To move forward:
>>>
>>> - userts who successfully applied .dae could also check whether
 another
>> exchange format would ha

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

@Morton

A C++ .blend importer may not be a viable alternative for some people
(artists)
but using an existing open source C++ .blend importer can be a viable
alternative for programmers.

It would be great to have well maintained COLLADA export/import for Blender
of course,
so good luck if someone can create and maintain a Python implementation.

Peter Amstutz wrote
>> When I looked last looked at OpenCollada, one critical issue preventing
>> someone else from taking over maintenance is the fact that it relied
>> heavily on autogenerated code, but the code generator and the input file
>> are not included in the online repository.

That is a serious issue. Did someone try to make those code generation
files available?

>> There would also needs to be a set of test cases,

Khronos/COLLADA workgroup has an extensive conformance tests,
unfortunately they are only available to members. If someone starts
maintaining
OpenCollada, they probably can get access to those conformance tests.

Thanks,
Erwin


On 7 January 2012 09:47, Morten Mikkelsen  wrote:

> Erwin I consider this irrelevant in the current discussion. Programmers
> should they choose to can write .blend importers
> but the current discussion is what to do about collada for blender. Telling
> everyone to write .blend importers (incl artists) is not
> a viable alternative.
> That being said it sounds like Juan has a good start here.
>
>
>
>
> On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans  >wrote:
>
> > You are right that in some cases an exporter is better, but in many cases
> > a C/C++ .blend importer is a better to go.
> >
> > I just wanted to remind anyone reading this thread that
> > there is an easy way to extract any data from Blender in C++,
> > including animation curves, skinning info, textures etc,
> > without the issues of COLLADA and FBX.
> >
> > I'm not familiar with baking,
> > but you might be able to store the baked data in the .blend file.
> >
> > Thanks,
> > Erwin
> >
> >
> >
> > On 7 January 2012 09:10, Juan Linietsky  wrote:
> >
> > > Erwin,
> > >That looks awesome and really useful, however the main advantage of
> an
> > > importer is the ability to bake everything (IK and other constraints)
> > just
> > > like it's displayed in Blender.
> > >
> > > Cheers
> > >
> > > Juan Linietsky
> > >
> > > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans  > > >wrote:
> > >
> > > > Instead of going through the COLLADA or other intermediate format
> > > > you can directly extract any data from a .blend using this C++ .blend
> > > > parser:
> > > >
> > > > http://tinyurl.com/6s7k9zw
> > > >
> > > > AnimKit with the .blend loader includes a small sample that loads a
> > > .blend
> > > > file,
> > > > extracts textures, meshes, animations, skinning and physics info.
> > > > It shows a skinned skeletal animated character using AnimKit and GLUT
> > > > (keeping dependencies to a minimum)
> > > >
> > > > Cheers,
> > > > Erwin
> > > >
> > > >
> > > > On 7 January 2012 07:38, Morten Mikkelsen 
> > wrote:
> > > >
> > > > > In my case I do not need morphs. I do need animation and skinning
> > > though.
> > > > > And obviously
> > > > > also geometries and materials. And it sounds like you have this
> > > covered?
> > > > > I have no sense of loyalty toward OpenCollada so if this is a
> viable
> > > > > solution
> > > > > I am for it. Can you make it available somewhere with instructions
> on
> > > how
> > > > > to install it so people can test it?
> > > > >
> > > > > Cheers and thanks,
> > > > >
> > > > > Morten
> > > > >
> > > > >
> > > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky 
> > > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > >I made my own Collada exporter in Python and that's what I've
> > been
> > > > > > using. It's less than 1k lines of code and does not depend upon
> any
> > > > > library
> > > > > > or anything, but it exports everything except morphs. I don't
> have
> > > much
> > > > > > time to work on it at the moment, but it's so simple and complete
> > > that
> > > > if
> > > > > > anyone else want's to work on it, it should be really easy. I'm
> > also
> > > > not
> > > > > an
> > > > > > expert at Python or Blender API so someone more experience can
> > > probably
> > > > > > shape it up better. It's also much more stable than the official
> > one
> > > > (due
> > > > > > to it being so small).
> > > > > >
> > > > > > Feel free to do anything with it or integrate it into Blender,
> just
> > > > > credit
> > > > > > me on the file. I would love to work more on it, or even make a
> > > proper
> > > > > > importer since I have a high level of expertise in Collada, but I
> > > have
> > > > > very
> > > > > > little time and must work to earn my meals.
> > > > > >
> > > > > > Cheers!
> > > > > >
> > > > > > Juan Linietsky
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen <
> > > > mikkels...@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Yes that's a very relevant po

Re: [Bf-committers] Collada importer/exporter kickout

[Alexandr Kuznetsov]

Hi Erwin.

I don't think .blend importer is very good idea. We need a 3D format like
.png for images because it makes easier to share projects between programs.
There is probably 10-20 major programs which people use with Blender. So,
writing for each of them an extension for .blend importer is not realistic.
In addition, the implentation will be very basic due to their quantity.
Another problem is .blend format. .blend is essentially a dump of blender's
program memory. It has useless data like different preferences and other
internal data which intended for blender use only. Moreover, there is no
standard for .blend file. File format is constantly evolving. Therefore C
importer must constantly reflect changes and so the plugins.
It is better to have a very solid importer/exporter for universal 3d
format. If there is no good opensource library, it is better to write it
ourselves, rather then to support 20 importers/exporters different quality.

Best Regards,
Alex


On Sat, Jan 7, 2012 at 2:16 PM, Erwin Coumans wrote:

> @Morton
>
> A C++ .blend importer may not be a viable alternative for some people
> (artists)
> but using an existing open source C++ .blend importer can be a viable
> alternative for programmers.
>
> It would be great to have well maintained COLLADA export/import for Blender
> of course,
> so good luck if someone can create and maintain a Python implementation.
>
> Peter Amstutz wrote
> >> When I looked last looked at OpenCollada, one critical issue preventing
> >> someone else from taking over maintenance is the fact that it relied
> >> heavily on autogenerated code, but the code generator and the input file
> >> are not included in the online repository.
>
> That is a serious issue. Did someone try to make those code generation
> files available?
>
> >> There would also needs to be a set of test cases,
>
> Khronos/COLLADA workgroup has an extensive conformance tests,
> unfortunately they are only available to members. If someone starts
> maintaining
> OpenCollada, they probably can get access to those conformance tests.
>
> Thanks,
> Erwin
>
>
> On 7 January 2012 09:47, Morten Mikkelsen  wrote:
>
> > Erwin I consider this irrelevant in the current discussion. Programmers
> > should they choose to can write .blend importers
> > but the current discussion is what to do about collada for blender.
> Telling
> > everyone to write .blend importers (incl artists) is not
> > a viable alternative.
> > That being said it sounds like Juan has a good start here.
> >
> >
> >
> >
> > On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans  > >wrote:
> >
> > > You are right that in some cases an exporter is better, but in many
> cases
> > > a C/C++ .blend importer is a better to go.
> > >
> > > I just wanted to remind anyone reading this thread that
> > > there is an easy way to extract any data from Blender in C++,
> > > including animation curves, skinning info, textures etc,
> > > without the issues of COLLADA and FBX.
> > >
> > > I'm not familiar with baking,
> > > but you might be able to store the baked data in the .blend file.
> > >
> > > Thanks,
> > > Erwin
> > >
> > >
> > >
> > > On 7 January 2012 09:10, Juan Linietsky  wrote:
> > >
> > > > Erwin,
> > > >That looks awesome and really useful, however the main advantage
> of
> > an
> > > > importer is the ability to bake everything (IK and other constraints)
> > > just
> > > > like it's displayed in Blender.
> > > >
> > > > Cheers
> > > >
> > > > Juan Linietsky
> > > >
> > > > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans <
> erwin.coum...@gmail.com
> > > > >wrote:
> > > >
> > > > > Instead of going through the COLLADA or other intermediate format
> > > > > you can directly extract any data from a .blend using this C++
> .blend
> > > > > parser:
> > > > >
> > > > > http://tinyurl.com/6s7k9zw
> > > > >
> > > > > AnimKit with the .blend loader includes a small sample that loads a
> > > > .blend
> > > > > file,
> > > > > extracts textures, meshes, animations, skinning and physics info.
> > > > > It shows a skinned skeletal animated character using AnimKit and
> GLUT
> > > > > (keeping dependencies to a minimum)
> > > > >
> > > > > Cheers,
> > > > > Erwin
> > > > >
> > > > >
> > > > > On 7 January 2012 07:38, Morten Mikkelsen 
> > > wrote:
> > > > >
> > > > > > In my case I do not need morphs. I do need animation and skinning
> > > > though.
> > > > > > And obviously
> > > > > > also geometries and materials. And it sounds like you have this
> > > > covered?
> > > > > > I have no sense of loyalty toward OpenCollada so if this is a
> > viable
> > > > > > solution
> > > > > > I am for it. Can you make it available somewhere with
> instructions
> > on
> > > > how
> > > > > > to install it so people can test it?
> > > > > >
> > > > > > Cheers and thanks,
> > > > > >
> > > > > > Morten
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky <
> redu...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > >

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Before writing my Collada Exporter I actually checked Erwin's work on
Bullet's Blender importer, but back then it was a little outdated and also
had that problem of efficiently baking stuff (like for example, IK or curve
follow constraint for a rollercoaster or some camera animations). I'm sure
if baking support was added for it, it would be really useful for us game
developers.
BTW, and also irrelevant to the current discussion, Erwin is my hero so
please be nice to him :D

Juan


On Sat, Jan 7, 2012 at 2:47 PM, Morten Mikkelsen wrote:

> Erwin I consider this irrelevant in the current discussion. Programmers
> should they choose to can write .blend importers
> but the current discussion is what to do about collada for blender. Telling
> everyone to write .blend importers (incl artists) is not
> a viable alternative.
> That being said it sounds like Juan has a good start here.
>
>
>
>
> On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans  >wrote:
>
> > You are right that in some cases an exporter is better, but in many cases
> > a C/C++ .blend importer is a better to go.
> >
> > I just wanted to remind anyone reading this thread that
> > there is an easy way to extract any data from Blender in C++,
> > including animation curves, skinning info, textures etc,
> > without the issues of COLLADA and FBX.
> >
> > I'm not familiar with baking,
> > but you might be able to store the baked data in the .blend file.
> >
> > Thanks,
> > Erwin
> >
> >
> >
> > On 7 January 2012 09:10, Juan Linietsky  wrote:
> >
> > > Erwin,
> > >That looks awesome and really useful, however the main advantage of
> an
> > > importer is the ability to bake everything (IK and other constraints)
> > just
> > > like it's displayed in Blender.
> > >
> > > Cheers
> > >
> > > Juan Linietsky
> > >
> > > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans  > > >wrote:
> > >
> > > > Instead of going through the COLLADA or other intermediate format
> > > > you can directly extract any data from a .blend using this C++ .blend
> > > > parser:
> > > >
> > > > http://tinyurl.com/6s7k9zw
> > > >
> > > > AnimKit with the .blend loader includes a small sample that loads a
> > > .blend
> > > > file,
> > > > extracts textures, meshes, animations, skinning and physics info.
> > > > It shows a skinned skeletal animated character using AnimKit and GLUT
> > > > (keeping dependencies to a minimum)
> > > >
> > > > Cheers,
> > > > Erwin
> > > >
> > > >
> > > > On 7 January 2012 07:38, Morten Mikkelsen 
> > wrote:
> > > >
> > > > > In my case I do not need morphs. I do need animation and skinning
> > > though.
> > > > > And obviously
> > > > > also geometries and materials. And it sounds like you have this
> > > covered?
> > > > > I have no sense of loyalty toward OpenCollada so if this is a
> viable
> > > > > solution
> > > > > I am for it. Can you make it available somewhere with instructions
> on
> > > how
> > > > > to install it so people can test it?
> > > > >
> > > > > Cheers and thanks,
> > > > >
> > > > > Morten
> > > > >
> > > > >
> > > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky 
> > > > wrote:
> > > > >
> > > > > > Hi guys,
> > > > > >
> > > > > >I made my own Collada exporter in Python and that's what I've
> > been
> > > > > > using. It's less than 1k lines of code and does not depend upon
> any
> > > > > library
> > > > > > or anything, but it exports everything except morphs. I don't
> have
> > > much
> > > > > > time to work on it at the moment, but it's so simple and complete
> > > that
> > > > if
> > > > > > anyone else want's to work on it, it should be really easy. I'm
> > also
> > > > not
> > > > > an
> > > > > > expert at Python or Blender API so someone more experience can
> > > probably
> > > > > > shape it up better. It's also much more stable than the official
> > one
> > > > (due
> > > > > > to it being so small).
> > > > > >
> > > > > > Feel free to do anything with it or integrate it into Blender,
> just
> > > > > credit
> > > > > > me on the file. I would love to work more on it, or even make a
> > > proper
> > > > > > importer since I have a high level of expertise in Collada, but I
> > > have
> > > > > very
> > > > > > little time and must work to earn my meals.
> > > > > >
> > > > > > Cheers!
> > > > > >
> > > > > > Juan Linietsky
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen <
> > > > mikkels...@gmail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Yes that's a very relevant point. A collada solution with just
> > > > > positions,
> > > > > > > UVs and normals
> > > > > > > is not a solution. In that case you might as well use obj
> format.
> > > > > > > I went through the hard work of writing a collada importer
> > > > specifically
> > > > > > to
> > > > > > > get skinning and animation
> > > > > > > into my tech frame-work.
> > > > > > >
> > > > > > >
> > > > > > > On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> > > > > > >
> > > > > > > > I know Collada importer / exporter is problem

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Yeah I'm not sure it's 100% bug-free, but if you look at the source code,
it's so simple that such issues are very easy to fix.


On Sat, Jan 7, 2012 at 3:16 PM, skoti  wrote:

> I wanted to test your exporter on my example scene, but there are errors
> and the files are not compatible with the specification - for example in
> "" you have a child "" ... in the specification have
> clarified that the "" may be only child of "".
>
> On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote:
> > Ah, I tried to attach it to the e-mail, guess the mailing list does not
> > accept attachments?
> >
> > Here's a dropbox link:
> >
> > http://dl.dropbox.com/u/53086520/io_scene_dae.zip
> >
> > Cheers
> >
> > Juan Linietsky
> >
> > On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsen >wrote:
> >
> >> In my case I do not need morphs. I do need animation and skinning
> though.
> >> And obviously
> >> also geometries and materials. And it sounds like you have this covered?
> >> I have no sense of loyalty toward OpenCollada so if this is a viable
> >> solution
> >> I am for it. Can you make it available somewhere with instructions on
> how
> >> to install it so people can test it?
> >>
> >> Cheers and thanks,
> >>
> >> Morten
> >>
> >>
> >> On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky
>  wrote:
> >>
> >>> Hi guys,
> >>>
> >>> I made my own Collada exporter in Python and that's what I've been
> >>> using. It's less than 1k lines of code and does not depend upon any
> >> library
> >>> or anything, but it exports everything except morphs. I don't have much
> >>> time to work on it at the moment, but it's so simple and complete that
> if
> >>> anyone else want's to work on it, it should be really easy. I'm also
> not
> >> an
> >>> expert at Python or Blender API so someone more experience can probably
> >>> shape it up better. It's also much more stable than the official one
> (due
> >>> to it being so small).
> >>>
> >>> Feel free to do anything with it or integrate it into Blender, just
> >> credit
> >>> me on the file. I would love to work more on it, or even make a proper
> >>> importer since I have a high level of expertise in Collada, but I have
> >> very
> >>> little time and must work to earn my meals.
> >>>
> >>> Cheers!
> >>>
> >>> Juan Linietsky
> >>>
> >>>
> >>> On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen  wrote:
>  Yes that's a very relevant point. A collada solution with just
> >> positions,
>  UVs and normals
>  is not a solution. In that case you might as well use obj format.
>  I went through the hard work of writing a collada importer
> specifically
> >>> to
>  get skinning and animation
>  into my tech frame-work.
> 
> 
>  On Sat, Jan 7, 2012 at 5:03 AM, skoti  wrote:
> 
> > I know Collada importer / exporter is problematic (I wrote an
> >> importer
> > for my engine and I know that everything in the Collada can be stored
> >>> in
> > N different ways).
> >
> > - If you want to use the model in Second Life / Google Earth, you
> >> have
> > to use Collada, if you want to use models in engines WebGL/Flash3D
> > practically have to use Collada (is there any web engine with FBX
> > importer?), Most game engines use Collada for importing data (support
> > for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> > blender, but it is not usually an option for people using Collada.
> >
> > - If someone uses Collada it not for the base mesh + uv (then using
> >> *.
> > obj) and for skeletal animation, lights, cameras and their animation
> > (motion, color, light and their intensity), multiUV (uv for color,
> > normalmap ... + uv for lightmap). And all this in current Collada
> > exporter works well.
> >
> > - No other exporter does not work here as well as Collada - ofc has
> > bugs, but it has nothing what could replace the Collada in this task.
> >>> In
> > the future, Alembic can replace Collada, but not for several years.
> >
> > IMO, better to leave Collada, until you will be able to replace it
> >> with
> > success to other formats like Alembic (FBX is not popular in the
> > software and you can not replace him Collada in most tasks).
> >
> >
> > On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:
> >> Hi,
> >>
> >> I realize the proposal was harsh, but it was meant as a public
>  statement
> > as well (to khronos, opencollada team, etc). I don't want to blame it
> >>> on
> > the hard working devs here. We do have collada IO work at some level,
> >>> and
> > that has been proven useful in several cases. The job is just
> >>> incredible
> > hard to achieve.
> >> To move forward:
> >>
> >> - userts who successfully applied .dae could also check whether
> >>> another
> > exchange format would have done the job as good. Tried FBX?
> >> - note that for basic mesh (+uv) export, a quite simple script
> >> co

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

I think unless there is a skeleton, it samples animation of anything that
has curves. As said, while it exprors everything, it needs some little
tweaking, but the source code is so simple that it should be easy to fix.


On Sat, Jan 7, 2012 at 3:34 PM, Gaia Clary wrote:

> I have done a couple of tests with Blender 2.61 to check if it exports
> correct for Second Life.
> For some reason it takes a long time to export an animatin which
> actually does not exist.
> Yes i have unchecked "export animation" :)
> The import to Second Life yields import errors.
> I havent tested in more depth. Maybe the script behaves wrong
> because it was made for 2.58 ?
>
> cheers,
> Gaia
>
> Am 07.01.2012 19:16, schrieb skoti:
> > I wanted to test your exporter on my example scene, but there are errors
> > and the files are not compatible with the specification - for example in
> > "" you have a child"" ... in the specification have
> > clarified that the "" may be only child of"".
> >
> > On Sat, Jan 7, 2012 at 16:49, Juan Linietsky wrote:
> >> Ah, I tried to attach it to the e-mail, guess the mailing list does not
> >> accept attachments?
> >>
> >> Here's a dropbox link:
> >>
> >> http://dl.dropbox.com/u/53086520/io_scene_dae.zip
> >>
> >> Cheers
> >>
> >> Juan Linietsky
> >>
> >> On Sat, Jan 7, 2012 at 12:38 PM, Morten Mikkelsen >wrote:
> >>
> >>> In my case I do not need morphs. I do need animation and skinning
> though.
> >>> And obviously
> >>> also geometries and materials. And it sounds like you have this
> covered?
> >>> I have no sense of loyalty toward OpenCollada so if this is a viable
> >>> solution
> >>> I am for it. Can you make it available somewhere with instructions on
> how
> >>> to install it so people can test it?
> >>>
> >>> Cheers and thanks,
> >>>
> >>> Morten
> >>>
> >>>
> >>> On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky
> wrote:
> >>>
>  Hi guys,
> 
>   I made my own Collada exporter in Python and that's what I've
> been
>  using. It's less than 1k lines of code and does not depend upon any
> >>> library
>  or anything, but it exports everything except morphs. I don't have
> much
>  time to work on it at the moment, but it's so simple and complete
> that if
>  anyone else want's to work on it, it should be really easy. I'm also
> not
> >>> an
>  expert at Python or Blender API so someone more experience can
> probably
>  shape it up better. It's also much more stable than the official one
> (due
>  to it being so small).
> 
>  Feel free to do anything with it or integrate it into Blender, just
> >>> credit
>  me on the file. I would love to work more on it, or even make a proper
>  importer since I have a high level of expertise in Collada, but I have
> >>> very
>  little time and must work to earn my meals.
> 
>  Cheers!
> 
>  Juan Linietsky
> 
> 
>  On Sat, Jan 7, 2012 at 11:49 AM, Morten Mikkelsen<
> mikkels...@gmail.com
> > wrote:
> > Yes that's a very relevant point. A collada solution with just
> >>> positions,
> > UVs and normals
> > is not a solution. In that case you might as well use obj format.
> > I went through the hard work of writing a collada importer
> specifically
>  to
> > get skinning and animation
> > into my tech frame-work.
> >
> >
> > On Sat, Jan 7, 2012 at 5:03 AM, skoti   wrote:
> >
> >> I know Collada importer / exporter is problematic (I wrote an
> >>> importer
> >> for my engine and I know that everything in the Collada can be
> stored
>  in
> >> N different ways).
> >>
> >> - If you want to use the model in Second Life / Google Earth, you
> >>> have
> >> to use Collada, if you want to use models in engines WebGL/Flash3D
> >> practically have to use Collada (is there any web engine with FBX
> >> importer?), Most game engines use Collada for importing data
> (support
> >> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> >> blender, but it is not usually an option for people using Collada.
> >>
> >> - If someone uses Collada it not for the base mesh + uv (then using
> >>> *.
> >> obj) and for skeletal animation, lights, cameras and their animation
> >> (motion, color, light and their intensity), multiUV (uv for color,
> >> normalmap ... + uv for lightmap). And all this in current Collada
> >> exporter works well.
> >>
> >> - No other exporter does not work here as well as Collada - ofc has
> >> bugs, but it has nothing what could replace the Collada in this
> task.
>  In
> >> the future, Alembic can replace Collada, but not for several years.
> >>
> >> IMO, better to leave Collada, until you will be able to replace it
> >>> with
> >> success to other formats like Alembic (FBX is not popular in the
> >> software and you can not replace him Collada in most tasks).
> >>
> >>
> >> On 7 Jan, 2012, at 12:30

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

I agree that a well maintained open source library for a stable 3D format
is best.

I just spoke to Sebastian from OpenCollada and asked him to open source the
code generation files,
so here you go:  http://code.google.com/p/opencollada/source/detail?r=867
I think improving the OpenCollada project is better than promoting FBX in
the long run.

Until that happens, we need to have some pragmatic solutions to get rich
data out of Blender.
Juan's Python .dae exporter is one solution, a .blend reader another.
The Blender .blend format is suprisingly stable, and we keep our .blend
importer up-to-date
(we can handle old-style animations and new style, and once bmesh is
available we will support it too)

Thanks,
Erwin



On 7 January 2012 12:04, Juan Linietsky  wrote:

> Before writing my Collada Exporter I actually checked Erwin's work on
> Bullet's Blender importer, but back then it was a little outdated and also
> had that problem of efficiently baking stuff (like for example, IK or curve
> follow constraint for a rollercoaster or some camera animations). I'm sure
> if baking support was added for it, it would be really useful for us game
> developers.
> BTW, and also irrelevant to the current discussion, Erwin is my hero so
> please be nice to him :D
>
> Juan
>
>
> On Sat, Jan 7, 2012 at 2:47 PM, Morten Mikkelsen  >wrote:
>
> > Erwin I consider this irrelevant in the current discussion. Programmers
> > should they choose to can write .blend importers
> > but the current discussion is what to do about collada for blender.
> Telling
> > everyone to write .blend importers (incl artists) is not
> > a viable alternative.
> > That being said it sounds like Juan has a good start here.
> >
> >
> >
> >
> > On Sat, Jan 7, 2012 at 9:23 AM, Erwin Coumans  > >wrote:
> >
> > > You are right that in some cases an exporter is better, but in many
> cases
> > > a C/C++ .blend importer is a better to go.
> > >
> > > I just wanted to remind anyone reading this thread that
> > > there is an easy way to extract any data from Blender in C++,
> > > including animation curves, skinning info, textures etc,
> > > without the issues of COLLADA and FBX.
> > >
> > > I'm not familiar with baking,
> > > but you might be able to store the baked data in the .blend file.
> > >
> > > Thanks,
> > > Erwin
> > >
> > >
> > >
> > > On 7 January 2012 09:10, Juan Linietsky  wrote:
> > >
> > > > Erwin,
> > > >That looks awesome and really useful, however the main advantage
> of
> > an
> > > > importer is the ability to bake everything (IK and other constraints)
> > > just
> > > > like it's displayed in Blender.
> > > >
> > > > Cheers
> > > >
> > > > Juan Linietsky
> > > >
> > > > On Sat, Jan 7, 2012 at 2:07 PM, Erwin Coumans <
> erwin.coum...@gmail.com
> > > > >wrote:
> > > >
> > > > > Instead of going through the COLLADA or other intermediate format
> > > > > you can directly extract any data from a .blend using this C++
> .blend
> > > > > parser:
> > > > >
> > > > > http://tinyurl.com/6s7k9zw
> > > > >
> > > > > AnimKit with the .blend loader includes a small sample that loads a
> > > > .blend
> > > > > file,
> > > > > extracts textures, meshes, animations, skinning and physics info.
> > > > > It shows a skinned skeletal animated character using AnimKit and
> GLUT
> > > > > (keeping dependencies to a minimum)
> > > > >
> > > > > Cheers,
> > > > > Erwin
> > > > >
> > > > >
> > > > > On 7 January 2012 07:38, Morten Mikkelsen 
> > > wrote:
> > > > >
> > > > > > In my case I do not need morphs. I do need animation and skinning
> > > > though.
> > > > > > And obviously
> > > > > > also geometries and materials. And it sounds like you have this
> > > > covered?
> > > > > > I have no sense of loyalty toward OpenCollada so if this is a
> > viable
> > > > > > solution
> > > > > > I am for it. Can you make it available somewhere with
> instructions
> > on
> > > > how
> > > > > > to install it so people can test it?
> > > > > >
> > > > > > Cheers and thanks,
> > > > > >
> > > > > > Morten
> > > > > >
> > > > > >
> > > > > > On Sat, Jan 7, 2012 at 7:06 AM, Juan Linietsky <
> redu...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > Hi guys,
> > > > > > >
> > > > > > >I made my own Collada exporter in Python and that's what
> I've
> > > been
> > > > > > > using. It's less than 1k lines of code and does not depend upon
> > any
> > > > > > library
> > > > > > > or anything, but it exports everything except morphs. I don't
> > have
> > > > much
> > > > > > > time to work on it at the moment, but it's so simple and
> complete
> > > > that
> > > > > if
> > > > > > > anyone else want's to work on it, it should be really easy. I'm
> > > also
> > > > > not
> > > > > > an
> > > > > > > expert at Python or Blender API so someone more experience can
> > > > probably
> > > > > > > shape it up better. It's also much more stable than the
> official
> > > one
> > > > > (due
> > > > > > > to it being so small).
> > > > > > >
> > > > > > > Feel free to do anything with

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

I reply as a middleware and tool developer, not as blender developer. This
may not be the place, but I believe my concerns also cover what Blender is
doing. My problem with OpenCollada:

1) It's way too big, and most apps don't need to either import or export
most of the format. Take a look at my Python exporter, which does most of
the job and it takes much fewer lines than even an interface with
OpenCollada. It's a lot of code to add to a project/repo and enlarges the
binary unnecesarily.
2) A strong point for using a library such as OpenCollada is proper
validation of the incoming DAE files. However, in the real world, it's easy
to find sightly broken files that you would rather import anyway than being
format nazi and refuse the import. Being honest, not even OpenCollada
plugins for MAX and Maya open their own DAEs most of the time.
3) It's been a lot of years and I still can't understand why there is such
a good support for MAX and Maya, and zero Blender support. Aren't Khronos
and ithe companies it represents supposed to fund and/or encourage adoption
of their format, yet the most open of the 3D modellers does not support the
most open 3D format?
4) Collada is an open format, but most apps that support it export their
data in different but valid ways. An example of this is the export of
skeletons, the usage of the inverse bind transform, how named/vs unnamed
bones are used, etc. Most apps that wish to import Collada don't work
internally like Collada and already have to do an important effort to guess
what the DAE layout looks like. OpenCollada is just too "general purpose"
and does not help this situation. Back then, other implementations such as
FCollada provided several tools that aided in the guesswork or provided
data the way it was meant to, so at least you could save writing some code
or doing some guessing.
5) I don't think blender should have "yet another DAE importer/exporter",
but something custom tailored to it's needs. I already wrote several
Collada importers for middleware or propertary game engines and can attest
that most of the work is not really importing Collada itself (what
OpenCollada does), but guessing how the Collada file is laid out and how to
translate that to the way Blender works. Using a large library such as OC
only adds an unnecesary layer of complexity at the simpler part of a
problem.
6) Collada is a very outdated format at this point. There is no support for
constraints, material support is still really poor (still no official
support for normal mapping or displacement mapping, let alone any sort of
node-based materials), multiple texcoord support is broken because each app
exports it any way it wants, and many other issues. This could be solved
simply by going the FBX way and exporting blender-only extensions (besides
the standard stuff) in a DAE, describing the full blender material or
something, so importers can do the best at guessing, and save artist time
from having to reimplement materials all over again when importing. I'm not
sure how well can OC do this. Exporting custom properties is also really
useful.


Cheers

Juan Linietsky
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

I acknowledge that the amount of work you guys have put into OpenCollada is
significant and I am definitely pleased with
this as an option. That being said I am beginning to warm up to what sergei
is suggesting more and I am actually a collada user myself.
Correct me if I am wrong but the way it works for autodesk these products
by default ship with some crappy collada exporter that someone within the
castle of autodesk has authored. Then as an alternative option you guys
made OpenCollada plugins available for Maya and 3dsmax from your website
correct?
So when you think about it is there really any harm in Blender shipping
with a "crappy" collada exporter of its own, like autodesk, and then having
the option of downloading an OpenCollada blugin for Blender from an
off-site location as well (Possibly even your site)?
And Juan no offense intended here I am just making a comparison. I am not
saying your code is literally crappy!

Cheers,

Morten.





On Sat, Jan 7, 2012 at 1:22 PM, Sebastian  wrote:

> Erwin already announced it: I've contributed the code generation
> libraries under the MIT license and committed it to our Subversion
> repository.
>
> You should see this as our commitment to the future of OpenCOLLADA.
> OpenCOLLADA is and was a lot of work, it's far away from being perfect
> or even error free but I would not suggest to develop yet another DAE
> importer/exporter specifically for Blender or even drop support for it.
> For the COLLADA community Blender is definitely one of the most
> important stakeholders to stop supporting COLLADA would make things in
> DCC exchange even worse.
>
> We are currently discussing further financing of OpenCOLLADA and will
> spend more time the next months on bugfixing and conformance tests.
>
> Sebastian
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

>
>
> And Juan no offense intended here I am just making a comparison. I am not
> saying your code is literally crappy!
>
>
The word crappy is completely subjective. In this case, what matters is:

1) Whether something works or not. It may have bugs and need a little more
work in the export options area, but it definitely does work (or is very
close).
2) How easy it is to maintain. I think we can agree that a ~1k loc python
codebase is much easier to maintain than a huge library and wrapper code.


Cheers

Juan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Morten Mikkelsen]

Okay I guess you did misunderstand my misuse of the word crappy.
What I meant was more like "less likely to work with existing OpenCollada
importers". Those which are already used in other apps.
Clearly an OpenCollada exporter is more likely to work with an OpenCollada
importer
across apps. This was all I meant really. And implicitly this was also what
Sebastian was saying
in regards to the dangers of introducing yet another one. It's really a
reflection of the Collada format
being ridiculously broad. I am not calling anyone's code literally crap so
sorry I misused this work.



On Sat, Jan 7, 2012 at 3:24 PM, Juan Linietsky  wrote:

> >
> >
> > And Juan no offense intended here I am just making a comparison. I am not
> > saying your code is literally crappy!
> >
> >
> The word crappy is completely subjective. In this case, what matters is:
>
> 1) Whether something works or not. It may have bugs and need a little more
> work in the export options area, but it definitely does work (or is very
> close).
> 2) How easy it is to maintain. I think we can agree that a ~1k loc python
> codebase is much easier to maintain than a huge library and wrapper code.
>
>
> Cheers
>
> Juan
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

On Sun, Jan 8, 2012 at 12:03 AM, skoti  wrote:
> I know Collada importer / exporter is problematic (I wrote an importer
> for my engine and I know that everything in the Collada can be stored in
> N different ways).
>
> - If you want to use the model in Second Life / Google Earth, you have
> to use Collada, if you want to use models in engines WebGL/Flash3D
> practically have to use Collada (is there any web engine with FBX
> importer?), Most game engines use Collada for importing data (support
> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> blender, but it is not usually an option for people using Collada.

Can you report these bugs please?

I'm no great fan of FBX/Autodesk with their idiotic EULA, but as
maintainer of FBX export I rather not have it be buggy.

Note that FBX has similar issues as collada, which is that different
applications support different parts of the FBX spec - so Lightwave
and Maya for example complain when importing non uniform scaled bones
from blender for EG because they don't support it.
So you cant assume just because a single application chokes on a
blender FBX model that it is a blender bug for sure.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[skoti]

Unfortunately I can not - I tested a month ago one scene and a file 
exported from Blender to 3ds max (reference implementation) and showed 
errors. I no longer have either the file or scene, and detailed 
information is not checked, because the FBX does not interest me.

On Sun, Jan 8, 2012 at 03:45, Campbell Barton wrote:
> On Sun, Jan 8, 2012 at 12:03 AM, skoti  wrote:
>> I know Collada importer / exporter is problematic (I wrote an importer
>> for my engine and I know that everything in the Collada can be stored in
>> N different ways).
>>
>> - If you want to use the model in Second Life / Google Earth, you have
>> to use Collada, if you want to use models in engines WebGL/Flash3D
>> practically have to use Collada (is there any web engine with FBX
>> importer?), Most game engines use Collada for importing data (support
>> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
>> blender, but it is not usually an option for people using Collada.
> Can you report these bugs please?
>
> I'm no great fan of FBX/Autodesk with their idiotic EULA, but as
> maintainer of FBX export I rather not have it be buggy.
>
> Note that FBX has similar issues as collada, which is that different
> applications support different parts of the FBX spec - so Lightwave
> and Maya for example complain when importing non uniform scaled bones
> from blender for EG because they don't support it.
> So you cant assume just because a single application chokes on a
> blender FBX model that it is a blender bug for sure.
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[François T .]

I'm probably a bit too late for the fight and tried to read all the thread
for this (there is several email with different subjects).
I do understand the complexity with collada, and yet I don't understand all
the issue you mention, but i'll trust you for this. Two years ago I wrote a
simple LUA DAE importer with my two cents of programming knowledge for a
propriatry engine we had in my company. I did it myself because the
engineer who did it in C was having somehow same troubles as you guys seems
to have with openCollada (yet I don't knwo OC at all). And his importer was
doing a terrible job.
I had nothing to do with complex bones or amarture so I wouldn't know about
that. But my simple LUA importer were dealing with scene, camera, lights,
obj, mesh, uv, material and textures and I it was tested with Blender
exporter at the time which was a python script, Max, XSI and Maya and
worked fine in all the cases, so I don't get the issue with vertices order
or whatever (or maybe I just not remember).
I couldn't wrote stuff in C and was only scripting in LUA at the time, so
it was easy for me to write a parser. I think the engineer fail to
understand the basics of the collada structure at first, and since I
couldn't do any C, all his code was useless to me and couldn't change or
enhance it as I wished.
And I also know that collada is so flexible that so many software insert
there own technics and not always the right way. But I think that if this
I/O was pure blender python based code (no dependencies, no external code),
more people (like me) would be able to develop or provide patches rather
than C which is only for a certain elite.
I remember asking at the time why doing this I/O with C in the first place,
I can't remember the reason exactly.

Anyway w/o collada (even though its not working as good as we wish right
now) Blender will get some doors closed to interoperate with other
software, and I know I'm probably the only one in the community who like
that, but its true.
3DS ... :/  obj ... very limited... FBX, great format for sure (even
 though I'm not a big fan of it, but the industry love it) we only have
output with it ! no import and eula issue with it as Campbell said... I
have read Alembic somewhere in this thread mention by someone I can't
remember the name. I want to remind him this is a bake  I/O format, no
edition possible afterwards
So question is : if we take of collada, what other better I & O format do
we have instead ?

so +1000 for a python, dependency less from scratch... one feature at the
time with clear, simple and well commented code ! I'm sure many people will
be able to help in the community. But until we have a I/O addon working for
basic features as a complete scene (no animation, no bones, no morph),
please pretty please keep it :/

F.

2012/1/8 skoti 

> Unfortunately I can not - I tested a month ago one scene and a file
> exported from Blender to 3ds max (reference implementation) and showed
> errors. I no longer have either the file or scene, and detailed
> information is not checked, because the FBX does not interest me.
>
> On Sun, Jan 8, 2012 at 03:45, Campbell Barton wrote:
> > On Sun, Jan 8, 2012 at 12:03 AM, skoti  wrote:
> >> I know Collada importer / exporter is problematic (I wrote an importer
> >> for my engine and I know that everything in the Collada can be stored in
> >> N different ways).
> >>
> >> - If you want to use the model in Second Life / Google Earth, you have
> >> to use Collada, if you want to use models in engines WebGL/Flash3D
> >> practically have to use Collada (is there any web engine with FBX
> >> importer?), Most game engines use Collada for importing data (support
> >> for FBX a few). FBX exporter also has bugs. Well, that FBX is in a
> >> blender, but it is not usually an option for people using Collada.
> > Can you report these bugs please?
> >
> > I'm no great fan of FBX/Autodesk with their idiotic EULA, but as
> > maintainer of FBX export I rather not have it be buggy.
> >
> > Note that FBX has similar issues as collada, which is that different
> > applications support different parts of the FBX spec - so Lightwave
> > and Maya for example complain when importing non uniform scaled bones
> > from blender for EG because they don't support it.
> > So you cant assume just because a single application chokes on a
> > blender FBX model that it is a blender bug for sure.
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 

François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

>
>
>
> so +1000 for a python, dependency less from scratch... one feature at the
> time with clear, simple and well commented code ! I'm sure many people will
> be able to help in the community. But until we have a I/O addon working for
> basic features as a complete scene (no animation, no bones, no morph),
> please pretty please keep it :/
>
>
You must have missed my post, that's exactly what i submitted to this
mailing list, except it supports all but morph.

Juan
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[angjminer]

Quoting Juan Linietsky :
> >
> >
> >
> > so +1000 for a python, dependency less from scratch... one feature at the
> > time with clear, simple and well commented code ! I'm sure many people will
> > be able to help in the community. But until we have a I/O addon working for
> > basic features as a complete scene (no animation, no bones, no morph),
> > please pretty please keep it :/
> >
> >
> You must have missed my post, that's exactly what i submitted to this
> mailing list, except it supports all but morph. 
>
> Juan
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
but as it is right now it does support animations, in my opinion(which 
i know doesn't amount to much right now) we need an equivalent to start 
with before it gets tore out. i agree it needs to be python like the 
rest,but to rip it out now and (no offense Juan) replace it with 
something that requires more work just to bring it back up to where it 
is now would be silly imho. heck the whole reason for "cryblend"
is because it was easier to do it in c(not pretty, just easier) i 
should have animation clips working by this weekend

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

>
>
> but as it is right now it does support animations, in my opinion(which
> i know doesn't amount to much right now) we need an equivalent to start
> with before it gets tore out. i agree it needs to be python like the
> rest,but to rip it out now and (no offense Juan) replace it with
> something that requires more work just to bring it back up to where it
> is now would be silly imho.


I'm not sure what you mean, but just in case it was a typo, what i
submitted does support animations fine,
and even bakes IK and constraints when exporting (something the current one
using OC doesn't).
The only real missing thing in what I submitted is
1) Cleaning up the export options (enable/disable stuff)
2) Morphs
3) Optimizing keyframes, like the FBX exporter
4) Fixing a bug or two because It wasn't tested as widely, only in some
specific projects with some clients.

Other than that, it exports everything fine and is as small as it can get.
The reason why this exporter is not 100% nice and polished is because I
didn't write this for inclusion into Blender, I wrote it because I got
tired of waiting for the Collada exporter to actually work, so I made my
own in a weekend. I'm not interested in mantaining it for the Blender
community either (I don't have enough time), and I'm only submitting it now
because I see that after half a decade, Blender is still going nowhere in
the Collada support.
At this point, it seems to me that most of the Blender developers really
either don't care about ir or have more important things to do than
supporting an open export format.

So in short, I submitted code that works, and should be very easy to
mantain due to the compact size (it's MUCH simpler than the FBX exporter
and it exports about the same information). If you guys want to take it
over and integrate it into Blender, go ahead, else i'll keep mantaining it
for my  own purposes and according to the needs of my clients.
I appreciate enormously the work the community has put into Blender, but
this is as much as I can contribute back for now.

Cheers

Juan Linietsky
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

On Mon, Jan 9, 2012 at 2:16 PM, Juan Linietsky  wrote:
>>
>>
>> but as it is right now it does support animations, in my opinion(which
>> i know doesn't amount to much right now) we need an equivalent to start
>> with before it gets tore out. i agree it needs to be python like the
>> rest,but to rip it out now and (no offense Juan) replace it with
>> something that requires more work just to bring it back up to where it
>> is now would be silly imho.
>
>
> I'm not sure what you mean, but just in case it was a typo, what i
> submitted does support animations fine,
> and even bakes IK and constraints when exporting (something the current one
> using OC doesn't).
> The only real missing thing in what I submitted is
> 1) Cleaning up the export options (enable/disable stuff)
> 2) Morphs
> 3) Optimizing keyframes, like the FBX exporter
> 4) Fixing a bug or two because It wasn't tested as widely, only in some
> specific projects with some clients.
>
> Other than that, it exports everything fine and is as small as it can get.
> The reason why this exporter is not 100% nice and polished is because I
> didn't write this for inclusion into Blender, I wrote it because I got
> tired of waiting for the Collada exporter to actually work, so I made my
> own in a weekend. I'm not interested in mantaining it for the Blender
> community either (I don't have enough time), and I'm only submitting it now
> because I see that after half a decade, Blender is still going nowhere in
> the Collada support.
> At this point, it seems to me that most of the Blender developers really
> either don't care about ir or have more important things to do than
> supporting an open export format.
>
> So in short, I submitted code that works, and should be very easy to
> mantain due to the compact size (it's MUCH simpler than the FBX exporter
> and it exports about the same information). If you guys want to take it
> over and integrate it into Blender, go ahead, else i'll keep mantaining it
> for my  own purposes and according to the needs of my clients.
> I appreciate enormously the work the community has put into Blender, but
> this is as much as I can contribute back for now.
>
> Cheers
>
> Juan Linietsky

@Juan, even if your not especially interested to maintain for such a
wide variety of uses.
(since it seems your happy with a fixed set of features which is
understandable for a format with very broad spec).

perhaps you could committed this as an addon so others can use it
without having to manually download and install.

As the author you can accept/reject changes so it wont become
something too different from your original intentions.

Reason I suggest this is that I'd rather not have the script committed
and then you continue to maintain your own version - where both
scripts get out of sync, fixes not applied to both - its worth
avoiding a fork if we can.

The addon can start in `contrib` repository which is available when
`Testing` scripts are enabled.

What do you think?

-- 
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Campbell, I don't mind accepting patches or helping out people to work on
the plugin , but what I can't do is to promise spending much time adding
more features myself or upon request. I don't really know much about the
development process of Blender, so if you feel this will work then I'll
gladly do that. I am also fine doing bug fixes if there are issues reported
to me or even adding small features upon request. I just can't work a large
amount of time myself on this.

Cheers

Juan


On Mon, Jan 9, 2012 at 1:39 AM, Campbell Barton wrote:

> On Mon, Jan 9, 2012 at 2:16 PM, Juan Linietsky  wrote:
>
> @Juan, even if your not especially interested to maintain for such a
> wide variety of uses.
> (since it seems your happy with a fixed set of features which is
> understandable for a format with very broad spec).
>
> perhaps you could committed this as an addon so others can use it
> without having to manually download and install.
>
> As the author you can accept/reject changes so it wont become
> something too different from your original intentions.
>
> Reason I suggest this is that I'd rather not have the script committed
> and then you continue to maintain your own version - where both
> scripts get out of sync, fixes not applied to both - its worth
> avoiding a fork if we can.
>
> The addon can start in `contrib` repository which is available when
> `Testing` scripts are enabled.
>
> What do you think?
>
> --
> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Kalle-Samuli Riihikoski]

>
> I'm also ready to help by adding features. I'm not so good to start
> things, but when I see
>
how it's done then I should be able to add new features... Let's do this :)
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

Hi Juan,

theres nothing wrong with this - its basically what I do for FBX and a
few other formats - keep them running and try to fix bugs users
report.

You wont be expected to fix every bug either - for more simple scripts
like this often technical users provide patches too.

- Campbell

On Mon, Jan 9, 2012 at 4:37 PM, Juan Linietsky  wrote:
> Campbell, I don't mind accepting patches or helping out people to work on
> the plugin , but what I can't do is to promise spending much time adding
> more features myself or upon request. I don't really know much about the
> development process of Blender, so if you feel this will work then I'll
> gladly do that. I am also fine doing bug fixes if there are issues reported
> to me or even adding small features upon request. I just can't work a large
> amount of time myself on this.
>
> Cheers
>
> Juan
>
>
> On Mon, Jan 9, 2012 at 1:39 AM, Campbell Barton wrote:
>
>> On Mon, Jan 9, 2012 at 2:16 PM, Juan Linietsky  wrote:
>>
>> @Juan, even if your not especially interested to maintain for such a
>> wide variety of uses.
>> (since it seems your happy with a fixed set of features which is
>> understandable for a format with very broad spec).
>>
>> perhaps you could committed this as an addon so others can use it
>> without having to manually download and install.
>>
>> As the author you can accept/reject changes so it wont become
>> something too different from your original intentions.
>>
>> Reason I suggest this is that I'd rather not have the script committed
>> and then you continue to maintain your own version - where both
>> scripts get out of sync, fixes not applied to both - its worth
>> avoiding a fork if we can.
>>
>> The addon can start in `contrib` repository which is available when
>> `Testing` scripts are enabled.
>>
>> What do you think?
>>
>> --
>> - Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[François T .]

@Juan, Yes I saw your post, but didn't take a look at the script yet (slow
super mega crappy connection those days). But my point was to encourage
this axe with your script as a starting point or starting blank if it
needed but with the same philosophy . Keep it simple, no dependency, with
basic feature first.

@Campbell, that would be great to push it to contrib




2012/1/9 Campbell Barton 

> Hi Juan,
>
> theres nothing wrong with this - its basically what I do for FBX and a
> few other formats - keep them running and try to fix bugs users
> report.
>
> You wont be expected to fix every bug either - for more simple scripts
> like this often technical users provide patches too.
>
> - Campbell
>
> On Mon, Jan 9, 2012 at 4:37 PM, Juan Linietsky  wrote:
> > Campbell, I don't mind accepting patches or helping out people to work on
> > the plugin , but what I can't do is to promise spending much time adding
> > more features myself or upon request. I don't really know much about the
> > development process of Blender, so if you feel this will work then I'll
> > gladly do that. I am also fine doing bug fixes if there are issues
> reported
> > to me or even adding small features upon request. I just can't work a
> large
> > amount of time myself on this.
> >
> > Cheers
> >
> > Juan
> >
> >
> > On Mon, Jan 9, 2012 at 1:39 AM, Campbell Barton  >wrote:
> >
> >> On Mon, Jan 9, 2012 at 2:16 PM, Juan Linietsky 
> wrote:
> >>
> >> @Juan, even if your not especially interested to maintain for such a
> >> wide variety of uses.
> >> (since it seems your happy with a fixed set of features which is
> >> understandable for a format with very broad spec).
> >>
> >> perhaps you could committed this as an addon so others can use it
> >> without having to manually download and install.
> >>
> >> As the author you can accept/reject changes so it wont become
> >> something too different from your original intentions.
> >>
> >> Reason I suggest this is that I'd rather not have the script committed
> >> and then you continue to maintain your own version - where both
> >> scripts get out of sync, fixes not applied to both - its worth
> >> avoiding a fork if we can.
> >>
> >> The addon can start in `contrib` repository which is available when
> >> `Testing` scripts are enabled.
> >>
> >> What do you think?
> >>
> >> --
> >> - Campbell
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 

François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Ton Roosendaal]

Hi Juan,

We work here with a lot of volunteers, people who can only contribute a little 
bit of time.

What Campbell  mostly likes to see is you remaining to be involved, just keep 
using the code and when there's time check on changes or fixes by others. No 
obligations, no further commitments needed.

It does add the obligation for us (Blender team) to find a new 'owner' for your 
script who does take responsibility to keep it work. And document it :)

So; Collada users here, please check it the code and report back?

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 9 Jan, 2012, at 6:37, Juan Linietsky wrote:

> Campbell, I don't mind accepting patches or helping out people to work on
> the plugin , but what I can't do is to promise spending much time adding
> more features myself or upon request. I don't really know much about the
> development process of Blender, so if you feel this will work then I'll
> gladly do that. I am also fine doing bug fixes if there are issues reported
> to me or even adding small features upon request. I just can't work a large
> amount of time myself on this.
> 
> Cheers
> 
> Juan
> 
> 
> On Mon, Jan 9, 2012 at 1:39 AM, Campbell Barton wrote:
> 
>> On Mon, Jan 9, 2012 at 2:16 PM, Juan Linietsky  wrote:
>> 
>> @Juan, even if your not especially interested to maintain for such a
>> wide variety of uses.
>> (since it seems your happy with a fixed set of features which is
>> understandable for a format with very broad spec).
>> 
>> perhaps you could committed this as an addon so others can use it
>> without having to manually download and install.
>> 
>> As the author you can accept/reject changes so it wont become
>> something too different from your original intentions.
>> 
>> Reason I suggest this is that I'd rather not have the script committed
>> and then you continue to maintain your own version - where both
>> scripts get out of sync, fixes not applied to both - its worth
>> avoiding a fork if we can.
>> 
>> The addon can start in `contrib` repository which is available when
>> `Testing` scripts are enabled.
>> 
>> What do you think?
>> 
>> --
>> - Campbell
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>> 
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Sebastian]

Hi,

that would be the third try to have COLLADA tools available for Blender. 
Beside the technical implementation details (Python, OC Library, Python 
again) I suspect the major problem is and was the missing maintainer for 
these converters.

Having a scripted exporter is easy to write, I agree. But OpenCOLLADA is 
only 5% about exporting and 95% about importing files into DCC tools. I 
do not expect a <1k LOC Python script to successful import any DAE files...

Perhaps a solution that is based upon Erwin's idea of using blend and 
having a standalone converter from DAE to blend and vice versa could be 
a valid possibility to separate the DAE capabilities from the trunk and 
not to completely abandon DAE support at all.

Sebastian



On 09.01.2012 11:43, Ton Roosendaal wrote:
> Hi Juan,
>
> We work here with a lot of volunteers, people who can only contribute a 
> little bit of time.
>
> What Campbell  mostly likes to see is you remaining to be involved, just keep 
> using the code and when there's time check on changes or fixes by others. No 
> obligations, no further commitments needed.
>
> It does add the obligation for us (Blender team) to find a new 'owner' for 
> your script who does take responsibility to keep it work. And document it :)
>
> So; Collada users here, please check it the code and report back?
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 9 Jan, 2012, at 6:37, Juan Linietsky wrote:
>
>> Campbell, I don't mind accepting patches or helping out people to work on
>> the plugin , but what I can't do is to promise spending much time adding
>> more features myself or upon request. I don't really know much about the
>> development process of Blender, so if you feel this will work then I'll
>> gladly do that. I am also fine doing bug fixes if there are issues reported
>> to me or even adding small features upon request. I just can't work a large
>> amount of time myself on this.
>>
>> Cheers
>>
>> Juan
>>
>>
>> On Mon, Jan 9, 2012 at 1:39 AM, Campbell Bartonwrote:
>>
>>> On Mon, Jan 9, 2012 at 2:16 PM, Juan Linietsky  wrote:
>>>
>>> @Juan, even if your not especially interested to maintain for such a
>>> wide variety of uses.
>>> (since it seems your happy with a fixed set of features which is
>>> understandable for a format with very broad spec).
>>>
>>> perhaps you could committed this as an addon so others can use it
>>> without having to manually download and install.
>>>
>>> As the author you can accept/reject changes so it wont become
>>> something too different from your original intentions.
>>>
>>> Reason I suggest this is that I'd rather not have the script committed
>>> and then you continue to maintain your own version - where both
>>> scripts get out of sync, fixes not applied to both - its worth
>>> avoiding a fork if we can.
>>>
>>> The addon can start in `contrib` repository which is available when
>>> `Testing` scripts are enabled.
>>>
>>> What do you think?
>>>
>>> --
>>> - Campbell
>>> ___
>>> Bf-committers mailing list
>>> Bf-committers@blender.org
>>> http://lists.blender.org/mailman/listinfo/bf-committers
>>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Domino Marama]

On Mon, 2012-01-09 at 11:43 +0100, Ton Roosendaal wrote about Juan's
script:
> So; Collada users here, please check it the code and report back?

As it is at the moment, I found it too buggy to use. It doesn't handle
parented objects well at all. My most basic test is a chain of 3
empties, translated and rotated. All 3 imported back at 0,0,0 and the
child ones have the wrong rotations.

I had a quick look at the code, and decided it was overly simplistic and
wouldn't handle a lot of valid cases correctly. A mesh shared between
two objects for example, I think would end up stored as two meshes
rather than one with multiple links to it.

Given how spectacularly it failed on the tests I threw at it, I went
back to coding on my own exporter which I started when you announced
your preference for dropping Collada. It only does cameras and empties
so far though, so it's not a viable alternative yet either :)


___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[François T .]

>
> I had a quick look at the code, and decided it was overly simplistic and
> wouldn't handle a lot of valid cases correctly. A mesh shared between
> two objects for example, I think would end up stored as two meshes
> rather than one with multiple links to it.
>

this is too bad because AFAIK collada is well designed to support
instances. Actually the entire design of it is based on that (or did
collada structure change so much since I looked into it a few years back.

 Having a scripted exporter is easy to write, I agree. But OpenCOLLADA is
> only 5% about exporting and 95% about importing files into DCC tools. I
> do not expect a <1k LOC Python script to successful import any DAE files...


maybe the importer should focus first on "well" exported collada ? again my
importer back then was a 2 cents one, but I was able to import (was only
working on importer at the time) scene, camera, mesh, material from maya,
max, xsi & blender without trouble. Maybe we were using a plugin for max I
can't remember, but I don't remember having special cases for one of the
program. I remember Max was using a lot of "technics" node for specific
feature which yes I was not supporting but is that really a priority ?
It was probably not coded the smart way or the most optimized way, but by
importing first all library and relinking all dependencies together then...
it wasn't much of an effort though.
But again since my importer was so simple and didn't import everything,
there is probably cases I never met. Is there a doc somewhere which defines
all those "exceptions" ?


cheers,

F.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Peter Amstutz]

This is great news!  I've reported bugs in OpenCOLLADA myself that I 
would have fixed but could not due to the lack of code generation tools.

Here's a thought, could these tools be used to generate a Blender Python 
API for OpenCOLLADA, then the data conversion for import/export (which 
is really the hard part) could be a Python add-on?

On 1/7/2012 4:22 PM, Sebastian wrote:
> Erwin already announced it: I've contributed the code generation
> libraries under the MIT license and committed it to our Subversion
> repository.
>
> You should see this as our commitment to the future of OpenCOLLADA.
> OpenCOLLADA is and was a lot of work, it's far away from being perfect
> or even error free but I would not suggest to develop yet another DAE
> importer/exporter specifically for Blender or even drop support for it.
> For the COLLADA community Blender is definitely one of the most
> important stakeholders to stop supporting COLLADA would make things in
> DCC exchange even worse.
>
> We are currently discussing further financing of OpenCOLLADA and will
> spend more time the next months on bugfixing and conformance tests.
>
> Sebastian
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Domino Marama]

On Mon, 2012-01-09 at 14:30 +0100, François T. wrote:
> I had a quick look at the code, and decided it was overly
> simplistic and
> wouldn't handle a lot of valid cases correctly. A mesh shared
> between
> two objects for example, I think would end up stored as two
> meshes
> rather than one with multiple links to it.
> 
> 
> this is too bad because AFAIK collada is well designed to support
> instances. Actually the entire design of it is based on that (or did
> collada structure change so much since I looked into it a few years
> back. 

I double checked and it does do shared meshes.. So either I'm
misremembering the problem, or was just mistaken.. I've 4 different
Collada exporters installed for testing so I might be getting their
various issues mixed up.

Sorry for any confusion..



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

The exporter i submitted handles both parented objects and shared meshes
between instances.
If you have testcases where this doesn't work, send them over and i'll see
what is wrong.

Juan


 here, please check it the code and report back?
>
> As it is at the moment, I found it too buggy to use. It doesn't handle
> parented objects well at all. My most basic test is a chain of 3
> empties, translated and rotated. All 3 imported back at 0,0,0 and the
> child ones have the wrong rotations.
>
> I had a quick look at the code, and decided it was overly simplistic and
> wouldn't handle a lot of valid cases correctly. A mesh shared between
> two objects for example, I think would end up stored as two meshes
> rather than one with multiple links to it.
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Sebastian]

That would be *lots* of work. OC is never meant as a simple standalone 
API but more a library to statically link against. There is no simple 
"C" like api but relies on the same memory allocators etc.

If you want to use Python don't stick with OpenCOLLADA ;)



On 09.01.2012 14:38, Peter Amstutz wrote:
> This is great news!  I've reported bugs in OpenCOLLADA myself that I
> would have fixed but could not due to the lack of code generation tools.
>
> Here's a thought, could these tools be used to generate a Blender Python
> API for OpenCOLLADA, then the data conversion for import/export (which
> is really the hard part) could be a Python add-on?
>
> On 1/7/2012 4:22 PM, Sebastian wrote:
>> Erwin already announced it: I've contributed the code generation
>> libraries under the MIT license and committed it to our Subversion
>> repository.
>>
>> You should see this as our commitment to the future of OpenCOLLADA.
>> OpenCOLLADA is and was a lot of work, it's far away from being perfect
>> or even error free but I would not suggest to develop yet another DAE
>> importer/exporter specifically for Blender or even drop support for it.
>> For the COLLADA community Blender is definitely one of the most
>> important stakeholders to stop supporting COLLADA would make things in
>> DCC exchange even worse.
>>
>> We are currently discussing further financing of OpenCOLLADA and will
>> spend more time the next months on bugfixing and conformance tests.
>>
>> Sebastian
>>
>>
>>
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Domino Marama]

On Mon, 2012-01-09 at 11:07 -0300, Juan Linietsky wrote:
> 
> The exporter i submitted handles both parented objects and shared
> meshes between instances.
> If you have testcases where this doesn't work, send them over and i'll
> see what is wrong.

I've had a look at the code, and it's a simple fix.. The matrix should
come before the node..

*** export_dae_orig.py  2011-10-12 08:33:39.0 +0100
--- export_dae.py   2012-01-09 15:23:21.639603139 +
*** class DaeExporter:
*** 755 
--- 756 
+ self.writel(S_NODES,il,''+strmtx(node.matrix_local)+'')
*** class DaeExporter:
*** 759 
- self.writel(S_NODES,il,''+strmtx(node.matrix_local)+'')
--- 759 

Best Wishes,
Domino



___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Sebastian]

COLLADA has a great conformance test suite at 
http://www.khronos.org/conformance/implementers/collada/

It's being made available for free and I've already seen Blender results 
uploaded some time ago.



On 09.01.2012 23:52, spatial wrote:
>> For the COLLADA community Blender is definitely one of the most
>> important stakeholders to stop supporting COLLADA would make things in
>> DCC exchange even worse.
> I agree. Not to mention all those who co use it alongside LW , all of
> DAZ productsetc.
>
> I actually tried to avoid a discussion here since a long time,
> but topic is too important.
>
> First, kicking out collada from blender doesn't help anyone. None of the
> "common" interexchange formats is that reliable / support all features.
> To have at least a second format as a backup strategy,  if a certain
> features arent't supported / have some unreliable results, is a "must
> have" in every cross application enviroment.
>
> And btw, blenders FBX import is, from my experience, still not as
> reliable as it should be, to actually replace collada. (sorry, this is
> no actual bashing... its already great what has been archived...
> especially if you consider that it is allways pain in the ass, to
> support such a complex exchange format)
>
>> We are currently discussing further financing of OpenCOLLADA and will
>> spend more time the next months on bugfixing and conformance tests.
>>
> Sorry to say this, but this is one of the mayor reasons I have to post this:
>
> Conformance tests do only help a little to 0
> The big _advantage_ fbx has, is a working reference application called maya.
>
> No conformance test can actually be that foolproof to support all
> features and variations. So by this simple unoffical agreement,"if it
> doesn't work in maya - it is broken", users and developers have an ideal
> platform to discuss errors / find workarounds.  This greatly avoids the
> "picking in the dark" situation all developers currently face with
> collada. Even if a dev doesn't have access to it, in a lot of cases, he
> can track down problems reported by users who do provide a simple
> screenshot.
>
> Could this collada reference application be Blender ?
> For me this is a very attractive idea, but also, I'm very aware of the fact,
> that I'm opening a can of worms I'm actually in no way in the right
> position to touch.
>
> Anyway just my 2 cents on this.
> chris
>
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Antony Riakiotakis]

Can you share link? It's funny because on the conformant products page
there's actually one product. Yep, that's right. Just one:

http://www.khronos.org/conformance/adopters/conformant-products

check the Collada tab
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

On Tue, Jan 10, 2012 at 9:52 AM, spatial  wrote:
>
> > For the COLLADA community Blender is definitely one of the most
> > important stakeholders to stop supporting COLLADA would make things in
> > DCC exchange even worse.
> I agree. Not to mention all those who co use it alongside LW , all of
> DAZ productsetc.
>
> I actually tried to avoid a discussion here since a long time,
> but topic is too important.
>
> First, kicking out collada from blender doesn't help anyone. None of the
> "common" interexchange formats is that reliable / support all features.
> To have at least a second format as a backup strategy,  if a certain
> features arent't supported / have some unreliable results, is a "must
> have" in every cross application enviroment.

Its frustrating that a lot of this discussion seems to revolve around
possible solutions for _other_ people to work on which blender
_should_ support.
We already tried to support collada and pretty much failed by the looks of it.

Kicking out collada helps because it means we don't give users a
barely working feature they report bugs about that we can't fix. It
helps not to give users crappy software. no?

It also helps to move into a branch that motivated people can work on
- so this feature can reach some level of quality before moving back
into trunk.

> And btw, blenders FBX import is, from my experience, still not as
> reliable as it should be, to actually replace collada. (sorry, this is
> no actual bashing... its already great what has been archived...
> especially if you consider that it is allways pain in the ass, to
> support such a complex exchange format)

again, would be nice to hear some example, even anecdotal as to what
isn't working in FBX (assume you mean exporter since we don't have a
stable importer).

> > We are currently discussing further financing of OpenCOLLADA and will
> > spend more time the next months on bugfixing and conformance tests.
> >
> Sorry to say this, but this is one of the mayor reasons I have to post this:
>
> Conformance tests do only help a little to 0
> The big _advantage_ fbx has, is a working reference application called maya.

FBX was written for Kaydara Motionbuilder, which I used as a
reference, Maya support was added later and it still doesn't support
all Motionbuilder's rigging options last I tested.
There are files written out of blender which work in Motionbuilder and
not correctly in Maya.

> No conformance test can actually be that foolproof to support all
> features and variations. So by this simple unoffical agreement,"if it
> doesn't work in maya - it is broken", users and developers have an ideal
> platform to discuss errors / find workarounds.  This greatly avoids the
> "picking in the dark" situation all developers currently face with
> collada. Even if a dev doesn't have access to it, in a lot of cases, he
> can track down problems reported by users who do provide a simple
> screenshot.
>
> Could this collada reference application be Blender ?
> For me this is a very attractive idea, but also, I'm very aware of the fact,
> that I'm opening a can of worms I'm actually in no way in the right
> position to touch.

its possible, but at some point we need to follow a spec that works
elsewhere for it to be useful.
Otherwise having overly specific blender/collada format runs the risk
of nobody adopting it and looses a lot of blender developer time.

> Anyway just my 2 cents on this.
> chris
>
>
>
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers




--
- Campbell
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Campbell Barton]

On Tue, Jan 10, 2012 at 10:38 AM, Campbell Barton  wrote:
>
> On Tue, Jan 10, 2012 at 9:52 AM, spatial  wrote:
> >
> > > For the COLLADA community Blender is definitely one of the most
> > > important stakeholders to stop supporting COLLADA would make things in
> > > DCC exchange even worse.
> > I agree. Not to mention all those who co use it alongside LW , all of
> > DAZ productsetc.
> >
> > I actually tried to avoid a discussion here since a long time,
> > but topic is too important.
> >
> > First, kicking out collada from blender doesn't help anyone. None of the
> > "common" interexchange formats is that reliable / support all features.
> > To have at least a second format as a backup strategy,  if a certain
> > features arent't supported / have some unreliable results, is a "must
> > have" in every cross application enviroment.
>
> Its frustrating that a lot of this discussion seems to revolve around
> possible solutions for _other_ people to work on which blender
> _should_ support.
> We already tried to support collada and pretty much failed by the looks of it.

*cough* this point was poorly made.

There are of course many possible ways to write good format support
into blender, and discussing implementations is fine, its just that we
need people to invest time working on it.

To say an interchange format (like collada) is a "Must have" is all
very well, but is there evidence collada can do this?

Is anyone using collada successfully for interchange character
animations between content creation applications?
(not export to game engine but actually move mesh+rig data between
apps for further editing).

My impression is this is not well supported elsewhere. I didn't see
comments like...
-- "my animations export from Maya to C4D really well, why cant
blender do this?".


Reading this list it seems collada has real problems being overly
broad spec - to work on collada would take existing devs time away
from projects they work on to support a spec which is questionable if
we can even support well.
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Ton Roosendaal]

Hi,

The Collada conformance suite is not working, and working on it won't help 
anything.
I wrote about this here;
http://code.blender.org/index.php/2011/10/collada-momentum/

Collada just has no reference stakeholder(s) (like how fbx was native for 
motionbuilder).
Blender would be the worst stakeholder for it even, since we have the awesome 
.blend :)

Much better stakeholders would be Linden Labs (2nd life), or CryTek... or Daz? 
Three names of companies who make plenty of dollars with software licensing. 
Why don't they put an employee as developer in our team, to ensure Collada 
exports smoothly for their products?

I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada, 
2ndLifeCollada, etc. It's how collada has been designed to work anyway...

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 10 Jan, 2012, at 0:25, Sebastian wrote:

> COLLADA has a great conformance test suite at 
> http://www.khronos.org/conformance/implementers/collada/
> 
> It's being made available for free and I've already seen Blender results 
> uploaded some time ago.
> 
> 
> 
> On 09.01.2012 23:52, spatial wrote:
>>> For the COLLADA community Blender is definitely one of the most
>>> important stakeholders to stop supporting COLLADA would make things in
>>> DCC exchange even worse.
>> I agree. Not to mention all those who co use it alongside LW , all of
>> DAZ productsetc.
>> 
>> I actually tried to avoid a discussion here since a long time,
>> but topic is too important.
>> 
>> First, kicking out collada from blender doesn't help anyone. None of the
>> "common" interexchange formats is that reliable / support all features.
>> To have at least a second format as a backup strategy,  if a certain
>> features arent't supported / have some unreliable results, is a "must
>> have" in every cross application enviroment.
>> 
>> And btw, blenders FBX import is, from my experience, still not as
>> reliable as it should be, to actually replace collada. (sorry, this is
>> no actual bashing... its already great what has been archived...
>> especially if you consider that it is allways pain in the ass, to
>> support such a complex exchange format)
>> 
>>> We are currently discussing further financing of OpenCOLLADA and will
>>> spend more time the next months on bugfixing and conformance tests.
>>> 
>> Sorry to say this, but this is one of the mayor reasons I have to post this:
>> 
>> Conformance tests do only help a little to 0
>> The big _advantage_ fbx has, is a working reference application called maya.
>> 
>> No conformance test can actually be that foolproof to support all
>> features and variations. So by this simple unoffical agreement,"if it
>> doesn't work in maya - it is broken", users and developers have an ideal
>> platform to discuss errors / find workarounds.  This greatly avoids the
>> "picking in the dark" situation all developers currently face with
>> collada. Even if a dev doesn't have access to it, in a lot of cases, he
>> can track down problems reported by users who do provide a simple
>> screenshot.
>> 
>> Could this collada reference application be Blender ?
>> For me this is a very attractive idea, but also, I'm very aware of the fact,
>> that I'm opening a can of worms I'm actually in no way in the right
>> position to touch.
>> 
>> Anyway just my 2 cents on this.
>> chris
>> 
>> 
>> 
>> 
>> ___
>> Bf-committers mailing list
>> Bf-committers@blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[johannes amorosa]

Offtopic: How far is Alembic support in Blender? (I apologize I don't wan't
to start a flame war)
johannes

On 10 January 2012 11:15, Ton Roosendaal  wrote:

> Hi,
>
> The Collada conformance suite is not working, and working on it won't help
> anything.
> I wrote about this here;
> http://code.blender.org/index.php/2011/10/collada-momentum/
>
> Collada just has no reference stakeholder(s) (like how fbx was native for
> motionbuilder).
> Blender would be the worst stakeholder for it even, since we have the
> awesome .blend :)
>
> Much better stakeholders would be Linden Labs (2nd life), or CryTek... or
> Daz? Three names of companies who make plenty of dollars with software
> licensing. Why don't they put an employee as developer in our team, to
> ensure Collada exports smoothly for their products?
>
> I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 10 Jan, 2012, at 0:25, Sebastian wrote:
>
> > COLLADA has a great conformance test suite at
> > http://www.khronos.org/conformance/implementers/collada/
> >
> > It's being made available for free and I've already seen Blender results
> > uploaded some time ago.
> >
> >
> >
> > On 09.01.2012 23:52, spatial wrote:
> >>> For the COLLADA community Blender is definitely one of the most
> >>> important stakeholders to stop supporting COLLADA would make things in
> >>> DCC exchange even worse.
> >> I agree. Not to mention all those who co use it alongside LW , all of
> >> DAZ productsetc.
> >>
> >> I actually tried to avoid a discussion here since a long time,
> >> but topic is too important.
> >>
> >> First, kicking out collada from blender doesn't help anyone. None of the
> >> "common" interexchange formats is that reliable / support all features.
> >> To have at least a second format as a backup strategy,  if a certain
> >> features arent't supported / have some unreliable results, is a "must
> >> have" in every cross application enviroment.
> >>
> >> And btw, blenders FBX import is, from my experience, still not as
> >> reliable as it should be, to actually replace collada. (sorry, this is
> >> no actual bashing... its already great what has been archived...
> >> especially if you consider that it is allways pain in the ass, to
> >> support such a complex exchange format)
> >>
> >>> We are currently discussing further financing of OpenCOLLADA and will
> >>> spend more time the next months on bugfixing and conformance tests.
> >>>
> >> Sorry to say this, but this is one of the mayor reasons I have to post
> this:
> >>
> >> Conformance tests do only help a little to 0
> >> The big _advantage_ fbx has, is a working reference application called
> maya.
> >>
> >> No conformance test can actually be that foolproof to support all
> >> features and variations. So by this simple unoffical agreement,"if it
> >> doesn't work in maya - it is broken", users and developers have an ideal
> >> platform to discuss errors / find workarounds.  This greatly avoids the
> >> "picking in the dark" situation all developers currently face with
> >> collada. Even if a dev doesn't have access to it, in a lot of cases, he
> >> can track down problems reported by users who do provide a simple
> >> screenshot.
> >>
> >> Could this collada reference application be Blender ?
> >> For me this is a very attractive idea, but also, I'm very aware of the
> fact,
> >> that I'm opening a can of worms I'm actually in no way in the right
> >> position to touch.
> >>
> >> Anyway just my 2 cents on this.
> >> chris
> >>
> >>
> >>
> >>
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
++
johannes amorosa
twitter: jamorosa
http://iamnotamus.de
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[François T .]

exactly it is off topic.
There is no comparaison to collada or fbx or whatover format which are
still editable after import/export.
Alembic is a BAKE format and will never be a replacement to other above
mention cross platform exchange format. Yet I can see is importance, but
don't have any place in this discussion AFAIK.



2012/1/10 johannes amorosa 

> Offtopic: How far is Alembic support in Blender? (I apologize I don't wan't
> to start a flame war)
> johannes
>
> On 10 January 2012 11:15, Ton Roosendaal  wrote:
>
> > Hi,
> >
> > The Collada conformance suite is not working, and working on it won't
> help
> > anything.
> > I wrote about this here;
> > http://code.blender.org/index.php/2011/10/collada-momentum/
> >
> > Collada just has no reference stakeholder(s) (like how fbx was native for
> > motionbuilder).
> > Blender would be the worst stakeholder for it even, since we have the
> > awesome .blend :)
> >
> > Much better stakeholders would be Linden Labs (2nd life), or CryTek... or
> > Daz? Three names of companies who make plenty of dollars with software
> > licensing. Why don't they put an employee as developer in our team, to
> > ensure Collada exports smoothly for their products?
> >
> > I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> > 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > On 10 Jan, 2012, at 0:25, Sebastian wrote:
> >
> > > COLLADA has a great conformance test suite at
> > > http://www.khronos.org/conformance/implementers/collada/
> > >
> > > It's being made available for free and I've already seen Blender
> results
> > > uploaded some time ago.
> > >
> > >
> > >
> > > On 09.01.2012 23:52, spatial wrote:
> > >>> For the COLLADA community Blender is definitely one of the most
> > >>> important stakeholders to stop supporting COLLADA would make things
> in
> > >>> DCC exchange even worse.
> > >> I agree. Not to mention all those who co use it alongside LW , all of
> > >> DAZ productsetc.
> > >>
> > >> I actually tried to avoid a discussion here since a long time,
> > >> but topic is too important.
> > >>
> > >> First, kicking out collada from blender doesn't help anyone. None of
> the
> > >> "common" interexchange formats is that reliable / support all
> features.
> > >> To have at least a second format as a backup strategy,  if a certain
> > >> features arent't supported / have some unreliable results, is a "must
> > >> have" in every cross application enviroment.
> > >>
> > >> And btw, blenders FBX import is, from my experience, still not as
> > >> reliable as it should be, to actually replace collada. (sorry, this is
> > >> no actual bashing... its already great what has been archived...
> > >> especially if you consider that it is allways pain in the ass, to
> > >> support such a complex exchange format)
> > >>
> > >>> We are currently discussing further financing of OpenCOLLADA and will
> > >>> spend more time the next months on bugfixing and conformance tests.
> > >>>
> > >> Sorry to say this, but this is one of the mayor reasons I have to post
> > this:
> > >>
> > >> Conformance tests do only help a little to 0
> > >> The big _advantage_ fbx has, is a working reference application called
> > maya.
> > >>
> > >> No conformance test can actually be that foolproof to support all
> > >> features and variations. So by this simple unoffical agreement,"if it
> > >> doesn't work in maya - it is broken", users and developers have an
> ideal
> > >> platform to discuss errors / find workarounds.  This greatly avoids
> the
> > >> "picking in the dark" situation all developers currently face with
> > >> collada. Even if a dev doesn't have access to it, in a lot of cases,
> he
> > >> can track down problems reported by users who do provide a simple
> > >> screenshot.
> > >>
> > >> Could this collada reference application be Blender ?
> > >> For me this is a very attractive idea, but also, I'm very aware of the
> > fact,
> > >> that I'm opening a can of worms I'm actually in no way in the right
> > >> position to touch.
> > >>
> > >> Anyway just my 2 cents on this.
> > >> chris
> > >>
> > >>
> > >>
> > >>
> > >> ___
> > >> Bf-committers mailing list
> > >> Bf-committers@blender.org
> > >> http://lists.blender.org/mailman/listinfo/bf-committers
> > > ___
> > > Bf-committers mailing list
> > > Bf-committers@blender.org
> > > http://lists.blender.org/mailman/listinfo/bf-committers
> >
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
> >
>
>
>
> --
> ++
> johannes amoros

Re: [Bf-committers] Collada importer/exporter kickout

[Erwin Coumans]

Until Blender has good fbx import or an alternative collada import
(python?) it would be good to postpone dropping OpenCollada.

>From the feedback, some people are using the import feature, and there is
no replacement.

Let's hope someone stands up and fixes the issues in trunk, rather then
branch.
 On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:

> Hi,
>
> The Collada conformance suite is not working, and working on it won't help
> anything.
> I wrote about this here;
> http://code.blender.org/index.php/2011/10/collada-momentum/
>
> Collada just has no reference stakeholder(s) (like how fbx was native for
> motionbuilder).
> Blender would be the worst stakeholder for it even, since we have the
> awesome .blend :)
>
> Much better stakeholders would be Linden Labs (2nd life), or CryTek... or
> Daz? Three names of companies who make plenty of dollars with software
> licensing. Why don't they put an employee as developer in our team, to
> ensure Collada exports smoothly for their products?
>
> I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 10 Jan, 2012, at 0:25, Sebastian wrote:
>
> > COLLADA has a great conformance test suite at
> > http://www.khronos.org/conformance/implementers/collada/
> >
> > It's being made available for free and I've already seen Blender results
> > uploaded some time ago.
> >
> >
> >
> > On 09.01.2012 23:52, spatial wrote:
> >>> For the COLLADA community Blender is definitely one of the most
> >>> important stakeholders to stop supporting COLLADA would make things in
> >>> DCC exchange even worse.
> >> I agree. Not to mention all those who co use it alongside LW , all of
> >> DAZ productsetc.
> >>
> >> I actually tried to avoid a discussion here since a long time,
> >> but topic is too important.
> >>
> >> First, kicking out collada from blender doesn't help anyone. None of the
> >> "common" interexchange formats is that reliable / support all features.
> >> To have at least a second format as a backup strategy,  if a certain
> >> features arent't supported / have some unreliable results, is a "must
> >> have" in every cross application enviroment.
> >>
> >> And btw, blenders FBX import is, from my experience, still not as
> >> reliable as it should be, to actually replace collada. (sorry, this is
> >> no actual bashing... its already great what has been archived...
> >> especially if you consider that it is allways pain in the ass, to
> >> support such a complex exchange format)
> >>
> >>> We are currently discussing further financing of OpenCOLLADA and will
> >>> spend more time the next months on bugfixing and conformance tests.
> >>>
> >> Sorry to say this, but this is one of the mayor reasons I have to post
> this:
> >>
> >> Conformance tests do only help a little to 0
> >> The big _advantage_ fbx has, is a working reference application called
> maya.
> >>
> >> No conformance test can actually be that foolproof to support all
> >> features and variations. So by this simple unoffical agreement,"if it
> >> doesn't work in maya - it is broken", users and developers have an ideal
> >> platform to discuss errors / find workarounds.  This greatly avoids the
> >> "picking in the dark" situation all developers currently face with
> >> collada. Even if a dev doesn't have access to it, in a lot of cases, he
> >> can track down problems reported by users who do provide a simple
> >> screenshot.
> >>
> >> Could this collada reference application be Blender ?
> >> For me this is a very attractive idea, but also, I'm very aware of the
> fact,
> >> that I'm opening a can of worms I'm actually in no way in the right
> >> position to touch.
> >>
> >> Anyway just my 2 cents on this.
> >> chris
> >>
> >>
> >>
> >>
> >> ___
> >> Bf-committers mailing list
> >> Bf-committers@blender.org
> >> http://lists.blender.org/mailman/listinfo/bf-committers
> > ___
> > Bf-committers mailing list
> > Bf-committers@blender.org
> > http://lists.blender.org/mailman/listinfo/bf-committers
>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Gaia Clary]

Hi, all.

While i believe that creating target dependent exporters/importers for 
Collada
make a lot of sense, i also believe in collaboration instead of 
separation :)
Wouldn't it be much more appealing to organize this as follows:
(i refer to a discussion on #blendercoders yesterday in IRC)

The idea is (independent on what basis it is implemented):

1.) Create a basic exporter/importer pair which works for blender
itself, is rock solid (exported objects/scenes/whatever will be reimported
without changes) and is eventually complete (regarding Blender)
I name this "Blender Collada" in the following.

2.) For each target system create an Exporter Blender2Target which does:

- call the Blender Collada exporter
- Applies a transform to the exported file.

A transform can be any program, maybe even an XSL transformation
which takes the given .dae and transforms it to another .dae which works
for the target system.

The Blender2Target modules should be addon modules for easy maintenance
by the responsible developers (target maintainers)


3.) For each Source system create an Importer Source2Blender which does:

- Applies a transform to the import file.
- call the Blender Collada Importer

A transform can be any program, maybe even an XSL transformation
which takes the given .dae and transforms it to another .dae which works
for Blender Collada.

The Source2Blender modules should be addon modules for easy maintenance
by the responsible developers (target maintainers)



For my understanding the benefits of doing it like proposed above are:

- Blender Collada can be done with Blender in Mind. No need to think
   about how other target systems might interpret the data. It should
   be enough to document, how Blender interprets it.
- Blender Collada can be created and tested by Blender developers/users
- .blend files can be created for testing export/reimport

- Blender2Target and Source2Blender transformers can be added by people
   who know what their target system needs. These addons are decoupled
   from the Blender Collada core and maintained by the specialists without
   interfering with possibly different needs for other target systems.



I also can not judge if the current Collada Implementation is close to a
"Blender Collada" or far away from that. Its still you developers who
decide what makes most sense. But i doubt it makes much sense to
create one complete Collada exporter for each target system.


So that was my one Euro and 2 cents on this topic :)
cheers,
Gaia

Am 10.01.2012 15:30, schrieb Erwin Coumans:
> Until Blender has good fbx import or an alternative collada import
> (python?) it would be good to postpone dropping OpenCollada.
>
> > From the feedback, some people are using the import feature, and there is
> no replacement.
>
> Let's hope someone stands up and fixes the issues in trunk, rather then
> branch.
>   On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
>
>> Hi,
>>
>> The Collada conformance suite is not working, and working on it won't help
>> anything.
>> I wrote about this here;
>> http://code.blender.org/index.php/2011/10/collada-momentum/
>>
>> Collada just has no reference stakeholder(s) (like how fbx was native for
>> motionbuilder).
>> Blender would be the worst stakeholder for it even, since we have the
>> awesome .blend :)
>>
>> Much better stakeholders would be Linden Labs (2nd life), or CryTek... or
>> Daz? Three names of companies who make plenty of dollars with software
>> licensing. Why don't they put an employee as developer in our team, to
>> ensure Collada exports smoothly for their products?
>>
>> I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
>> 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
>>
>> -Ton-
>>
>> 
>> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>>
>> On 10 Jan, 2012, at 0:25, Sebastian wrote:
>>
>>> COLLADA has a great conformance test suite at
>>> http://www.khronos.org/conformance/implementers/collada/
>>>
>>> It's being made available for free and I've already seen Blender results
>>> uploaded some time ago.
>>>
>>>
>>>
>>> On 09.01.2012 23:52, spatial wrote:
> For the COLLADA community Blender is definitely one of the most
> important stakeholders to stop supporting COLLADA would make things in
> DCC exchange even worse.
 I agree. Not to mention all those who co use it alongside LW , all of
 DAZ productsetc.

 I actually tried to avoid a discussion here since a long time,
 but topic is too important.

 First, kicking out collada from blender doesn't help anyone. None of the
 "common" interexchange formats is that reliable / support all features.
 To have at least a second format as a backup strategy,  if a certain
 features arent't supported / have some unrelia

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

I didn't realize a collada exporter was so important. If so..

I have a *very* *tested* and *very* *small* collada importer in my
middleware stuff (~3k lines of C++ code). It supports pretty much
everything (models, skeletons, materials, cameras, lights, morphs, any-axis
orientation, animations with matrices or curves, etc).

Given it's very small size and non-dependency on OC, it's very easy to
understand and *very easy to mantain*. It pretty much just ignores
conformance of input files and just attempts to grab wathever data it needs
so *compatibility is extremely high*.

It's not a standalone library, but it's separated enough that *if someone
knowledgable of blender internals *wants to give a try to adapting it to
blender (of course with me 100% available for answering questions with
this), i think in a matter of a few hours we can solve the Blender problem
of collada import support. However as I said in previous mails, I really
lack the time to get familiar with Blender internals and do this myself.

Cheers

Juan Linietsky


On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans wrote:

> Until Blender has good fbx import or an alternative collada import
> (python?) it would be good to postpone dropping OpenCollada.
>
> >From the feedback, some people are using the import feature, and there is
> no replacement.
>
> Let's hope someone stands up and fixes the issues in trunk, rather then
> branch.
>  On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
>
> > Hi,
> >
> > The Collada conformance suite is not working, and working on it won't
> help
> > anything.
> > I wrote about this here;
> > http://code.blender.org/index.php/2011/10/collada-momentum/
> >
> > Collada just has no reference stakeholder(s) (like how fbx was native for
> > motionbuilder).
> > Blender would be the worst stakeholder for it even, since we have the
> > awesome .blend :)
> >
> > Much better stakeholders would be Linden Labs (2nd life), or CryTek... or
> > Daz? Three names of companies who make plenty of dollars with software
> > licensing. Why don't they put an employee as developer in our team, to
> > ensure Collada exports smoothly for their products?
> >
> > I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> > 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > On 10 Jan, 2012, at 0:25, Sebastian wrote:
> >
> > > COLLADA has a great conformance test suite at
> > > http://www.khronos.org/conformance/implementers/collada/
> > >
> > > It's being made available for free and I've already seen Blender
> results
> > > uploaded some time ago.
> > >
> > >
> > >
> > > On 09.01.2012 23:52, spatial wrote:
> > >>> For the COLLADA community Blender is definitely one of the most
> > >>> important stakeholders to stop supporting COLLADA would make things
> in
> > >>> DCC exchange even worse.
> > >> I agree. Not to mention all those who co use it alongside LW , all of
> > >> DAZ productsetc.
> > >>
> > >> I actually tried to avoid a discussion here since a long time,
> > >> but topic is too important.
> > >>
> > >> First, kicking out collada from blender doesn't help anyone. None of
> the
> > >> "common" interexchange formats is that reliable / support all
> features.
> > >> To have at least a second format as a backup strategy,  if a certain
> > >> features arent't supported / have some unreliable results, is a "must
> > >> have" in every cross application enviroment.
> > >>
> > >> And btw, blenders FBX import is, from my experience, still not as
> > >> reliable as it should be, to actually replace collada. (sorry, this is
> > >> no actual bashing... its already great what has been archived...
> > >> especially if you consider that it is allways pain in the ass, to
> > >> support such a complex exchange format)
> > >>
> > >>> We are currently discussing further financing of OpenCOLLADA and will
> > >>> spend more time the next months on bugfixing and conformance tests.
> > >>>
> > >> Sorry to say this, but this is one of the mayor reasons I have to post
> > this:
> > >>
> > >> Conformance tests do only help a little to 0
> > >> The big _advantage_ fbx has, is a working reference application called
> > maya.
> > >>
> > >> No conformance test can actually be that foolproof to support all
> > >> features and variations. So by this simple unoffical agreement,"if it
> > >> doesn't work in maya - it is broken", users and developers have an
> ideal
> > >> platform to discuss errors / find workarounds.  This greatly avoids
> the
> > >> "picking in the dark" situation all developers currently face with
> > >> collada. Even if a dev doesn't have access to it, in a lot of cases,
> he
> > >> can track down problems reported by users who do provide a simple
> > >> 

Re: [Bf-committers] Collada importer/exporter kickout

[Daniel Salazar - 3Developer.com]

That sounds *very* exciting and *very* appropriate for our needs :) OC ads
too much weight to Blender's big ass

Daniel Salazar
3Developer.com


On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky  wrote:

> I didn't realize a collada exporter was so important. If so..
>
> I have a *very* *tested* and *very* *small* collada importer in my
> middleware stuff (~3k lines of C++ code). It supports pretty much
> everything (models, skeletons, materials, cameras, lights, morphs, any-axis
> orientation, animations with matrices or curves, etc).
>
> Given it's very small size and non-dependency on OC, it's very easy to
> understand and *very easy to mantain*. It pretty much just ignores
> conformance of input files and just attempts to grab wathever data it needs
> so *compatibility is extremely high*.
>
> It's not a standalone library, but it's separated enough that *if someone
> knowledgable of blender internals *wants to give a try to adapting it to
> blender (of course with me 100% available for answering questions with
> this), i think in a matter of a few hours we can solve the Blender problem
> of collada import support. However as I said in previous mails, I really
> lack the time to get familiar with Blender internals and do this myself.
>
> Cheers
>
> Juan Linietsky
>
>
> On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans  >wrote:
>
> > Until Blender has good fbx import or an alternative collada import
> > (python?) it would be good to postpone dropping OpenCollada.
> >
> > >From the feedback, some people are using the import feature, and there
> is
> > no replacement.
> >
> > Let's hope someone stands up and fixes the issues in trunk, rather then
> > branch.
> >  On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
> >
> > > Hi,
> > >
> > > The Collada conformance suite is not working, and working on it won't
> > help
> > > anything.
> > > I wrote about this here;
> > > http://code.blender.org/index.php/2011/10/collada-momentum/
> > >
> > > Collada just has no reference stakeholder(s) (like how fbx was native
> for
> > > motionbuilder).
> > > Blender would be the worst stakeholder for it even, since we have the
> > > awesome .blend :)
> > >
> > > Much better stakeholders would be Linden Labs (2nd life), or CryTek...
> or
> > > Daz? Three names of companies who make plenty of dollars with software
> > > licensing. Why don't they put an employee as developer in our team, to
> > > ensure Collada exports smoothly for their products?
> > >
> > > I even wouldn't mind a (python) addon "Export to DazCollada,
> CryCollada,
> > > 2ndLifeCollada, etc. It's how collada has been designed to work
> anyway...
> > >
> > > -Ton-
> > >
> > >
> 
> > > Ton Roosendaal  Blender Foundation   t...@blender.org
> www.blender.org
> > > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> > >
> > > On 10 Jan, 2012, at 0:25, Sebastian wrote:
> > >
> > > > COLLADA has a great conformance test suite at
> > > > http://www.khronos.org/conformance/implementers/collada/
> > > >
> > > > It's being made available for free and I've already seen Blender
> > results
> > > > uploaded some time ago.
> > > >
> > > >
> > > >
> > > > On 09.01.2012 23:52, spatial wrote:
> > > >>> For the COLLADA community Blender is definitely one of the most
> > > >>> important stakeholders to stop supporting COLLADA would make things
> > in
> > > >>> DCC exchange even worse.
> > > >> I agree. Not to mention all those who co use it alongside LW , all
> of
> > > >> DAZ productsetc.
> > > >>
> > > >> I actually tried to avoid a discussion here since a long time,
> > > >> but topic is too important.
> > > >>
> > > >> First, kicking out collada from blender doesn't help anyone. None of
> > the
> > > >> "common" interexchange formats is that reliable / support all
> > features.
> > > >> To have at least a second format as a backup strategy,  if a certain
> > > >> features arent't supported / have some unreliable results, is a
> "must
> > > >> have" in every cross application enviroment.
> > > >>
> > > >> And btw, blenders FBX import is, from my experience, still not as
> > > >> reliable as it should be, to actually replace collada. (sorry, this
> is
> > > >> no actual bashing... its already great what has been archived...
> > > >> especially if you consider that it is allways pain in the ass, to
> > > >> support such a complex exchange format)
> > > >>
> > > >>> We are currently discussing further financing of OpenCOLLADA and
> will
> > > >>> spend more time the next months on bugfixing and conformance tests.
> > > >>>
> > > >> Sorry to say this, but this is one of the mayor reasons I have to
> post
> > > this:
> > > >>
> > > >> Conformance tests do only help a little to 0
> > > >> The big _advantage_ fbx has, is a working reference application
> called
> > > maya.
> > > >>
> > > >> No conformance test can actually be that foolproof to support all
> > > >> features and variations. So

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Heh I wanted to emphasize that it works, but I seriously do need to work
with someone familiar with writing blender and/or blender import plugins in
C++ to do it, who can take my code and adapt it to Blender. It should be a
short task for someone with that experience.

Cheers

Juan


On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com <
zan...@gmail.com> wrote:

> That sounds *very* exciting and *very* appropriate for our needs :) OC ads
> too much weight to Blender's big ass
>
> Daniel Salazar
> 3Developer.com
>
>
> On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky  wrote:
>
> > I didn't realize a collada exporter was so important. If so..
> >
> > I have a *very* *tested* and *very* *small* collada importer in my
> > middleware stuff (~3k lines of C++ code). It supports pretty much
> > everything (models, skeletons, materials, cameras, lights, morphs,
> any-axis
> > orientation, animations with matrices or curves, etc).
> >
> > Given it's very small size and non-dependency on OC, it's very easy to
> > understand and *very easy to mantain*. It pretty much just ignores
> > conformance of input files and just attempts to grab wathever data it
> needs
> > so *compatibility is extremely high*.
> >
> > It's not a standalone library, but it's separated enough that *if someone
> > knowledgable of blender internals *wants to give a try to adapting it to
> > blender (of course with me 100% available for answering questions with
> > this), i think in a matter of a few hours we can solve the Blender
> problem
> > of collada import support. However as I said in previous mails, I really
> > lack the time to get familiar with Blender internals and do this myself.
> >
> > Cheers
> >
> > Juan Linietsky
> >
> >
> > On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans  > >wrote:
> >
> > > Until Blender has good fbx import or an alternative collada import
> > > (python?) it would be good to postpone dropping OpenCollada.
> > >
> > > >From the feedback, some people are using the import feature, and there
> > is
> > > no replacement.
> > >
> > > Let's hope someone stands up and fixes the issues in trunk, rather then
> > > branch.
> > >  On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
> > >
> > > > Hi,
> > > >
> > > > The Collada conformance suite is not working, and working on it won't
> > > help
> > > > anything.
> > > > I wrote about this here;
> > > > http://code.blender.org/index.php/2011/10/collada-momentum/
> > > >
> > > > Collada just has no reference stakeholder(s) (like how fbx was native
> > for
> > > > motionbuilder).
> > > > Blender would be the worst stakeholder for it even, since we have the
> > > > awesome .blend :)
> > > >
> > > > Much better stakeholders would be Linden Labs (2nd life), or
> CryTek...
> > or
> > > > Daz? Three names of companies who make plenty of dollars with
> software
> > > > licensing. Why don't they put an employee as developer in our team,
> to
> > > > ensure Collada exports smoothly for their products?
> > > >
> > > > I even wouldn't mind a (python) addon "Export to DazCollada,
> > CryCollada,
> > > > 2ndLifeCollada, etc. It's how collada has been designed to work
> > anyway...
> > > >
> > > > -Ton-
> > > >
> > > >
> > 
> > > > Ton Roosendaal  Blender Foundation   t...@blender.org
> > www.blender.org
> > > > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
> Netherlands
> > > >
> > > > On 10 Jan, 2012, at 0:25, Sebastian wrote:
> > > >
> > > > > COLLADA has a great conformance test suite at
> > > > > http://www.khronos.org/conformance/implementers/collada/
> > > > >
> > > > > It's being made available for free and I've already seen Blender
> > > results
> > > > > uploaded some time ago.
> > > > >
> > > > >
> > > > >
> > > > > On 09.01.2012 23:52, spatial wrote:
> > > > >>> For the COLLADA community Blender is definitely one of the most
> > > > >>> important stakeholders to stop supporting COLLADA would make
> things
> > > in
> > > > >>> DCC exchange even worse.
> > > > >> I agree. Not to mention all those who co use it alongside LW , all
> > of
> > > > >> DAZ productsetc.
> > > > >>
> > > > >> I actually tried to avoid a discussion here since a long time,
> > > > >> but topic is too important.
> > > > >>
> > > > >> First, kicking out collada from blender doesn't help anyone. None
> of
> > > the
> > > > >> "common" interexchange formats is that reliable / support all
> > > features.
> > > > >> To have at least a second format as a backup strategy,  if a
> certain
> > > > >> features arent't supported / have some unreliable results, is a
> > "must
> > > > >> have" in every cross application enviroment.
> > > > >>
> > > > >> And btw, blenders FBX import is, from my experience, still not as
> > > > >> reliable as it should be, to actually replace collada. (sorry,
> this
> > is
> > > > >> no actual bashing... its already great what has been archived...
> > > > >> especially if you consider that it 

Re: [Bf-committers] Collada importer/exporter kickout

[Ton Roosendaal]

Hi,

You can count on plenty of people jumping on a patch if you publish it. Don't 
understimate the power of having many eyes looking. If it requires more 
expertise or IO experience, Campbell is around to check on it too.

-Ton-


Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands

On 10 Jan, 2012, at 23:39, Juan Linietsky wrote:

> Heh I wanted to emphasize that it works, but I seriously do need to work
> with someone familiar with writing blender and/or blender import plugins in
> C++ to do it, who can take my code and adapt it to Blender. It should be a
> short task for someone with that experience.
> 
> Cheers
> 
> Juan
> 
> 
> On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com <
> zan...@gmail.com> wrote:
> 
>> That sounds *very* exciting and *very* appropriate for our needs :) OC ads
>> too much weight to Blender's big ass
>> 
>> Daniel Salazar
>> 3Developer.com
>> 
>> 
>> On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky  wrote:
>> 
>>> I didn't realize a collada exporter was so important. If so..
>>> 
>>> I have a *very* *tested* and *very* *small* collada importer in my
>>> middleware stuff (~3k lines of C++ code). It supports pretty much
>>> everything (models, skeletons, materials, cameras, lights, morphs,
>> any-axis
>>> orientation, animations with matrices or curves, etc).
>>> 
>>> Given it's very small size and non-dependency on OC, it's very easy to
>>> understand and *very easy to mantain*. It pretty much just ignores
>>> conformance of input files and just attempts to grab wathever data it
>> needs
>>> so *compatibility is extremely high*.
>>> 
>>> It's not a standalone library, but it's separated enough that *if someone
>>> knowledgable of blender internals *wants to give a try to adapting it to
>>> blender (of course with me 100% available for answering questions with
>>> this), i think in a matter of a few hours we can solve the Blender
>> problem
>>> of collada import support. However as I said in previous mails, I really
>>> lack the time to get familiar with Blender internals and do this myself.
>>> 
>>> Cheers
>>> 
>>> Juan Linietsky
>>> 
>>> 
>>> On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans >>> wrote:
>>> 
 Until Blender has good fbx import or an alternative collada import
 (python?) it would be good to postpone dropping OpenCollada.
 
> From the feedback, some people are using the import feature, and there
>>> is
 no replacement.
 
 Let's hope someone stands up and fixes the issues in trunk, rather then
 branch.
 On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
 
> Hi,
> 
> The Collada conformance suite is not working, and working on it won't
 help
> anything.
> I wrote about this here;
> http://code.blender.org/index.php/2011/10/collada-momentum/
> 
> Collada just has no reference stakeholder(s) (like how fbx was native
>>> for
> motionbuilder).
> Blender would be the worst stakeholder for it even, since we have the
> awesome .blend :)
> 
> Much better stakeholders would be Linden Labs (2nd life), or
>> CryTek...
>>> or
> Daz? Three names of companies who make plenty of dollars with
>> software
> licensing. Why don't they put an employee as developer in our team,
>> to
> ensure Collada exports smoothly for their products?
> 
> I even wouldn't mind a (python) addon "Export to DazCollada,
>>> CryCollada,
> 2ndLifeCollada, etc. It's how collada has been designed to work
>>> anyway...
> 
> -Ton-
> 
> 
>>> 
> Ton Roosendaal  Blender Foundation   t...@blender.org
>>> www.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
>> Netherlands
> 
> On 10 Jan, 2012, at 0:25, Sebastian wrote:
> 
>> COLLADA has a great conformance test suite at
>> http://www.khronos.org/conformance/implementers/collada/
>> 
>> It's being made available for free and I've already seen Blender
 results
>> uploaded some time ago.
>> 
>> 
>> 
>> On 09.01.2012 23:52, spatial wrote:
 For the COLLADA community Blender is definitely one of the most
 important stakeholders to stop supporting COLLADA would make
>> things
 in
 DCC exchange even worse.
>>> I agree. Not to mention all those who co use it alongside LW , all
>>> of
>>> DAZ productsetc.
>>> 
>>> I actually tried to avoid a discussion here since a long time,
>>> but topic is too important.
>>> 
>>> First, kicking out collada from blender doesn't help anyone. None
>> of
 the
>>> "common" interexchange formats is that reliable / support all
 features.
>>> To have at least a second format as a backup strategy,  if a
>> certai

Re: [Bf-committers] Collada importer/exporter kickout

[Sebastian]

Is there a list containing all COLLADA related bugs somewhere? There are 
only a few, some of them very unspecific, on the 2.6 bug tracker.



On 11.01.2012 11:06, Ton Roosendaal wrote:
> Hi,
>
> You can count on plenty of people jumping on a patch if you publish it. Don't 
> understimate the power of having many eyes looking. If it requires more 
> expertise or IO experience, Campbell is around to check on it too.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 10 Jan, 2012, at 23:39, Juan Linietsky wrote:
>
>> Heh I wanted to emphasize that it works, but I seriously do need to work
>> with someone familiar with writing blender and/or blender import plugins in
>> C++ to do it, who can take my code and adapt it to Blender. It should be a
>> short task for someone with that experience.
>>
>> Cheers
>>
>> Juan
>>
>>
>> On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com<
>> zan...@gmail.com>  wrote:
>>
>>> That sounds *very* exciting and *very* appropriate for our needs :) OC ads
>>> too much weight to Blender's big ass
>>>
>>> Daniel Salazar
>>> 3Developer.com
>>>
>>>
>>> On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky  wrote:
>>>
 I didn't realize a collada exporter was so important. If so..

 I have a *very* *tested* and *very* *small* collada importer in my
 middleware stuff (~3k lines of C++ code). It supports pretty much
 everything (models, skeletons, materials, cameras, lights, morphs,
>>> any-axis
 orientation, animations with matrices or curves, etc).

 Given it's very small size and non-dependency on OC, it's very easy to
 understand and *very easy to mantain*. It pretty much just ignores
 conformance of input files and just attempts to grab wathever data it
>>> needs
 so *compatibility is extremely high*.

 It's not a standalone library, but it's separated enough that *if someone
 knowledgable of blender internals *wants to give a try to adapting it to
 blender (of course with me 100% available for answering questions with
 this), i think in a matter of a few hours we can solve the Blender
>>> problem
 of collada import support. However as I said in previous mails, I really
 lack the time to get familiar with Blender internals and do this myself.

 Cheers

 Juan Linietsky


 On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans wrote:

> Until Blender has good fbx import or an alternative collada import
> (python?) it would be good to postpone dropping OpenCollada.
>
>>  From the feedback, some people are using the import feature, and there
 is
> no replacement.
>
> Let's hope someone stands up and fixes the issues in trunk, rather then
> branch.
> On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
>
>> Hi,
>>
>> The Collada conformance suite is not working, and working on it won't
> help
>> anything.
>> I wrote about this here;
>> http://code.blender.org/index.php/2011/10/collada-momentum/
>>
>> Collada just has no reference stakeholder(s) (like how fbx was native
 for
>> motionbuilder).
>> Blender would be the worst stakeholder for it even, since we have the
>> awesome .blend :)
>>
>> Much better stakeholders would be Linden Labs (2nd life), or
>>> CryTek...
 or
>> Daz? Three names of companies who make plenty of dollars with
>>> software
>> licensing. Why don't they put an employee as developer in our team,
>>> to
>> ensure Collada exports smoothly for their products?
>>
>> I even wouldn't mind a (python) addon "Export to DazCollada,
 CryCollada,
>> 2ndLifeCollada, etc. It's how collada has been designed to work
 anyway...
>>
>> -Ton-
>>
>>
 
>> Ton Roosendaal  Blender Foundation   t...@blender.org
 www.blender.org
>> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
>>> Netherlands
>>
>> On 10 Jan, 2012, at 0:25, Sebastian wrote:
>>
>>> COLLADA has a great conformance test suite at
>>> http://www.khronos.org/conformance/implementers/collada/
>>>
>>> It's being made available for free and I've already seen Blender
> results
>>> uploaded some time ago.
>>>
>>>
>>>
>>> On 09.01.2012 23:52, spatial wrote:
> For the COLLADA community Blender is definitely one of the most
> important stakeholders to stop supporting COLLADA would make
>>> things
> in
> DCC exchange even worse.
 I agree. Not to mention all those who co use it alongside LW , all
 of
 DAZ productsetc.

 I actually tried to avoid a discussion here since a long time,

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

Not a patch, but here's my collada importer, it's really simple, very
complete feature wise and very compatible.
Main file: collada.*
Simple xml parser: xml_parser.*
Stuff that loads into middleare: scene_format_collada.*

Probably the way to go is to just integrate the simple xml parser and then
try to port collada.h/collada.cpp,
later use the data (using scene_format_collada.* as reference) to import it
to blender. If any help is needed, drop me a mail.

Cheers!

Juan Linietsky



http://dl.dropbox.com/u/53086520/colladaimport.zip


On Wed, Jan 11, 2012 at 7:06 AM, Ton Roosendaal  wrote:

> Hi,
>
> You can count on plenty of people jumping on a patch if you publish it.
> Don't understimate the power of having many eyes looking. If it requires
> more expertise or IO experience, Campbell is around to check on it too.
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>
> On 10 Jan, 2012, at 23:39, Juan Linietsky wrote:
>
> > Heh I wanted to emphasize that it works, but I seriously do need to work
> > with someone familiar with writing blender and/or blender import plugins
> in
> > C++ to do it, who can take my code and adapt it to Blender. It should be
> a
> > short task for someone with that experience.
> >
> > Cheers
> >
> > Juan
> >
> >
> > On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com <
> > zan...@gmail.com> wrote:
> >
> >> That sounds *very* exciting and *very* appropriate for our needs :) OC
> ads
> >> too much weight to Blender's big ass
> >>
> >> Daniel Salazar
> >> 3Developer.com
> >>
> >>
> >> On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky 
> wrote:
> >>
> >>> I didn't realize a collada exporter was so important. If so..
> >>>
> >>> I have a *very* *tested* and *very* *small* collada importer in my
> >>> middleware stuff (~3k lines of C++ code). It supports pretty much
> >>> everything (models, skeletons, materials, cameras, lights, morphs,
> >> any-axis
> >>> orientation, animations with matrices or curves, etc).
> >>>
> >>> Given it's very small size and non-dependency on OC, it's very easy to
> >>> understand and *very easy to mantain*. It pretty much just ignores
> >>> conformance of input files and just attempts to grab wathever data it
> >> needs
> >>> so *compatibility is extremely high*.
> >>>
> >>> It's not a standalone library, but it's separated enough that *if
> someone
> >>> knowledgable of blender internals *wants to give a try to adapting it
> to
> >>> blender (of course with me 100% available for answering questions with
> >>> this), i think in a matter of a few hours we can solve the Blender
> >> problem
> >>> of collada import support. However as I said in previous mails, I
> really
> >>> lack the time to get familiar with Blender internals and do this
> myself.
> >>>
> >>> Cheers
> >>>
> >>> Juan Linietsky
> >>>
> >>>
> >>> On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans <
> erwin.coum...@gmail.com
>  wrote:
> >>>
>  Until Blender has good fbx import or an alternative collada import
>  (python?) it would be good to postpone dropping OpenCollada.
> 
> > From the feedback, some people are using the import feature, and
> there
> >>> is
>  no replacement.
> 
>  Let's hope someone stands up and fixes the issues in trunk, rather
> then
>  branch.
>  On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
> 
> > Hi,
> >
> > The Collada conformance suite is not working, and working on it won't
>  help
> > anything.
> > I wrote about this here;
> > http://code.blender.org/index.php/2011/10/collada-momentum/
> >
> > Collada just has no reference stakeholder(s) (like how fbx was native
> >>> for
> > motionbuilder).
> > Blender would be the worst stakeholder for it even, since we have the
> > awesome .blend :)
> >
> > Much better stakeholders would be Linden Labs (2nd life), or
> >> CryTek...
> >>> or
> > Daz? Three names of companies who make plenty of dollars with
> >> software
> > licensing. Why don't they put an employee as developer in our team,
> >> to
> > ensure Collada exports smoothly for their products?
> >
> > I even wouldn't mind a (python) addon "Export to DazCollada,
> >>> CryCollada,
> > 2ndLifeCollada, etc. It's how collada has been designed to work
> >>> anyway...
> >
> > -Ton-
> >
> >
> >>>
> 
> > Ton Roosendaal  Blender Foundation   t...@blender.org
> >>> www.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The
> >> Netherlands
> >
> > On 10 Jan, 2012, at 0:25, Sebastian wrote:
> >
> >> COLLADA has a great conformance test suite at
> >> http://www.khronos.org/conformance/implementers/collada/
> >>
> >> It's be

Re: [Bf-committers] Collada importer/exporter kickout

[Juha Mäki-Kanto]

Hi,

Did some digging into this -> armature animation vs
collada

>From testing and looking at the code Blender imports and uses animation
curves directly which isn't good. It'll only match the original in special
circumstances like if the rotation difference between bone's restpose vs
parent's restpose is identity and you're only animating rotations. For
Second Life there is actually a trick to set all restbones to be positive
Y-axis (identity matrix) which apparently then loads correctly there.

It seems that 2.59 did export/import for armatures correctly
(#29082);
tested it and the eulers in the file were interpreted to be quaternions
(and the animation works) so the previous system was somewhat aware of this
caveat.

The gist to me is that collada's transformations may not match a program's
internal representation and reinterpreting usually goes via collada data to
full matrix, possibly fix the matrix and then decomposite to curves. It's a
lossy conversion, key's should match but interpolation won't -> you need to
bake/key every frame when importing the curves.



2012/1/11 Sebastian 

> Is there a list containing all COLLADA related bugs somewhere? There are
> only a few, some of them very unspecific, on the 2.6 bug tracker.
>
>
>
> On 11.01.2012 11:06, Ton Roosendaal wrote:
> > Hi,
> >
> > You can count on plenty of people jumping on a patch if you publish it.
> Don't understimate the power of having many eyes looking. If it requires
> more expertise or IO experience, Campbell is around to check on it too.
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> >
> > On 10 Jan, 2012, at 23:39, Juan Linietsky wrote:
> >
> >> Heh I wanted to emphasize that it works, but I seriously do need to work
> >> with someone familiar with writing blender and/or blender import
> plugins in
> >> C++ to do it, who can take my code and adapt it to Blender. It should
> be a
> >> short task for someone with that experience.
> >>
> >> Cheers
> >>
> >> Juan
> >>
> >>
> >> On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com<
> >> zan...@gmail.com>  wrote:
> >>
> >>> That sounds *very* exciting and *very* appropriate for our needs :) OC
> ads
> >>> too much weight to Blender's big ass
> >>>
> >>> Daniel Salazar
> >>> 3Developer.com
> >>>
> >>>
> >>> On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky
>  wrote:
> >>>
>  I didn't realize a collada exporter was so important. If so..
> 
>  I have a *very* *tested* and *very* *small* collada importer in my
>  middleware stuff (~3k lines of C++ code). It supports pretty much
>  everything (models, skeletons, materials, cameras, lights, morphs,
> >>> any-axis
>  orientation, animations with matrices or curves, etc).
> 
>  Given it's very small size and non-dependency on OC, it's very easy to
>  understand and *very easy to mantain*. It pretty much just ignores
>  conformance of input files and just attempts to grab wathever data it
> >>> needs
>  so *compatibility is extremely high*.
> 
>  It's not a standalone library, but it's separated enough that *if
> someone
>  knowledgable of blender internals *wants to give a try to adapting it
> to
>  blender (of course with me 100% available for answering questions with
>  this), i think in a matter of a few hours we can solve the Blender
> >>> problem
>  of collada import support. However as I said in previous mails, I
> really
>  lack the time to get familiar with Blender internals and do this
> myself.
> 
>  Cheers
> 
>  Juan Linietsky
> 
> 
>  On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans<
> erwin.coum...@gmail.com
> > wrote:
> 
> > Until Blender has good fbx import or an alternative collada import
> > (python?) it would be good to postpone dropping OpenCollada.
> >
> >>  From the feedback, some people are using the import feature, and
> there
>  is
> > no replacement.
> >
> > Let's hope someone stands up and fixes the issues in trunk, rather
> then
> > branch.
> > On Jan 10, 2012 2:15 AM, "Ton Roosendaal"  wrote:
> >
> >> Hi,
> >>
> >> The Collada conformance suite is not working, and working on it
> won't
> > help
> >> anything.
> >> I wrote about this here;
> >> http://code.blender.org/index.php/2011/10/collada-momentum/
> >>
> >> Collada just has no reference stakeholder(s) (like how fbx was
> native
>  for
> >> motionbuilder).
> >> Blender would be the worst stakeholder for it even, since we have
> the
> >> awesome .blend :)
> >>
> >> Much better stakeholders would be Linden Labs (2nd life), or
> >>> Cry

Re: [Bf-committers] Collada importer/exporter kickout

[Juha Mäki-Kanto]

That being said, would be helpful if someone could give a concrete example
of how the exporter-side fails when skinning (not "bones look different
after collada" * ) or the error in my logic. From looking at the files
produced the animation matrices should be correctly parent space.

* Bones may look different after import/export if they are interpreted as
lines between joints (where a leaf-bone doesn't have a well defined
orientation) or bones just are on different axis.

2012/1/14 Juha Mäki-Kanto 

> Hi,
>
> Did some digging into this -> armature animation vs 
> collada
>
> From testing and looking at the code Blender imports and uses animation
> curves directly which isn't good. It'll only match the original in special
> circumstances like if the rotation difference between bone's restpose vs
> parent's restpose is identity and you're only animating rotations. For
> Second Life there is actually a trick to set all restbones to be positive
> Y-axis (identity matrix) which apparently then loads correctly there.
>
> It seems that 2.59 did export/import for armatures correctly 
> (#29082);
> tested it and the eulers in the file were interpreted to be quaternions
> (and the animation works) so the previous system was somewhat aware of this
> caveat.
>
> The gist to me is that collada's transformations may not match a program's
> internal representation and reinterpreting usually goes via collada data to
> full matrix, possibly fix the matrix and then decomposite to curves. It's a
> lossy conversion, key's should match but interpolation won't -> you need to
> bake/key every frame when importing the curves.
>
>
>
> 2012/1/11 Sebastian 
>
>> Is there a list containing all COLLADA related bugs somewhere? There are
>> only a few, some of them very unspecific, on the 2.6 bug tracker.
>>
>>
>>
>> On 11.01.2012 11:06, Ton Roosendaal wrote:
>> > Hi,
>> >
>> > You can count on plenty of people jumping on a patch if you publish it.
>> Don't understimate the power of having many eyes looking. If it requires
>> more expertise or IO experience, Campbell is around to check on it too.
>> >
>> > -Ton-
>> >
>> > 
>> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
>> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
>> >
>> > On 10 Jan, 2012, at 23:39, Juan Linietsky wrote:
>> >
>> >> Heh I wanted to emphasize that it works, but I seriously do need to
>> work
>> >> with someone familiar with writing blender and/or blender import
>> plugins in
>> >> C++ to do it, who can take my code and adapt it to Blender. It should
>> be a
>> >> short task for someone with that experience.
>> >>
>> >> Cheers
>> >>
>> >> Juan
>> >>
>> >>
>> >> On Tue, Jan 10, 2012 at 6:53 PM, Daniel Salazar - 3Developer.com<
>> >> zan...@gmail.com>  wrote:
>> >>
>> >>> That sounds *very* exciting and *very* appropriate for our needs :)
>> OC ads
>> >>> too much weight to Blender's big ass
>> >>>
>> >>> Daniel Salazar
>> >>> 3Developer.com
>> >>>
>> >>>
>> >>> On Tue, Jan 10, 2012 at 3:48 PM, Juan Linietsky
>>  wrote:
>> >>>
>>  I didn't realize a collada exporter was so important. If so..
>> 
>>  I have a *very* *tested* and *very* *small* collada importer in my
>>  middleware stuff (~3k lines of C++ code). It supports pretty much
>>  everything (models, skeletons, materials, cameras, lights, morphs,
>> >>> any-axis
>>  orientation, animations with matrices or curves, etc).
>> 
>>  Given it's very small size and non-dependency on OC, it's very easy
>> to
>>  understand and *very easy to mantain*. It pretty much just ignores
>>  conformance of input files and just attempts to grab wathever data it
>> >>> needs
>>  so *compatibility is extremely high*.
>> 
>>  It's not a standalone library, but it's separated enough that *if
>> someone
>>  knowledgable of blender internals *wants to give a try to adapting
>> it to
>>  blender (of course with me 100% available for answering questions
>> with
>>  this), i think in a matter of a few hours we can solve the Blender
>> >>> problem
>>  of collada import support. However as I said in previous mails, I
>> really
>>  lack the time to get familiar with Blender internals and do this
>> myself.
>> 
>>  Cheers
>> 
>>  Juan Linietsky
>> 
>> 
>>  On Tue, Jan 10, 2012 at 11:30 AM, Erwin Coumans<
>> erwin.coum...@gmail.com
>> > wrote:
>> 
>> > Until Blender has good fbx import or an alternative collada import
>> > (python?) it would be good to postpone dropping OpenCollada.
>> >
>> >>  From the feedback, some people are using the import feature, and
>> there
>>  is
>> > no replacement.
>> >
>> > Let's hope someone stands up and fixes the issues in trunk, ra

Re: [Bf-committers] Collada importer/exporter kickout

[Juan Linietsky]

The problem with importing/exporting of Collada and skeletons is not really
that it doesn't match the internal representation.
Animating 3D objects in a 3D Animation package is always done through euler
angles, local or global, and that is easy to export
seamlessly in Collada.
But skeleton based models like characters almost always use IK or other
sort of constraints which are impossible to convert back to euler due to
gimbal lock issues, so the only way to reliably export skeletal animation
is to export a full rotation snapshot either via a quaternion (which
Collada does not support) or 4x3 matrix., and later optimize redundant
keyframes to save storage space.
So I think in short, it's the lack of support for constraints what makes
Collada not very useful as an exchange format between DCCs, but yet it's
still very useful for exporting to game engines.

Juan




On Sat, Jan 14, 2012 at 5:28 PM, Juha Mäki-Kanto wrote:

>
>
> The gist to me is that collada's transformations may not match a program's
> internal representation and reinterpreting usually goes via collada data to
> full matrix, possibly fix the matrix and then decomposite to curves. It's a
> lossy conversion, key's should match but interpolation won't -> you need to
> bake/key every frame when importing the curves.
>
>
>
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Sebastian]

There was a proposal once on the COLLADA mailing list to include 
constraints. It turned out that with COLLADA 1.5's kinematic model and 
the full MathML support for formulas nearly every use case could be 
handled. If you're interested and prepare a blend file we can handcraft 
a corresponding COLLADA file.

Sebastian




On 15.01.2012 15:10, Juan Linietsky wrote:
> The problem with importing/exporting of Collada and skeletons is not really
> that it doesn't match the internal representation.
> Animating 3D objects in a 3D Animation package is always done through euler
> angles, local or global, and that is easy to export
> seamlessly in Collada.
> But skeleton based models like characters almost always use IK or other
> sort of constraints which are impossible to convert back to euler due to
> gimbal lock issues, so the only way to reliably export skeletal animation
> is to export a full rotation snapshot either via a quaternion (which
> Collada does not support) or 4x3 matrix., and later optimize redundant
> keyframes to save storage space.
> So I think in short, it's the lack of support for constraints what makes
> Collada not very useful as an exchange format between DCCs, but yet it's
> still very useful for exporting to game engines.
>
> Juan
>
>
>
>
> On Sat, Jan 14, 2012 at 5:28 PM, Juha Mäki-Kantowrote:
>
>>
>>
>> The gist to me is that collada's transformations may not match a program's
>> internal representation and reinterpreting usually goes via collada data to
>> full matrix, possibly fix the matrix and then decomposite to curves. It's a
>> lossy conversion, key's should match but interpolation won't ->  you need to
>> bake/key every frame when importing the curves.
>>
>>
>>
>>
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Juha Mäki-Kanto]

 My basic point is that to me it seems like going to collada means you
either haven't done object/armature animation yet or you're done with it
and happy to have it "baked" as per frame rot/loc/scale or matrices. I'm
not sure about most other programs so I'll just ask: what would be the
correct way in collada to handle a parent inverse- matrix in child-objects
(possibly has skew in it) and the "default" rest-pose attributed
translation+rotation between parent-child bones?

2012/1/15 Juan Linietsky 

> The problem with importing/exporting of Collada and skeletons is not really
> that it doesn't match the internal representation.
> Animating 3D objects in a 3D Animation package is always done through euler
> angles, local or global, and that is easy to export
> seamlessly in Collada.
> But skeleton based models like characters almost always use IK or other
> sort of constraints which are impossible to convert back to euler due to
> gimbal lock issues, so the only way to reliably export skeletal animation
> is to export a full rotation snapshot either via a quaternion (which
> Collada does not support) or 4x3 matrix., and later optimize redundant
> keyframes to save storage space.
> So I think in short, it's the lack of support for constraints what makes
> Collada not very useful as an exchange format between DCCs, but yet it's
> still very useful for exporting to game engines.
>
> Juan
>
>
>
>
> On Sat, Jan 14, 2012 at 5:28 PM, Juha Mäki-Kanto  >wrote:
>
> >
> >
> > The gist to me is that collada's transformations may not match a
> program's
> > internal representation and reinterpreting usually goes via collada data
> to
> > full matrix, possibly fix the matrix and then decomposite to curves.
> It's a
> > lossy conversion, key's should match but interpolation won't -> you need
> to
> > bake/key every frame when importing the curves.
> >
> >
> >
> >
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Peter Amstutz]

So the 2.61 COLLADA support isn't just bad, it's a regression from 2.59? 
  What changed?

Personally, I would be happy with reliable import of skeletons and 
rigged/skinned models.  My use case is to be able to move characters 
that were modeled/rigged/animated in 3DS Max into Blender, and not look 
back.

On 1/14/2012 3:28 PM, Juha Mäki-Kanto wrote:
> Hi,
>
> Did some digging into this ->  armature animation vs
> collada
>
>> From testing and looking at the code Blender imports and uses animation
> curves directly which isn't good. It'll only match the original in special
> circumstances like if the rotation difference between bone's restpose vs
> parent's restpose is identity and you're only animating rotations. For
> Second Life there is actually a trick to set all restbones to be positive
> Y-axis (identity matrix) which apparently then loads correctly there.
>
> It seems that 2.59 did export/import for armatures correctly
> (#29082);
> tested it and the eulers in the file were interpreted to be quaternions
> (and the animation works) so the previous system was somewhat aware of this
> caveat.
>
> The gist to me is that collada's transformations may not match a program's
> internal representation and reinterpreting usually goes via collada data to
> full matrix, possibly fix the matrix and then decomposite to curves. It's a
> lossy conversion, key's should match but interpolation won't ->  you need to
> bake/key every frame when importing the curves.
>
>
>

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout

[Stephen Swaney]

On Tue, Jan 10, 2012 at 11:15:20AM +0100, Ton Roosendaal wrote:

> I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada, 
> 2ndLifeCollada, etc. It's how collada has been designed to work anyway...

Given how the Collada specification is so all-encompassing (or other
word that means "specific yet vague"), I suspect this is where we are
going to end up: with lots of little purpose-built exporters and importers.

-- 
Stephen Swaney  
sswa...@centurytel.net

___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout export crytek

[angjminer]

Quoting Ton Roosendaal :
> Hi,
>
> The Collada conformance suite is not working, and working on it won't help
> anything. 
> I wrote about this here;
> http://code.blender.org/index.php/2011/10/collada-momentum/
>
> Collada just has no reference stakeholder(s) (like how fbx was native for
> motionbuilder). 
> Blender would be the worst stakeholder for it even, since we have the awesome
> .blend :)
>
> Much better stakeholders would be Linden Labs (2nd life), or 
> CryTek... or Daz?
> Three names of companies who make plenty of dollars with software 
> licensing. Why
> don't they put an employee as developer in our team, to ensure 
> Collada exports
> smoothly for their products?
>
> I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> 2ndLifeCollada, etc. It's how collada has been designed to work anyway... 
>
> -Ton-
>
> 
> Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
I have actually been thinking about that, we had talked in an email 
earlier (cryblend). 
and i really didnt like the idea of forking off . just wanted to get 
people going as quickly as possible. 
just about got animation clips to export, but i really want people to 
benefit from the constant improvements in blender, not get held back by 
a version freeze, i will be more than happy to do a crytek collada 
exporter, cryblend is popular enough to warrant it and it would benefit 
everyone. 
it would allow me to include running the rc.exe from the exporter, only 
thing is ,,, I will be bugging you guys to death in the beginning , 
If that is not going to be a problem then that's what i will do,
just need you guys to suggest a base to start from.(juan if you read 
this... do you mind?)
angjminer
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers

Re: [Bf-committers] Collada importer/exporter kickout export crytek

[François T .]

>
>
> > Much better stakeholders would be Linden Labs (2nd life), or
> > CryTek... or Daz?
> > Three names of companies who make plenty of dollars with software
> > licensing. Why
> > don't they put an employee as developer in our team, to ensure
> > Collada exports
> > smoothly for their products?
>

Because they use FBX (at least if they work as the one I know). FBX is well
supported in the entire pipepline from MotionBuilder for anim & mocap to
maya and max for integration and very easy to integrate into in-house tool
as well.
In this original pipeline Collada is not so popular so why would they
bother to re-adapt the entire workflow when they only have one format to
implement at the end in there in-house tools since they have no issue with
paying licence ?
Those company usually support Collada as well, but don't support it to much
and do not care if it doesn't work since they always have the fbx solution
:p






> >
> > I even wouldn't mind a (python) addon "Export to DazCollada, CryCollada,
> > 2ndLifeCollada, etc. It's how collada has been designed to work anyway...
> >
> > -Ton-
> >
> > 
> > Ton Roosendaal  Blender Foundation   t...@blender.orgwww.blender.org
> > Blender Institute   Entrepotdok 57A  1018AD Amsterdam   The Netherlands
> I have actually been thinking about that, we had talked in an email
> earlier (cryblend).
> and i really didnt like the idea of forking off . just wanted to get
> people going as quickly as possible.
> just about got animation clips to export, but i really want people to
> benefit from the constant improvements in blender, not get held back by
> a version freeze, i will be more than happy to do a crytek collada
> exporter, cryblend is popular enough to warrant it and it would benefit
> everyone.
> it would allow me to include running the rc.exe from the exporter, only
> thing is ,,, I will be bugging you guys to death in the beginning ,
> If that is not going to be a problem then that's what i will do,
> just need you guys to suggest a base to start from.(juan if you read
> this... do you mind?)
> angjminer
> ___
> Bf-committers mailing list
> Bf-committers@blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 

François Tarlier
www.francois-tarlier.com
www.linkedin.com/in/francoistarlier
___
Bf-committers mailing list
Bf-committers@blender.org
http://lists.blender.org/mailman/listinfo/bf-committers