Textures rezzing very slowly

[Snoots Dwagon]

I have a hard time accepting that after 15 years, no one has gotten a handle on a proper viewer. I would even be willing to pay some sort of monthly subscription fee to have an awesome working model.

There are a lot of people that would. For some time the community has tried to get both the Opensim project and the Firestorm project to monetize and "professionalize" development... along with an experienced management team that decides what projects need worked on, and the coders paid employees. Projects would be picked through regular meetings with qualified users (grid owners, land owners and merchants with years of experience) to help prioritize projects. Unfortunately all attempts to monetize the project have been rejected, so no one has taken the first step in that direction (that of starting a funding campaign).

But I surely agree with you that this is not only desirable... but perhaps vital to Opensim. Right now there is one person developing the Opensim-specific viewer. The complete control of the Opensim physics engine is in the hands and decision-making process of one person. This is about as far away from "a safe and protected future" as one can get in such wide-spread software used by so very many people.

I am reminded somewhat of Linux... which has failed to beat either Apple or Microsoft for market dominance for once single reason: it is so fractured and "distracted" by personal interests, that it has failed to form a powerful, cohesive whole. Linux could have taken over the PC market. Instead it is a jumbled "techie" OS. That's kind of what we're seeing in Opensim. Except that unlike Linux, very few people are willing to work on Opensim and Firestorm. In fact, very few people are even allowed to. (These are just my opinions. We're just "forum discussing" here.)

Because really, after all these years... Opensim should be in the form of a push-button, "install and go" format for everyone who has a computer and modem. Install it; it works. A wizard asks the tough questions, fill in the blanks, it works. Every time.

As it stands though, one has to have a bit of tech knowledge to set up an advanced database, configure the modem, set the variables in multiple .ini files, plug in modem addresses (instead of them being auto-fetched), etc etc. And while Dreamgrid has gone some way toward "easier" installation, despite the claims it is still not a push-button installation. If Opensim is ever going to become truly widely used and widely respected, it should have professional easy-installation, good to go. And it should work, period. We've surely had enough years to work out the kinks.

(Note: some people state Linden Lab is monetized and the software still reeks. Let's not make the mistake of using LL as an example of quality coding. Good project management and caring about the end user is also part of the package. LL has neither.)

As you state, Firestorm by now should be monetized and professionally developed. I appreciate Bec to no end (the sole OS-version Firestorm developer), but I'd much rather she and two or three other professional coders be paid for their work, working full-time, with assignments made and prioritized by a management team, and these cursed bugs be eliminated (poor texture loading, non-prioritization of on-demand textures, broken cache, and terrible Contents fetching). Firestorm needs simplified (seriously... those menus are like a "hoarders" nightmare)... and the learning curve lowered to something that doesn't totally freak out new users.

And wouldn't a browser-based Viewer be just totally awesome? (Okay, back burner that one.. .but it would.)

I'll stop now, before I write a manual entitled "What REALLY REALLY REALLY Needs Fixed on Opensim and Firestorm-- According to Dwagons".

Chapter 1: REZ A NOT-FOR-PROFIT COMPANY, set to "full-perm"...

mwahahahahahaaa...

[Krull Kitty]

Here is a thought about textures.

There are;
256x256
512x512
1024x1024
2048x2048
And irregular sized textures also.

When a creator uploads a massive texture, lets say 1024x1024, which is the
common high rez texture upload, but they tack it to a small object, it's overkill.

A large texture clearly takes longer and more bandwidth than a smaller texture.
This can cause loading lag.

There is no reason for a 1024x1024 floor tile texture since you will most likely be repeating it
over the surface of the floor prim.

A 256x256 sized texture will serve the same purpose without much loss in detail.

Also, there is no need to drop a texture over an entire object if you only need it on one surface.
I believe there is a cost to using a texture on every surface of an object, doesn't the texture
have to load into the viewer for every instance?

Be frugal with your application of textures.

Just thinking out loud.

[Snoots Dwagon]

I'm shooting from "memory hip" here Krull, but if I remember correctly, once a texture loads it doesn't matter how many surfaces it's applied to. In fact builders encourage repeating the same texture on surfaces if at all possible.

Say you're looking at a cube. If you use the same texture on all sides, once that texture loads it's "easy" for the system to apply it to every side. But at the most you can only see 3 sides of it; three of those sides are obscured from view. Does the system go ahead and "visualize" the entire cube anyway, or does it occlude the non-visible sides? I dunno. Perhaps a tech would know. Now if you put a different texture on each surface... yeah, that's an issue.

If you wanna really tick people off... no, never mind. I don't wanna give anyone any ideas.

[Krull Kitty]

Ahhh, you may be right Snoots.

I've noticed that most of my sculpted prim textures seem to take longer to rez out
than builds that do not use sculpted prims.

This is what leads me to think that perhaps the loading of prims with large textures
applied to them slows things down.

I also noticed that mesh objects with custom textures also seem to take longer to appear
than mesh object without texturing applied.

These observations led me to wondering about texture load and general loading times.

[Snoots Dwagon]

The stats on this forum thread show that there is a major texture bottleneck. Ilan and Oren have worked to locate this and reported a fix to Firestorm, but that fix hasn't been integrated yet. There are multiple causes of this, including cache failure (textures should be stored and loaded from cache, but aren't, which causes the system to reload the same textures over and over), and zero-prioritization of on-demand textures (the need to give top priority to texture rezzing on object which the user is directly interfacing).

Sculpties are basically textures on crack, and are just a bad idea. They're widely used, but are the slowest-loading prim/object I know of. Instead of being a recognized shape (such as a normal prim), each has its own sculpt map (one texture) with some kind of mask over that (another texture) and then the visual texture (at least, that's how it's been explained to me)... all of which has to be bent into a specific shape by the system 3D engine. Unfortunately (from what I've heard) that engine was written by LL themselves and works badly. So whereas a similar mesh might load quickly, a sculpty loads oh so slowly.

The word on meshes is "Linden Lab did a bad job". This comes as no surprise. From what I hear Ilan and Oren regularly carry around shovels and buckets to clean up the LL coding mess.

Opensim was created by third party coders, but was designed to be compatible with the LL Viewer. That Viewer code came from LL... and since the Viewer is what does all the client-side rendering, well... welcome to FEATURES!

I doubt I've got all the tech 110% correct but this is the gist of what I've heard from techs over the years. I'm sure Ilan or Oren could get much more specific (as could other users here), but I think the above sums it up with reasonable accuracy.

[Ada Radius]

The smallest possible texture is 4x4, very useful for solid colors or alphas. I left a box of them for free at my shop in Wellspring and I think I put out another box at the Cookie II sandbox. A long time ago in SL the limit was 2048x2048, more typical for games, but now it's 1024x1024. We can have any size or ratio of textures in between, as long as they're even numbered. They'll upload as square, but you can stretch the prim to fit.

And ya, what Krull said, use the smallest size that will work. Repeat textures as much as possible. A 1024x1024 on four surfaces is probably more efficient than four 512 textures on those surfaces. Avoid uploading textures with alpha channels unless they're necessary - each alpha channel on a prim quadruples the viewer load for that prim (or sculpty or mesh), according to Linden Lab's definitions for avatar rendering cost.

[Snoots Dwagon]

Avoid uploading textures with alpha channels unless they're necessary - each alpha channel on a prim quadruples the viewer load for that prim (or sculpty or mesh), according to Linden Lab's definitions for avatar rendering cost.

GASHP! Seriously... there should be a big ol' red "hazardous waste" sign appear in such cases!

Or like dancing weasels singing "You're using an alpha!"... or something...

[Krull Kitty]

Told ya so Snooty snoot snoot