Feynt Mistral

Technically we have all the bones we need to do facial animations, the two eyes and the mSkull bone are all unnecessary for most avatars (though the lack of eye motion may bother some), meaning you have three bones for controlling facial muscles and the jaw. This allows you to fully form all the basic phonemes for speech, as well as some basic emotions. This means you don't necessarily need a separate head mesh. However the classic way of doing the head separate of the body works as the others mentioned. It's easier for texture swapping, easier for replacing with other states of the head (beat up with a swollen eye, or a cartoon goose bump, bed head, etc.).

Polygons (or polys for short) versus triangles (or tris) depends largely on your background as a modeler. To the world of cinematography and art in general (those focused on still renders rather than animations) a polygon represents any number of sides from 3 onward. In gaming and similar real time production fields, modelers will tend to use polys and tris and synonyms. When I talk about the poly count of my meshes I refer to the triangle count (because triangles are polygons). Many people swear by doing quad modeling. The goal is to keep the edge count down so that you can clearly see how your edges flow. This becomes important with character models mostly, as it lets you clearly deliniate muscle groups. Triangles tend to limit geometry or require extra cutting to eliminate, however they're valid tools when you really just need to condense your geometry. And as mentioned, in games (and all real time simulations really) your mesh will be converted to triangle strips for rendering. It's much faster (for graphics cards) to work with an array of vertices, with each current plus the previous two vertices being used to make a triangle, instead of quads where there isn't necessarily a clear way to create a strip in an array form.

Tinies win in a few ways actually. Being so small they can get away with lower poly meshes for their avatars and still appear quite detailed (after all, who besides the camera zoom whores would notice that your pecs aren't 50 polys and are instead only 4-8 with some baked shadows?). The folks at polycount could probably have a field day making smaller than normal avatars which would be amazing on SL.

It's likely the Apply button is the culprit. I've exported several rigged meshes, but if you rig a vertex to a group (as you would for bones) and then remove the target of that group by applying the modifier, it's pointing to nothing now. Try exporting again without clicking Apply and see if you get better results, or a different error if you still hit a wall.

Lining up meshes along an infinitely thin line is annoying. Even with script assistance, there's still visible seams. Makes me sad that we can't just have the one piece all in one go. But thanks for picking up on that entry, I guess the "mesh is larger than 256m" didn't get changed to "larger than 240m" Hope that can be fixed sooner or later. >/

It's already split up into several 64m or smaller pieces. Each bounding box for each piece is under 70m diagonally. It's just that the TOTAL mesh, consolidated in Blender, shows those boundaries. I'm not too worried about the diagonality of it either, I can rotate it quite a bit without it sweeping off the sim's main parcel accidentally.

I've been working on my giant tree (mentioned at various times throughout the mesh beta, and demonstrated at least once) and have reached what I consider a finished state on the mesh side of things. When I went to upload it to the beta grid however, imagine my surprise when I crashed immediately! 8 attempts later, I finally encounter a message box and no crash, stating that the mesh exceeds 256m. This is, in fact, a lie. According to Blender, the mesh is approximately 143 x 154 x 241m. I have to scale down the mesh using the upload dialog to 0.94 in order to get it to upload properly, causing me to lose 15m off of the height of the tree. This is actually a big deal, because the branches are arranged in such a way that they would just hang over some floating apartments in the sim this is supposed to go in. With the loss of those 15m, the branches would now extend into the apartments. Why is there even a check on the Z axis for a maximum size? There's effectively no height limit in a sim anymore. With the 64m limit, you would probably run out of vertices to throw at a build long before reaching 4km.

What saddened me at first was that I had come back to the mesh discussion after several months of RL issues to hear the maximum size was constrained to 64m^3. Ok, I can understand that, there aren't many builds which need more than that and those that do could be cut up (unhappily, as my current project requires a 170m tall prim, and if it were one piece the dimensions would be comparable). Now what I'm reading is the tree I'm working on will be impossible due to the PE cost on something so large. I fail to see how a non-physical (prim physics shape) model with a reasonable number of triangles (likely not more than 100k with foliage, and quite possibly much less) will impact someone more than the traditional hair, shoes, and jewelry we all are subjected to daily. What does it matter whether 10k polys are compacted into a 1m^3 area or stretched out over 64m^3? It's the same complexity to stream and render.

Ok, a few "this is probably whys" are in order here: Firstly, costs. It's better to start out high and then realize that "hey, we really could handle more of this, let's turn down the cost." No one complains about a price decrease. Everyone complains about price increases. Based on a technical, and also theoretical basis, the costs and prim equivalencies will make sense once the client/server communication catches up with each other, and even if they don't the public beta testing on the main grid will show them under real circumstances the impact that streaming meshes will have. If they find that overall the experience is improved and the streaming is managable, they can decrease the costs to match and encourage further mesh usage (so that those low end machines can enjoy a properly LoD'ed landscape). Second, meshes vs. sculpties. There's no comparison, sculpties win hands down on streaming. ALL of their information is stored in a compact little 32x32 picture that is made for streaming. The normals are calculated based on the surface generated from the colour channels. There's no UV data transmitted either, it's generated as well. That single 32x32 picture pulls triple duty. With meshes you're passing along three values, certainly (x,y,z vertex info), but there's also individual normal and UV data sets for each vertex, so you've got two to three times the data. And that's excluding possible weighting. 

Yes, this would work. However as was mentioned getting the body and the head to line up properly without obvious seams would be a challenge. The moving mouth isn't worth the trouble in my opinion, and with bone offsets you could already do mouth movements with spare bones like your eye and head bones. Your head can move believably with just the neck bone, leaving you with (possibly) three bones to use for facial animation. Likely just the eyes could be used for this though. Addendum: While a few people will look at me funny or make comments about how using the eyes for a mouth would look odd, most people don't care about the eye movement and can't even see it outside of an extreme close up. With an appropriate animation overriding the default "track the mouse" behavior you can use the bones to animate the face as necessary.

As a note to future readers, newer versions of software can break older functionality. Case in point, Blender 2.57 has a rotational issue with rigged meshes in its COLLADA support, the vertices will be offset oddly as if each bone were turned 90 degrees. It however works perfectly fine in Blender 2.49b. Something similar may happen with 3DS Max as well, where simply exporting with .DAE doesn't work in newer versions and the workflow that Daniel suggested is necessary.

You should be able to make it like this: \_/ That, outward facing, at a distance, should be indistinguishable from a fully formed handle.

You could probably make the handle a triangle strip that's outward facing, maybe 6 triangles (3 quads).

The problems are two fold, but related: If you adjust the size of your avatar (in world) in any way from the default, it's unlikely that your mesh will be the same size as the base and will probably have a seam showing. If your mesh doesn't line up with the default mesh, it's quite possible that you will have your creation end up being larger/smaller dependant on how it's modeled. As an experiment, you can create a default shape and export/import the default avatar to wear. This should overlap perfectly and cause flickering between your obviously textured body and completely untextured mesh avatar upload.

Right up until that last, lowest LoD it looks excellent. I'll admit though at just a few pixels on screen, it's unlikely anyone would actually see that lowest LoD. >D

I would guess it depends on the nature of your model, but even if it were a doughnut I would expect the same behavior with a basic enough shape. The physics engine hates concave surfaces. Holes or curved surfaces (no matter how deep, like an archway) in models you would walk through are concave surfaces (unless broken down to simpler parts). Thus the physics assignment process would make it a non-concave surface. I do know that the importer used to do a good job of breaking down a shape, but it's possible that because your archway is so low poly it cannot be broken down further. Try applying a subsurf or multi-res modifier to it and make it two or three times as complex and then see what happens.

If the PYTHONPATH for Python didn't get set up properly during installation, Blender doesn't know where it is. You have to go in and specify the directory in Blender so it'll find it, and then the exporter should work (assuming it isn't a mesh issue).

I don't know, this looks pretty good: http://www.cgarena.com/freestuff/tutorials/maya/lowpolyHair/ There are tons of tutorials out there on making low-mid poly hair, and quite a few tutorials on youtube about how to convert hair/fur renderer ouputs into an editable mesh which can then be exported with your mesh.

One! One cost change, ah ah ah! </Count>

That is basically the only limitation though. There are multiple ways around the world to get payment info on file, so it's not like it's a major limitation. The only real limitation is knowledge; learning to model, unwrap, and possibly rig your meshes.

ARC should technically go down by a factor of 10 for a low poly mesh avatar (constructed of 12 tri cubes) versus a typical prim (cubes in this case), but the ARC is modified by the streaming cost as well if I recall. It should still be a significantly lower cost. Culling on the other hand would function almost the same if not faster with the lower poly cube. Less triangles means less back face culling to test, but that's almost automatic now a days because the check is so easy to make in OpenGL. The octree culling should technically remain the same because the corners are still the same sizes, so visibility of the object doesn't change. With regards to the render cost, yes a prim has more polys than the one you made, but the one you made also has a fixed form. Prims are generated programatically. That means the cost of storing them in memory is far cheaper. Now, whether it's 10 times cheaper or not I don't know, I haven't gone hard core graphics programmer to find out.

Regardless of payment info being required, the simple inclusion of mesh into SL makes it "two tiered" in this case. There are the people out there now with building knowledge who will likely pick up on mesh in short order, and then there are people who couldn't build a sphere to save their lives. And try as you might, even though they may understand the build tools for the day you teach them, their sieve like brain (for building) will forget all that you taught them by tomorrow. These are the people to whom the very notion of downloading Blender would make them exclaim "LOL!" at you, followed by some excuse.

The only appearance modifications that will work for meshes are those which adjust spacing (hip width, shoulder width) or those which adjust size/length (arm length, neck length, head size). Anything else regarding adjusting the appearance of the person (breast size, body fat, etc.) do not translate to mesh. Those make use of something called morph targets, essentially an animation blended between two states (super skinny to ultra fat in the case of body fat). This system will not be supported by LL at all.

Well, see, everyone who's interested in sculpties, and now makes them, forces themselves to learn. They learn Blender (or a small part of it), they learn the limits of sculpties, they learn how to add in the export package (JASS or Primstar), they learn that while 32x32 is the supposed dimensions a 64x64 works better (usually), and finally how to texture to this new shape with an odd texture map. Now, suddenly, all they really need to learn is a bit more of Blender, and how to make textures work on what they made (and possibly how to rig and weight an avatar, but that's advanced level stuff and I would expect people to need tutorials for that). For those already familiar with sculpties, the sudden cut/extrude-ness of meshes is most likely going to be a breath of freedom. For those unfamiliar with either, it'll be an easier barrier of entry to overcome than sculpties because suddenly the thousands of tutorial videos and sites for Blender (to say nothing of the hundreds and thousands (and hundreds of thousands) of tutorials for Maya and 3DS) all apply in spades. Everything short of particle emissions (like hair, leaves on trees, or fire). The entry level is lower. The mastery is a long but hopefully enjoyable road.

Gaia Clary wrote: I believe that making a good mesh is not realy "easier" but "different" to making a good sculpty. Yes, you can do better models with mesh, yes you can do better texturing with mesh, yes you can use main stream 3D editors, work like a professional 3D designer Up to this point I was almost thinking it was going to be a, "Huh, you know what? Yes it is easier" post. >3 Gaia Clary wrote: ...but then also you have to: take care about LOD in your model editor, the SL-LOD generator is only good for a quick step (better than nothing) understand how to do model specific UV-unwrapping understand how to optimize a mesh for usage in a game engine understand physics Honestly the only thing you really do need to know from this is the UV unwrapping, which is very much a learned skill. You can be taught how to do it all day long, but in the end it's your own talent at unwrapping new shapes you make that counts. LoDs with mesh however is easier and better than with sculpties because your fabulous looking chair degrades to a mess of triangles as soon as the LoD changes due to all the folding necessary to make independant legs and possibly a backing with posts, and aside from limiting your design choices (no separate legs, no opened back) or dedicating more vertices to enforcing your design (thus taking away detail) you can't stop it. And that lack of control over the LoDs is what turns a lot of people off of sculpties. The other two are what the guide will be for, I'm sure. Gaia Clary wrote: This is a lot MORE to deal with compared to what you need to know when you make sculpties. Sure with sculpties you are limited and with mesh you can do more "what you want", but then you also must know what you want and you must know how to get what you want... So... transition from sculpty to mesh will mostly deal with why a sculpty maker has to give up some habits and how to fill the missing links to create better meshes. Just watch what currently happens in my tutorial... i am at the point where physics and costs come int play... i still do not know how to put that in simple words ;-) There's not a whole lot that a sculpter needs to know about modeling besides "remember that whole, start with one shape and never change its topology? Forget that, here's how you extrude and cut..." Now... Keeping a coherent topology is an entire tutorial line in itself, and the subject of many a school course. >3