Kyrah Abattoir

https://utilizator404.wordpress.com/downloads/ Avatar 2.0. Kemono. Rikugou. M3/M4 heads. They are all fairly solid and mod. BoM is supported.

Yeah it's not difficult to make "hole caps" that use much less geometry than a full outfit underside. It's a shame that so much of the oldschool game modding tutorials are now gone. As games have gone fancier and fancier, a lot of the old informations from the half-life modding scene simply disappeared. And a lot of people now assume that something that's just textured rather than fully meshed is down to the artist's lazyness, when it is typically more involved to "suggest" details than actually detailing it. It doesn't take a lot of work to cover a piece of industrial equipment with rivets, no one models rivets individually, it's all copy pasting. What does take work is to figure out how to get the same overal look and feel, without the rendering cost.

@Chic Aeon In your example I see a lot of duplicates, or near duplicates: The 4 "pot window" sections could share area, and that would avoid having them at an angle. The plant leaves could probably share texture too, you have 10 unique leaves and no one would notive repetition there. Top right & bottom left wood show lots of duplication. Personally I wouldn't have baked the wood at all, I'd have used a single small repeatable texture, rotated UV islands to change grain direction, and maybe used an extra "face/material" or two on the mesh to be able to darken a few of the wood sections/inner/undersides with the in-world tinting tool to provide a little bit of contrast at no cost.

On a lot of projects, if the unwrapping tend to create a few "long" uv sections, it's not a bad idea to assume this section will be 1024px long, then you can arrange all the other UV islands as tightly as you can at the same resolution and see how much you actually need: 1024x1024? 1024x512? 1024x256? less?

The numbers themselves are not really relevant, it depends how you use them, and different types of objects call for different approaches. The big question is what is necessary versus what is superfluous. Why do you need that geometry? Does it matter? Can you notice its absense? And if yes, can anyone else?

Count yourself lucky, "In my 2004" days I don't know how many thousands uploads i had to do to test the couple dresses I made originally. Thankfully we don't have to do that anymore An added bonus of local textures is that they update live, you can have SL in a small window next to your texturing program and everytime you save over the file that the local texture uses, it will update in-world (only for you obviously it's called 'local' for a reason)

MD is a fine piece of software for what it does, but it is not a modeling software. I'd call it more a "design" software. It is a great tool to bring your vision of a specific garment into the digital space (as long as you don't mind not being in full control of the result). You can use MD for years and still know nothing about the skills you will need to bring your idea into secondlife, or any other game. And sure you can consider that next step as simply "beneath you" and not worth your time, hell, you can probably outsource it to someone else for a hundred buck. The reality however is that all those steps are ultimately connected, how you will UV your model depends on the textures you will use, how you will LOD your model depends on what matters and what doesn't detail wise, and even when you are still designing and refining your idea in MD, these are things that have to be kept in mind. Which is why you see time and time again the same mistakes being made in SL, which lead to bloated geometry, bloated texture resolution, dodgy rigging, dodgy texture UVs and a worse experience for everyone. I'm not telling people that they have to be perfect, just that they need to try to care at least a little. This is no different than the prim era, you can be smart about it, or you can just cram as many prims and textures as the linkset limit allows.

Still wouldn't hurt to send her the information too.

I think the answer on those is either: They sell fullperm mesh 'kits' because they are beginners and they don't have the ability/time/drive to make it a complete product. They don't care and they know that their customers don't know any better. Time spent vs asking price.

By design llDialogs CLOSE when an option is selected, it's up to you, as the scripter to re-open the menu if you believe it is more convenient for the user. As a scripter, you have to code that explicitely. As a user, there is nothing you can do, popup menus were never designed to be used as full blown interfaces, so any behavior you observe in one or another products is completely driven by the script you are interacting with.

Alternatively i'd recommend to send a note about the issue to Marine Kelley too since she is the official RLV creator and maintainer out there.

I see several issues with this: It's a brittle solution that means your product will more or less live or die with your store. (EDIT, this should really be made clear on purchase) You will need some sort of external server to relay requests, that means a monthly/yearly running cost. If your problem is the uncontrolled duplication of soup bowls, if they are temporary attachments, first, the person doesn't get to keep it as it will be destroyed once detached o when they relog. And even if they could, you can simply have the pot initialize the bowls as they are created, and simply make the script non-functional until it has been initialized.

Personally I just write my own, color changing huds aren't exactly a complex script. This way you can replace the creator's incompetence with your own Which granted, might be worse, but at least it's something you can improve

Yeah but i can't really do that with a design that someone else came up with, that wouldn't be cool.

Even with demos it doesn't help, no one appears to recycles textures which means a fully furnished region is just a constant stream of texture popping as soon as you decide to move around, unless you build absolutely everything from scratch.

Maybe I should just stop buying structures and decoration props alltogether, anytime I find something that looks nice on the box it has either: Bad LODs and crumples as soon as you zoom out. All baked textures, making it not only impossible to re-texture properly, but also bloating it's memory usage. I'm starting to wonder if i should just re-create the things I buy with prims (or my own meshs) and texture them with reusable textures instead. Which makes me wonder why I even buy things in the first place?

44$

You shouldn't have taken the commission before you knew what you were getting into. Yup, everything you upload will be hosted permanently in the Linden Lab servers, so obviously there has to be some kind of throttle/fee. Pretty much everyone who uses Blender also uses Avastar which you can purchase here: https://avastar.machinimatrix.org/

I've done some quick testing for a future EEP related skybox project and I couldn't get stars to show up below the horizon line. It is far away from the ground, am I missing something?

There is still a considerable benefit to reusing meshs, even if they are not instanciated, it's still a single download. In addition, it MIGHT still be one instance in ram, before transform operations.

Assets that can be invoked by UUID: Textures Notecards Sounds Assets that can be TRANSFERED by UUID. None. You'll have to use llAttachToAvatarTemp() And if the "device" is going to be sold, the buyer need to rezzable objects copy & transfer, there is no way around that.

It took me a while myself until it dawned on me that it's really just a per pixel gloss value, the same way we have per pixel environment. Then suddently it just clicked.

I'm part of a group of builders that uses a shared texture pool, we try to reuse the same textures as much as possible when landscaping

Any ETA for when EEP will become the main viewer?

AParently this will soon be a thing of the past, I believe LL is gutting out the legacy renderer.