Rahkis Andel

I think you should go for it. It's been done and although Codewarrior is right that there is no guarantee "hacks" so to speak will continue to work in the future, assuming this is for personal use, who cares? Of course, I wouldn't recommend marketing something that could potentially break due to future updates. Asides from that bit of encouragement, in a real production pipeline, texturing and rigging can sometimes happen all at once depending on the size and scope of the team's responsibilities. Working alone, you could interpret that as "there's little difference which I do first". In my experience, rigging should happen first. It's often while perfecting your skin weights that you realize "Wow, I really wish I'd added an extra loop here". Anything that can change the topology of your mesh will alter your UVs and therefore potentially break your textures in the process. Textures are not the kind of work you want to have to re-do.

First of all, don't bother making mesh objects if you can't use the Beta grid to test. It's really all about the testing -- on the beta grid there is no real L$ charge. With that out of the way, it's hard to diagnose your issue without being able to see how it looks in blender. Could we see a wireframe of the mesh and armature you're trying to upload?

The odd weights that cause pink colored vertices seems like a bug to me. Keep at it -- I'm sure you're doing fine. The weight painting tools in Blender are actually excellent when you put the time into understanding how they work.

I have had this issue once before. You just need to open your 3d viewport panel (n key) and select each vertex that is pink. You'll probably see a very odd value in one of the weights. Just delete the glitchy bone association with that vertex there and the pink will go away.

You have to have alpha transparency/z transparancy enabled in your material settings or your textures will never show up as transparent. I hope that's your issue, because it'll be fixed in a matter of seconds and you can move on. PS: There really aren't much of any good classes focused on Blender in existence, even if you did want to pay for them.

When you updated Firstorm, did you do a clean install like they suggested? That will supposedly solve a lot of viewer related issues caused by the recent update to the server side baking version of Firestorm. This really doesn't sound like a formatting issue. I don't think there is any .dae you can attempt to upload that will crash your viewer. That's my hunch, anyway.

You're wecome.

Yes, with rigged mesh, we need the deformer. No doubt. All I was saying was that mesh itself (unrigged) is no different than a prim or sculpt.

Explain.

That's a good idea too. There's actually a ton more ways to do this, but that's the beauty of it all, right? Edit: Come to think of it, I don't really think having to tilt the roof either way is saving you time. Create one new orientation and lock to face z and x axis respecitively. There was only one extra button press.

To expand on that last post, here's a roof demo to illustrate how nice the transform orientation panel is. You can actually create your OWN transform orientations which set the z axis to the normal direction of any face you select. Here is how I would recreate your roof: I started with half of a cube on a 45 degree angle and extruded the top faces up. At this point, i have the same issue as you; If I wanted to extrude an overhang, it would extrude along the normal direction of that face, which in this case is not the direction I want. I selected the face opposite of the direction I wanted to extrude, because that one was oriented in the correct 45 degree angle. In my viewport properties panel in the Transform Orientation tab, I pressed the (+) button next to "global". Then selecting a new orientation from the dropdown, you will notice "face" is now an orientation. If you select that orientation, you can then rename it as you wish. Then I extrude (e) and immediately right click to cancel the move operator, because it will still be going in the normal direction. I then move (g) the face lock it to the "face" z axis (z -> z). And so now I have the desired overhang and can do the same with the other side. You would just use the opposite side of the roof to grab the orientation for that 45 degree angle. You can have as many orientations saved as you like and you can delete them by pressing the (x) button in the transform orientations tab. Hopefully this demo gets you exactly what you wanted. Cheers. Edit: Come to think of it, I didn't need to select the opposite side of the roof to get the correct angle. Since I wanted a transformation perpendicular to the 45 degree slope of the roof, I could have just locked the transformation to the x "face" orientation instead of z.

I have edited my post because the end of it was rubbish. I didn't really explain it properly and I've remembered the "right" way to do it. As Aquila pointed out, extrude is two functions; First the selection is extruded and then placed into translate mode with the orientation being locked to the normal z axis. That moves the selection along their average normal direction only. You can get that same behavior without extruding first: All you have to do is open your viewport properties panel (n) and scroll down to the transform orientations tab. It is set to "global" by default. This produces the behavior you know now, which is you enter a transformation mode and press x, y or z once to lock your transformation to that global axis and press it again to lock to the local axis. You get the same behavior by switching the transform orientation to "local". Either way, it just toggles between global and local. If you set the orientation to "normal", however, the second time you press x, y or z it will lock it to the face normals. Specifically, normal orientation takes the face normal direction, or average normal direction of all selected faces and sets the z axis to that. So if you want to scale, rotate or translate along the face normal direction, you want to lock it to the normal z axis. if you select a face and press (alt+s), that has the same behavior as scaling along the normal z axis. That is a really useful hotkey for inflating your mesh after several smooth operations because you tend to lose a lot of volume. I'm surprsised there is no such hotkey for move and rotate -- perhaps they just aren't as often used. Personally, I often need to move faces along their normals in architectural modeling, so I'm glad I remembered this method.

I think the tip you were thinking of is that if you hit a transform tool and press x y or z to lock it to an axis, it will lock it to the global axis first and if you press it (x y or z) again, it will lock to the local axis, which may give you a different result. Hopefully I didn't mix those up, but you get the idea.

And I agree with you.

No problem.

I already conceded that she probably didn't need to worry about the tris in this case. On several occasions. I think you're splitting hairs here, and I'm not sure why. Anyway, back to the real topic... @Sienia: I think the flowers look okay so long as there is not a subsurf applied to them. I could give you a demo of how to reduce them further, but I'm not sure the improvement would be worth the trouble for you. Edit: I should mention that I'm starting to notice that you are working with a subsurf applied to the editing cage. I wouldn't reccomend working this way because it's giving you an inaccurate vision of what your mesh will look like in game. In game, your mesh will look like a subsurf level of 0. (no subsurf) Come to think of it, if that is all the detail you had before and you had a subsurf modifier applied on top of -that-, it's pretty clear what was causing your mesh to be so overwhelmingly dense. You may have to step back and rework your topology with the non-subdivided mesh in mind to make sure your curves are still curvy.

What if down the line she wants to add a loop cut straight through that trim edge? It's all triangulated so she can't. She would have to extrude a new row of faces. Will it matter in this unique case? Maybe not. That's why it's the rule of thumb and not just the rule. Quads are undeniably easier to work with. That doesn't mean you're not allowed to so much as look at a triangle, or else. Besides, we're technologically beyond the point where we will make significant gains from losing a few edges here and there by making heavy use of tris. That kind of really low poly modeling is rather unnecessary here, and I see no particular benefit to it. Clearly, you do and that's great. Difference of opinion. However, it isn't really accurate to say that a tri is more reliable than a quad. We have a triangulate modifier; you can always know what your mesh will look like when triangulated -- there is no guess work here. If you have one triangle in an all quad mesh, when it is all triangulated, that one triangle is going to stand out a little bit. The two things that I can think of off the top of my head that can make tris disadvantageous (asides from the workability factor) are: Smooth shading, lighting and shadows will be subtly less consistent across the affected faces. Normal maps will have a higher quality when evenly triangulated meshes are used. How much either of those things matter depends mostly on how big of a perfectionist the artist is (disclaimer: I am one). That said, if there are disadvantages to a method and no real advantages to it, does it really matter how minor the disadvantages are?

I think what you missed is the "Working mesh" bit. That phrase was up to interpretation, I admit. That is to say, go ahead and triangulate your mesh before/during export, but while you are working with it, keep it to all quads. As for why: I'm sure you already know the answer to that.

Now you're getting it! My only critique is that I would reccomend avoiding triangles in your working mesh. Eventually, you're entire mesh will be triangulated, and any triangles you put in yourself will not be split and may cause irregularities that can have some minor but avoidable complications. Plus, quads are a million times easier to work with.

No, that isn't bad topology at all. You should delete every other edge as you are doing and it won't affect the shape much at all. It could still be improved on top of that, though. I would also like you to try something for me: 1. Enter edge selection mode. 2. Select every other two vertical edge rings (ctrl+alt+shift+rmb). In other words, select two consecutive edge rings, skip one and select two again until you make it to the other side of your object. 3. Deselect everything from the bottom two edge loops that define the wavy shape. 4. Edge collapse everything you've selected (x -> edge collapse). 5. Clean up the leftover triangles by dissolving them. This way, you maintain the wavy shape you want, but remove the density where it isn't needed, higher up.

I'm not a master of game physics by any means, but I can answer at least a few of these questions. The physics shape is just a shape. it doesn't need to have a UV map associated with it nor does it need to have any materials. Remember that the physics shape is not visible, so it has no renderable information to give to the engine. So the answer to your last question is yes by default. Your physics shape need not have any relation to the visual shape so long as it allows for accurate physics simulation.

I think they mean quads...As opposed to tris. 4 sided polygons. I guess they are saying that you should convert to triangles, but I disagree. Assuming you're using a recent version of Blender, the exporter automatically triangulates your mesh upon export.

Yes, That's expected. One thing you could do is apply the subsurf and manually remove all of the edges that do not define a shape that needs to be a smooth curve. As long as it's reasonably smooth, that's enough to look good at any reasonable difference with a texture. Just realize that the uploader starts having a panic attack at around 25k triangles (don't quote me on that). Also realize that the default avatar is around 7k triangles altogether. No single article of clothing ever needs to be more dense than an entire character model.

Do you really need the subsurf? If not for that, the mesh would be fine. With smooth shading, I doubt you'd know the difference. Remember, this is a game, not an animation.

My personal workflow is likely very different from yours. Here's of how I box model the topology of the lower body.In the video, for demonstrative purposes, I added a subsurf modifier and used the sculpting brushes to shape the model, but in reality, I'd add a multiresolution modifier and shrinkwrap it to a concept sculpt. If I were going to use it with the default avatar as clothing, I'd match the edge loops up with the loops of the avatar, adding/subtracting as needed. The closer the match, the better the model will deform with the avatar.