[Rigged Clothing works fine in blender, but looks wrong in world.]

5 hours ago, Ickarus0 said:

Not entirely sure what you mean here. I thought you said I should try not using avastar? Aren't the 'classic' and 'fitted' options things that I would have to do through avastar?

Yes i have been telling you to try with and without avastar. I think the problem is the Blender version, at this point. What you show in the first picture, exported with default Blender collada from previous version, shows exactly the collision volume bones problem that Avastar addresses (scaling on the joints). Basically it was working correctly, but the SCALE of the cBones isn't supported in Blender and all the item got squashed like that. Try to install Avastar on that previous version (discard Blender 2.79 for now) and things should go definitely better.

[The importance of low poly count]

2 hours ago, NaomiLocket said:

A stripped down basic flat shader will render hundreds of thousands to millions of triangles without sneezing on old outdated hardware. Though if the controlling program, or shader is written particularly poorly, it might not. But that is a hard one to get wrong.

Not really that hard, if you're writing your own. SL got their materials, based on opengl blinn/phong basic model and modified with custom maps data and encoding. There is no shader i know of that has an "environment" entry, i know of "ambient", but it doesn't do what SL's environment does; the closest type of data in a shader is the f0 which is supposed to indicate a surface's reflectance at normal. But i supposed that the works LL are doing in parallel with the main, more famous Animesh project, is key in reducing ALM's impact on render stats. I think Rider Linden is in charge of renewing the Windlight system. And for a good reason: windlight doesn't actually have an environment component, and the areas marked with white in a environment map just shows a dull default skydome in the object's reflections, no trace of the windlight itself. So, to me materials are cool, but the shader can be optimized and improved with windlight going through the environment map.

As per polygon count, as i often say you should use the amount of geometry to actually make the object volume clear also from a distance. The fact that Chinrey pushes so much towards optimization is due to the other known fact that people would upload sculpted models straight from ZBrush. A flat shader can help an old machine render a few milion polygons, but it can't when those "few million polygons" is found on each single item in a scene.

Making a good model is a matter of compromises: i need to keep the polygon count as low as i possibly can because a) fewer polygons make easier editing b) too much fine detail modeling makes UV mapping imprecise and more difficult, the model is more prone to modeling artifacts (like non planar/overlapped/too small faces) in areas where textures might have done the job perfectly fine, as long as the detail doesn't need actual "volume". Why wasting time and polygons on polygon detailing if the shape hasn't to really be part of the object's silhouette? Hence it's a matter of general optimization, where polycount gives its contribution in a virtual world where "high poly = high quality" in most of the end users' minds. When i got a reply like "But it looks better, it's not like games where you can see the jaggyness of the polygons, this is Second Life and it has to look life-like, hence i don't care if it's heavier, i choose this. Otherwise, we could just stick with the classic avatar, it doesn't make sense". It's easier to smooth/subsurface/turbosmooth a character and whip it into SL as is, rather than optimizing the vertices locations so to have roundness where needed. So the so called "designer" did: easier and faster. Plus, all the small wrinkles on your skirt/shirt are modeled one by one, which shows you're a professional and a great artist, totally worth those 30K polygons per piece of clothing, not those fake/painted folds those 3D noobs make (sarcasm here). Assets so much better than those from the "3D noobs" that people can't rez them for something like five minutes. Should i remind of the famous high quality mesh head with a brain model inside, to show people that it actually attached but it's just taking its time to rez? (more sarcasm here).

To me, as i stated in the animesh forum already, it always boils down to the general design of your item. Every part counts, from polygon count to textures (shaders also, but we have no power on that) and scripts. Doing your best on all sides ensures your best optimal product (for the time being, until you improve even further), and that's what every content creator in SL should aim to, for the platform's health in the first place.

[Rigged Clothing works fine in blender, but looks wrong in world.]

I think the shape keys come from the Avastar plug in for the fitted mesh system to work. Indeed, what i would suspect is that you're not using the default shape, somehow, and the whole thing gets shifted. The whole fitted mesh system in Avastar is a sort of workaround to allow volumes display, when Blender doesn't actually support what the volume bones are supposed to do. The only thing i can think of, right now, is that your harness is not "fitted" in Blender when you bound to armature. There should be a drop down selector to choose between "classic" and "fitted". Make sure it's set to fitted, of course. You can double check whether you did it already or not (in case you can't remember if you did) by going to the shapekeys section: if it shows something like what you're posting here from the body, it's already attached as fitted; otherwise go ahead and try that!  

[Rigged Clothing works fine in blender, but looks wrong in world.]

3 hours ago, Ickarus0 said:

I just opened up the male JOMO dev kit, clicked my harness, shift clicked the rig, then clicked 'bind to armature' with weight set to 'meshes', and the 'clear weights' and 'interpolate' options checked.

Indeed, you did copy the weights from the avastar model, in my opinion. Try using Blender's native parenting and do: select the mesh, then add the armature to selection, ctrl+P and set that with automatic weights. You can follow that tutorial using the Data Transfer modifier, or you can do a quick test using the regular copy weights (select the body mesh first, then the harness and use the CopyWeights button in the T panel on the left) to just see whether things change.

As a side note, i seem to remember that the Data Transfer modifier needs to be applied before it's possible to export, to finalize vertex groups and weights, reason why i think you got that warning for unweighted vertices. Since you didn't mention this detail, i thought you may give a shot to this if you didn't already.

 

 

[The importance of low poly count]

9 minutes ago, ChinRey said:

Hmmmm...

A team of professional developers who really should have known better, does a bodged up, left-handed sub any standard job and then hand the result over - without any proper documentation - to a bunch of ignorant dabblers who have managed to fool themselves and others into believing they know what they're doing. Who's fault is it when thing goes wrong? Hard to say but really, anybody with enough intelligence and skills to write a working script or program at all, ought to know that superfluous data is just that.

Lack of documentation and clear example based explanation has been the main reason for me. We simply had the option of a custom oblong sculpt map right out of the box, with no clue around about the proper use. Of course anyone with no tech mind would think "texture encoding : higher res = higher precision", which ended up to be a question someone once asked me "how can a 64 pix square image have more precision than one at higher resolution?". Somewhere they had read about the size, but they just knew better, as you pointed out  

[The importance of low poly count]

9 minutes ago, ChinRey said:

No, it's my fault - aka a typo. I was too lazy to do the math so I used a spreadsheet and typed 128*182 rather than 128*128 and didn't even think twice about the strange result I got.

Apart from that, there is a perfectly good explanation why I managed to make such a newbie mistake, I just haven't made it up yet.

That explains it. So in the end, it's still the exporters' coders fault if they did even allow sizes not dictated by the "grid" sizing.

[The importance of low poly count]

3 minutes ago, ChinRey said:

Unfortunately, at least three of the most popular old sculpt applications, Prim Generator, Tatara and Wings 3D generate oversampled maps with 23,296 rather than 4,096 pixels. Those maps are horrendously laggy and also far more prone to render errors than properly made ones.

That's who wrote the exporter's fault, i assume. How can one export an image of 152.63 pixels per side? How did the application accept that, in the first place....

[Rigged Clothing works fine in blender, but looks wrong in world.]

1 hour ago, ChinRey said:

But most likely there is some other unrelated factor that causes Ikarus' problem.

Another thing i couldthink of, is that the maker has used the female skeleton, while he's clearly using a male shape, both in avastar and inworld. The male skeleton has quite a few flaws, especially regarding the wrist area and, in general, when making an avatar that uses joint positions it's always good advice to start from a female skeleton. But i guess this kind of information should be included in the devkit docs.

 

1 hour ago, ChinRey said:

The JOMO body doesn't have clothes layer though so that can be reason in this case.

*can't be the reason* but i understood what you meant - Dang, i wanted to give them the benefit of doubt  

1 hour ago, ChinRey said:

may be that the maker of my shorts has tried to compensate for the flaw

In such case, it's very sad. How's a clothies designer supposed to work without a matching shape avatar? This is one of those mistakes that slowly kill a mesh body off the market because there's no garnment available. Who would make clothes on a constant basis for this body if you have to lose so much time in trial and error? You go and try, if it works within a short amount of time you keep it, otherwise the body is discarded for the release, next outfit maybe goes better. Which leads to a lack of accessories and clothing for particularly flawed mesh bodies. At least this is what happens to me with Aesthetic. I try and see how big of a discrepancy i get this time with the model i'm working. If i can get acceptable results in a short time, it goes to the release package. But the shape difference and weights (heavy) imprecision most of the times leads me to discard the Aesthetic version from that release. In 3 hours i rig on 6 body brands, i don't see why i should be wasting 1 or more hours just on that body because the devkit is extremely loose.

[The importance of low poly count]

1 hour ago, ChinRey said:

In case you misunderstood, I didn't doubt what you say.

I didn't misunderstand what you said, i just pointed you to more indepth info for your understanding. Flaws and general issues that sculpts always had can certainly be better explained looking at the feature's history.

 

1 hour ago, ChinRey said:

it's a very weird and seemingly inefficient way of doing it. A sculpt map is nothing but a list of xyz vertice coordinates and their UV coordinates are hardcoded constants

it would be inefficient if the sculpt map was baked onto a too big resolution image or wrong conversion to polygons settings. Making sure that the conversion to polygons occurs using a specific set of settings, you get the grid UV as you need it for sculpts and a matching size sculpt map is being generated. The difference is in the ability to generate the polys from the nurbs surface interactively, so as long as the final number of vertices is the same, you can generate the same sculpt as a square map or as an oblong, depending on the spline's number of spans, just by changing a few parameters in the splines' history. Besides, the fact that it is a constant grid makes possible to use a folded mesh plane that respects the same number of vertices for the type of sculpt map you're making. It's probably easier approach, but it forces you to recreate the sculpt-compliant object if you want to change the output map size. Using Nurbs surfaces, instead, you can get that change from the surface construction history with no effort, because the polygon object gets generated as a folded plane with flat 0-1 UVs.

[Rigged Clothing works fine in blender, but looks wrong in world.]

4 hours ago, ChinRey said:

Here is a closeup of pair of shorts from one of the two biggest sellers of JOMO clothing:

that may well be some room left for the texture layers, which hopefully soon will be a bad memory with baking services extended to meshes. However it is a common problem to many devkits, the body shapes aren't always a perfect match. Maitreya and Aesthetic to name a couple, this latter also has different weights from the inworld model! In my opinion, it is a matter of how the dummy in the devkit got the weights copied over from the original model. And before that, the aggressive decimation that some of those go through may have affected the model's volume as well as the lack of geometry in key spots to capture that area's weights. Sum all up together, perhaps with imprecise copy weights settings, et voilà you've got awesome discrepancies. 

However, my guess is still that Blender+Avastar may have copied weights from the classic avatar, judging from the pretty harsh deformations shown in the picture. The distance from the body is really exaggerated, while on the classic avatar it appears to be sunk in the torso.

Another thing that, if not handled correctly, can lead to issues in Blender is when the character was made with multiple bind poses in mind in another software like Maya, thing that Blender handles for you only via Avastar's scripts for you to *work with* different bind poses, but it doesn't handle a custom bind pose import. And a bind pose can also be involving collision volume bones, which give volume to body parts. If the devkit was exported from a thinner/thicker/taller/whatever shape, in Blender you'd get that as rest pose, while the bindpose (the original pose used for binding skins) was just lost. And there you get a consistent discrepancy with a sort of "fixed distance" between the garnment and the body, like the one ChinRey shows in her last picture. There may be a lot of concurrent causes to give us this devkit discrepant results with the inworld model they're supposed to support. I cant believe this was made on purpose, it would be plain stupid.

[The importance of low poly count]

5 hours ago, ChinRey said:

It is of course possible to make a polygon from a NURBS but it is a very akward method and if that actually is how the rendering sofware handles sculpts, it would explain why they are so strangely inefficient.

http://wiki.secondlife.com/wiki/Sculpted_Prims:_FAQ Qarl Linden, that's the exact name, is the developer who came up with this idea starting from the basic features a NURBS surface give: a planar square UV regardless of the shape. The Maya workflow is very similar to the workflow a sculpt generator had, in the past. I can't remember its name, it worked with a stack of "slices".

NURBS curves are the ones which create the main "low res" set of Isoparams, the "grid" as you call it. You can also set custom isoparams to fix a grid line in place. NURBS surfaces are then converted into polygon meshes with the same UV grid derived from the NURBS coordinates. The conversion to polygons sets the subdivision rules, and a specific setting makes them 100% accurate with the same subdivisions a sculpt needs. Strangely,  wisely using this method gives the most LoD resistant sculpts.

[Rigged Clothing works fine in blender, but looks wrong in world.]

I see the same jaggy deformations that the default avatar shows. I need to ask whether the jomo avatar is fitted or not in the first place. Then, in your pictures it's easy to see, but i noticed the armpit deformation in Blender, and it doesn't seem exactly the same on the inworld avatar. Since you haven't provided details about the procedure you followed, i can just give you my guess there.

So, at current state, if you have used Avastar copy weight features, you might have copied the weights from the classic avatar instead of the Jomo avatar. Use the Data Transfer modifier instead, making sure to point to the Jomo avatar body object. Make sure to Limit the number of influences to 4 (or less, never more than 4). It's a tool available in the weight painting tools, in the panel that toggles with T. You also need to remove the unused vertex groups before the export, but I don't know how this is performed in Blender.

[The importance of low poly count]

6 hours ago, ChinRey said:

Not really. A sculpt is a grid while a NURBS is a procedural shape

Sorry, but it's very much really the case, Chinrey. The very first sculpt exporter was made by Q Linden, for Maya, starting from a NURBS surface which, by definition, is a square planar UV surface created procedurally. NURBS converted to polygons get a polygon UV that is the same as the NURBS and covers the whole UV range. Exactly what a sculpt is supposed to have. Therefore, sculpts in SL are direct descendants of NURBS surfaces. Don't look at this account birth date, i'm older than that, enough to have seen the introduction of sculpts.

[The importance of low poly count]

3 minutes ago, ChinRey said:

1 hour ago, OptimoMaximo said:

To me, sculpts don't have any use anymore.

There is this land impact bonus though.

Yes i know a sculpt has a capped LI i comparison to a mesh. What i meant there is that, to me, sculpts don't have a use anymore. I don't find any use for them in what i usually make. I don't like them, i never liked to work with NURBS and sculpts are their direct descendants.

 

8 minutes ago, ChinRey said:

Beq once told me that the mesh (and sculpt) data even includes all the prim twist parameters even though they're not used of course.

Yeah, this, for sculpts was said

1 hour ago, OptimoMaximo said:

Then, the sculpt map comes into play. It is a one unit cube RGB displacement map, which makes it very similar to a vector displacement map with the difference that the mesh data is assumed, instead of being embedded

Assuming the original mesh data doesn't require it to be embedded in the sculpt map, but it's some data that needs to be there for the base system anyway. When mesh first came in(Beta stage), they initially were treated as sculpts, with an uploaded object and an asset inventory item (the little pyramid item) which had to be dropped in the build tool as sculpt maps need to in order to work, and it turned the prim into your mesh. Which makes total sense, because it's an asset that has to root into the item storage base system and hence requiring some data that actually hasn't to be there because unused. However those initial parameters on the base prim did actually affect the final LI of a prim turned into mesh, depending if you were rezzing the uploaded object or turning a regular prim into a mesh using a asset item. I don't recall that very well, but i seem to remember that the upload was limited to object and no corresponding asset item because of these prim torture related parameters on the base prims the user wanted to turn into mesh. I guess this was handled by defaulting to the set of parameters that actually binary compress with lowest byte usage. From this, i would evince that mesh should be the item type that, with equal amount of geometry, should be able to render faster, not having to read much or update any of the prim torture data. Plus, the internal format splits all LoDs models material faces into submeshes, while a sculpt is a single, stitched surface. In many cases, i had lower LI on models with multiple materials than the same model carrying only one material, i'm guessing because of the submeshes split.

[The importance of low poly count]

5 hours ago, ChinRey said:

With one reservation of course: remember that every pixel counts too. Replacing geometry with more complex textures and normal and specular maps isn't always a good idea.

Indeed, the model is what needs actual volumes, and that's what needs geometry. Since every pixel counts, visually, as much as every triangle does, texturing work should only account for the detail that really doesn't have a noticeable volume of its own.

 

5 hours ago, ChinRey said:

I've done some tests earlier that might indicate that sculpts are slightly heavier to render than mesh with exactly the same geometry.

As far as i know, sculpts always have been heavier than prims for a few reasons. First off, it's a stitched conversion to a single surface with the same max number of faces that a prim can have, right off the bat. Then, the sculpt map comes into play. It is a one unit cube RGB displacement map, which makes it very similar to a vector displacement map with the difference that the mesh data is assumed, instead of being embedded (that's why the normalized unit cube assumption). So to me it makes total sense that a sculpt prim is heavier to render than a prim, probably more than it could have been if the development quality at the time was better. To me, sculpts don't have any use anymore. But that is me, i never liked sculpts  Mesh is another bag, as i think you can get that to compress and unpack more efficiently and the render time performs better than sculpts.

[LOD & LOD Factors - Stop listening to out dated advice]

Then there is the variation where the designer makes an optimized mesh and the customer comes saying "but it's badly made, it NEEDS to be seen 2 sims away because the others do even if i actually own only one sim and it's a useless feature to me. If you don't, Others = high quality, you = beginner"

[LOD & LOD Factors - Stop listening to out dated advice]

8 hours ago, iamyourneighbour said:

Every new mesher who doesn't care about optimization

Forgive me, i would remove "new" from your statement

[The importance of low poly count]

10 hours ago, ChinRey said:

I was really surprised by this myself. I did hope to get a measurable difference  but five percent improvement from eliminating 512 triangles and 384 that's crazy. There are single meshes with more than ten times as much geometry as that.

There could be a difference though: prims are parametric meshes, and may take shorter/longer to render depending on the parameter you chose and the mesh changes that this delivers. On the other hand, an imported mesh is not parametrized nor it can be and the result may be different, in terms of FPS dilation.

10 hours ago, ChinRey said:

Remember that every vertice and every triangle counts.

Absolutely true, use the geometry you need and no more.

EDIT: Absolutely true, use the geometry your model needs and no more.

[What is the purpose of these "extra" cubes]

13 hours ago, Beq Janus said:

So my theory is, the creator wants to have an object that is LOD resistant to a known distance and used those cubes to mark out the extents that they needed. after that, it does not matter how much of that volume the model itself uses it will still LOD switch at the expected distance. Just speculation but it makes sense to me for the most part. Note that they even have a deliberate physics shape that hugs the books.

Thanks for taking the time to inspect this case Beq. Another thing i thought, is that if the creator also wanted to make animated textures by switching them entirely, those transparent cubes could be used to hold the textures in cache, in order to animate the switch with no load time. I don't think this model does that, but this is an additional idea for that extra geometry.

[Making a new texture, with Normal Map and Specular Map]

@Chic Aeon i just asked a question for something that didn't make sense to me, and you explained it clearly now. Certainly you do have the right to have an opinion, although i keep not seeing what the lighting improvements could really be without the dynamic materials behavior to such lighting, aside from removing the light number limits and shadows add more natural feel as this feature always did. It's ok with me too if you don't like materials, i just think you're missing out on a topic that is used in general in 3D items on many platforms that goes to your general knowledge anyway, and you may probably find out that those normal maps you didn't like the effect of, were probably not the best result from a research on a previously unknown feature to those creators. And many might even not have improved in the meantime or dropped materials all together, instead of learning to properly make and calibrate them. This learning can also improve your Cycles bakes even more. Just saying, make your items the way you like to

[Making a new texture, with Normal Map and Specular Map]

17 hours ago, Chic Aeon said:

I simply PREFER the look of Cycles bakes and rarely use normal maps which of course are an extra download for those that have ALM on

Oh wait a minute, i wasn't saying "no bakes if you use materials". To cover those who don't have ALM turned on, i myself use bakes, but then i add materials on top. I know some people doesn't love materials, i understand though that it is due to how these materials enabled things were initially released. Normal maps whipped out of Crazybump are totally too strong for use. but i'm digressing.

17 hours ago, Chic Aeon said:

In general, I (personally) don't like the look of normal maps on many things. In clothes especially a lot of creators and now including materials and non-materials options in their releases --- which points to the fact (to me anyway) that not everyone loves materials :D.  Of course is an item is mod, it is easy to take the materials out of the equation. 

Not everyone loves materials, to me, for a couple of reasons: so far i've seen materials with strong normal maps, withuot alpha for the glossiness value and specular maps for metals used on non metal textures. Result: a plastic bumpy thing. Would you love materials if you were shown how bad an item looks like that, in comparison to regular bakes? Of course you wouldn't. But again, if you don't want to use ALM, turn it off, why should you remove something from it because it's mod? You now do not appreciate it, who knows in the future if those designers would learn how to make proper materials and you start liking it. This comment really sounds like you're pulling back to stay in the past, instead of learning a new way to produce content. I invite you to take a look at my materials inworld, as textures and applied on objects.

18 hours ago, Chic Aeon said:

That doesn't mean it is WRONG, just not what I like and use. 

You don't like what those creators made. If they just convert textures to normal maps and to a random specular generated from there, with no other work on it, of course it SUCKS, i agree with you. I renew my invite to look at my materials.

 

16 hours ago, anna2358 said:

Happily Optimo's comments are WAY over my head at the moment.

Sorry for that.

[How to get hi-res bakes on 1024 and 512 images?]

9 hours ago, ChinRey said:

The question there though is how do you define "better" in this context? Better for what? Better for who?

Can be that it's impossible to retexture manually for the above mentioned reasons, remapping to random placements and rotations across multiple materials to gain best texture space. splitting with this method will make impossible to avoid seams or any reasoned detail placement, therefore you can't make it any better. 

a few images to explain a bit better

high res texturing, you can definitely mod on this UV. Lot of texture space is unused though

remapping for SL. i split all in several shells across multiple materials

See now why you can't make mods on UVs like this

This was a quick and dirty layout (five tiles) i could make a better coverage on each tile, i admit. However, see how connected, adjacent patches are put in different tiles (materials) and with random orientations. How would you go for modding an item with such UVs? It's gonna be full of seams and it's gonna require a lot of trial and error, for a result that, honestly, won't look as good as the original.

 

As per Penny, i've already spent enough time trying to explain something she doesn't want to hear, so i will just pass and not waste any more time.

[How to get hi-res bakes on 1024 and 512 images?]

38 minutes ago, Penny Patton said:

Despite your claim, this method is still utilized frequently in modern gaming.

My claim is for pre-rendered textures based games, like SL. If we're to talk about game engines, shading doesn't belong to the color texture at all so it would be perfectly fine. Texture atlases are fine with overlapping UVs, again there's no AO or shine on the color texture. This is the difference you seem to be not grasping. There is people who doesn't WANT to use such techniques because they want their items to have a defined look in their shading, not a painted one with shading flaws here and there. If you read what i wrote carefully, i said i agree with you that some creators make bad UVs coverages and/or split stuff into too many individual textures, but it's what they are demanded by the average customers, who don't even CARE about VRam and what it is

Again, "doesn't matter the cost" and "life-like" are two of the major keypoints in all requests. Failing to meet this expectation means your customers' exodus toward the "higher quality" competitor brand. I recently have written about this "high quality" issue, in regard of mesh bodies, in another thread, so i won't be repeating myself here.

1 hour ago, Penny Patton said:

Content in SL is not made by a single individual or team, so textures are not recycled often between various content. SL is frequently throwing far more unique textures at you than any game, modern or otherwise.

Of course there aren't recycled textures, even if you recycle them in your software, the final rendering is a unique texture for the very nature of pre-rendered (baked) environmental items textures. It seems to me that you're referring to square tileable textures to apply flat on a building surface, in which case you're missing the point of shading. Making a vignette-like shade on the textures edges is not baked shading, nor even gets close to it. I'm sure you can achieve great results with your skills, yet it's not the same and you can't expect designers to agree with your method. So if Vram is a concern, why not looking also at avatar render costs and mesh polygon densities? A png image at 1024 takes on average <= 1 MB, while a collada file containing a high density rigged model can esily get to a few tens megabytes. It all gets compressed in a binary format, still the fewer data in input, the smaller the converted file. Since SL content, as you said, is not made by one individual or a coordinated team, you can't claim a common standard because that complies to your workflow. Are you better at optimizing content? Make tutorial videos and provide a link to those no-mod creators that you have been so dissatisfied with so far. And make them public, so more people would see the method in action and learn. A video like "SL item improvement through modding", where you show the before, the work you do, and the final result. Let the audience decide whether it's an actual improvement, in spite of the fact that you certainly get better viewer rendering stats.

 

[Making a new texture, with Normal Map and Specular Map]

15 hours ago, Chic Aeon said:

I usually use them on natural things like rocks. That's just my opinion. When materials first came out, most creators felt that they HAD to have them in order to sell things -- and that might have been true then. Now, especially with Cycles it doesn't seem to matter much.

I'm sorry Chic, but i don't agree with this statement. A baked result gives you static shading from the normal map, but in SL the normal map carries the glossiness data in its alpha, which is THE deal when it comes to materials, much, much more than the specular map does.

 

9 hours ago, ChinRey said:

I think there are four rules for good use of normal maps in SL:

1. Don't include every little bump in the surface - it'll always look fake and "plasticish" if you do
2. Don't use it on its own for too big details - after all is said and done, it's just a fancy form of texturing and not "real" geometry
3. Make sure your build looks good even without the normal map

1. True if you don't use a glossiness map in the normal map's alpha along with a specular.

2. Quite true if you don't include rounded shapes in the formula, a rounded corner can be achieved using a normal map and transfering vertex normals from a rounded source object.

3. True with no doubt. Materials as intended in offline applications are realtime, diffuse based color images.

I will attach here the class materials i use at Builders Brewery when i give the class "SL materials explained"

This is the RL blinn shader model, based on diffuse. In SL the regular texture is called diffusecolor, to distinguish it as the resulting color after render/bake

So you see, SL materials are a sort of mix between the older rendering system and a blinn/phong shader, which can't use proper Diffuse to indicate a metallic area (backward compatibility), folding over to the specular map's alpha, to define which areas of the textures is a metal and what is not metal (dielectric).

I can send you all some sample materials textures inworld to let you see how a material set of textures should be built correctly. Just let me know

[How to get hi-res bakes on 1024 and 512 images?]

4 hours ago, Penny Patton said:

With all due respect, you don't know that. I'm not saying you HAVE to sell mod for my sake, only that I will not buy no-mod myself and that I will share my reasons for this so that others can make informed purchasing decisions based on that information and their own values.

Oh yes that i can know you can't mod my stuff, as i make a jumbled mess, with no UV shells connected, many many pieces put in random order. you, as anyone else myself included, can NOT possibly retexture it by hand. That's why you can't. And that's why that stuff is no mod. And i write "COPY ONLY" on the vendor texture, in a font size as big as a colonial house. However, after a demo purchase and a full purchase, bad reviews arrive because "everything should be moddable, give me mod item or i don't delete the bad review". NO. You aren't ABLE to texture at my same level and you would crappify my item. Let alone the fact that i use a mapping method which is a impossible mess to work manually, but even if i did make PS or GIMP usable UVs, you won't make my textures any better. Guaranteed. That's why i use a texture change hud, with color grading options. 

 

4 hours ago, Penny Patton said:

Arton brought up the fact that repeating patterns can often lose detail, creating a small but high-res and repeatable portion of the pattern is a great way to get around this.

The problem with this assumption of yours sits in the UV mapping technique where you downscale the image and loss of details occurs, so you resort to tiling. My method preserves the texel density from any mapping resolution to the same texel density in multiple 1024 maps resolution. I don't think i need to explain to you what texel density is, do I?

The method you describe was used at the time of games like Torchlight/Torchlight2 and even earlier, WoW, i'm sorry. These repeatable patterns are, again, best used when placed in the same coordinates of different UV spaces/tiles, so that you can bake model information on another texture/material/mesh part, not always on the same. What you describe can work, but it doesn't give the user the amount of control you should get on the texture, needed for detailing. Like the chain example, every link can't have the same textures as the shine and ambient occlusion can work well on a few, on the others they would look very off. Should every single link/groups of links get a material on its own to load in another texture? That isn't very optimal, as it calls another set of textures to draw.

I'm not saying that you're full wrong on the whole line, i want to clarify. Or that you're a low level texture creator that can't possibly reach my heigths. I'm saying that you're making assumptions on one method (yours) being best over all the others, when i clearly showed something that not many know it's possible and how to do it. I could make a whole car in one UV tile to make a render out of it, who cares: tiling textures go well there as the lighting is being rendered after a click. Who cares, in such case, of the UV space taken by each shell. Then i upload it an sell it to you as moddable. you're not getting a good result from that because you either tile textures (bleah) or paint detailed ones that have small texture space. Overlapping pieces works in rendering, how about the doors when baking or texture painting, if they're overlapped? Mirrored details to be optimistic. What about moving the mirrored half in another UV tile? you get another material/SL face to texture, a mean to bake to texture only once and apply the same texture (flipped if you also flip the mirrored UV map to have their normals in the correct orientations. Yes, UVs have normals as well.) or bake independently into two different textures.

The fact is that most likely the no mod creator has made their product in a way that works optimally in their mind to get the visual look they planned, which is not guaranteed to work for another person. Or like me, it would be IMPOSSIBLE to texture the item manually because of the mapping method. I couldn't do that myself on my own model, i have to take the texturing stage Maya file again and bake again to the SL maps when done. But rest assured that if i started high res with a 2K map where only a 1024**2 area was wasted space, the final SL mapping gets me 3 fully used texture maps, no resolution loss and no resource loss. This is why you can't generalize about no mod items being a money throwaway and that ALL can be optimized/improved. On a product like mine, the only optimization you could do is to downscale my textures. But then you lose the detail that i so cleverly managed to retain, thanks so much.