Theresa Tennyson

AliceDarkWidow wrote: There's an avatar I've bought, yet the eyes that go with it are sold seperately and by a different creator on SL named Laqroki. I can't find them at all in the SL marketplace....does that mean they might only be inworld? The company previously known as Laqroki is now generally called LAQ but it's the same place, as linked by Rolig.

Rhonda Huntress wrote: ChinRey wrote: HarrisonMcKenzie wrote: Sansar isn't SL2. You mention that early on, but it's clear that it hasn't sunk in. That is a problem of course. Linden Lab, creators of the famous Second Life, is building a new virtual reality. Despite all the known facts, it's very hard not to think of it as "SL2". That probably explains the contradictions Nalytha mentioned: Just like everybody else, Ebbe and the other Lindens can't help thinking of Sansar as a Second Life replacement. Even though they know better, it's still there in the back of their minds. While they are congruent in the large view because they will both be virtual worlds it is going to be a massive change. I believe it will be a distillation of SL. Second Life = Woodstock Sansar = Super Bowl half time show. In another perspective, take the 80/20 rule and run Machiavellian with it. Of everything that made money, what were the top 20%? Expand those aspects, protect them from beiang copied, worked around or achieved through other processes and chop everything else. Actually that's a near-perfect analogy, because Second Life wasn't designed to become what Second Life now is and Woodstock wasn't intended to be what Woodstock became. Woodstock was originally supposed to be a profit-making concert - it became a massive free concert by accident. After the concert and the lawsuits by surrounding landholders the organizers were $1.4 million in debt. They were eventually bailed out due to proceeds from the record and movie. Hippie chicks weren't the only ones losing their shirts... https://en.wikipedia.org/wiki/Woodstock Second Life was originally supposed to be a small, coherent world. There are notecards of early meetings (i.e. before there was a Teen Grid) where the Lindens said there would only be 150 accounts per last name. The economy wasn't a major concern. At the very, very beginning what became Second Life was a combat sim with terraforming by grenades. Things we take for granted like private estates and large, profitable merchants weren't on the radar and there are many things we take for granted that not only weren't expected but that the architecture is completely unsuited for. Mainland skyboxes/skydomes are idiotic - there is absolutely no reason to simulate a full region constantly connected to eight others in a massive grid for something that is built in such a way that the owner wants it to be completely isolated. It only works that way in Second Life because the system was designed for connected ground-level regions. The ability to build in-world in real time is a huge load on the simulator system despite the fact that very few people actually do it regularly and even when they do they only do it occasionally. There are many regions that literally haven't been changed in years but the simulators still have to check for changes eight to forty-five times per second 24 hours a day. After Woodstock nobody tried to do it again for 20 years. The Super Bowl brings in huge amounts of money every year. There may be a pattern here...

Qie Niangao wrote: KarenMichelle Lane wrote: Does Linden Lab in fact trade [for stabilizing or for profit reasons] in the LindeX at all? As the regulating body and owner of the LindeX that has some big ethical issues wrapped up in it. The Lab has always sold L$ in order to keep the game currency supply from drying-up due to "sinks" such as upload fees, Search and Classified listings, Marketplace fees, and anything else L$ denominated, which draw down the supply (much?) faster than the few remaining L$ sources (notably stipends to the dwindling Premium membership). Back in the day, they used to issue monthly economic statistics on all sources and sinks, including how much income they generated selling L$s to replenish the money supply. That's the thing, though: the Lab sells L$s regularly. There's nothing unusual about it. Now, it would be possible for them to suddenly start dumping an unusual amount on the market and thereby sell much more than their usual share of L$s for a while during which residents' standing sell orders wouldn't execute at their old rates, and it might take a while for those residents to adjust their orders to the new exchange rates (and maybe even pile-on some extra selling at even worse rates if they get a little nervous that the currency might be tanking). I don't think that happened, personally, because the longer term increase in revenue would be negligible, and might even be negative. That's because, if the Lab dumped a bunch at junk rates just to capture the market for a whie, they'd displace residents who nonetheless will eventually have to sell at some rate -- and while those residents are selling at whatever rate, Supply doesn't get to execute its usual sales. Put another way, they could possibly "borrow" some US$s in accelerated L$ sales, but they'd lose it back quickly forgoing sales on which they regularly rely. The short-term benefit might have been tempting if the need were desperate enough and the amount were enough to matter, but we know the total volumes weren't that huge and we also know that at least some of that modest volume was resident sales anyway. I doubt Linden had any hand in this at all, other than maybe another L$1 uptick in exchange rate that they seem to be doing semi-annually recently. There would be a good reason for Linden Lab to make Lindens slightly cheaper - right now and for as long as the exchange was around L$250 to the dollar, if you buy Lindens in the viewer (the way the average user does it) a round number of Lindens - say L$2000, the default in the viewer - sells for slightly more than an even number of dollars when you factor in fees, etc. During the recent spike the same amount sold for slightly less than an even number of dollars. It's easier to make a sale if your price is slightly under an even number of currency units - that's why things in stores are usually priced at $7.95 instead of $8.00. If the Lindex was manipulated to bring the exchange rate to a point where Lindens typically sell for the slightly lower price they'd get more impulse purchases.

MemeMarine wrote: Recieved these (https://marketplace.secondlife.com/p/KKBB-Bag-Pants/5198159) as a gift but can not modify them as they are all marked no modify. What do I do? If ANY part of an object, including scripts contained in it, are no-modify the object will be listed as "no modify" in your inventory. However, if the object may still be able to be modified - select it with the editor and there will be a line that says either "You can modify this object" or "You can't modify this object." Also bear in mind that even modifiable rigged mesh can't have its shape be modified the way a non-rigged object can.

TaliaRaven wrote: What is it that makes people try to fix things that DO NOT need fixing. The same thing that makes people buy things they neither need nor understand.

SeductiveShortie wrote:  i want to get rid of the white feet but how? The white shoe is a foot shaper, probably for a different pair of shoes. If it came with those shoes they probably had an alpha with it that you need to wear, and also it looks like the shoes are well out of position and would need to be slid up your legs with the editor.

June Trenkins wrote: Hello everyone, is there an option where i can make body parts like a mesh hand and feets and so on locked? For example - I often lose my hand, when i wear bags or i lose a mesh eye, when i wear a headflower. :-) This would be a good idea...or not? ...just a thought (yes, i know i can ADD things) Rigged mesh items like your hands can be worn on any attachment point. Try attaching them to different points - they'll still work the same way and you will have less problem with things that default to using the "right hand" attachment point knocking them off.

ChinRey wrote: There is something fundamentally wrong with how the viewers and servers determine an avatar's ARC. You run the same data through the same software several times and you get different output, in this case different enough that the deviation can be more than enough to determine whether an avatar should be shown in full of "jellybabied" out. It appears that previous viewers took the render weight of some objects, especially sculpted or tortured prims,"on the fly" at whatever LOD they were at when the calculation was taken. This number was somewhat persistent until something made the viewer recalculate it. This meant that the draw weight of those items would be quite variable, and would explain why your alts (who must have been running Firestorm) were seeing different numbers for the same avatar - they were at different distances from it. The jellydoll viewer calculates the draw weight of all items at the maximum LOD so that it can make the muting consistent - otherwise avatars popped in and out of being rendered. I find the numbers for the current viewer quite consistent. This means, though, for many overenthusiastically sculpted/tortured prim creations this means that the draw weight will be incredibly, and unrealistically, high. My aunt has a hairstyle from a certain old-school hairmaker with a draw weight of a mind boggling 697,511 (211 twisted torii - if it was physical it would crash the server). If you zoom in on it you are very definitely drawing over 3 million triangles per frame just for that hair, but that number will drop off rapidly in the real virtual world. (If she throws that hairstyle on and a pair of Stilletto Moody shoes on with it I she has an ARC of over a million. Intense... Turn your RenderVolumeLOD up around her and dispair.) As far as the server number for draw weight, I used a scripted draw weight monitor in a trafficked area and I could see the numbers change for the same avatar as various people entered and left the area, suggesting that it works exactly the way the wiki (and I) suggested. Sometimes in a quiet situation it would return exactly the same number as the jellydoll viewer but it was often lower and variable. particularly with outfits with non-mesh attachments. The server number will only be an approximation until all viewers use a criteria that produces consistent numbers.

wherorangi wrote: by jumping I mean I am playing scripted dance animations which can be seen in the variance of FPS on the gfx card. The FPS range is about 50 to 80 average 58.4. The variance is wide due to: a) occlusion (more or less) triangles in the view as avatar turns and moves, and b) the work the main processor (i7 in my case) has to do to prep the data for the 660, and c) the time taken to transmit data over the internal bus, and retrieve data from memory and/or from cache seems to me that while mesh objects can contain less triangles than oldschool prims, it takes longer for the main processor to prep the data than it does for prims, due to the organic shape of mesh clothing (more math calculations) seems to me also that in the metric calculation there is a understatement toward mesh and away from prims, meaning that I am not sure that the work that the main processor has to do (in a type vs type comparison) has been factored in as well as it might be adding more avatars to the view doesnt change the basics of this. There's just more data of each type to manage and render I'm not sure that's completely correct. With a mesh, it's more work to calculate the first one but once it's calculated it's consistent and repeatable. One Maitreya mesh body will produce a substantial drop in framerate, but going to the Maitreya store and watching a dozen avatars wearing Maitreya bodies doesn't produce a drop a dozen times as high becase many calculations can be re-used. With the formula multipliers that are "unreasonably high", they calculate things that are going to potentially and often unpredictably change every frame - with flexiprims the location of the vertexes will change when the object moves, and with alpha-blended textures each pixel has the potential to have a different value based on the other textures seen through that prim. (Incidentally, ChinRey is wrong - prims with alpha masked textures aren't subject to the alpha texture multiplier.) Your flexi-hair tests were done in situations where the only textures involved were the hair itself or system-generated land and sky textures instead of a changing background. I'm not saying that the formula is completely accurate but I don't know enough about the rendering engine to say exactly how accurate or inaccurate it is. I do know that flexiprim rendering has been revised more than once in the five years I've been around here, and being in an area with a lot of alpha-blended overlapping grass prims is/has been death for framerates, at least with my old computer.

ChinRey wrote: And that means it's perfectly ok to start a sentence with a conjunction now? But I never really agreed with that rule anyway. Nor do I follow it myself. So I'm hardly in postion to criticise. But I think the reason why it seems so strange to me is that I interpret it as: "Now that all have been said and all the facts are on the table, what is the conclusion?" In other words: The OP has already made up his/her mind, knows the answer and is not interested in hearing what others have to say. Could work as a header for an article (although the gimmick would grow old fast) but it's hardly the way you'd usually start a discussion, is it? Bingo! You figured it out.

Kat Clifton wrote: Hey all, I'm looking for a scripted ferry to travel on one sim from island to island. Would love it to be automated to travel on its own, but... a drivable version would be great, too. Don't need anything huge - just a small ferry to carry people - up to maybe 10 or 12. Doesn't have to be fancy, although true to what might be seen in RL would be cool. Mesh desired. Anyone know where I might find something like this? Kat Clifton Take a look at this: https://marketplace.secondlife.com/p/Columbia-Ferry-Kit/6170230

ChinRey wrote: Theresa Tennyson wrote: Please provide evidence to show that the numbers from the "server" are accurate at all. Wow! I may often disagree with LL's decisions but even so, I do actually belive they are honest and that when they do things like updating the llGetObejctDetails() function to include render weight, they make sure they get it right. This is the kind of things they know everything about. But if you want irrefutable evidence, you'll have to ask some Linden. Only they have access to the source code for the server software. But apparently you also believe when the same Lindens issue a new viewer specifically engineered to work with avatar rendering and muting, they get it "wrong". There have been a number of tweaks to how the latest viewer calculates avatar rendering cost in the new viewer in the run-up to its release, so it may well return different numbers. Servers are limited in what they know about the "world", particularly on the graphic end. One bone of contention for years is that if you poll the servers to tell what height an avatar is, it will give you a number that doesn't match the actual dimension of your avatar from the top of its head to the bottom of its feet. This is because the only information on this that it can put its little electronic fingers on quickly is the avatar bounding box dimension, which stops at about eye level, and it can't be jazzed to process slider information to get the actual avatar mesh dimension. ETA - Looky here, where the Wiki mentions that llGetObjectDetails returns numbers "based on values reported by nearby viewers." It may poll a number of viewers and average the number so that a malicious viewer couldn't claim that a graphics crasher is Super Innocent and Small. Note that this entry was written and only edited by Maestro Linden. http://wiki.secondlife.com/wiki/OBJECT_RENDER_WEIGHT

ChinRey wrote: Aethelwine wrote: Whilst their ARC formula seems so badly flawed, is it really going to be of any use? Well, they just have to fix it, and fix it fast. Oz, are you reading this? One very obvious flaw that has turned up, is that QuickGraphics isn't actually based on the actual ARC at all, it's based on the ARC aproximation built into the viewer. I did some quick tests and found differences as high as 50% between the vierwer's and the sim server's readings. That was quite a shock and of course completely unacceptable. Easy to fix, add the actual ARC formula to the viewer, or alternatviely use the server's data instead. But a bug as basic as that should never ever have survived all the way to an official release anyway and the fact that it did casts serious doubt on the quality of the project as a whole. Please provide evidence to show that the numbers from the "server" are accurate at all. Personally I doubt that the server calculates ARC - it's just not designed to do it. Take a sculpted prim, for instance. All the server knows is that it is a 3D primitive with a texture of a certain UUID on it. Determining the number of vertexes, etc. would be a waste of cycles that the server needs to calculate physics interactions, etc. The server should logically let the viewer figure that out. This suggests that the "server" numbers are actually those sent from the connected viewers. With earlier viewers I've noticed that with sculpt/flexi items the ARC displayed often varied quite a bit with the same item. Now that I'm running the current jellydoll viewer some numbers seem different than before but are quite consistent, and higher than I remember before from the same items. This suggests that the current viewer calculates ARC differently than previous viewers. The numbers reported by the server are from a wide variety of viewers. I suspect that it's actually the current viewer figures that are accurate and the server numbers that are inaccurate.

Aethelwine wrote: Theresa Tennyson wrote: Aethelwine wrote: Theresa Tennyson wrote: Aethelwine wrote: Chimney, I am curious to know where you got those numbers and if there is a more detailed explanation anywhere for how the ARC Is calculated. The reason I am curious is because I have seen a comparison of mesh bodies and heads where the ARC value is very different from the complexity of the mesh measured by the number of vertices. The relationship between the two figures was the inverse of what you would expect. My understanding is that the rendering cost is how hard it is to render an avatar in any given frame. Many of the bodies that have high polygon counts but low ARC's have many additional triangles that aren't normally textured and visible - for example, alternate hand poses, etc. The rendering engine automatically ignores these triangles when it's rendering a frame but that data still needs to be sent to your viewer when that avatar arrives. It will take longer for that avatar to show up the first time because more data is sent, but it won't necessarily be difficult to draw (i.e. reduce your graphics framerate) it when it finally arrives. The Catwa head Jessica is made up of 3,931,000 Vertices, Lelutka head's about 62,000. Yet the ARC for Catwa head is 8,270 and the Lelutka 49,900. I do get a noticeable difference wearing these heads, the Catwa often takes a few logs to load, friends with that head often look like eye ball and brain monsters. The Lelutka head loads fine, they are both animated heads, they both look smooth. So what is going on with the ARC? and why does the low value head cause more problems than the high ARC head? How can a head 70 times more complex than the other have a fifth the ARC? If people work reducing their ARC to avoid being jelly beans and wear the low ARC head then that will cause more headless people on the grid and more rendering problems. The problems you're seeing with the Catwa head are because all those polygons take a long time to arrive at your viewer and everyone else's. Once they arrive, most of them aren't drawn at all. It's two completely separate things. It's as if you have two classes in school - with one of them your nightly assignment is to read 10 pages out of a 1000 page book, and with the other you read all of a series of 100 page books every night. The book for the first course will always be heavier to carry; the assignments for the second course will always take longer to read. I understand what you are saying, I think, but I still don't see how that can explain those numbers. Both are heads, both will have some tattoo layers, both will have stuff invisible for doing their facial expressions. The more complex head is a fraction of the ARC of the much lighter head. When I asked the Chalice Yao about this she replied: "The answer is that Render Weight, for whatever reason, hardly freaks out about insane geometry. Which does not really make sense, especially when it comes to rigged geometry. Heck, Render Weight freaks out at times about things that *don't* slow down your PC; Flexies are an example. Flexies kick RW up by the 10's of thousands, but while flexies are calculated on the CPU, they also have a tiny, hard limit of time their calculations are allowed to take..you'd need a LOT of flexy to slow anything down. Yet, it's punished very, very harshly." Whilst ther ARC formula seems so badly flawed, is it really going to be of any use? and if it encourages people to wear insanely complicated mesh, as it appears to do, won't the effects be to make peoples experience worse and not better? I did a test, standing on a pose stand in a skybox with a low draw distance and kept my camera position stationary. This meant that the figure "KTris per Frame" under the Statistics panel was absolutely solid and identical for every frame. This number is the actual number of triangles the rendering engine draws every frame - the higher the number, the harder it's working. CONTROL: Avatar with only the required system components, draw weight 1000 = 83.944 Ktris per second. SAME AVATAR WITH CATWA "ANNIE" MESH HEAD DEMO AND ASSOCIATED ALPHA = 133.916 Ktris per second. SAME AVATAR WITH LELUTKA "KARIN" MESH HEAD DEMO AND ASSOCIATED ALPHA = 171.680 Ktris per second. These numbers suggest to me that the higher render weight for the Lelutka head is perfectly accurate for what the render weight is meant to represent, despite the Catwa head having a much higher vertex count.

Aethelwine wrote: Theresa Tennyson wrote: Aethelwine wrote: Chimney, I am curious to know where you got those numbers and if there is a more detailed explanation anywhere for how the ARC Is calculated. The reason I am curious is because I have seen a comparison of mesh bodies and heads where the ARC value is very different from the complexity of the mesh measured by the number of vertices. The relationship between the two figures was the inverse of what you would expect. My understanding is that the rendering cost is how hard it is to render an avatar in any given frame. Many of the bodies that have high polygon counts but low ARC's have many additional triangles that aren't normally textured and visible - for example, alternate hand poses, etc. The rendering engine automatically ignores these triangles when it's rendering a frame but that data still needs to be sent to your viewer when that avatar arrives. It will take longer for that avatar to show up the first time because more data is sent, but it won't necessarily be difficult to draw (i.e. reduce your graphics framerate) it when it finally arrives. The Catwa head Jessica is made up of 3,931,000 Vertices, Lelutka head's about 62,000. Yet the ARC for Catwa head is 8,270 and the Lelutka 49,900. I do get a noticeable difference wearing these heads, the Catwa often takes a few logs to load, friends with that head often look like eye ball and brain monsters. The Lelutka head loads fine, they are both animated heads, they both look smooth. So what is going on with the ARC? and why does the low value head cause more problems than the high ARC head? How can a head 70 times more complex than the other have a fifth the ARC? If people work reducing their ARC to avoid being jelly beans and wear the low ARC head then that will cause more headless people on the grid and more rendering problems. The problems you're seeing with the Catwa head are because all those polygons take a long time to arrive at your viewer and everyone else's. Once they arrive, most of them aren't drawn at all. It's two completely separate things. It's as if you have two classes in school - with one of them your nightly assignment is to read 10 pages out of a 1000 page book, and with the other you read all of a series of 100 page books every night. The book for the first course will always be heavier to carry; the assignments for the second course will always take longer to read.

Aethelwine wrote: Chimney, I am curious to know where you got those numbers and if there is a more detailed explanation anywhere for how the ARC Is calculated. The reason I am curious is because I have seen a comparison of mesh bodies and heads where the ARC value is very different from the complexity of the mesh measured by the number of vertices. The relationship between the two figures was the inverse of what you would expect. My understanding is that the rendering cost is how hard it is to render an avatar in any given frame. Many of the bodies that have high polygon counts but low ARC's have many additional triangles that aren't normally textured and visible - for example, alternate hand poses, etc. The rendering engine automatically ignores these triangles when it's rendering a frame but that data still needs to be sent to your viewer when that avatar arrives. It will take longer for that avatar to show up the first time because more data is sent, but it won't necessarily be difficult to draw (i.e. reduce your graphics framerate) it when it finally arrives.

Chrismaky wrote: Amethyst Jetaime wrote: You have way over simplified mesh vs. prim. It is NOT easy building realistic and efficient items in prims or mesh. If it was there would be no need for content creators since everyone would be making their own stuff and saving tons of money since SL started. In answer to your question though, I vote with a big NO! There are too many people in SL that enjoy creating things using regular prims just for their own personal enjoyment and as a creative outlet. They have neither the time, talent, money (for uploads) or the incentive to learn how to create mesh. Mesh has to be created outside SL and that is a big drawback for a lot of people. If they were going to spend a lot of time outside of SL doing that, for a lot of people who just come here to create what is the point of being in SL then? But what if simplified mesh creation replaced the prim building tool? I don't believe anything is impossible and I do believe the very core of Second Life, the building tool itself, needs to be upgraded...made simpler to use and using a mesh creation engine. I am not saying right now but way down the road. It is totally a possibility. Theresa Tennyson puts on her very, very most innocent face. What's the difference between a mesh object and a prim object in Second Life? Oh, and I just saw this - "made simpler to use"? Weren't you arguing that the current building tool is too simple earlier?

Prokofy Neva wrote: No, Theresa, you are *still* not telling the truth about this obvious phenomenon that everyone knows about. Do you log into Second Life much? It is indeed IMPOSSIBLE to put mesh on mesh NEARLY ALL THE TIME. It's not a rare occasion or a small percentage of time. It's the main default with few exceptions. You admit that it's the majority of times. That indeed means it is IMPOSSIBLE. Your nit-picking and thinking there is some need for you to "intervene" here and "set me straight" about those *edge cases* where mesh does place is a typical forums caper but that doesn't validate it any more. Only applying binary yes/no code conceptions to the phenomena of real life could you come up with a statement like this. Real life -- the real experience within SL -- is that nearly always, mesh bounces. Before I posted that, I went to a few of the several SL properties I own, which I log onto daily, and rezzed several mesh objects onto other mesh objects, both houses and furniture. None of the items failed to rezz. In a certain location in one skybox the items rezzed in unexpected locations in that skybox - that was the only problem I had. I didn't say it was a majority of times, I said it may be. From my experience, it isn't. Given that you're convinced that mesh won't rezz on mesh, how often do you try currently?

Prokofy Neva wrote: No, you're simply not telling the truth about this at all. I decorate dozens of units constantly and put down mesh constantly, hundreds of pieces day in and day out. The overwhelming majority of cases BOUNCE and give you the error and disappear into a kind of "lost and found" UNLESS you rez them on a prim. Everyone knows this and your pretense that it isn't true just boggles the mind. If occasionally some items don't do that, great, but that can also be due to the fact that some house makers now put prims under their floors to deal with exactly this issue. It's not "prior experience". It's ongoing, daily, constant experience with the very newest and best mesh creations from the latest events of even this week. There's no need to be contrarian for contrariness' sake. We all know the reality of the mesh placement problem. 1.) You said it was "impossible" to rezz mesh on mesh. 2.) It isn't. Yes, there are occasions that what you describe will happen. It may even be a majority of times. But it's not every time, and it's not impossible.

Perrie Juran wrote: Chrismaky wrote: It is 2016 and SL is still loaded with a lot of terrible looking high prim non-mesh items, especially in its marketplace. Now I am a bit biased because I'm a hardcore mesh addict and I like to have my items, objects, clothes and myself look nice. But a lot of people it seems still prefer (and alot of designers continue to make) non-mesh stuff. Why? Mesh is more realistic, better looking, resizeable, and is much lower in prim/land cost. Do you think there should be a push to make SL 100% mesh? So many assumptions and part truths here. You sound like a graduate from the school of "If It's Mesh Its Got To Be Good." For every crappy prim you can find I can find you a piece of crappy mesh. Maybe you just haven't seen a lot of what a truely talented Prim Artist can do. Sadly there seem to be fewer and fewer in SL. How much I wish the Nemo or Alpha & Omega Sims were still here. Thye were technically marvelous works of art. And while granted you may be able to do more for lower Land Impact with Mesh, Land Impact is a server side measure. It does not tell us what really should be our bigger concerns, Avatar Rendering Complexity and Mesh Rendering Weight. That's what's happening Client side and where people really have the problems they encounter. Oh, I could go on and on here. In fact I could postulate that Mesh has done more to hurt SL than it has helped and make a pretty good case for it. In fact in some if not many cases Mesh has degraded and not enhanced peoples Imagination. eta:Shpelling The truly talented Prim Artists are probably now truly talented Mesh Artists, because as Artists they are going to be drawn to the most versatile tool that will help them produce their Art. I've already argued that if mesh items are what's driving inflated rendering weights I don't see it by looking at actual attachments. I have fully-mesh outfits that have lower rendering weight then one sculpted sneaker (not even taking into account the bonus features that sneaker might have had, such as a multi-hundred-kilobyte resize script and an invisiprim scripted to change textures every ten seconds.)

Chrismaky wrote: Thank you for visiting my sim. Too bad ya couldnt go a step further and actually engage in any form of conversation. And yeah, laying out a box (or a shape from the building tool for that matter) and is way too easy and simple. Same with stretching and such. The basic build engine is incredibly simplified. You didn't seem to be in the mood to chat, as you kept asking how I found it when I was looking for the now-vanished club you were advertising the grand opening of two months ago. Spawning shapes, clicking and stretching is actually a not-uncommon way to use professional 3D programs - it's how Vectorworks behaves, for instance. And, after I took a quick peek, Blender itself for that matter, right down to the tri-colored vector display. There are no style points for making something unnecessarily complicated. The measure of a build is the build itself. Most tools can seem simple once you learn how to make them work, but are difficult until you do. It's the same with scripting a door, or running a club.

Chrismaky wrote: I totally understand that SL is a user generated content community. I get that. But a lot of you need to understand that creating mesh is FREE and easily learned. It's not a hard thing to grasp. I'm not saying to force mesh on everyone by replacing primmy stuff. What I am saying is more people should start downloading Blender and other free mesh creation tools, and LEARN. Clicking build and putting down a box is like for little kids when we had Blocks. Its too easy. Too simple. We need to keep expanding our minds and learning new things. BLUE In your initial post you said, and I quote, "Do you think there should be a push to make SL 100% mesh?" RED There's no such thing as "too easy" and "too simple" if there's an easy, simple way of doing an action. Besides, personally I consider the SL build engine neither simple nor easy.

Chrismaky wrote: It is 2016 and SL is still loaded with a lot of terrible looking high prim non-mesh items, especially in its marketplace. Now I am a bit biased because I'm a hardcore mesh addict and I like to have my items, objects, clothes and myself look nice. But a lot of people it seems still prefer (and alot of designers continue to make) non-mesh stuff. Why? Mesh is more realistic, better looking, resizeable, and is much lower in prim/land cost. Do you think there should be a push to make SL 100% mesh? Everything in Second Life has some sort of major flaw or shortcoming, or else nobody would ever make anything new. It's human nature to overlook the flaws in things that you're used to and focus on flaws on things that are new to you. Also, things that are new often have bugs that need to be worked out, and people used to older things may reject those things because of those bugs and don't realize that some of those bugs will later be fixed or overcome with experience. For instance, Mr. Neva's statement that "you can't rezz one mesh object on top of another." It's perfectly possible - I just did it. However, when mesh houses first were introduced many builders built things in such a way that you couldn't, not knowing all of the idiosyncracies of the Second Life environment. Therefore, Mr. Neva assumes that it's impossible based on his prior experience. As far as making SL "100% mesh", it already is and always has been, as it's made up of objects consisting of an array of points in space that form polygons. There have been at least three ways these objects have been formed - by manipulating 3D "primitives" directly, by using bitmaps to move vertexes on those objects ("sculpted prims"), or by uploading predetermined models from outside sources. All these ways have their own strengths and weaknesses.

Lessa Joubert wrote: Is anyone else having problem with system clothing (like old, non-mesh) not rezzing? My avatar is rezzing, skin, hair, attached prims, but where the system clothing would be I'm just white. Not something I've ever seen before! Help? See if you're wearing an item called "New Shirt" or "New [whatever]". Sometimes the system will get the idea you're wearing a completely new non-textured clothing item when you never actually put it on, and it will appear as an all-white garment completely covering what that item would normally cover.

Teagan Tobias wrote: Supersatan3 wrote: They accused me of poaching the prospective auctionees. I denied it. The owner says that I hit up on his alt, which I didn't. My only guess is that someone I've pissed off made some stuff up in retaliation. I just want my money back at this point. Hmmm, so the owner has alts making bids to drive up the selling price, sounds like a sound business practice to me. Not to mention collecting cash for the bids before the auctioned item is won.