Domino Marama

Well obviously they are noticable otherwise we wouldn't have this thread to post in. Also avatars are a completely different animal with the advent of mesh than when the bvh handling was designed. If you were doing a couples animation of say a giant ruffling a tinies hair, a couple of degrees could be the difference between a cute animation and a broken neck. We support bvh export as well in Avastar. We are providing tools that give artists more choice and options, The data to store a keyframe on a joint is just 8 bytes - so for something like breathing (typical fine detail) which has probably a keyframe per second - on a one minute animation with two bones affected - that's just 8 x 2 x 60 - under 1Kb difference. And that's assuming there's no other animation on those bones that would normally result in a keyframe. So an entire AO's worth of animation is going to increase network load by less than one 512 x 512 texture used when a 256 x 256 would do.. Use one 256 x 256 image instead of a 1024 x 1024, and you've saved more than a sim's worth of avatar AOs extra keyframes. And that's assuming the worst case that each and every animation has lots of extra keyframes. In actual use, that's just not going to be the case. So I seriously think any network load effect from supporting these small movements is negligble and providing the artist with tools that allow them to decide when such fine detail is necessary or not is essential with the wider range of possible avatars. You should also consider why that feature on bvh imports is there in the first place - I think it's for simplifying motion capture where it's likely every bone is keyframed every frame. In that case of course removing fine detail is the correct thing to do. With the retargetting of motion capture to the avatar in Avastar, you can do this sort of simplification of data before saving the .anim or .bvh file. And obviously hand animated files are already going to have considerably less keyframes than motion captured data.

Drongle McMahon wrote: Hi Domino. Why can't the old illusoft exporter from 2.49b be adapted to work with the new Blender versions? Have the Blender internals changed too much? It probably could. But I'm sure you can imagine the issues in converting ~400k of code to a different API. It was also slow - it was written against a version of Python that didn't have elementtree, The xml side would need changing from minidom to elementtree and the blender side needs changing to the new API. So the conversion actually becomes a total rewrite if you want to do it right. Even then, not all Collada features were supported.

Chosen Few wrote: Nothing's been decided yet, so nobody panic yet. If worse comes to worst, and the Blender devs do cease official support for COLLADA, I'm sure enterprising SL residents will just create their own COLLADA exporter for Blender, and release it to the public, just like they did for the excellent sculpty tools that so many Blender users now enjoy. Are you looking over my shoulder? Oddly just before this issue came up, I'd just started digging into the Blender code to fix some Collada bugs. I do tend to agree that the current implemention in Blender is awkward and in the long term best replaced. So instead of fixing bugs, I've started on a Python implementation of a Collada exporter. And getting it working for SL is the first priority - it'll be free to all Primstar 2 and Avastar owners - I hope to have it ready before Collada support is dropped from Blender

It's a minor change to the viewer code to add support for the .anim files which Avastar can produce. The .anim files are effectively at step 4 of the overview of the internal animation format used by Second Life. Things such as hand poses, emotes and loop points are all stored in the header of the .anim files, and these can be set in Avastar. So you have as much control there as you do in uploading bvh files. As far as priorities are concerned, you actually have more control here as Avastar allows per bone priorities to be set (the joint priority mentioned in the format reference). The .anim files actually support up to priority 6. Because we support other worlds besides SL, and people may wish to replace the default higher priority animations for those worlds, we allow these to be set in Avastar. We don't recommend the use of these for normal animations though.

What you call "the uploader clean up" is part of the conversion from .bvh to .anim that the viewer does before upload. By using the .anim format and 3rd viewer bulk uploads, you skip that step completely. There's no doubt that Avastar is a complex product designed around all avatar editing, not just animation. Some features are exposed for machinima tricks rather than just SL animations as well. It'll also take us some time to document how to use it all. So there's plenty of room in the market for 3rd party training if you fancy doing an Avastar version of your instruction manual

You can avoid the loss of fine detail in .bvh files by using Avastar and exporting in the native SL .anim format. You'll need to be using a 3rd party viewer that supports uploading these as well.

It looks like Blender users are going to be spoiled for choice when it comes to animating for SL For support of the archetype.xml file, there's only one choice as far as I know - Avastar does that and a whole lot more, including support for SL's native animation format for 100% accuracy..

Yeah looking at the sculpt code does bring back memories, and having to say "this is how it should work" and "here is how the LL code does it" is positively deja vu

The hard coded constraint is a minimum of 4 x 4 quad faces.. That needs 5 x 5 pixels to describe on a sculpt map. As SL doesn't support non power of two textures, that means we need to use an 8 x 8 sculpt map. Using a 4 x 4 map is only enough for 3 x 3 faces, but the 4 x 4 faces will still be mapped to this smaller image, resulting in one compressed face and the three you can see. The 2 x2 example has 3 compressed rows in U and V, so you only see a single quad of the 4 x 4 quads. You can test this by applying a UV Grid image, or even a simple black and white checkerboard and seeing how much of the texture is used on the visible faces.

I'm just checking around with 3rd party viewer developers on the format of their export features. Unfortunately I don't have all their email addresses. So hopefully, the ones I've missed will see this here. I'm working on Primstar 2.0 for Blender 2.5 and plan on making it into a full offline prim editor. At the moment I plan on using LLSD for imports and exports. Does your viewer have import and export features? If so could you confirm that LLSD based XML is what your export uses? I've heard rumours that some viewers have slightly different variations, so if you are compatible or not with other viewers, could you also mention that. It'd obviously be to everyone's benefit to be using the same format so I look forward to hearing your thoughts on this. Thanks & best wishes, Domino

It looks like you used extrude to make the eye sockets. This is generally a bad idea as the new faces get a uv unwrapping over the entire sculpt image. You either need to manually fix the UV layout, or delete the offending faces and bake the sculpty. Import this sculpt map (Primstar will fill in the holes) and then remodel the eye sockets by moving existing vertices rather than using extrude.

Head to http://dominodesigns.info/ in the site menu under the Primstar links is Avatar - just click that to download a blend file with the avatar. Once you open the file, checkout the shape keys in Blender as you can adjust the mesh to better suit the target avatar there. This version is rigged with the avatar skeleton so you can pose it as well.