Tonk Tomcat

You should switch to wireframe mode and i guess you will see what is causing the lag. Even with the best machine sl is unable to run really smooth as soon as some ppl are arround you, because the most of the wonderful creators think it is high quality to use as many polygons as possible and so a simple avatar can have more complexity than an entire scene in a current AAA game. Set the allowed avatar complexity to somewhat about 30-40k and blacklist all objects with a dense mesh to the render blacklist will help.

Don't forget to retopo and use normal maps to save polygons: How to Bake Perfect Normals in Blender - Tutorial

Sadly not only beginner are doing this. Nearly all the "famous" creators sell non optimized, highpoly mesh that should never exist inworld. None of them is spending the time that is needed to create game ready mesh, but as long as it works in sl and the clueless customers are buying it, they probably will never change, because if they would do it right, they couldn't be on 5 events a month and would loose money -.- I would say 90% of the sl mesh content should not be in sl. It may look nice, but thats all. It's mesh for doing pictures, but not for using in a game, especially not in a massive multiplayer environment, where stuff should even be more optimized.

Thanks everybody I managed to get it to work with the open source grid persister from Latif Khalifa. I set it up to my own google app engine and use the server object uuid as persistent key. This key is sent to my client object together with the google app url and after a sim restart the server and client contact the google app to magically be able to find again. So i guess the url is not stored anywhere, but the scripts on the google app help to generate a http url with the persistent key, so both items are able to communicate again. With "the thing" i mean to register the url to a webserver. I'm not sure if that is what happens with Khalifas scripts, because i'm not familiar with using Phyton. But i think that code just use the input persistent key to generate a http url and send this back to the objects after a request.

Yes! Thats exactly what i want to do. Isn't the thing from Latif Khalifa doing this?

Hey, one question: If you set-up the app for persistent grid URL made by Latif Khalifa on your own google app engine, is it somehow possible to request one persistent key without the need to use a website interface and put that key into your script by hand? If so, can someone give me a little hint on what i should wrap my head around? It's my first time doing something like that.

Most times you can't really do anything, because most creator sell their mesh items with absolutely zero game optimization in polygone and texture usage. So your computer has to render more polygones like in some recent computer games whilst you have to download gigabytes of textures at the same time.

That's what i though, now im sad 😃 I think it would be a nice feature to be able to do so.

Hey, is it possible to somehow get the texture size or the vram of a texture from an object? I'm currently working on some id badges and want to prevent ppl to upload and apply unneccesary 1024 textures to customizable faces of the object. I did not find anything in the LSL portal, so probably the only thing i can do is to offer templates in a small texture size and hope ppl will use those to create their own, or am i wrong?

Rigging = Weights painted on each vertice of an object telling them with what bone they have to move with. So, if you want to rotate and move an object, how should that work? Idk if it's possible to dynamically apply/multiply/some mathematic way of computing the rotation/scale/position to all the vertice weights to have it still move the intended way with the sl skeleton.

Also make sure to look for blender tutorials NOT especially made for second life (modelling wise), because if you do so, you will most likely find tutorials how you should not do it (extreme highpoly non-game optimized content). For rigging questions it's okay tho.

Because it's nearly impossible to find those informations in the wiki: 1. Does invisible mesh somehow has an impact on the performance (rendering/serverside)? [i.e. parts of clothings that are hidden]. I could imagine that from serverside the user of the invisible mesh will download the mesh anyways, but hows about others seeing (or better, not seeing) it? 2. For buildings: I remember in the past when those mega prims appeared first, there were some issues when too many ppl walked on the same prim (or was that only rumours?) So, for mesh buildings, is it better to use a mesh ground with physics applied or to use an old fashion prim (max. size?).

Be careful, people don't want to hear about limits in here

I just can laugh when i read this Depends how complicated the item is (i'm talking about clothings), if you do it right, you do 1 release per month, at most you do 2. Thats when you retopo by hand to optimize things. And believe me, the bigger brands don't need more than that. I will not call any numbers how much a single item will bring, but if a big brand attends on more than 2 events per month and don't have optimized content, thats just greedy, and not because they need to do that.

Don't do that for clothes. It's like using twice the polycount of your object and it's totally unnecessary. Retopo your object by hand, so you only have one solid hull. For the holes in your cloth(like the neck and wrist areas) just build the thickness and do like 1-2 rows of polys in the inside, then extrude one time and merge verts to center. So you close the hole. Make the texture black on that area and fade it out to the outside. That way you simulate the shadow from the inside fading to the outside. Try to avoid having polys where you can't see them.

I'm glad you're having fun. As in any game, there are only a few things to improve performance. And for sl that are polygon count and texture usage. If you cannot apply limits, then there is no way to improve anything. Now enjoy your brickwall, because that is you who don't want to realise that there are no other options to improve. Or please show me other options if you think you have to laugh about mine? I did not see any other solutions.

Alright, so, conclusion: You just want to let all be like it is, poor creators have to rush out the highpoly stuff because the costumers are demanding it. I did not ignore what was said to the limits, but those limits are the only way to prevent the lag and all the highpoly stuff and i even said how to do it so "smart" ppl can not just circumvented those limits. So, let's say how it is: We don't have to discuss anything, because LL will not change anything, so are the creators. All for the quick money, nothing to improve things like it's done for every other multiplayer gaming plattform. Good to know even the user defends those creators to rush out with this highpoly stuff. So i better will not look into the forum in the future to tell that it's possible to create the same good looking stuff, even with every limits applied, just not in the short time.

Yeah, it's a balancing act, that's right. But imagine if everybody would do it right, or would have to do it right because of limits. The users, or costumers, would learn, that it is just not possible to release new properly made content every week. And if everybody would do so, that would be the new standard in sl. So all this "pressure" just came because the majority is not creating stuff the way it should be and rushing out poorly made content (that actually looks really good, as long as it's just for pictures, but not for a game).

But why should they be pressured? I'm making my living with sl too. It's possible to do, even if you create optimized content. But if the "bigger names" want to take part on literally all events to just get all the money, they are just greedy and don't want to spend the time it needs.

I don't think it's the end use fault, because, as you said, you are just a user. And you cannot expect that the user checks everything and has the ability and knowledge to decide what's good and what is bad. It's the fault of LL that it's even possible to bring in all these things. That "creators" just upload things, because they can, is the human nature i guess.

Wrong. I learned 3D for second life. 12 years ago. And i learned using the tools and reducing the polygon count. And when i started to learn, i was an amateur, but still my stuff does not look like the stuff today, because they all want to do it fast and don't want to waste the time in doing it right (of course there is a small amount of ppl who really want to learn and improve, but most other creators i talk to and told them they are doing to high poly count and have to retopo just told me that takes too much time, so yeah. lol)

95% of all content is not AAA quality. It is content, that NEVER should exist in SL, and it will never exist in any game. A pants with 150k polys, where you see the brand logo made in mesh and every stitch in mesh is no quality, it's just stupid. In an AAA game, the content is game optimized. And i'm sorry, EVERY amateuer 3d creator, who creates stuff as hobby or for games like sims or so for free has to learn how to retopo and do low poly 3d assets. You only see those highpoly stuff in sl, because they somehow forgot to add an upload limit. That has nothing to do with aiming to amateur ppl. I started as an amateur too, and even my first mesh item ever i made in 2011 for sl is low poly already. And all the limits i wrote above, are limits that they need to have sl run properly again. You can find any reason why not implemeting those limits. But this is the one and only way to do it. Everytime LL will tell you they are working on performance improvements are just a laugh. Except if they are secretly working on the next gen super high performance graphics card that's 10 times faster as a 2080 ti, so your machine will handle a 50 million polygone scene with all the stupid highpoly content.

Showing the item stats will not solving the problem, because most ppl don't care about it. It would help if the worn polycount/texture memory could be read by a script, so sim owner could have an eject from sim script if polycount/textures are too high (same as in early days when there was the script limit eject thing). The only real solution would be: 1. LL have to limit the allowed polys per upload. 2. To prevent the "smart" creators: Limit the polys per linked object (so the smart guys can't upload 100 single objects and put them together again) 3: Limit the total allowed polys per avatar. So the users would try to find more low poly items by themself too to be able to wear more stuff as an outfit (would be equal to low land impact items to have more stuff in your place) . 4: For texture memory: Maybe have a limit of the total allowed texture memory per avatar. I know, that are many limits and i bet most of the "creators" will scream that they can't create stuff anymore. But thats how it should be done. Ppl will and have to learn how to create game optimized content.

If you plan to add color options, like different zipper colors, you also can move the zipper/metal parts to a seperate texture. Use the complete UV square, and just use a 256x256 texture for those parts. You still will have a lot more texture space to use than on the same square like the complete pants, so you'll see more details. And changing only the small metal parts texture instead of applying several 1024 maps will also use a lot less texture memory.

I don't see why you need this? If that's your workflow, just copy all uvs in the finale version to the 0-1 space and apply the according textures to the faces in sl after the upload. In your example, the uvs are pretty bad. Don't waste that much texture space, you easily can copy all uvs to one map. If you want to use a hud to change textures of some parts, you have to think about that while doing the uvs. For the eyes for example, you could add the uvs to the other uvs too, and let them just white. So you could use the sl mod tools to change the color of the eyes without appling another texture. Or, if you want a special textures there, stretch the eye uvs to one square, but use a small seperate texture for them (depends on your details), 128x128, max 256x256 should be enough, because nobody really needs to zoom into such small parts so close, so everything else would be waste of texture memory.