Quote - [Depends on where you d/load it... I don't much bother with Qt Designer except for mock-ups (mostly to check spatials and arrangements). Otherwise, I use my own bitmaps and color schemes, and edit the bastich in a real IDE (Used to be a SlickEdit addict, now I just stick with Eclipse.)

Haven't worked with eclipse much myself, but after perusing it looks like it has some really nice features.  Might have to give it a whirl.  Been a while since I did any Linux coding, most of what I've been doing lately has been Visual C, so this will be a very nice change of pace.

Quote - I love the idea of having two sets of 'bones'... I'd been toying with the idea offhand for awhile now (that is, one set of invisible joint-matching bones and 'skeletal' mesh to conform an item to the figure, and a second set of visible bones in a parallel hierarchical tree/branch set to allow for clothing movements). This allows for more accurate clothing movements (e.g. a jacket that actually drapes backwards at the bottom when a figure sits down, long skirts that can actually drape outwards away from a figure's sitting butt and legs, etc.)

Material zones are a different critter altogether. in D|S they are (IIRC, have to check) treated separately.

One of my biggest problems with poser has always been that material zones in Poser are edited with the same grouping tool you use to group parts of the mesh for rigging, which works fine, if you setup your material zones before you add bones.  If you don't, well it becomes a royal pain in the butt.  It also becomes a real pain when you want to remove a material zone you setup but realize you don't really need or one that was imported as part of the original object but you don't want - the only way I've found to get rid of such a "orphaned zone" is to go in and hack the cr2 with a text editor. 

My own plan is a little different, if I can get it to work right you'll be able to do multiple bone sets and the material zones will be considered seperately as well, so you can slice and dice the mesh pretty much as many different ways as you need to get the desired effect.

Quote - It's possible, but that depends on the features you want to include. OTOH, you could possibly extend it as well, then have one export save to the std. COLLADA format for everyone else, and your own extended version for in-app goodies. Whether other apps decide to use those extensions or not is up to them... who knows, maybe COLLADA will decide to add the extensions? :)

I like the idea of extending collada and making the format changes openly available to other developers.  Some of the features I'm thinking of probably won't be supported entirely by the original.  For example, an flag in the character/prop file to indicate that the mesh was intended to be used with sub-d modeling.  That way FAST can apply sub-d to objects either in preview mode or when they are submitted to render based on this flag.  Lower resolution items could then be used to much greater effect, and speed could be increased dramatically. 

For high end, complicated meshes like V4, this flag would default to off - so sub-d would not be applied.  More or less a smart filtering system for what objects need sub-d and when it should be applied.  Naturally the end user will be able to overide sub-d on any object merely by adding or removing a checkmark from that box, but this way merchants and content providers can setup objects to use sub-d by default, and if the end user doesn't change this default setting (which most will not) they'll never really know the difference between that and a much higher poly mesh, other than of course when they go to render or animate and the speed difference becomes apparent.

In this way I think it will be possible to remain true to Posers traditional higher poly meshes and still be able to integrate them with the more industry standard lower-poly mesh with sub-d applied and make it as seamless as possible for the end user.

Lol - needless to say I have my work cut out for me, but were off to a promising start so far and I'm pretty confident that once I get something I can release as pre-alpha over at sourceforge it will be enough to show other developers that the project is viable, and we'll be able to recruit a few prior to the actual alpha stage.

Once we get past the alpha stage I have a feeling we'll be getting more than a few developers signing on, I think this will be the sort of project that will really grow quickly over time.

-Never fear, RenderDog is near!  Oh wait, is that a chew toy?  Yup. ok, nevermind.. go back to fearing...