Feynt Mistral

I actually think it should be important unless they're running completely different builds each to test for optimal fitness (Mod help us, we're enacting the law of nature with server builds!). If you upload something in one sim, moving to another sim shouldn't cause it to disappear in the previous.

Well as far as I know most people reuse their higher grade texture for lower LoDs to a certain point, but in game design at least there are some artists who make their own MIP maps to optimize for different ranges. This uses the same texture, but with different UV coordinates at different LoDs specified by hand at model creation time. As for a zero triangle "face" you can create a quad (attached to other parts of a mesh), then select all the vertices of that quad in edit mode and delete the face (X, choose Face). You should then be able to unwrap that quad to a separate map, though obviously it'll be kind of weird. Edit: The UV map will always be as you made it, and if you remove geometry from the mesh but still keep the UVs, it'll be arranged the same way as before. At a certain point you'll look at it and say "you know, that baked underboob doesn't look so good with my medium LoDs' pyramid boobs...", but at that point you're either doing as above (MIP maps of your own) or not destroying important geometry to preserve the map longer (becaues underboob is srs bizniz).

There is something I had wondered though. There is code in place to affect change on the base avatar's morph targets and bone positions/lengths/scales (see hip width, arm/leg/torso/neck length, head size, etc.). If we use bones named for the base avatar's skeleton we can get the bone positions/lengths to change via appearance sliders. Why, then, can't we simply have a hook for the rest of the appearance sliders that says "if you make a morph target and name it this way, this thing will work"? Or, perhaps more importantly, "if you make a morph target and name it this way, your avatar will move its mouth when speaking." >D If the option was there, I'd do the extra work to make at least the face animate.

LoDs, as far as I'm aware, always use the UV map you specify for them. If you don't specify, it appears to auto calculate the new UV based on the vertices it removes when auto chopping your mesh for lower LoDs. If you make your own LoDs you could effectively make a different UV map for each level. But... Why?! >D

Kettle quest. >3 Yes, the idea of a sculptie to mesh primer is great. "Ok, we're going to make a chair with an open back using sculpties.......... Now that we finished that, let's do it again in mesh.. See? Wasn't that easier?"

Expressions/hand gestures, no. Those are morph target animations (especially stupid/odd for fingers, but whatever, we don't get finger animations) and we can't make meshes listen to those. Now also an important point is we can't do mesh substitution now like we could with sculpties, swapping maps around to animate a face. You will need to attach multiple meshes with multiple UV maps (up to 8 per mesh), and flip through full transparent versions to provide animations. This will have the end effect of expanding a simple 300-800 poly face to 1k-3k for very basic phonemes and mouth positions until they provide us with custom skeletons to extend the head to include facial bones. That is unless you do something like reposition the eyes (they're bones too!) and rig the face to those to do animation. But you'd still kind of be limited to (custom) animations between jaw open and jaw closed, since you'd need 3 working bones to make subtle cheek movements while talking and pronouncing parts of words. Avatar joint displacement is apparently in place, but stretching is not yet. Or was it the other way around... We'll get both eventually, just not both before launch I think. There is still cause for optimism if you're a macro fan.

It's only against the ToS if it's gambling, this is a sure thing. >3 I'm not sure I agree so much about mesh getting worse. Nailing down a prim cost will be vital to its being of value to builders, and I agree that making it easier to calculate will be important as well so you can look at your vertex/poly count and say "Ok, that's definitely going to be under X prims." As someone focusing primarily on avatars (though there is that giant tree I mentioned. Also not so hot on the idea of only 64m^3 since a multi-part tree 150-200m tall and wide will likely vary on LoD looks) I'm not as interested in prim counts as long as it attaches.

L$500 on 6-10 if the odds are extreme. >)

The thing is a "best practices for mesh" guide would essentially be a "how to model" guide. I don't think it's entirely feasible to do that best practices idea because it'll either be too vague ("make separate LoDs for your mesh and assign them to the various levels... How do I make an LoD?" essentially) or too complex and you're better off going external for instruction to get it done on time. There are a good deal of free software choices, but I'd advise at the very least doing a tutorial with Blender because it's the highest profile free software on SL (current interest in sculpties directs you to Blender first and foremost). It doesn't need to be much, make a low quality hippo in Blender 2.5x and import it to SL, then do the export/upload thing. You can bookend the whole working in Blender part with community recommended links to other pieces of software and tutorials for them.

Well, again, morph targets are unpopular for real time graphics where programatic control is done. Bones can be directly manipulated in code and commonly are their own objects, while morph targets are typically just different animation states. You can't really do much with morph targets in code. For movies morph targets are grand since you can blend between animation states (blend angry facial poses with the phoneme sequence for "what the hell?!" for instance), but you can still use bones to do the same things.

Not so rapidshare. >3 I prefer dropbox, though in a pinch megaupload will also work. If you have a constant connection and a domain tied to your IP (like through dyndns) you could even use HTTP File Server (HFS).

Ah, and that's likely why I'm able to upload my avatar mesh based on the avatar.blend file, because I've completely weighted it to the skeleton.

CTS-613 is all kinds of wacky right there. The prim cost thing though will be subject to change over the coming weeks after the new format finishes, as per the Lindens today. To reference Runitai, he expects the system to change 5 times before it goes live.

Since Blender is free, I would also like to see community recommended links for getting started with modeling and character modeling in Blender. We've got a few going already I believe, but having everything in one place would be ideal so it becomes a "Start here to do mesh stuff" document.

It's just really really dark under water.

I'd also like to point out that there are sculptie clothes already, essentially offering the same thing as a mesh attachment would (though we'll need the ability to resize attached, rigged meshes if we want say, a single piece coat that moves with the avatar properly. A non-weighted mesh attachment would work just like a sculptie right now) which themselves are not affected by the avatar's sliders.

I'm not sure you could copy pasta it here, parts of it might get eaten by the posting software. Preview first to confirm before posting.

Proper as of COLLADA 1.4.1. The most up to date version though according to Wikipedia is 1.5 as of two years ago. So Sketchup 8 could be using COLLADA 1.5, and it might not be backward compatable since it's a minor version change as opposed to a simple revision (the 1.5 versus 1.4.2).

The other option, and probably more professional, is to accept additional bone data and then have modifiers on those bones which register them as "free". This way it becomes a case of weight painting, and flexi-physics can take over on the bones. Oh and another, if they implement morph targets, we could animate between the various states of our wiggly stuff and the appropriate extremes can be animated and blended together according to scriptable motion control (tying animation control and LSL together). This would also allow us to create morph targets that match the default avatar, thus making support for the appearance sliders seamless if we choose as well as animateable mesh faces for talking. But since morph targets are typically less popular than bones (at least in game design) this is not a likely option.

I've got an avatar.blend from ages ago in the closed beta, probably the same file, and I was able to upload it a couple of days ago and mesh based on it. It's possible that there's some kind of weighting issue with your file, or maybe you're uploading to a sim version that doesn't support weighting anymore (at least in the way we knew it)? Hopefully the Lindens can shed some light on this through your JIRA entry.

I believe the incentive to use low impact meshes will be reflected in the upload cost rather than its prim cost. Which is a shame, because you can use a goodly amount of verts and polys to produce a much easier to render house (than straight prims), and yet it can end up costing as much in prims or more.

Well maybe part of this last run to release is updating the importer in SL to support COLLADA 1.5 as well, at least so much as to allow mesh importing with weighting.

Well I don't know why you would have to enable shadows, but I just know that you should be able to see shadows.

I'm not exactly sure that being up to date on your OS upgrades is the same as being up to date on your graphics drivers on a Mac. On a PC the two are decidedly separate. But if I recall there's an upgrade center for Mac which lets you download and install the latest third party drivers if they're out of date.

Yes it would need supporting code to work. >D The idea is basically that Qarl had suggested once about making sculpties flexible with an associated greyscale map controlling which parts of the object should bend along a particular axis (the same as other prims, most likely). In this case there are a couple of ways to do it, but the one I would pick would be having black segments of an associated texture (matching the UV of the mesh object) count as rooted vertices. Then all vertices connected to an appropriately encircled rooted area which are not black will be flexible along a flexiprim like bone structure rooted at the center of this ring of blackness that affects the vertices just on the edge of the greyscale change. The whiter the UV area, the more it moves from its original position. The idea is if you were to apply this texture as the object's UV map, every dangly part that's suppose to move would be various shades of grey or white, while the parts that shouldn't move will clearly be marked full black. Programmatically it shouldn't be too hard to generate the root point, but identifying which vertices should flex how much with the flexi string would be more problematic.