Kyrah Abattoir

There are two schools when it comes to 3D orientation: World space: +X is forward, +Y is left, +Z is up (architectural POV, the world is mostly flat, Z only matters if there is some height). Screen space: +X is right, +Y grows up, +Z is forward (screen POV, we don't change X and Y we just add Z). Neither is inherently wrong, they simply conceptualize 3D space from a different starting point.

With Utilizator's Avatar 2.0 you can sometimes get lucky with standard sized wearables.

Or anything but a carefully optimized singleplayer game.

I'm looking forward to the geometry node graph system to be fleshed out more.

"Slightly more robust graphic card" is such a bull***** take. Unless you are on a really underpowered laptop, Your GPU is basically asleep when running SL. You can literally mine ethereum in the background and see no change in FPS on a gtx1070. @Tonk Tomcat1.3M triangles and 100Mb of textures too. Why compromise when you can have both! Please tell me you left the review it deserved.

Well, I'm sorry. I tend to be pretty bitter even when trying to help because of this feeling that nothing I do or say will sway anyone in the right direction because other than increasing their profit margin or getting done faster, people don't appear interested. I tend to take this way too seriously, but I've lived through SL for so long it is just hard to let go.

Oh my bad, I'll remember to avoid being helpful in the future ^_^.

Ou je ne sais plus écrire, ou vous ne savez pas lire.

If you already know your LOD swapping distances, it is very important that when you look at your lods, you look at them at the camera distance they are intented for, and that you do so using the LL viewer default settings, since that is the "default" experience. Most low lods tend to look horrible from up close, but they are NOT ment to be seen up close, they are ment to be "there" and to avoid drawing too much attention when the higher lods pop into view. The two high lods tend to be the more difficult ones to get right because they are usually close enough to the camera that a sudden loss in detail will be much more noticeable, and that's the ones where you have to be clever if you want to hit that 50% reduction from highest to high.

I'll point out that Opensim & SL use different physics engines, and might process meshs differently in the background.

Les règles sont un peu différentes aux états unis, il y a probablement des variances état par état mais en général, le refus de vente n'est pas illégal. Après tu devrais pondérer un peu avec le language judiciaire, tu ne risques pas la prison ici, c'est un jugement d'égal à égal, au même titre qu'un patron de bar qui déciderait de ne pas te servir... Je ne dis pas qu'ils ont raison ou qu'ils ont tors, c'est juste un créateur qui ne veut pas faire de business avec toi c'est tout.

Can you explain a little more what you mean by that?

The key element is really to limit yourself to a single "layer" of alpha at all times and to use an opaque surface & materials to simulate the "far" side. I'd avoid including a projector light in a store product however, these can be fairly taxing and should be left at the discretion of the land owner. @Beev Fallen's example is pretty stunning, here is a simple one which might make it easier to tell what is actually going on. the glass's outer walls are translucent with specular/environment. the inner walls of the glass are opaque. the liquid layer is just a section of the inside walls with different material properties and glows a little, it is fully opaque too. the top layer of the liquid is almost fully transparent and is only there to change the color of the liquid slightly compares to what is seen through the glass. Ideally you might also want to re-order all the vertices if you have an overlap of alpha like i have between the glass "foot" and step or you'll get alpha sorting issues. if you have a label, a nice touch is to reserve a separate face on the backside of the glass that you can darken a bit, to suggest that you are seeing the back side of the label. This is peripheral to the question but, as with all SL projects, and game related assets, it is of utmost importance to try to keep your texture usage to a minimum, fully readable labels can be a fun photoshop exercise, but since bottles are by definition background filler objects, you only need as much on those textures as is needed to convey the "idea". Likewise, unless your normal maps contain very important and essential details, it doesn't hurt to test them at half or even quarter resolution, especially for something like glass, which is generally fairly smooth and rounded. And for specular maps? if you can get away using the default SL white texture, or even a 16x16px? do it.

You'll have a lot of trouble finding help then.

768 isn't a power of 2 but a multiple of 2.

Policies are just rough guidelines. At some point they won't be able to dig this hole deeper.

I mean... LL could just "tell" those creators to make the move "or else". Of course that is assuming LL has any kind of spine for this.

Pricing MAINLY depends of the time you will spend on it. Remember we are on this earth only for so long, so don't insult yourself and budget according to how much your time is worth.

It comes to my mind that another performance killer comes from sliceable bodies (increase in draw calls), which are "almost" not needed anymore since BoM rolled out. I'd argue that the reason only a handful of bodies embraced it fully is that most mesh body creators are unable/unwilling to upload a new slice-less version. There could be many reasons, loss of originals, tool changes creating mismatches, it could also be the fear of changing something that is fully accepted by now (slice huds). I'm not going to pretend that I understand how separate materials are rendered in SL but I'd wager is is more likely than not that no consolidation is done, and that a 50-80 slices body is rendered as 50-80 separate materials.

I do think pruning should be part of the system tho, even assuming they have no weight, there is no value in having groups filled with avatars that aren't used for land related functions and haven't been online in 10 years. Yes, but desire doesn't produce clean, reliable and functional code. If you can't do it properly, sometimes the right approach is to not do it at all.

Oh I like it the way it is personally, but groups should probably be capped to a few hundred members as they simply aren't designed to be used as RSS feeds. I do agree that groups should have some sort of optional automatic pruning system, whether they are used for land or not, so many dead avatars will remain in largely defunctr groups until the heat death of the universe...

My very limited understanding is that groups are distributed along multiple servers. Which server handles which group being sort of a fixed assignment, (most likely based on the group key, which never changes and is picked "randomly" at creation) The problem with this is that it is possible for a few extremely large groups to live in the same server, negatively affecting any and all groups that share that server with them.

I'm not sure what you mean there, we don't really have a "null" material in SL so i'm pretty sure all the hidden parts are, (even if alpha masked which will drop the rendering load) at least undergoing skeletal transform, which is quite costly.

It is, but because how prims are generated, exported cubes for example have all their faces use 3x3 grids of triangles, so 18 triangles per side, instead of the 2 needed. Likewise, twisted toruses and tubes create tons of unneeded geometry.

That is not simplifying anything, at best you reduce draw calls by reducing the number of material faces, but wit what you just explained, all you've done is convert a set of parametric prims into a mesh that effectively takes longer to download. You can save a ton of polygons when you do those conversions, but you have to actually simplify the model. That was uncalled for, I use prims all the time because I need a more flexible build that I can edit on the fly, there is nothing wrong with in-world building. There is everything wrong is converting prims to mesh with zero cleanup, and then fiddling with the LOD generator because you decided that it should be 1LI.