Kwakkelde Kwak

If the (correct) plugin is installed, you can import any .fbx or .dae file the same way as you import any other non-.max file. You can use the import menu or just drag the file into a viewport.

Madelaine McMasters wrote: If it doesn't dump high resolution textures for objects no longer needing them (because they occupy only a small number of pixels in the scene) then the system will start choking quickly. It's not only a matter of memory usage, but as you move away from a high resolution object, the renderer must scale down the texture. If it wants to do that well, it'll have to examine every pixel in the original texture to compute the scaled texture. That would quickly bring the system to its knees, as even a one pixel thing off in the distance could require the squishing of four megabytes of texture data (1024x1024xRGBA). Dumping the texture from memory and not using the texture are two different things of course. One would have to zoom out then in and see what happens. I'm a fraid my computer is a bit to fast to notice the difference between loading from cache, loading from RAM or loading from VRAM. Might be worth having a go at it though. Mipmapping can actually lower memory usage if it's done correctly. It's true that a full mipmap takes 4/3 the space of the base texture, but you needn't load the entire map if the object occupies only a small portion of the scene. You'd only load that portion of the map that corresponds to the apparent resolution of the texture So if I understand it correctly, the entire mipmap is stored in RAM (taking up more space there) and only the part needed to draw the screen is loaded into VRAM (taking up less space there)? That makes sense. I always thought the entire map was stored in VRAM. You get the benefit of visually accurate texture scaling without having to do it in real time. You still have to scale a bit, as the mipmap only provides textures in 2x resolution steps, but it's a lot easier/faster to scale something by less than 2x than by as much as 512x. That's what I meant with the matching of pixel and texel.

Good for you, good for everyone

Madelaine McMasters wrote: So, while your comparison of compressed and uncompressed image sizes is valid, and JPEG size means nothing with respect to GPU memory usage, it's probably even more complicated to figure out how texture memory actually gets consumed. I know I simplified the process. As far as I know you hit it pretty much on the head with how textures are loaded in SL. Only thing I wonder about is how good SL is at dumping high res textures from memory. I get the impression it doesn't do it at all or if it does, it does it poorly. That would be a reason why lag builds over time, especially when you teleport around a lot. So while it's true for an eye (or anything else small on screen) SL doesn't load the full resolution into the viewer, I'm not 100% sure what happens when you zoom out. Mipmapping doesn't lower memory use does it? One would think it uses a bit more even since the texture is 4/3 the size. It makes it easier to match pixel and texel, isn't that what it's for?

It is all rigged mesh, combined with alpha blending. Didn't I say that?

I'm not quite sure how jpg compression works, but I suspect it kind of works like "this entire area is all black". That's not a lot of data, so the resulting size is small. I don't know the exact technical reasons, but the fact is, SL textures in VRAM are uncompressed. Look at it this way: zip files are smaller than full files and contain all data. You can't use the files when they are compressed though. In order to look at them, you need to uncompress them, that's what happens in the video card before the gpu can understand any of the data. Every single pixel is assigned a (8 bit) value for each channel, so the numbers I posted earlier are the ones you should use. The size of your jpg on disk before upload is a bogus number for SL, even before it reaches your graphics memory. All textures are stored as jp2 on the SL servers. So bmp images get smaller after upload, jpg images probably a bit larger, depending on the level of compression. Then as they hit your graphics card they are all the same size as a bmp again, or 1/3 higher for the Alpha channel.

The sun and moon are pictures on a background, not objects at a certain altitude. So the answer is "no".

Drake1 Nightfire wrote: You definately need a new card.. the 260 is a very weak card. It's an old card, but by no means a weak one. Memory bandwidth is higher than a GTX650, FLOPS are pretty darn close. It uses a lot of power, but it should perform quite well. @OP If you're going to upgrade, pick at least a GTX660 or you might not notice any difference at all.

Luckily not everyone steals just because they can. Luckily some people manage to stay ahead too just by being creative. Luckily scripts can't be copied this way, I'm sure it's possible, but since scripts never leave the LL servers, those are far harder to grab. Customer service or knowhow on the products is something that can't be stolen too. Finally, luckily copybotters don't (always) distribute or resell the copied items. I have items I have on sale copybotted in the past, the offender even proudly showed me the result. Well he said this and that person did it and he exposed them, but I got the impression those persons were one and the same. Anyway, I think most copybotters are just playing around. If your sales rely on how good your items look, not how they function, there's always the risk of someone copying all your things. All in all I wouldn't consider SL business "selling sand at the beach".

Somehow I don't think LL will ever do this. Let's call shadows and occlusion an "advanced" feature. Advanced features take more from a computer than just the basic features like a diffuse texture. Like in pretty much any engine, the shadows and occlusion are added by LL as a global and personal option. Adding a second way seems a bit ... odd. I do agree it could save a ton of memory when implemented right. 128 or 256 square as a maximum should be plenty. Not allowing repeats I don't understand though. Maybe LL needs to tune the LI system again and include texture size. Then adding a second or even third diffuse layer would be safe. It would need a "are you really really sure you want to replace this 256x256 texture with a 1024x1024 one?" feature so people won't get all their items returned when editing them. It would be fair, but I don't see that happening too. So much scenarios where people would get their things handed back to them. EDIT The last thing you'd want is the viewer combining the textures before they go to the graphics card, that would be baking the texture onto a 1x1 texture again, either making a 4x4 repeat huge or making it blurry again. Maybe that's the entire problem.

I can think of two things. First one is one to avoid like the plague. Split up your floor into multiple planes and texture them seperately. This would be the "texture memory killer" option. For example, a 4x1024x1024 floor would use 12MB of texture memory, quite a lot for the low end computers out there and a big chunk out of the 512MB SL lets us use. Second one is a bit more complex and can be a bit tricky. I'm also not sure if it will survive future updates to the render system, but it has worked from the moment we got mesh until now. In 3ds max, copy your floor, assign a new material (or ID) to it and attach it to your original floor. The one floor you can texture using repeats, the other floor you can texture with a lower resolution shadows or occlusion map. Make sure the occlusion/shadows map you upload to SL is transparant/opaque rather than black/white. The two floors will have two faces in SL, just like any other object with two materials. In 3ds max you will probably see the textures flickering. In SL one will show on top of the other though, without any glitches. This way you can have something similair to two layers in photoshop. It should even work with more than two layers, but you might have a terrible time selecting the correct face in SL if you do that, I think only a script would work then. Kitsune Shan has a blogpost on this "trick". In fact I think that's where I picked up the idea.

Medhue Simoni wrote: but just blacking out everything but the eyes on the avatar texture to make each eye color isn't wasting much data. It's wasting huge amounts of data. From another thread I understand this would be a 512x512 texture. I suspect the eyes to be in the 32x32 range, so as Drongle says, for two eyes 32x64. (That is unless you stack the eyes, which would work perfectly fine I guess.) When someone uses one skin and two different eye colours, they would have to load three 512x512 textures with your setup. That's not a couple of kb on your texture memory, that's 2.25MB. If you had used one 512x512 for the body and two 32x64 textures for the eyes, the memory use would have been 0.75+0.01MB. I'm having a hard time following your logic and I kind of get the impression that you think a single texture used twice uses twice the amount of memory, OR that you think black canvas space uses less memory than coloury parts.Both aren't the case. It's very simple, if you use a 32x64 pixel area of a 512x512 texture, pretty much the entire texture is wasted. ______ An uncompressed texture uses one byte per pixel per channel. So every pixel is either 3 bytes (3x8=24 bit for RGB) or 4 bytes (4x8=32 bit for RGBA) So a 512x512, 24 bit texture uses 512x512x3=786432 bytes, which is exactly 0.75 MB.

Medhue Simoni wrote: they would do good to add in a 768 x 768 texture, as the difference between 512 and 1024 in total data is vast. The difference between a 512x512, 512x1024 and 1024x1024 not so much though. (1, 2 and 4 MB for a 32 bit texture)

Nacy Nightfire wrote: It sounds like a lot of work for the ripper. Most mesh for sl I suspect is fairly simple geometry. If you have the skills to correct for distorted perspective, it seems like it's just as easy to model from scratch. The real art is in the texturing. If thieves are ripping meshes in this way, what about the UV's and the corresponding textures? One would think intercepting the data between the viewer and graphics card would make it possible to copy all of those. Textures are stored in your graphics card, geometry is, UV data is. Your graphic card needs all of those to draw the picture on screen afterall. One would also think it would be possible to use the data between the server and viewer. The format will be different, but all data is available there too. With the viewer being open source, I don't think that is very difficult to do.

Laurie7983 Gothly wrote: I'm not sure how to change the resolution/repeats without going outside the UV box. If you don't use shadows or other baked in properties, nothing prevents you from going outside of the box. Here's an example I used in another thread: You can also use a texture repeat in SL as suggested before. In this example I did both. The UV map 4 times as big as the texture, then on top of that a 4x4 texture repeat. You can see that in the material editor (the tiling) and you should also set this in the SL edit menu. That way you should be able to use a 512x512 texture and get very good results, possibly even 256x256. There is absolutely no need for huge textures that degrade performance for a floor like this.

Chronometria wrote: I am at a loss as to what is triggering it Alpha (blending) on any rigged mesh item.

Ah I missed that. I think the user is a genius though. I for sure can't keep track of 20 pages!

As I said earlier, built with mesh the download weight (and graphical load) will be lower, since you can use as little as two triangles for the visible objects. Five prim boxes use 540 triangles, at least on the highest LoD. The server weight will also be lower, since you only need two individual objects. If you use prims you will need five for the same shape and even more if you want a smoother physical shape. Drongle (or someone else) might know if the SL uploader will recognise the mesh blocks as boxes or as arbitrary hulls. If SL recognises the boxes there shouldn't be any differences in physics weight between mesh and prims. If it doesn't, prims will have a lower physics weight (and therefor lower physics load on the servers).

Drongle McMahon wrote: But then I remember that, provided they are only stretched and rotated, with no other distortion, prim boxes use the havok primitive box physics shape (hence the very low physics weights). Can you penetrate those? And what happens if you do? Do you get stuck inside? You just answered your own question, then asked it again..or something like that. Prim spheres, cylinders and boxes act like convex hulls. (Or really as physical spheres, cylinders and boxes) A physical box is an element just like a single hull or triangle is. From what I understand, you can't ever get stuck in an element. A box can be scaled in all directions independently or as a whole, a cylinder can be scaled in height or as a whole, a sphere can be scaled as a whole. Any other alterations will make the physics shape triangular based, with the risk of getting stuck in them.

If you want to use hulls (analyzed physics when uploaded) for a corner, you'll have to split the physical shape into several non intersecting blocks, as shown in the blue object. The problem then is, any vehicle can go through the gaps, no matter how small you make them. So what I did was splitting the object into two seperate ones, the white and the red. Because of the overlap, there are no gaps. You could do the same with prim boxes, which I think would result in a lower physics weight. The downside would be a much higher download and server weight.

Want to share what the problem was and how you fixed it?

I did some track work for someone, I didn't test the invisible walls myself, but was told my setup of 7 meter thick convex hulls worked perfectly. I set it that big so cars can't get stuck, even on a convex wall cars can get stuck if one part is on one side and another part on the other, or it's pushed through the ground or into the air very slowly. Make sure you don't use connected blocks for corners, you will be able to slip in between. I used a double object, with intersecting blocks.

Intoxicate wrote: Apparently it affects hair as well. It happens on all rigged mesh, obviously SL can't tell the difference between a shirt, pants or hair.

Perrie Juran wrote: That's them. Now if they can find a way to put an Avatar on the ground and that Avatar could interact with the Environment..................they could potentially put SL out of business in very little time. "If", now that's very important. As far as I understand, such voxel engines rely on repetition, where SL relies on diversity. That repetition is possibly why it seems to be so hard to animate voxel based (rigged) objects. However, Phil seems to think it's possible, so who knows?