Pandorah Ashdene

I have been following the discussion here on the forum, and on various other sites, but there seems to be an aspect, that hasnt cropped up anywhere, so, let me play the devil's advocate here for a moment, and let me point out a consequence of the 'official' postion held by Linden Lab; just to make that clear, it is nothing I 'suggest', but it is merely a logical result of how Peter Gray (Linden Lab spokesman) 'explained' the Lab's position regarding the TOS changes; I quote Peter Gray from http://nwn.blogs.com/nwn/2013/09/linden-lab-tos-textures.html: "Linden Lab often acts as an intermediary between Second Life residents (for instance, in its capacity as the operator of the Second Life Marketplace) which necessitates that Linden Lab have certain rights (such as the right to re-sell) in order to effectuate such exchanges or transactions." So, let's think that through, shall we? Agreement to the TOS is necessary for the Lab to be able to deliver items on the market place. So. What will happen now to all the content, that is on the MP belonging to accounts that havent logged in since the TOS change? Because strictly speaking those merchants havent agreed to the TOS change, from which follows their products can not be delivered by the Lab, since agreement to the TOS is necessary for that service. Will all those products be removed and/or set inactive? When is this purge going to happen? Or can we decuce by argument of contradiction, that since the removal is not happening, that the 'justification' is not valid, ie. the position that the TOS change is necessary for the MP delivery just not true? Linden Lab, your move. ((Not that I expect a reply, to be honest - the Lab is as usual 'sitting it out' and hopes for the whole thing to 'blow over', - soon to be replaced by another decision we can all get excited about))

HisaDrug wrote: (...) Also I found another bug today that the confirmed payments on MP only show up on my trasnaction, but on MP. I'm not even sure what they bought because they are untrackable (...) Hisa, I had the same issue and was puzzled for a while, but it seems that the ones that show up in the transaction without an entry in the MP book keeping are the 'latecommers', ie. these are the payments you 'missed out' on; you probably have to go way back in your MP book keeping to find the original purchase entry;

The "customer charged, item delivered but creator not paid" bug is still up and running. Just had one instance myself:

Well, considering the fact that the MP is still not 'uptodate' regarding that merchants still have to specify an object's land impact in the slot 'prims', the Lab seems to have some consistency problems on their own, but can you be a little more specific and clear (not that your post was not fun to read)? Regrads, Pan.

Oskar Linden wrote: (...) The SVC-8124 issue is one which we are working on fixing in the Magnum channel. __Oskar Thank you Oskar, I realy appreciate that 'feedback - even if it's not much more than "we are aware of it"' - as Hitomi pointed out, a lot of the 'anger' and frustration on our side has to with the lack of communication, and being left 'in the dark'; - sorry to say so, but the 'acknowledged' flag on the Jira and the assignement to WorkingOnIt Linden has lost its value over time, where Jiras stayed unfinished in that state for ages; I realy can't emphasize enough the killer-dimension this bug has for people like me with a datacap; without me noticing that hole in the bucket used up this month's data alocation in a few days, before I became aware of the issue and could locate it (- no malware or virus, but logging into SL at the wrong spot); and for the rest of it I am forced to pay each MB I use the net extra; I realy wonder, if you (not especialy you personal) are underestimating the impact this has and the urgencey - it realy is more than "people have to deal with a little more lag than usual"; So, at least it's recognised as an issue and I realy hope you get that fixed sooner than later; - for me personal SL is off-limits for the rest of the month.

You're not serious, are you? My jaw just dropped to the floor. - I am seeing https://jira.secondlife.com/browse/SVC-8124 mentioned nowhere. We are bleeding datatransfer-wise to death, and you are planning "no intentional changes to existing behaviour"? Sorry, I am so angry that I better refrain from posting one more word.

WolfBaginski Bearsfoot wrote: ... At times SL systems are trying to send very large amounts of data, using significantly more bandwidth than I have set as a limit in-viewer. This is maxing out my connection and showing high rates of dropped packets. ... There is a major network bug spaming the pipeline: https://jira.secondlife.com/browse/SVC-8124

Theresa Tennyson wrote: My understanding of the accounting is that hollow objects like tubes or torii are hateful for physics calculations which is why they're penalized. However, you can set the physics type to "none" for your tube and put simpler invisible shapes inside it for the walking surface, or you can sandwich together two scooped out half-cylinders. Hello Theresa, thank you for suggesting possible workarounds for the issue; the matter still stands that the era of one legacy prim = one landimpact is over;

arton Rotaru wrote: Hi Pan,:cathappy: I asked this last week at the pathfinding meeting. It's just like it's described in the release notes. The keyword here is "streaming cost", which is the "download weight" in the viewer. Only the download weight is capped. The physics weight is unchanged. So if the physics weight of a legacy prim is greater than 1, it's land impact will be greater than 1 as well. Hello Arton, It took me a while to wrap my head around your clarification, but I am seeing the problem clearer now; thank you very much. So it is the physics setting to 'Prim' (which is the default when you rezz them) that is the 'source' of the landimpact explosion, which has to be switched to 'Convex hull' to avoid the effect; which is not practical, in case you want the prim to have an 'inside', say a hollow cylinder, that you want to use as walkable canal pipe; I see a lot of grief in this implementation and not the intended "encouragement" to switch to the 'new' accounting;

Hello Oskar, you keep repeating: Changed prim accounting for legacy prims which use the new accounting system All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0). This provides the benefit of not penalizing prim-based creators for optimizing their content by opting into the new system and will make the streaming cost more reflective of the true network cost of the objects.But this is NOT how it works! Some of us are still waiting for the answers to the questions we brought up in the thread for the deploy of 2012-07-09 (http://community.secondlife.com/t5/Second-Life-Server/Deploys-for-the-week-of-2012-07-09/td-p/1595111 ) Would you please be so kind to clarify?

Innula Zenovka wrote: @Talia -- thanks, and this is what's puzzling me. The KB article on Calculating Land Impact (a topic I don't really understand, which is maybe why I'm having problems) says that For each object in the Second Life world, Second Life compares three important performance factors: download weight, physics weight, and server weight. It then chooses the highest of these weights and assigns it to the object as that object's land impact rating. and Maestro seems to be suggesting the reason the LI of Pandorah's object is so high is that its physics cost is the highest of its three weights in this case, so that's the value being used to calculate its Land Impact. That makes sense to me, but at first sight it seems to subvert what I'd thought was the intention behind these changes to the prim accounting system, since any benefits gained by changes to the way the object's streaming cost is calculated are apparently purely academic once the streaming cost falls below the physics weight. Is it that, if I've got an object currently composed of complex prims and sculpties that uses the Volume Detect hack, and I want to ensure that setting the "phantom" child prims to PRIM_PHYSICS_SHAPE_NONE doesn't increase my object's LI to an uneconomic figure, I simply need to set the non-phantom components to PRIM_PHYSICS_SHAPE_CONVEX at the same time I set the components I want to be phantom to PRIM_PHYSICS_SHAPE_NONE in order to enjoy the benefits of these changes? This seems to be exactly the issue; Like in the post I made (two up) consider this example: I rezz a mesh I-Beam (physics 'prim': download 0.1, physics 0.3, server 0.5) with LI=1 and link it to a hollow cylinder (physics 'prim': download 0.6, physics 13.0, server 0.5) with LI=1 and the result is LI=13 (!!) Prior to linking the physics of the cylinder (13.0) is 'hidden' because on rezzing the cylinder uses 'legacy accounting' and it shows a landimpact of 1; the linking to the mesh element changes that and the LI jumps to 13; you could now set the physics of the linked-in cylinder to 'none' (if it's not the root) or 'convex hull' to 'compensate'; But I find this ridiculous; if you're building you have to go through all elements in the linkset and switch all by hand; if you have a scripted situation the script will have to go through all elements in the linkset and make the 'right' choice; sorry, makes no sense to me.

Innula Zenovka wrote: I think what's confusing Pandorah (and if it's not, I apologise, but it's certainly confusing me) is what Nyx was saying about changes to the LI accounting system at the Mesh User Group meeting of March 30, (12:18 and following) and what Falcon was saying at the Simulator User Group meeting of March 27 (about 5pm) . The idea was to stop people using the llVolumeDetect hack to phantom child prims (particularly sculpties), because that and pathfinding don't play nicely, and have them do it properly by setting them to PRIM_PHYSICS_SHAPE_NONE, wihout breaking large amounts of content by forcing them to use the LI accounting system and become horribly expensive. Maybe I misunderstood, but the impression I got from reading those, and various other transcripts at the time was that, while nothing was finalised, the aim was to change the LI accounting system so that changing non-mesh objects to the LI accounting system didn't appreciably increase their cost. Did I and others get that wrong? Or is it going to happen but it's not yet been turned on, or what? Yes Innula, this is exactly how I understood it too, but obviously that's not how it's meant to work, or at least it's not working on the Magnum test sandboxes.

Maestro Linden wrote: Pandorah: what caused the land impact to be 113? Was it physics weight? Both tori and hollow cylinders are very expensive to the physics engine, and thus have a very high physics cost. Setting them to physics shape type 'prim' should be avoided whenever possible. This guide has some more information: https://wiki.secondlife.com/wiki/Physics_Optimization Hello Maestro, thank you for replying to my post. Maybe I should explain the general problem I have with the way you have implemented the landimpact accounting in the 'mesh context', which I was hoping would finaly be fixed by the pathfindng rollout. Take this simple scenario: I build something out of legacy prims, say I rezz a cylinder and hollow it; the way the prim gets 'born' is with physics shape 'prim'; and not a problem, the land impact is 1; now I rezz a second cylinder, say again a cylinder, hollow it and use it as ring around the first; I link both prims; landimpact becomes 2; fair enough; - and please note: BOTH prims default to physics 'prim' in this situtation; Now I try to be a considerate builder and decide to set the physics of the second hollow cylinder to 'none', because, well the bigger cylinder as collision shape should sufficent; and POOF! - the landimpact jumps to 13 (!!) Seriously. This makes no sense - the two cylinders - both with physics 'prim' - count as LI=2; switching one of the prims to physics 'none' results with a LI=13 (more than six times the value!) for the linkset; this is totaly reverse to what it should be! - dont I reduce the server physics calculation by switching off one the prims in the linkset? Originaly my 'problem' actualy surfaced in the context of using mesh in combination with legacy prims (again hollow cylinders and the like), because linking a mesh object with legacy prims has exactly the above described effect; and let me be frank here, I stopped making new mesh stuff because I find it realy hard to 'explain' or justify this effect to people who potentialy buy my stuff; The way legacy prims and mesh interact regarding the landimpact make it in my opinion unusable; sorry to say so; I was helping you guys testing when mesh was still on Aditi and was realy looking forwar to it being on the main grid, but to be honest, the way you implemented it, you realy ruined it for 'us' builders; Basicaly I have to label the mesh items I make with a WARNING! sign and an explanation as long as my arm, to prevent people from linking their own builds with them; how much sense makes a mesh building element (say a corrugated metal sheet) if people can not link into their builds with the landimpact exploding? The comments in the Pathfinding context, that legacy prims will be capped to a LI=1 and sculpts to LI=2, made me hope that there is finaly light at the end of the tunnel, but it doesnt seem so; I rezz a mesh I-Beam (physics 'prim': download 0.1, physics 0.3, server 0.5) with LI=1 and link it to a hollow cylinder (physics 'prim': download 0.6, physics 13.0, server 0.5) with LI=1 and the result is LI=13 (!!) Sure, *I* do understand why that happens (looking at the 'More Info' panel, - but look at it the way it looks to the 'average' hobby-builder, that normaly has the 'More info' panel not open: when they link in the mesh part the landimpact explodes! In this case, it might look 'easy' to find the source of the problem, but imagine a build with say a hundred legacy prims; somebody links in the i-beam and POOF! they get the build returned and probably cant even rezz it anymore because the landimpact went way beyond what they have as resources; and then I get IMs blaming me that my stuff is crap because it ruined their build; what do I tell them? "Go to a sandbox and try to switch the physics of some of the prims in your build to 'none' or 'convex hull'"? Sorry, but this is a total mess, and I was realy hoping that the Pathfinding cap for legacy prims would finaly 'repair' the situation; obviously it doesnt; which leaves me at a loss.

Maybe somebody can help me out here (I assume I am 'missing' something) regarding the following 'feature' on the Magnum Server: All legacy-style prims have their streaming cost capped at 1.0 (except for sculpts, which will be capped at 2.0). This provides the benefit of not penalizing prim-based creators for optimizing their content by opting into the new system and will make the streaming cost more reflective of the true network cost of the objects. I made the following test: a pipe built out of 4 legacy prims (four hollow cylinders and a quarter hollow torus) and two sculpts (bolts), which shows up with a land impact of 6 with 'legacy' accounting; when I switch the sculpts to 'physics shape' "none" the land impact jumps to 113 (!); Shouldnt the 'capping' have the effect that it is limited to a land impact of 8?

Medhue Simoni wrote: Pandorah Ashdene wrote: Hello Medhue (/me waves), I am not so sure about your remark "It is all mesh based, so they are never going to see the massive overuse of polygons and textures that plagues SL." - what makes you think that? As far as I could see there are no polylimits or any accounting (like LI) in place as of yet, and the texture size limit is 1024x1024, - same as SL; so it should not be too hard to upload pretty 'heavy' meshs ploywise, with a bunch of materials, each of them overlaoded with a 1024. Hey Pandorah!! Yep, you are totally right. I should have elaborated. See there is a big difference between object made with prims and sculpties and a mesh. Each new sculpty requires a texture, and many have really high poly counts for what they actually are. A mesh of the same sculpty could easily be 1/10th. With prims, you need to use many to get a complicated shape, and the more you twist and distort a prim the more polys you get. A prim can also have 6 different textures on it. Plus, even a mesh box can be less polys than an SL cube, and it will only have 1 texture, even if every side is different. Now, when you compare this to a mesh. There is a much higher learning curve to making it. This means, that generally more people will understand not to go crazy with polygons if you don't need to. When you combine this with the fact that a mesh has an editable UV Map, the total texture data saving can be crazy. I've put whole animal skins on 1 1024 x 1024 texture. People put whole building on 1 texture. Just in total texture data alone, you are talking a massive amount of texture data savings. Thanks for clarifying you point of view. And having had a few discussions with you, when mesh was still on Aditi, I know that you are a conscious builder and take all those aspects into consideration; I know that YOU know how to make effective mesh content. I could even lengthen your list of bad building practice, especialy with sculpts, where I have even seen people use 1024x1024 sculpt maps, lol, - but I did not question whether mesh CAN be used more efficient than legacy prims or sculpts; The issue I have with your statement "It is all mesh based, so they are never going to see the massive overuse of polygons and textures that plagues SL.", is that you imply, that the fact, that all content is only mesh there will be "no overuse of polygons and textures". Right now the biggest question for me as builder is "What will be the 'accounting' of builds/meshs?" - what I mean by that, is right now as far as I could see you can upload pretty much anything and rezz it; in SL the upload costs and to a much higher degree the landimpact 'encourage' you to a certain degree to be effective, at least regarding the polycount (you can still slap eight 1024s on the materials, which is roughly a 32MB download for the object); Mesh content without the implementation of an 'incentive' is NOT going to be necesarily 'effective', not if we talk about "user created content"; not if you think of the users that are beginners or hobbyists, that often arent even aware of the 'problem'; CloudParty will have to put a lid on 'usage' in some way - otherwise you can be sure that people will upload & rezz meshs that bring your computer on its knees - and that 'lid' will enforce 'effectiveness'; mesh per se does not guarantee low-lag content or prevent abuse.

Hello Medhue (/me waves), I am not so sure about your remark "It is all mesh based, so they are never going to see the massive overuse of polygons and textures that plagues SL." - what makes you think that? As far as I could see there are no polylimits or any accounting (like LI) in place as of yet, and the texture size limit is 1024x1024, - same as SL; so it should not be too hard to upload pretty 'heavy' meshs ploywise, with a bunch of materials, each of them overlaoded with a 1024.

I had similar problems in various situtations (the ambient occlusion or texture of a meshpart 'meeting' a surface not being in the 'spot', where the mesh actualy met the surface); this is what I figured out about the problem and the 'solution' always worked for me: I assume you are modeling (like most people do, including me) in rectangular faces (quads) and not in triangles; the quad can be split two ways into two triangles; if you do not do that yourself, the dae converter will do it before you make the upload to SL; so, 'in' SL the mesh will have triangular faces only; Blender does this quad to triangle splitting as well 'on the fly' while you are looking at the mesh (in textured view), and it does the split when rendering the ambient occlusion or any other bake. The problem I observed with Blender is that it makes a difference which way the quad is split, and what basicaly happens is that Blender splits the quad for the AO calculation in one way, despite using the opposite split for display; I solved all this mess by simply splitting the quad in question myself (quad to trig) and forced Blender thus to use the same quad split for the bake process and the display (and finaly as well for the dae export);

According to Charlar Linden in the mesh user group meeting ( https://wiki.secondlife.com/wiki/Mesh/Archive/2011-07-25 ): [12:47]Charlar LindenUpload cost will go up after we reach 100% deploy to maingrid. So, can you please be a little less nebulous? Or is the parrot gonna pick a random number in the last minute?

Marcthur Goosson wrote: ... (I also found a bug: texture faces switching when changing LOD) ... You might have stumbled over that one: https://jira.secondlife.com/browse/CTS-603?

Josh Susanto wrote: >"How many people are working on the Marketplace Codebase?" If you hire 1 person to polish 2 turds or hire 2 people to polish 1 turd, the result will tend to be about the same either way. Not true. In the first case you get twice as many polished turds.

I did not notice your following statement when first skipping through your post: Welleran Kanto wrote: (...) I also notice that I do not have a Mesh folder in my Inventory. What am I doing wrong? Are you sure you are using the right viewer and are in the right grid? You must use the project viewer (found here : http://wiki.secondlife.com/wiki/Linden_Lab_Official:Alternate_Viewers#Second_Life_Project_Viewers ) which will logg you automaticaly into Aditi, where you should find the 'Mesh' folder in your inventory.

When the upload works you will have two new items in inventory (both with the same name): * one in the folder 'Mesh' * the second in your 'Objects' folder The one in the 'Objects' folder is the one you can rezz. If you did not 'fix' the scale in the upload window and your mesh is coming from Blender it is very likely that it is very very tiny to begin with. If neither of them appears, did you check if the circular 'lights' for the lower LODs are green in the upload window?

ChuckBaggett wrote: Just because something is being seen doesn't mean it's accomplishing it's purpose. Annoying people repeatedly shows up on view counts just as well as pleasing or influencing them in the desired manner does. Your animated badge here is one the two I've got blocked so far. Your animated badge about viewer 2 in the Jive forum wasn't quite as annoying as the badge you're using here. Seeing that animated viewer 2 signature gif did not improve my opinion of viewer 2 any, of course, but it did cause me to be slightly annoyed in connection with viewer 2 many times. I suspect that if the ability to make specific animated gif files display the first image but not animate was buillt into browsers that there would be a lot less animation being displayed. I suspect that if one could turn off the animated gif files but still see the first image here in our settings there would be a lot less animated being seen. Unfortunately these options aren't available. The only options are to see the animations repeatedly, press escape after each page display, or not see the image at all, so instead of seeing a static version of the animated gif, you see nothing. I'm not interested in never seeing any animated gif files anywhere on the internet, so the about:config suggestion isn't something I want. I so totaly agree. In general and on the specifics.

Madeliefste Oh wrote: Where can I find the subscription of this office hour, please? http://wiki.secondlife.com/wiki/User:Brooke_Linden/March_User_Group_3-1-2011

Downloaded and installed it. Admitedly you have finaly fixed some mayor annoyances (like floater transparency) after, what, eight months? But you still havent fixed https://jira.secondlife.com/browse/VWR-14070 Oddly enough the latter is not an issues with the mesh viewer version. Don't you guys swap patches?