Sebastyne Alpha The mesh avatar worn over a bodyshape is not a factor. All attachments worn with a bodyshape are "phantom" and have no actual solid physical form or presence. The bodyshape is what matters, as it also defines the size of the bounding box. The bounding box is the physical part of an avatar which collides with it's surroundings. It's invisible and cannot be seen, usually.

SarahKB7 Koskinen So you're talking about the bounding box height, measured by the scripts, not the height of the avatar when you rezz a box next to it and measure it that way? It matches. The bounding box is nothing to go by for sure, and it's not a good way to go about sizing your avatar.

But when you size your shape to the metric unit, the avatars do match the box size rezzed next to them. They match exactly. I remember trying some random mesh avatar that didn't match the prim box height, but for the most part they do. (Depending on where the head or body is rigged to I suppose it can alter the outcome.) Bounding box is irrelevant to me, but it would be nice to be able to work with scripts, but scripts could have a "grab shape settings" function to them which they currently don't.

Terveisiä, muuten. Hieno sukunimi. ;)

Sebastyne Alpha I'm asking that the Appearances bodyshape editor be resyncronised to display a true avatar height.

Ideally, a barefooted 5'10" tall bodyshape should have a 5'10" bounding box and the bodyshape be of identical height to a 5'10" prim and be able to just about squeeze through a 5'10" doorway or opening. And for this 5'10" height to be displayed as 5'10" in the Appearances bodyshape editor.

At the moment (and for the last 15 years since V1 was replaced) the Appearances is displaying a slightly taller false height figure in the editor that is not the true height and needs to be resyncronised in all current V7 viewers.

SarahKB7 Koskinen You're barking at the wrong tree here. What you want is the bounding box to match the shape editor's value, but that might not even be possible, given people's attachments, NOT so that the editor is set to show a false value that then suddenly doesn't match prim size.

The avatar height display in the Appearance Editor is accurate. It matches the size of rezzed prims EXACTLY by my experience. The bounding box does not match, nor do the scripts that measure the bounding box. (Every script also gives a different result by my experience.)

The door openings are tricky because you may have a slightly altered hover height (not gonna work) and your feet or hair might be blocking you, but I agree in theory that a 5 foot 10 avi should fit through a 5 foot 10 door.

I agree that the 5 foot 10 should appear correctly in the shape editor, which it does not, it doesn't show inches at all, so the measurement is correct, 1.77 meters is 5.80709 feet, or 5 foot 10 inches. That should be corrected to show a human-readable value.

The scripts should be enabled to grab the avatar's height from shape's metric value, and leave the bounding box alone.

But if you are building something that you want to do that exactly, to let certain height avatar's trough while leaving everyone else out, a script that would grab the Appearance Editor's value should fix that problem with a script door or something.

If you just want to make sure everything matches, rezz a 1.77 meter block and compare you avatar to it. It should match exactly.

Appearance Editor heights are and always have been and always will be, a guess, it doesn't KNOW where the top of your avatar's head is, or where the soles of your avatar's feet are.

All it knows is your bounding box height, and the two hover height settings, the one in your shape and the one in the viewer. THAT is IT.

Viewers that show a figure closer to "prim height" do so by guesswork, and using fixed additions based off empirical observation.

Typically, a "human sized" avatar will be about 17 cm / 6.4 inches taller than the bounding box, so just add that to the bounding box height and it should be good enough for users who are not obviously insane...

To do what you are asking, LL would have to alter the system to start checking bounding boxes on mesh bodies, and mesh heads so it can calculate the "prim height".

And since the reported height isn't JUST in appearance editor, it's a STORED value, that's updated EVERY TIME your client sends a change of current outfit notice to the servers, which means everyones height, would have to be re-calculated, not just when adding a system shoebase, or hit save while editing a shape...

But EVERY TIME they add or remove ANY attachment, including HUDS, because HUD attachment can easily be a rigged mesh deformer that makes you taller, or shorter.

THAT is going to add a crapton of lag to SL, all because YOU...

Outstanding.

Many here make good points, covering a lot off issues. In making these points, let's check ego and snide at the door, eh?

The thing is, there is quite a bit that can affect an avatar's visible height. And yes, attachments do just that. Wear a pair of boots with a boot shape adjuster, and your visible height will definitely increase.

As stated, the system doesn't measure the visible height of one's avatar. We can test this by simply trying to zoom in on a mesh avatar. We all know the results of that: our camera winds up on the other side of the sim or in outer space or la la land. To the system, there is simply no avatar there.

Which one has to question really, because the system can detect other things such as prim attachments. So why not mesh? Is a puzzlement, which boils down to "Because no one has tackled that issue."

(People really hate trying to zoom in on mesh. What a royal pain. Should have been fixed years ago.)

I'm not sure there is really an easy solution to this one... and if it's not easy, we're not likely to see it.

This reminds me of an old, old issue: why is it that the COLOR editing box shows figures from 0 to 255... but the scripting edit figures are from 0 to 1? This requires scripters to do a math conversion just to script proper colors.

They don't fix this because they think they can't. This has existed for too long, and too many scripts use the 0-1 setting. Likely someone at Linden Lab believes they can't implement a script-color-converter that converts colors in a script that exceed 1 to the existing script value. (Did that make sense to non-scripters?) Plain English: If something is "too difficult" to implement, they'll keep doing it the old way, regardless of sensibility.

One could argue that the scripting language and color editor should have been coordinated from the beginning, but the simple fact is they weren't. So here we are, stuck with the decades-old system.

Same applies to avatar height vs prim height. If it hasn't been implemented, the problem is so old and set it probably won't be fixed, and frankly LL very likely believes it's not important enough to fix. For a certainty, there are years-old unresolved issues out there that are far more system-impacting.

EDIT: I just learned this HAS been fixed in Firestorm. So there ya go. ;D

"why is it that the COLOR editing box shows figures from 0 to 255... but the scripting edit figures are from 0 to 1? "

It's called "Kodak colour", and it's an Industry Standard, that dates back to the first huge, digital printers, made by companies like Kodak for the Industrial printing needs of for example, commercial magazines.

It's all about "colour bit depth". If you are printing at 24 bit colour, RGB 127,0,0 is a nice deep red, but if the printer is set to use 48 bit colour, 128,0,0 comes out as nearly black...

0.5, 0, 0 works on ANY bit depth, 24 RGB, 48, 96, whatever. that's why colours are stored as float vectors with ranges of 0 to 1.

An actual Industry Standard, that actually makes sense.

Zalificent Corvinus I appreciate the information and insight. If that's the industry standard... then why use 0-255 instead of sticking with the 0 to 1 industry standard? Or they could have had the script engine internally convert 0-255 to the 0-1 automatically instead of forcing the scripter to waste time doing so... color after color after color.

The issue isn't which standard they chose or which is better. It's a matter of using two different standards on the same platform. Makes no sense. But it's there, and by now is pretty much hard-wired into the system.

The 0-255 thing is, wait for it, another Industry Standard, being the standard way paint packages have shown rgb colour pickers to devices running Meatware 1.0.

So meatware 1.0 systems decided to display 0-255 to other meatwares, while using 0-1 to talk to non meatware systems like computers and printers.

This is wwhy I laugh so hard when people go on about how SL must conform to Industry Standards .

Zalificent Corvinus lol... I hear you there. Cory Linden (several years ago) admitted that he had been pushed to "rush" the development of LsL and in his words, paraphrased, 'I basically designed the LsL system in one day, and it shows. I will never do that again." He also stated that he constantly wanted to fix the foundation of SL but was always pushed into creating new "toys", which caused him a great deal of job dissatisfaction.

Even Philip Linden is aware that they once again did the same thing, and pushed PBR too quickly into production without thinking about it. Rushing projects to achieve some arbitrary deadline (in PBR's case, SLB21) is no way to run a stable computer-based business.

Software takes time to produce and debug properly. The very concept of SL itself isn't industry standard. Industry standards be hanged.

Even though I'm a merchant of 21+ years, I am tired of merchants dictating to LL how they want the system to run. I seriously doubt even one non-merchant person said, "You know what SL really really needs? PBR!" And from what I've seen, for every person who says, 'I just love PBR" there are ten people who hate it, even if their computer can handle it.

I believe it was you who mentioned PBR items looking like they have a varnish coating, and I couldn't agree more. PBR ruined the appearance of my favorite armor. I have to wonder, "Since this armor does not use PBR textures and never has... why would implementing LL's brand of PBR even have an effect on its appearance, at all?

But that's what happens when someone tries to pound an industry standard into a non-inudstry-standard system. "If it ain't broke, break it and call it a feature." Then the tech-elitists scoff and say, "Buy new equipment!"

I don't plan on upgrading my 2-year-old gamer-level system for quite some time. If it gets to the point I can't use SL with my system , I'll consider that time to stop using SL and move on to something more sane. They almost lost me when they brought out PBR, but I stuck it out. Others didn't, cursed LL up both sides, and left.

Was that the goal of implementing PBR... to tick off customers? Surely not, but that's what it did. And as Cory and Philip both have stated, LL has a tendency to rush projects and then try to play damage control when people start shutting down regions.

"I believe it was you who mentioned PBR items looking like they have a varnish coating, and I couldn't agree more. PBR ruined the appearance of my favorite armor. I have to wonder, "Since this armor does not use PBR textures and never has... why would implementing LL's brand of PBR even have an effect on its appearance, at all? "

Well, basics...

REAL PBR in a REAL game by REAL Game devs, is a total system, rendering engine, lighting system, surface shaders, and fake reflection probes, designed to give a "minutes per frame ray traced" style appearance at frames-per-second speeds.

The lighting for a pre-made level map, will be a mix of pre-baked Image Based Lighting, and a FEW actual dynamic lights, for example a "torch" carried by the player character. The fake reflections are pre-backed too into the reflection map for that level-map or section of a level-map.

LL-Fail-PBR does NONE of that. They didn't put in the lighting system at all, that breaks the rendering engine, and it sticks varnish on everything in response, largely from trying to "reflect the sky", the tone mapping fubars the colour rendition on everything too, even "legacy" surfaces, and the sky, and the engine sticks in massive numbers of "auto-probes" to generate massive numbers of fake reflection maps, which update far too often.

That's why LL-Fail-PBR is laggy crap, with a polyurethane varnish universal finish, bad sky, and glitched water.

"Was that the goal of implementing PBR... to tick off customers? Surely not, but that's what it did. And as Cory and Philip both have stated, LL has a tendency to rush projects and then try to play damage control when people start shutting down regions."

The Goal?

Hmmm... The Goal is Phil's "Golden Vision of SL".

Problem is, that vision dates from 2005, a dream of a golden future, in distant 2015, when everyone in SL will be using Voicespam in Puke-O-Scope Geek Goggle Vision, with Mo-Cap Auto-Gurning Expressions and Arm-Thrashing, during their daily routine of Tele-conferenced B2B Power Meetings, and filling in the time between having High-Brow conversations in Virtual Experimental Art Galleries, while listening to Improvisational Jazz...

Problem is it's 2025, Voicespam is unpopular in SL, Puke0-O-Scope is a nearly dead technology, people don't want their snack eating, coffee drinking, and one-handed typing mirrored by their Avatars, and nobody uses SL for B2B meetings, hardly anyone visits the experimental art sims, and lots of SL people are haters of Jazz.

So under his guidance, LL flail about, trying insane "fixes" that simply do not work, like his next Great Idea, LL kidnapping your Avatar when you log out, and using it for an AI Controlled ToS Violation Spambot, that will earn YOU a ban WHEN ( not IF) it violated the ToS by doing kiddy pron RP.

I wish I was joking, but he really did suggest Post Log-Out AI Avatar Kidnapper Bots, to help fake concurrency numbers.

Zalificent Corvinus Zal, we might remember there are different levels of system knowledge, and people often speak from personal user experience and desires rather than full tech knowledge of how the system works. All they stated was something they would like to have. That's what this feedback area is for, and I'm glad there are Lindens that actually read it regardless of user experience and knowledge.

The upvotes indicate how popular the concept is... or isn't. This one has 62 upvotes (as of this posting), which is to be considered. While you and I and others here understand some of the issues behind all this, not everyone does. Nor may they be aware of the options that are available such as in Firestorm.

I remember years ago when Char Linden took the time to teach me how to make a basic large floor by copying prims... and altered my understanding of building on SL thereafter.

I'm the owner of DragonForge, creator of Dinkie Dwagons and BrokeDolls (and much more), had a nice store at Fantasy Faire '25... and after 21+ years of merchanting I still remember Char Linden's kindness to a newb.

Tonya Souther It does.

Tonya Souther Which is one of the many reason I use Firestorm... attention to small details. : )

Soap Frenzy No, this isn't correct. While the height measurement displayed in the default Second Life viewer's shape editor is indeed taken from the Z axis of the avatar's hitbox, the avatar's hitbox itself ends around the avatar's eye level and does not reflect the height of the actual visible avatar model. This is a long standing and well known issue.

Several scripted height detectors attempt to fix this by adding an offset or multiplier to get a more accurate measurement. Viewers like Firestorm use their own calculations too, both methods result in a much more accurate approximation than going by the size of the avatar's hitbox alone. This can be verified relatively easily by measuring avatars against a prim and checking said prim's Z axis size.

It is such a simple thing to fix, but in usual Linden Lab fashion it has been up to the users to try and find their own work arounds. Avatar height goes hand in hand with the creation of a well proportioned shape, and well proportioned shapes both objectively look better, and work better with realistically scaled content. Working in a realistic scale makes building easier and results in much more realistic and immersive builds. It is also crucial for VR, and all revolves around having an accurate height reading for one's own avatar. Step it up, Linden Lab.

The value is the bounding box, incidentlly avatar dimensions are akin to a cindy doll as in perpotionaly distorted, this is critical because the human brain is trying to make a 2D object 3D. Creating a 3D world on a flat screen reqiures a lot of visual trickery.

Soap Frenzy The visible avatar is the same size as a block rezzed next to it in the same size. They are exactly right. So I agree the shape value is correct.

Hitbox? Is that the same as a bounding box, I'm not sure, but the bounding box is NOT the same size as the avatar, no, but to me it's not a huge issue although scripts would be nice if they could actually detect the visible height accurately. They should just grab the Appearance Editor's shape height value and be done with it, and ignore whatever shoes or hair avatars are wearing.

Leslea Aldrin The actual size of everything will not change. This request is for the display error in the shape editor.