Texture loading efficiency.

Okay, I'm making a script that is going to be using a lot of texture. Here is what I want to know, is it better to just put all the, about possibly 100 or so, textures in the object or would it be better to just make a list of all the texture keys and put it in a notecard? Its all about the efficiency of it that I want to know.

it would be better if you can shove it all in the max of a 1024x1024 image, of course fit most optimally

if your images happen to use every single pixel in whatever powers of 2 image size you decide to use you would be using the exact same amount of video ram, and only be doing 1 call to the asset server, which is the biggest bog when loading

the basic rough process for calling an image is

query
find
transfer
confirm

now multiply that by 100x

I don't believe you can detect any difference between the two
What matters when it comes to 'Loading efficiency' is the time it takes for a client to download the textures. The download starts not until the client's camera can see the prim that has the texture on it.
That means you can 'pipeline' a slide show by showing next texture on a hidden face while the current texture is shown.
The only way I know that can reduce the download time is to reduce texture size.
You can also do what Osgeld told. That will reduce the time per texture but the initial download will be what it is for the total texture.

download time is an almost irrelevant factor

even in normal jpeg at 100% quality, a 1024x1024 image is just a minor blip in download

(and i am taking a wild guess that jpeg 2000 has a better compression ratio, and that its set somewhere around 70% quality)

the major bog is asking the asset server for multiple assets

Disagree.

Even smaller textures tend to take time to download for me, and it's not because of my interbutts connection.

The point is that no texture is asked for until the clients camera can see the prim

Ok, I understand what your saying. What my project is, is a build-a-bear vendor. So the whole point of it is that there is a prototype bear in which you can switch the textures on each part of it to make it how you want it. But the reason why it will be 100+ textures is that about 8 of the 12 scuplty prim bear will have likely a unique texture. Also, you will be able to switch the shapes of the parts with different scuplty textures. So even if i have about 20 different variations of textures, and 40 or so sculpty maps(total for all parts), that adds up to alot, over 200 diff textures. Now my thought, being you said it would be smart to use a 1024 x 1024 jpeg and try to fit most of the textures in it, would be to use multiple of those, since i wont be able to fit the 200+ textures in one(unless they are 5 x 5). But that would only work for the actual textures and not the sculpty maps, since they cant be put all together. So my next question, in this case, multiple 1024 x1024 is the smart way to go?

how about multiple low quality compilation maps with a reference list for the higher quality equivalents when the product is done (although I would NOT load them via notecard... unless you intend to expose them to anyone looking.) although, TBH, at that much variety of composition, load time is your least issue... this might be better severed outside of SL... just a thought.

Ok, I understand what you are saying, but none of it would work

1. the low quality compilation maps wouldnt work, cause i am using a prototype bear (one attached to the vendor) to show people how it would look, in which it would be using the same list of texture keys or inventory of textures(which could be hiding in a different prim in the vendor). And once they receive the bear, all textures, or the notecard(in which way this would be easier) would just be removed via script, as well as the script that changes it when rezzed.

2. As for using scripting outside of SL via XML and a website, I have no experience with that. I would enjoy learning, but at the present moment, it would be too difficult.

thats cause of the speed the asset server is feeding your viewer the image info, now multiply it

If you have that many textures to go through, your customers are going to be building bears for quite a while. Dealing with big rez-time delays on top of that is going to be a killer for your business. The larger the texture, the slower the rez time. You can beat a lot of that problem by preloading textures onto a linked prim sitting off to one side (color its faces black so it's not a distraction to the customer). If you can combine several textures into one, as others have suggested, that will also save rez time. If that's an option, then, I'd suggest loading sixteen 256 x 256 px images (or four 512 x 512 px images) each onto 1024 x 1024 px textures. If you preload them, rotating six textures at a time through the linked prim, a customer ought to be able to sail through your 100+ sample textures rapidly without experiencing any annoying rez-time slowdown. If you don't do something like this, the typical customer is going to get frustrated and walk away without buying a thing.

If I understand your comments so far, the potential problem with this method is that you only want the customer to receive the specific textures that he/she has chosen. If you combine images onto composite textures, that's going to be tough. You have two choices, then: (1) Use a whole stack of single 256 x 256 (or 512 x 512) images, still using the preloading system to cut down rez time or (2) Use composite textures in the demo/vendor unit and then, once the customer has made a Demo Bear, pass UUIDs for its textures to a Bear Assembly Unit off to one side that creates a final product using separate images.

I hope you end up selling a LOT of bears (or maybe one really expensive one) to recover your upload costs. At L$10 a pop, this project isn't going to be cheap.

Yes, that would work fine And it wont cost alot for the bear textures considering I already have alot of them. I would start off making cheap bears, but I will make updates to the vendor to allow more intricate(i think thats how you spell that) bears, with prim attachments.

my though was that you could save effort on rez times when building by having the building portion reference lower resolution textures that were compiled to a large image (ad reference the offsets) and then reference the actual higher quality single textures in the product you have them buy.

in fact I can see a double set being made, one that gets manipulated using the compiled textures for speed (allowing the customer to build faster) while the actual bear is put together off to the side, with the slower to rez final textures)...

it'll require more texture uploads (you'll need to add the composite ones) but the final product will rez faster and smaller both while building and when the customer takes it home.