Search the Community

Are their other ways of writing this code that's more efficient and less demanding of script memory? Feels like I'm writing the same code over and over for each child prim that is scripted to move. Wondering if any better ways of cleaning this up, perhaps some kinda Getting of Linkset Names as a global list in the state_entry() inside of having to spam the same code to always re-seek the the same info? Wasn't a new lsl function added not to long ago where one could store a linkset's data in the root prim or something like that and call stuff from that.. kinda acts like a list but isn't? Im not so sure on that one as I've forgotten what it was called or did but vaguely remember details. XD Gist of it, script sits inside the root prim, touch event searches the linkset child prim that is defined below, then searches the linkset again for said child prim and does the code to move it. Anyways, the code Snippet! key owner; integer eng1 = FALSE; Engine1() { if (eng1 == FALSE) { eng1 = TRUE; //llPlaySound(sound_gear,volume); integer prims = llGetNumberOfPrims(); integer counter = 0; for (counter = 0; counter < prims; counter++) { if (llGetLinkName(counter) == "Engine Cell 1") { list params = llGetLinkPrimitiveParams(counter, [PRIM_DESC]); list detailz = llParseStringKeepNulls((string) params, [":"], [""]); llSetLinkPrimitiveParamsFast(counter, [ PRIM_POS_LOCAL, (vector) llList2String(detailz, 1), //PRIM_COLOR, 0, <0.596,0.596,0.596>,1, PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]); } } } else if (eng1 == TRUE) { eng1 = FALSE; //llPlaySound(sound_gear,volume); integer prims = llGetNumberOfPrims(); integer counter = 0; for (counter = 0; counter < prims; counter++) { if (llGetLinkName(counter) == "Engine Cell 1") { list params = llGetLinkPrimitiveParams(counter, [PRIM_DESC]); list detailz = llParseStringKeepNulls((string) params, [":"], [""]); llSetLinkPrimitiveParamsFast(counter, [ PRIM_POS_LOCAL, (vector) llList2String(detailz, 0), //PRIM_COLOR, 0, <0.596,0.596,0.596>,0, PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_NONE]); } } } } Engine2() {}//Would repeat more of the same code above for other child prims. Just for example. default { state_entry() {owner = llGetOwner();}//Dont mind this.. just part of an Access System. touch_start(integer total_number) { integer linkno = llDetectedLinkNumber(0); list details = llParseStringKeepNulls(llGetLinkName(linkno), [" "], [""]); key id = llDetectedKey(0); if (llGetOwnerKey(id) == llGetOwner()) { if (llGetLinkName(llDetectedLinkNumber(0)) == "Engine Cell 1") {Engine1();}//Cell 1 else if (llGetLinkName(llDetectedLinkNumber(0)) == "Engine Cell 2") {Engine2();}//Cell 2 //Else if Repeats more of above ^ that would other wise be placed here. } } }

Howdy folks! I've been searching this forum (and others) for, simply put, a tutorial or description of the workflow for someone beginning in Marvelous, best export settings used, tools programs used, etc. I realize - or the sense I get, anyway - that MD gets a bad rap for lazy creators dumping rigged DAEs straight from it into SL, and it's the retopologizing/optimization process I'm struggling with the most. I have experience in rigging simple shapes, photoshop-and-local-textures based texturing and know enough to be dangerous, but I cop to having a lack of foundation (along with a measurable artistic disability that's alleviated by using tools like MD rather than being able to sculpt a hoodie from scratch.) I'm not even looking to start a big successful fashion label, but I would like to dress my Jake + 3rd party devkit combo, and I'd like to learn as many best practices as I'm able. Even after my best attempts at re-meshing and optimization I see this: (I realize textures do most of the magic in this process, and the shirt has none - it's the rough edges around the arms and the breaks in the seams down the edge I don't see in 'professional' work.) But I digress into details. My eternal gratitude in advance for being pointed in the right direction. And maybe a free pair of trackies if I do get good ;E

I just wanted to share this interesting article I stumbled across where someone built an entire environment in Unreal with the goal of only using one single texture. One-Texture Environment And here's a thread on Polycount where the artist posted WIP shots over the course of creating the environment. Granted, the artist here uses a lot of technical tricks that aren't available to SL users but it's still fascinating. And while this is on the extreme end it does highlight how much emphasis is placed on optimization for realtime 3D art outside of SL, something I wish we'd see more of in this community. While modular textures are common in game design, I can't say I've ever seen the particular trick used in content made for Second Life. If we ever want to see better performance in SL, and more reasonable hardware requirements for what we see on screen, it's something the SL community really needs to push towards. The thread in General regarding the Crystal Cave skybox LL released for Premium accounts got me thinking again about how LL's in-house content should really do more to showcase good creation habits that users might learn from, or at least be able to see examples and the performance gains possible.

With all of the talk lately about how any effort to get content creators to optimize their work might "force content creators out of SL" I thought I'd make some tutorials showing just how easy optimization can be. So for this first tutorial, I'm tackling LOD. Here is the link to the tutorial. I hope you find this information useful.

A few people have asked about this in the "A Conversation with Linden Lab CEO Ebbe Altberg" thread so rather than derailing there, I'm making a new thread here to give people some insight into this issue. To get a higher and more stable framerate in SL would require LL to really discourage poorly optimized content in SL while also providing tools to encourage better optimized content, and make it easier for content creators to optimize their work. As well as tools for consumers to make more educated purchasing decisions, and disincentives for purchasing content that uses excessive amounts of resources. For example, excessive texture use is far and away the biggest framerate killer in Second Life right now. Based on months of observation using a viewer used to demonstrate some VRAM management tools, I'd say that your average avatar is walking around with over 200MB worth of textures. Avatars exceeding 500MB of textures are not as uncommon as you'd think. I've regularly seen avatars pushing 800MB to a GB of textures.That's one full gigabyte of data that you have to download and hold in your graphics memory, for one single avatar. There are sims out there using over 10GB of memory just on textures alone. Why do people do this? Because there's absolutely nothing to discourage them from doing it except the performance hit, and too few people know how this issue affects them so they blame it on bad viewer code or some other strawman. How much VRAM does your videocard have? Even if you have an expensive, high end gaming card you probably only have 8GB of memory. Chances are, most of us have much less than that. Also, VRAM isn't just for textures. Shadows, DoF effects, light effects and more all need VRAM. This makes the "just buy a better videocard" argument unhelpful, to put it politely. And there are people who will argue "but SL doesn't load all those textures at full resolution all at once!" ignoring that as you move and cam around SL you're hardware is constantly sifting textures in and out of data. Constantly moving that much data in and out of memory is a huge burden on both your videocard and your bandwidth. Go to a sim built by someone who understands VRAM issues and you could easily find yourself experiencing double or triple the FPS you typically experience in Second Life. At least until one of those 1GB avatars wanders into view. In some cases, after optimizing an environment I've found myself enjoying FIVE TIMES the fps compared to what I saw before optimizing texture use. That fact alone should be enough to prove the point. You want higher and more stable FPS? LL needs to step up and start discouraging excessive resource use in content. Giving users a tool to derender avatars with excessive VRAM use. Tools that let users see the VRAM use of all of their attachments and rezzed objects. LL needs to start including texture use in Land Impact calculations, so that objects with excessive VRAM use cost far too much LI for anyone to want to use. LL needs to add texture memory to the information marketplace sellers can display in their listings, so people can make informed choices and start avoiding content with high memory use, or content which fails to list memory use (just like people tend to avoid products that fail to list land impact cost). Give people tools and all of this can be super easy, for both content creators and the people who buy that content. There's good, easy to learn tricks to reducing memory use but LL doesn't make it available through any official channels. There's no official SL building tutorials, and the tutorials out there are made by other residents, typically those who do not have any experience or education regarding game design. LL needs to improve the "jelly doll" feature so the resources used by avatars get released when they're jelly-dolled. Right now their textures, at least those that loaded before the avatar gets derendered, remain in VRAM. And that's just textures. Avatar attachments, not limited by LI costs, tend to be far too high-poly. Some of the mesh bodies out there are absolutely ridiculous. There's tricks people use to get around reasonable LI and draw weight costs (avoid any content where the creator recommends you increase your LOD threshold), LL needs to close those loopholes and rework LI and draw weight to be more useful. To better encourage good content creation habits, and better discourage the bad habits. It's very important to note that discouraging bad habits does not mean reigning in creative freedom, or making content creation more difficult. A lot of people hear what I've posted above and are terrified that if LL did these things it would drive them out of SL. That's simply not the case. Optimizing is easy! It's just a matter of learning where you need extra texture detail, where you can get away with less, and learning not to create textures that are filled with unused space. Tell people new limits are coming, give them the tools to work within those limits, the time to learn to use those tools, and it will not be a problem. According to LL some of these tools are coming! That's a very good sign that in the future we may very well experience a Second Life where higher framerates are the norm. If LL handles this right they could even increase the maximum texture resolution cap in SL.

It's been about six months since LL introduced the "Jelly Dolls" feature to derender avatars with exceptionally high draw weight. I figured this would be a good time to take a step back and see how this feature has impacted our SL experience. When LL introduced Jelly Dolls I was frustrated. My prediction was that the feature would have little effect on content creators and most people would simply disable the avatar derendering and just ignore it altogether. I think I was somewhat right. It seems to me that a lot of people do simply turn the feature off, and I still see plenty of avatars with a draw weight well over 200,000 wandering around. Especially in RP sims. In one RP sim the average draw weight appeared to be around 300,000. And this was only a month or two ago. As I feared, texture use is largely unaffected and remains the number one framerate killer in SL. Since textures have a very limited impact on your draw weight number, people continue to use excessive amounts of texture data and unnecessary blended alpha textures rather than the easier to render masked alpha. On the other hand, I've also seen a general trend towards lighter avatars. No less detailed than older avatars, but far easier to render. So it would seem that there has been some success in influencing content creators with the Jelly Dolls feature. I've found it easier to find content to reduce my own draw weight as well and currently sport a detailed fantasy avatar with a draw weight of 33,890. I've even seen a thread here on the forum where people were trying the "80,000 Challenge", trying to get their draw weight under that magic number, and sharing tips on doing so. In fact, most of the high draw weight avatars I see are relying heavily on older content. Lots of sculpts and flexi-prims. Since I do keep the feature on, and tend to keep the cutoff around 80,000, I have been enjoying significantly higher framerates than before the draw weight cutoff was introduced. How has the Jelly Dolls feature affected you and your experiences in SL? Are you seeing improved performance? Did you find it easy to reduce your draw weight or has it proven a challenge? Do you disable the feature? Has the feature caused you any problems? What are your thoughts so far?