Da5id Weatherwax

Every word here is true but there something I will add to it, specifically for those people who are capable of the "vision" in MD and other tools but find themselves stumbling when it comes to translating the results of that into a model for SL or any other 3d environment... We're geeks. We do what geeks do and we use "terms of art" a lot. This can obscure that what we're really talking about is a way to think about the project. A "model" in MD or other design-oriented software is not a 3d asset in the same way that a fashion sketch is not a sewing pattern or a design sketch for a piece of furniture is not a cutting list for a carpenter. I used these two examples advisedly, because in both cases to get from the sketch to something usable you need to be thinking in the same way as you would to get from design to 3d asset - and it's something that, shorn of all the geeky language, many of you already know how to do. Let's stick with sewing, since in many cases when raising these concerns we're talking about clothing models. We talk about "edge loops", "topolgy" and "UV mapping" when we're talking about many of the same concerns involved in creating a pattern and laying it out on fabric. If you sew at all you've probably worked with stretchy fabric. You know there are ways you can construct a garment that work with it and there are also wrong ways to do it, that might conceivably look ok pinned to a mannequin but will never work on an actual body. The skin of your model is like that, we talk about working with quads and keeping clean edge loops and we're thinking in exactly the same way as you are when considering whether a particular piece of fabric should be cut on the bias or not, we're looking at the grid that makes up our model like you look at the weave of your fabric and just know that "it can't be made to stretch like that there" and you have to cut that piece differently. If the grid of your model looks too tortured to be made in cloth, it's probably not going to work well as a 3d model either. When we're saying "your UV map is inefficient" and you can't get your head around that, try thinking "Don't lay out your pattern like that, look at all the wasted fabric. That stuff's expensive!" The edges of UV islands are called "seams" for a reason! Too many vertices? that's like a design that needs to be pinned to the mannequin every couple of inches to hold its shape. You know you can do better than that in cloth, you can do it with vertices on a 3d model too. None of this is anything you can't do, you just need to not be daunted by it, make the link between it and the skills and knowledge you already possess in creating stuff for the "real world" then see how the same approaches can translate well into making your creations not just "real" but also "good" in SL too.

I "referenced Snow Crash" on day one of my SL existence - at username creation

Yeah, this level of custom stuff is exactly the sort of solution I had in mind - I've done it before with my SL "stage gear" where I can switch guitars to the one I'm actually about to play simply by equipping it from inventory - it vanishes from its on-stage stand , it forces the detach of any other member of the set that I might be wearing at the time (which then, in turn reappears on its on-stage stand) But every single one of those meshes is mine, a copy of my RL instruments, down to the slight damage to the headstock on one of 'em, so already having having the models both inworld with any perms I might need and also in blender just made it a matter of designing a comms API and implementing the scripts. And that was a somewhat simpler task given the limited and well defined circumstances that this API needed to function in. There's plenty of us on here could make what the OP is wanting - and if offered a big enough carrot would... He deserves to know just how big of a were-rabbit he's talking about feeding though

A custom gun cabinet is easy. We just talk over exactly how you want it to look, whether you want it scripted for interactivity in any way and the rest is just time until you're happy with the result. It's the bit about "having the guns in there that I want" that gives me a small amount of pause. Scenario 1: These are guns that already exist in SL, they are creative constructions (not modeled on a RL weapon) that you own. That's a whole can of worms - would you, for example, want the guns "in the cabinet" to disappear from there when you attach the "functional" gun from your inventory? Would you just want them to be cosmetic and always appear in there? Either way I'd have to potentially recreate another creators product (albeit probably at a lower resolution and only in part since you can't see them from 360 degrees around if they are in the cabinet, even with the door open) and interactivity of any kind would require the gun to be mod perm and capable of accepting an "interact with the cabinet" script - something that a lot of combat systems anti-cheat coding will flag on, even if the creator left the gun modifiable. A purely cosmetic non-functioning "lookalike" in the cabinet presents fewer problems and would be meshed as an integral part of the cabinet so it could not be turned into a standalone object but I can still see some creators objecting to their creativity being the source for it, even just as reference images - and if they did choose to object they would have at least a moral case if not a legal one. Scenario 2: These guns aren't in SL or they are but are representations of RL weapons - for example you might say "I want it to contain a Wingmaster, an AR-17 and a P-226." Any IP concerns would then be with the manufacturers of the RL weapons, and in that I'd be on no more shaky ground than anyone else making a copy of a RL weapon in SL. For the most part folks get away with that so let's assume that we can dispose of these concerns. You want the guns in the cabinet as static props? Takes extra time, more of it the more faithfully you want them modeled. You want them interactive at all and you being able to "take one out and equip it" and then we're into the same concerns as scenario 1, with the additional wrinkle that you may end up asking me to make the "equippable" version of each weapon too, which would lead me into asking about how "functional" you want its scripting, any SL combat system you wanted it to be used with, whether any such has a development kit available and at what cost etc... None of this is impossible. If I haven't put you off yet, let's talk. But be aware that you are potentially talking about a major "product development" project, that could involve obligatory collaboration with other SL creators (assuming they would be willing to) and upfront costs, whether you ask me to take this on or somebody else. Neither I nor the majority of other SL creators will be looking to gouge you but you might find yourself either reducing your requirements to eliminate the components that would be most costly to develop or suffering a little sticker shock at the cost of meeting them all

As the security manager for a club I must endorse Lewis' suggestion 100%. Fortunately the rest of the managers and the club owner are highly responsive so that if any of my team witnessed something like this the group would be locked down to invite only and scripts disabled for non-group members in minutes... and it would stay that way for as long as required. We have a really good relationship with our estate's management too and they would be as unwilling to have this behavior going on on their turf as we, so the odds of folks who made a nuisance of themselves this way collecting a multi-sim estate ban would be perhaps a little higher than they anticipated when starting their "little bit of fun"

Back in the day few folks used that option. Then a rather predictable cycle happened. The griefers and trolls got quite creative, they found all sorts of ways to really genuinely mess with folk's experience of SL. In response, land and venue owners got pretty good at promptly booting and banning 'em. Of course, the idiots would then descend on a place with a bunch of throwaway alts - to which the response of the place's management was to flip on the switch that said "nobody under 30 days old." The rippers were using throwaway alts too, because they didn't want their main banned if they were caught at it, so store owners started flipping that switch too. It gradually became standard practice for the managers of a sizable fraction of the grid to set this option, and it has remained so for quite a few places. Not for the same reason in all those cases, to be sure, but the common theme in those varied reasons is usually seeing the "throwaway alt" as some kind of risk factor. It is unfortunate but also unavoidable that if, as a venue or business owner, you decide you're going to exclude the "throwaway alt" from your place, in the process you will also be taking all the noobs out of your customer-base too. I think there is a pretty strong argument for folks to consider that decision more carefully rather than just setting that option as a matter of course, but I'm pretty sure that even after considering it that way no more than about half of the places that have that option set would unset it. Even though the effectiveness or net benefit of setting this has never been properly demonstrated. it's certainly more fact-based than the belief that setting all your products nomod and making folks use scripts to resize or recolor anything protects them from being ripped - and just about everybody still does that, even a lot of folks who are otherwise quite smart....

I'm really sorry if I came across as unhelpful, but in all honesty my - admittedly a bit glib and brief - answer was why it wasn't working. Look at it without the texture applied, looking where the edge loops are going, if they are following the contours of the fitted model well... Now, on this one, in the picture I replied to you can see a couple of serious issues there. The horizontal loops are going up and down like a tarts knickers without any real justification for them to do so in the shape you're trying to achieve in the model. The paths of the vertical lines are so distorted that even without the somewhat funky triangulation it would be hard to trace them. You do expect that there will be some curving around - you want your edge loops to curve across the contours of a body, dipping down to outline an underbust curve or accentuating a cute butt a bit - but when the edge loops so blatantly do not respect the form they are trying to outline you are going to have problems. If you beat your head against the UV unwrap hard enough you can compensate for this - It's certainly possible that by tweaking the UV map vertex by vertex you will be able to achieve a distortion-free mapping of your texture on this model as it stands but that's going to be a lot harder, take many hours more and be and front-loaded with problems if you don't clean up the topology before you go for an initial unwrap.

That thing needs some serious retopo anyway

This may be something in the drivers for your audio device. Many incorporate an anti-feedback strategy where the mic sensitivity is reduced or even muted when the computer detects the mic picking up what it is sending to the speakers. Some don't even check, they assume your mic WILL pick up speaker output and do it anyway.

Just IMHO but... If it's supposed to be an ad pic for a SL product then it should be photographed in the official viewer and get no postprocessing apart from cropping. If a user cannot make their view of the product look like your ad pic even on ultra graphics level in the official viewer, your ad is dishonest. Particularly so if it isn't being rendered in a SL viewer at all. It's perfectly OK to make the product so that it can be made even prettier using the higher quality graphics possible in other viewers such as Black Dragon and if you are taking "art shots" then by all means do that and postprocess it to your hearts content but if it is an ad, it should show the potential buyer what they can reasonably expect to see in the default viewer not a third-party one. At the very least, if the ad pic could not be taken in the default viewer then you should clearly state this to avoid deceptive marketing - something that can get your product listing flagged.

six/five and pick 'em. It would all depend on other factors. If, for example, the model would not otherwise be using a normal map at all (unlikely, I know but bear with me for the sake of the example) then you'd obviously be more efficient baking the weave into the diffuse - if (and only if) you can get acceptable results baking it like that there is no reason to load another texture just to normal map the weave that looks "good enough" without it. At the (equally unlikely) other extreme where there is no texturing in the diffuse apart from the weave but there are features which are normal mapped, since you're loading the normal map anyway if (and again, only if) you can get away with a "default blank and tint" for the diffuse and just normal map the weave then that will be the more efficient option. Between these two silly extremes, though, you're thinking about a huge raft of other factors and trying to strike a balance that gets a good enough result while minimizing the amount of both geometry and textures the viewer has to download and render. Remember that "the perfect is the mortal enemy of the good enough" - which is why we get folks uploading some of the insane stuff they do and saying it's "better" when it may be more faithfully modeled and rendered but nobody will ever see the difference.

Not knitted - that really needs the AO on the yarn in addition to the normal map. Depending on the weave a woven fabric is possible with a flat diffuse and a normal map alone but the coarser the weave or the more "featured" it is - such as overshot weaves, for example - the more you get to needing the AO for its structure baked in. A tightly woven fabric made of medium to fine yarn, though, normal mapping is enough - you see "just enough" of it at normal viewing distances to know it's there but that's all that is required (you may need to make the normal mapping a tad stronger than you would if the fabric texture was baked into the diffuse). The effect breaks down if you've got the fabric right up against your camera's near clipping plane but you would design a texture/material intended to be viewed from that close differently.

No, it's not just causing framerate drops in "their place" - Amongst the biggest offenders in this regard are avatars, clothing and accessories - they are causing those framerate drops for everybody, wherever they go. And you can't genuinely point at "people's internet speed and computers" as the cause. I'm plugged directly into a fiber connection and I still see download delays in the texture console when somebody who is wearing several dozen 1024x1024 textures walks into wherever I am. I can tell without actively looking when somebody wearing an insane 500ktri hairpiece walks in to the club where I'm performing and I promise you I do not have a low-end GPU (if it were the club where I work they'd be getting the hairy eyeball since I'm the security manager there) Now, personally I think that the more aggressive solutions some folks propose will never fly - There is no percentage for LL in trying to weather the manure-nado that would result. A steady, incremental approach that winnows out the worst offenders while making it easy for creators to keep up with the changes as they release updates in the regular course of their business, on the other hand, is something I would wholeheartedly applaud.

Something I have believed for a long time is that the capabilities of SL rendering with full use of materials have been seriously unappreciated on the "mainstream market" - Modellers use normal mapping for detail but so many people are still baking shadows, when at most they would need a tiny amount of AO, they are still baking stuff into their diffuse map that the render pipeline can handle if you let it and it can easily make the final result look worse. Sometimes what you can achieve with just the right normal and specular maps, including the capabilities built in to utilizing their alpha channels, while leaving the diffuse map as a flat color is surprisingly effective. I'm sure a major driver for this has been LL's reluctance to finally nuke the legacy renderer - for as long as it continues to exist there will be people running a low enough graphic setting to use it, and to cater to those people I fully understand that creators have to keep the "baked everything" in the diffuse map... but then you run head-first into the disconnect where they say "turn up your LOD factor" but don't say "turn on advanced lighting" when the latter is less taxing on the GPU than the former! If LL are going to finally bite the bullet and dispose of the legacy renderer that will be huge - folks will have to light their places properly, which in turn will mean that things made for "realistic" lighting will be rendered how they should be and when the incredible creativity of SL-folks really gets focused there I'm sure there are dozens, if not hundreds, of people out there who will push its limits in ways I've never even imagined. As for the fabric test.. I have to hold my hand up and say that it was a real quick-and-dirty recreation of an experiment I performed over a year ago and there are a lot of flaws in it. If I'd been being serious I'd have cleaned up the artefacts in the photo I sourced the fabric structure from much more aggressively, left in they are far too noticeable when making the slubs tileable. The normal map needs to be stronger, the slubs don't "pop" from the fabric surface as much as they should and the texture of the underlying weave is not as strong as it should be. The iridescence of something like a dupioni fabric, where the bicolor effect is entirely due to using two colors of thread in the weave is much easier to create than a true iridescence or opalescence - for this the specular map is just a higher contrast version of the diffuse map tinted a different color. True opalescence or iridescence is something I've only had limited success in simulating with SL materials but I'm a horrible tinkerer and each time I come back to it I get closer - I might even achieve a result I'm prepared to let somebody else see one day

Quick test with an indigo/crimson warp and weft on the beta grid. Slubs normal mapped to raise them slightly, darkened slightly in the diffuse map and blackened completely in the specular map. Base color of the diffuse map is the deep indigo, with the crimson tint on the specular map. Glossiness 51, Environment 0. Official viewer set to ultra graphics. The object is just a test piece created by using blender's cloth sim to drape a circle over a small sphere

Heaven speed the day!

be fair - getting fabrics right in SL rendering, particularly since you have to account for folks not having advanced lighting on and therefore not seeing materials to their full effect actually takes a modicum of sneakiness. You wouldn't want the poor dears to actually have to think, would you? But it IS worth it, though - judicious normal mapping and tinting of the specular map is, as far as I know, the ONLY way you'll make a dupioni look anywhere near right in SL

The really cray-cray part, Kyrah, is that almost nobody seems to get that there is a prim-era trick that can be made to work on mesh too - a "face" (material) of the model that hasn't been unwrapped at all - ie still has every quad on the model UV mapped to the entire texture (that's how blender sets them when creating a new UV) - will usually take a small tileable texture in planar mapping and have the 'repeats per meter" in the SL edit window work.... Seems to me that something like roads would be an ideal time to see if this works with a quick upload to the beta grid... (ETA: IT's real easy to break if your model isnt clean quads, because the default UV mapping of tris is less predictable as to which corner of the texture the vertices are on but if your road surfaces aren;t clean quads, you're probably doing a lot more wrong than the texturing!)

Heh, Niran, and folks call you "touchy" (or worse)... For me, your snarky style (including self-snark so you're clearly an equal opportunity snek) never fails to make me grin - particularly since you manage to do it while being technically correct too

Absolutely! The OP was talking blender and that's what I use, so I was talking blender right back. I totally missed that you were coming in with a more app-agnostic approach and you're right, I should have thought a little further outside my "blender box" - because now that I have been nudged into doing so I find myself 100% in agreement with you.

Unless the bake happens before the mirror modifier is applied and "made real". Then, only the island for the "real" part, not the overlapping one for the other half generated by the modifier, actually exists and is the only one baked. That's why, in my post, I said " unwrap and texture it before "applying" " With normals you definitely have a point. My personal rule of thumb is that if all baking can be completed successfully before applying the mirror modifier and actually creating the duped verts, the overlapped islands will usually be ok. If I have to do any baking after generating the overlapping islands then I may as well leave it all until then because I will need to separate the islands anyway.

It's worth noting that if you are building a model using the mirror modifier and the two sides are going to be textured identically, unwrap and texture it before "applying" the mirror modifier to convert the "mirror" into "real geometry" - that way the UV will be generated - and any maps baked - with the mirrored islands already overlapped as in @Wulfie Reanimator's example since this modifier duplicates the mirrored vertices and changes only their position, all other aspects of their data, such as their UV coords, are preserved.

I don't think there's a cuisine anywhere in the world that doesn't have a sauce made of fermented fish somewhere in it, from Worcestershire to Nam Pla..... And it does go in just about everything

It's a totally different profile to the heat too - The pepper profile for southwest and Mexican cuisine is deliciously complex from the balance of different peppers alone, but the number of different types of pepper bringing in both heat and flavor is lower in Thai and Indian cuisines - they have other, non-pepper, complexities of flavor available to them that are not locally available to the southwest or Mexican cook - and just take a short boat ride out to the Carribbean and the profile changes again, with different local pepper types.

I make a pretty wicked wasabi mayo that goes really well with my recipe for any strong oily fish cooked in soy and ginger...