Wulfie Reanimator

I understand, and I'm not going to start trashing any products. I regularly use the Steffi myself. I just want to give out some perspective on how significantly the SL performance could be changed if everybody was well educated on the importance of performance alongside actual features. And trust me when I say this, almost all of the "human head market" is in a similar state to Steffi, so there's no point in me trying to specifically pick it apart. Without even having looked at the Genus head, I guarantee that the same applies, especially with all that @Elinah Iredell said in the opening post.

@Gabriele Graves I don't think Chic meant a head she's making, just a head she uses. Right-click and Inspect, mostly. I'm going to use two of my heads as examples to compare and hopefully give some perspective of how different heads spend their resources for appearance. They will have almost identical features (appliers, alpha toggle, Omega, etc) I'll highlight some things at the end. Catwa Steffi (bento rigged): Land Impact 8, Complexity 3662 The head has over 80K triangles and uses 19 different textures (40MB video memory including mesh, A LOT!) Utilizator Normie (bento rigged): Land Impact 17, Complexity 9160 The head has little over 2K triangles and uses 6 textures (10MB video memory including mesh.) Paws Maned Wolf (unrigged mesh, several mouth/eye states): Land Impact 8, Complexity 2120 The head has 62K triangles and uses 3 textures (5MB video memory including mesh.) I threw in the Maned Wolf head for a third point of view of a more outdated/unusual head, as it's for furries unlike the first two, which are entirely human heads. I have more heads on another account but it's already very uncomfortable navigating with a laptop and a trackpad. Before I go further, just look at the numbers and the given complexity. Steffi uses 40 times the amount of triangles and 3 times the amount of textures, but somehow manages to have only 40% of the complexity of Normie. Does that make sense? Here's what the heads actually look like: Steffi http://puu.sh/CrPUP/c577245230.png (world view) http://puu.sh/CrPVr/6b0a7be2cf.png (wireframe, face, onion layers NOT visible) Note the mid-section of the upper lip and tooth caps Remember that there are 1-2 additional copies of the face, double or triple everything. http://puu.sh/CrQ1h/f8b7c329c5.png (wireframe, teeth from inside mouth) Each tooth is individually detailed Normie http://puu.sh/CrQ9h/7ab9d85afd.png (world view) http://puu.sh/CrQ9N/4889f9c880.png (wireframe, face) http://puu.sh/CrQai/fa8b535161.png (world view, teeth) Teeth are not individual, but one connected face with some crevices and additional shadow from the texture. Steffi only uses the High and Medium levels of detail, Low and Lowest are set to a minimum, eg: 15912, 15912, 5, 5 and 23790, 23790, 93, 8 Normie uses more stepped levels of detail, eg: 5598, 1398, 350, 176 and 1722, 861, 214, 54 So my point is, when people say "less tris" or "lower poly," they probably (hopefully) don't mean as low as the LL system body. (I think most can agree that it is outdated and lacks a lot of polish, like that sharp belly!) They just mean "reasonably low." Even if you were to go in and remove every other edge loop in Steffi's topology (mesh form), the difference would be indistinguishable to the plain eye. There is so much unnecessary (unnoticeable) detail in a lot of mesh that could be safely and easily reduced. Things like the teeth on the inside of a mouth do not need to be individually modeled for everyday use. That kind of detail should only exist for people who want extreme closeups in their SL photography with real intent on showing the teeth. The problem is, even if you made two versions of the head, one optimized and one with "ultra realistic detail," the uneducated masses (the average consumer) will probably want the one with more detail, because it's prettier, right? They're probably not wrong to think that either, especially when SL doesn't have a restricted camera distance like almost any regular game, but the trade-off is that everybody suffers when anybody is using it outside of its intended context. Not even a full-body character in a modern (major) game with all of its clothing and accessories is going to use as many triangles as most bald heads in SL. There are lots of numbers on many recent-ish releases to cross-reference, even if they are kind of unspecific. And now that I got started, I could keep going into hair, props, and texture use, but... I don't want to spend my vacation writing an essay on a pretty boring subject.

Granted, but your code style and variable names are indecipherable to anybody else. I wish for... a new wish that cannot be corrupted.

I still strongly disagree that avatar rendering complexity is of any real value in its current state. Not even as a "rough estimate." It is way too easy to manipulate the value, knowingly or not.

??? One of the main goals for BoM was to reduce the need for onion layers, and you're calling it smart to have a toggleable BoM with the layers unchanged? What you said earlier was the actually smart thing -- having two versions of the head, or just layers separately. Low complexity is infamously easy to obtain, have you checked the LODs on the individual parts of the head? (Rez the head on the ground for easy selection. Also could you name the brand or send it to me privately? If they're genuinely good, I'll be glad to throw money at them.) I totally agree on appliers staying for a long time after BoM, though.

That only applies for the web search. The legacy search (in the screenshot) can only be sorted by name or by traffic.

This is incorrect, you can read no-mod notecards that you didn't create, even if it was given in a box. This would make sense because you can even read notecards that only exists in someone else's inventory, if you have the UUID. What are you trying to create, exactly? Low channels make sense for chat commands, but not much else. I can't imagine the practicality of "I want sequential channels for each copy of the product, starting from 1, that is unique to each person." Whatever you are doing, surely there must be a simpler way to do it? What do you mean by "faking a UUID given a root number (which is always 1 for linksets and 0 for unlinked)?"

If you haven't visited them, try Oracul (Kuso sim), they have lots of very fluid AO sets for cheap. (150-600L each AO, 10L per animation name and you get 1-5 height variants)

Avatar movement? As for framerate issues.. it's hardly the fault of mesh itself. Like I already said, prims are mesh too. It's the amount of it that creators use for the high/highest LODs, even going so far as to reduce the lower LODs in order to be able to put more in the higher LODs, and as a result a lot of people are using LOD factor 4 or higher because otherwise most mesh looks terrible (because of creators).. and they're always rendering absolutely everything at the highest LODs which is not at ALL how you're supposed to handle real-time 3D rendering. What's your LOD factor set to anyway, @Alyona Su?

Even if you could name the function, that wouldn't be an argument. Pussycat and I are talking about the language itself, its environment, goals, features, and how it's designed. One "stupid" or broken function doesn't encompass any of those subjects.

I am 100% certain that the main reason why most of the mesh that seems to cost inconceivable amounts of LI is because nobody makes proper (read: simple) physics shapes for their mesh. Importing a tree? Let's let the importer calculate a mesh shape for it, yeah! Or even better, let's use the model itself as the physics shape, that way it's more accurate! And the server would scream if it had a mouth. Keep in mind that all prims are auto-generated mesh as well, even if they don't necessarily use the same LI calculation (unless you set them to Convex). The biggest difference is the simplicity of their physics shape, which avoids lots of little computer pitfalls, like small gaps (complex physics calculations). There was this one mesh that was basically a series of hollow hexagonal tubes with a small gap between them and using the model as a physics shape. It was about 8 LI at its regular size, but if you scaled it down just right... I think we got it to 517 LI at worst. If the entire mesh was encased with a simple cube as its physics shape, that couldn't have happened. Similarly, I've seen quite a few skyboxes that have a very basic, one-room box shape with no excessive use of mesh, but the LI is still way higher than it should be and I bet it wouldn't be even half if it used a cube with inverted normals (to keep you inside) or just a hollow, reasonably thick 16-face box for its physics.

Out of curiosity, what are some specific flaws you're referring to?

No products will need to be updated as long as there is an applier for the BOM-specific UUIDs. After the BOM UUIDs are applied for the head, you can wear system layers and they will work as you would expect.

I was guessing that was what you were doing. In that case, I'd suggest a little trick: Creating a channel from the object owner's UUID, plus a base channel for the specific product. integer channel = (integer)("0x" + (string)llGetOwner()); To explain that a little bit, you can write integers in a hexadecimal format (up to 8 characters after 0x), for example, 0x601693cb is 1612092363. All UUIDs use only hexadecimal characters, so you can use any UUID for this. For example (using my UUID), the code "0x" + (string)llGetOwner() gets you "0x601693cb-8c20-4a28-86f1-073d9e23bab2". This is too long to be an integer, but when you typecast it to an integer, it gets shortened to be a proper length and you get 0x601693cb. This is now a valid number you can use as a channel, and add whatever numbers you want. This way, the same line of code always gives a unique channel for each user and you only need to change that base channel for completely different products.

New question: Does every copy of the product have a unique number in a separate notecard, even if the script is the same? How do you manage to do that? What is the number used for?

One global integer variable at the top of the script. Using a notecard doesn't reduce the amount of editing you need to do, it increases it. If you have the number in the script, you can change that as you update the rest of the script. If you use a notecard, now you have to update the script and the notecard, and you rely on no one taking out the notecard or you have to make the whole object no-modify. If your object is already no-modify, you could use the object's description instead if you aren't already using it for something else. see: llGetObjectDesc, llSetObjectDesc

@Ichi Rexen, do you think the benefits of making everything no-modify is greater than the punishing limit it puts on legitimate, paying customers?

Can you explain why you would need modify permissions on an item if the "questionable viewer" can ignore permissions? Hint: You don't. That's an excuse, not a reasonable argument. (I'm also not gonna speak more on this because of obvious reasons and it's got little to nothing with the thread.)

You are correct. There is no rule even close to "don't mention any names." The closest thing we have is "don't post Interpersonal Disputes or Personal Negative Commentary," aka "don't name-and-shame" which is easily extended to stores/businesses. It's the consequence and intention that matters and there's no harm in pointing out positive examples, unless it's done in excess like advertising. That said, I'm also pretty upset by the poor quality of mesh skyboxes. Even when you can demo them inworld (no way I'd buy blind), there's usually no rezzing enabled to try out the floor... I'm primarily concerned with function, so I have no trouble living in a 6 prim box if all else fails.

Isn't the last assignment unreachable? return, well, returns from the function.

@moirakathleen did a good job at explaining the details and practicalities, but I also want to underline what the difference really boils down to: You cannot take off the "normal body." Every avatar has one, always. A mesh body is an "attached object." There are different kinds to choose from.

Reasons. However you can add new things into the quick preferences. For some odd reason, I was able to use the "slider" type up to 500k max, but when I went back to take screenshots, it would limit me to only 100k max and I can't get it back to 500k. But in the last screenshot you can see that I was able to use the "text" type to set max complexity to 543210 and it's reflected by the "real" slider.

So.. what the product is almost definitely going to need: Several mesh models Several textures At least one texture for a "particle system" (smoke) Several particle systems At least one animation for each action. Several sound effects The scripts This is a lot to ask for if you don't have any of these at hand. Finding someone who has the skillset to create all of those can be difficult and then you have to convince them to also do it. Keep that in mind while talking to whoever might be interested in the job, the price should be quite high.

Installing LSL for Sublime Text 3 from scratch (because I'm on a laptop which didn't have either of them installed)... Install Sublime Text 3 with default settings. (optional, but works) Install Package Control, restart Sublime Text. (The manual instructions are probably easier) Open the Command Palette (Ctrl Shift P), select Install Package, select =BB= LSL and wait for it to install. Sublime Text will show a pop-up saying "=BB= LSL requires SublimeLinter, would you like to install it now?", click OK, restart Sublime Text. Done, Sublime Text now has "LSL" as a language choice from the bottom-right corner of the window. Autocomplete shows states, events, functions, constants, and variables. It is also up-to-date, including llSetLinkPrimitiveParamsFast and Animesh functions. Edit 1: One thing that bugs me with the BB one though.. The syntax highlighting is at least partially incomplete. For example using the "list" keyword in global scope will cause it to not be highlighted. Even with my almost zero experience with sublime-syntax and RegEx, I am able to fix this, but I cannot guarantee that it works properly in all cases. I have a different highlighter on my desktop that I've been using for a long time and works as intended, but it will be a while before I can go back and figure that one out.. Edit 2: After some searching and testing, this seems to be the one I've been using: https://packagecontrol.io/packages/LSL Installation is the same as for the BB version, just find it in Package Control (by searching for "LSL" and going down a bit). It properly highlights all variable types and includes even the latest functions for Animesh. If you've already installed the BB version, you can use Disable Package or Remove Package in the Command Palette. P.S.: OSSL is for OpenSim and it is a separate language that you can ignore entirely.

Which hands were they?