Kwakkelde Kwak

Swobbly Minogue wrote: Thanks Medhue. Do you normally use a 512 x 512 texture or can we get away with 1024 x 1024? A 512 x 512 texture seems awfully low res if used on a larger object, but I was always taught to never use higher than 512 x 512 when building in SL? What do you think? If you weren't supposed to upload or use 1024x1024 textures, LL wouldn't have given you the option. It really depends on the object what size of texture you use. I normally use 512x512 for 10x10 m and that seems to look fine. But that's for buildings with flat surfaces. If you have something very curvy, the surface can be a lot bigger compared to the size. If you have text you'll probably need a pretty high res texture. It all really depends. Just keep in mind a 1024x1024 uses 4 MB of video memory. And SL not being a high end game and the average SL resident doesn't have a high end PC, 4 MB is quite a lot. People with a 256 MB video card can only process 64 1024x1024 at a time at a reasonable speed. (At least that's how I understand it). 512x512 textures use 4 times less, so the same card can process 256 of those textures, 256x256 again 4 times smaller resulting in 1024 textures. Repeating your textures either per surface or per object will do wonders for image quality without having to use very large textures, but ofcourse it's not always preferred or even possible.

Swobbly Minogue wrote: IN 3DS max can I create 8 seperate materials and apply them to my model or do I need to create 1 multi/sub-object material with up to 8 sub-materials? Or do both work? Adding 8 seperate materials to your mesh should have the same result as making a multi/sub. You can verify this by applying the 8 seperate materials, then picking the material from the object. You'll see it is now a multi/sub. As you are new to max, this is what you can do. Put all the materials on the object, or attach all your objects with different materials to eachother (don't know your workflow or kind of object/scene). Then open the material editor. Select an unused material then select "pick material from object". It's next to the objects name. If you use seperate objects for your different LoDs, I think it's better to use the multi/sub to begin with. I'm not entirely sure, but I can imagine the material order getting messed up in the .dae file. The materials for each LoD should be identical, I suspect a different order in 3ds max means a different order in the .dae aswell. In that case the uploader will refuse your models. Again, I'm not entirely sure. Making a multi/sub will also make it easier to keep an eye on the number of used materials. Also how do you import the texture? Is it automatically exported in the .dae and applied to the model when imported inworld? or do I need to extract and upload the texture seperately. Sorry for the noobishness of the question, still new to Max and currently stuck on UVW unwrapping, not actually got to the point of uploading a texture yet. Medhue said he can't include any textures in the .dae from 3ds max. The current autodesk collada exporter doesn't include a texture export for .dae files, unlike the .fbx. I'm not sure if there are any other exporters for max that do. I always upload the textures seperately. Just make sure you have your UV maps worked out. There aren't a lot of tutorials on max in the SL wiki, but there is one about UV mapping / UVW unwrapping. Exporting a mesh from 3ds max It's halfway through the page, three youtube movies.

leliel Mirihi wrote: Video games use dirty tricks like this all the time to cut down on resource usage, especially on consoles. I'm not that familiar with video games, not at all actually, but I am pretty sure it would do wonders for SL if LL makes it possible, as you edited yourself, it would mean a 66% decrease in video memory use if the highest res could be left out and up to pretty much 100% if the object is in the far far distance.

leliel Mirihi wrote: As the edit to my above post shows it's beyond academic to the point of being a waste of time to talk about. Yet you kept talking about it where I wanted to leave it a page or so ago.... Your examples I quoted say otherwise. In a video game textures are used as many times as possible, in SL they aren't. So working with a trick or solution or technique that only works for non duplicated items would suit SL, not an optimised video game. I already said it's possible to get it to work, just not worth the effort. If you can somehow keep the high res texture out of the vid memory when it isn't used, I'd say that could be very well worth the efford. If it is cached onto your HD, it won't take that long to load it when needed aswell.

leliel Mirihi wrote: To what end? What are you trying to save by doing this? It's the full size image that's taking up all the ram, cutting back on some image half way down the mip chain isn't going to do much of anything. We're talking about extensive modifications to the viewer to over ride how the GPU does mipmaps to save, what 5%? Who cares? There are much lower hanging fruit. Isn't that exactly what I said 10 times already? It not being worth the efford and it being academic... This just highlights the differences between sl and a real game. In a real game you can make these sorts of guaranties about objects so doing these kinds of optimizations makes sense. I'd say quite the opposite. The viewer would have to keep track of all the objects at all the time, it would need some smarts for times when people zoom in and out so it doesn't keep loading and unloading textures, etc. It's possible, but it's also an easy way to add bugs. I can see the jira issues now about the viewer being confused about how far an object is and refusing to load the high texture and so on. And how does the viewer know what LoD to show? Because it already keeps track of both object size and position. The loading textures issue I already mentioned and I wouldn't be surprised it's at least one of the reasons LL decided to go with an all textures for all LoDs approach.

Robert Galland wrote: Is there a way to work on the table with the lamp in the scene but only export the table without the lamp? I bring this up because of the examples given about separating builds which I am also working on. Can I have a scene with two house parts and upload them separately? In 3ds max you can "export selected", so you can have all your lods and all your different objects in a single scene. Possibly Blender has this option aswell. Maybe I am thinking about this wrong and, while the scene would be uploaded together, the objects are already separate. For example, can my table in the above example have 8 materials as well as the lamp or am I limited to 8 materials for the scene which included the table and lamp? I hope this makes sense. Again, in 3ds max, if the objects are seperate in the scene before uploading, they will be linked in SL, but seperate objects. So you can indeed use 8 materials on each of them.

leliel Mirihi wrote: Because you're plastering everything with high res textures! According to whom?? I never use textures bigger than needed, I always make them fit the object. ( Your whole example sounds to me like "How can I use a high res textures for tiny objects without it increasing memory use". Maybe I'm reading more into it than there really is but that's the way it looks to me.) Then you clearly don't hear what I am saying. I am talking about lowering the texture use on the lower LoDs, I never mentioned increasing the high one anywhere. One atlas for more than one object, i.e. the table and chair use the same texture. This works best for non square objects that would otherwise have a large amount of wasted texture space. Depends on how you use the textures. If you want 512x768 for the table and 512x768 for the chair, yes. The results would probably not be that much better than two 512x512s. And some people might want only the table, no chairs. Then you really have unused texture space. The viewer only loads the low res texture when the object starts out far away, once you zoom in on the object it has to load the full texture which stays in vram even if you zoom back out Point taken.... but that's how it works now, not how is has to work. What makes you so shure the viewer will dump the large texture? The object is still in view after all. And this whole trick will only work if you have one copy of the object in view, if you have multiple copies at different LODs than you're now using way more vram then a normally made object. I'm not sure it does, but I am sure it's possible, since a LoD change means a model change. One copy of one object is what you'll be looking at in most cases and in SL most objects have unique textures. If you build grass or trees it's probably not a wise choice. If you are building pretty much anything else you won't often see duplicates. This is very different from what you'll see in video games, where reusing textures is the norm for obvious reasons.

Maeve Balfour wrote: Mmmm... things like doors etc I am thinking about in regards to LODs, possibly faking them larger with a tiny triangle placed away from them to force their bounding box larger (just an idea for now - the doors themselves will eventually slide INTO the wall cavities, so the extra triangle won't be seen in normal usage. Won't that mess up the physical shape of the doors? On a simple object like a door (assuming it's a simple box) I'd go with more detail on the lower LoDs. A (mesh)box won't press on your landimpact, staying at LI 1. It ofcourse depends on how many doors you want in a single object, I can imagine you can combine a couple since they are sliding. All you need is 6 faces with 12 verts for a (sliding) door with some volume, you could have 4 faces with 8 verts for a lower LoD, I can't imagine that will push the impact over 1.

Medhue Simoni wrote: I think the only time you are going to see a script impact a mesh, is if the mesh is only 1 or 2 as far as Land Impact. The only time you will see the addition of scripts having a raise in landimpact is when the server weight of the object is more than half that of the other two weights, unless the object is physical, then there will be no extra impact. (not arguing with your statement...just narrowing it down...) To the OP... You could make a seperate "script prim" for the chair. Make the entire unscripted chair out of one mesh, to keep the server weight down, you'll see a lower number than 9. Then make a very simple chair shape (could be a box even), slightly bigger than the chair you have and make it invisible, just make sure it sticks out of the chair everywhere. Make it invisible, set it to phantom so people won't walk into it and put the sit script in that object. People can now right click the chair (or at least they think they are) and sit on the seperated prim. this will have all the benefits of the shadowprim being used for it, without people having to search for a place to click. You could also put the script in the chair itself, as long as you make it out of one mesh. Chances are the server weight will still be under the download weight, then there will be no extra landimpact. It's possible the server weight will go over slightly, adding to the landimpact. Then it's for you to decide if the all-in-one-costing-slightly-more version is worth the extra impact. Having two seperate objects is ofcourse clumsy.

leliel Mirihi wrote: The problem is you now have more date you want to store in vram then what you can fit. My video card has 1GB of ram and I routinely see the viewer eat all of it up and still want more. That's because people use high res textures way more often than they need to. They don't use texture atlases as much as they should (mesh now makes this easier). Ok, now you have me confused. In two ways. Why would I have more memory than will fit the vid memory? And why would using atlasses be better for memory use? One 1024x1024 texture uses as much memory as two 512x1024s to my best knowledge. I thought the big advantage was the textures on an object loading all at once rather than piece by piece. If there was no need for the entire set of materials on all LoDs, you could use two 512x1024s, on a lower LoD only one of them. I am tempted to say that is a reduction of memory use by 50%. The point is you're really not going to save much in the way of memory bandwidth doing this, and that's not what's in short supply (in this case). These big textures take up more vram and that's what we're short on. Yes very clear, I thought I said the savings were very small a couple of posts up. And how is a 32x32 oncoloured texture big? Geometry and texture LOD may work similarly but they're intended to solve very different performance problems. Applying the theory of one to the other does not work so well. I don't know where I said they are the same and can be treated the same way. When you switch between geometry LODs the viewer is actually unloading one list of vertices and loading the next, both don't stay in vram at the same time. With texture LOD it's all done by the GPU and the whole texture mipmap stays in vram the whole time, no matter how far the object is from the camera. SL is a bit of a special case since the viewer only loads the texture up to what is currently needed, but once you zoom in on the object the whole texture is in vram and stays there for as long as the object is in range. The GPU can not unload part of a texture and the viewer never does. Now this is interesting. And it more or less brings me back to the "fake" mipmapping. Again in order for it to work, the lower LoDs should have a subset of the higher LoD materials rather than the entire set. (As Drongle said the way is was supposed to be in the first place) Also as I understand you, the entire texture is loaded into vram, this is not what you said earlier when you said the viewer uses a lower res version of that texture when far away before sending it to the GPU. If the entire texture is always loaded into vram, that indeed means the GPU will pick its mipmap choice from that loaded memory depending on the size on screen. If you fake the mipmapping by using 1024 for LoD0, 512 for LoD1 etc... and you walk away from an object, the biggest offender can be dumped from memory. The GPU will do its mipmapping with a smaller version, giving the exact same results visually, but using a fraction of the memory. When closing in on an object, the same will happen. I can see problems with textures not loading fast enough, but memory wise it sounds a lot more efficient.

leliel Mirihi wrote: In a real game a human would decide it's a waste to use such a high res texture for something you'd have to zoom into in order to see. One of the problems in sl is that the residents often decide the exact opposite and plaster the smallest of trinkets with the biggest texture they can just on the off chance people will cam in on it all day long. Yes and isn't that exactly what confuses so many people on both the forums and on the grid? SL is indeed realtime, but it's not a game. People dress up, can zoom in on things, care about small details you will never find in a game. So that is exactly why you can make big differences between the LoDs. A necklace with nice detail on the highest LoD won't bother anyone. (A nice necklace with high detail on lower LoDs will.) Not until they zoom in real close and that is when the rest from their screen disappears and they can focus on that one single item. I know perfectly well how to build low poly on all LoDs (and I am very careful with textures), I just don't think that's a wise decision in a lot of cases. A "big" texture on the highest LoD won't be visible on lower LoDs/bigger distances/smaller sized objects as you keep explaining. You say both the viewer and graphics card make sure of this. ETA: In your example above of the necklace covered with one texture, no repeats. By the time your camera is 10m away the necklace is only taking up 100 pixels at most, the GPU would have long since dropped to the 32x32 mip level or lower. 100 pixels on your screen is most definately not 100 pixels of texture. on something like a necklace you only get to see maybe 20-30%. I gave the 10 meters just as "a"number...I didn't test it. Use 2 meters instead then if it makes a difference or 3 or 6, any distance where the GPU would pick a multicoloured 64x64 mipmapped texture.

leliel Mirihi wrote: What? Either we're having a major miss communication or you don't understand what mipmaping is. I know what mipmapping is. You said the viewer sends a lower res texture when not close to an object. That gives essentially the same result as mipmapping then. Or at least a first step in that process. Why not just use a low res texture to begin with? Did you read my post at all? the example? On for example small objects, where all detail is lost at a distance not that big, you can use a 1x1 pixel image (well if SL would support such small ones, but 32x32 with only one colour will do, the "blank" texture) The small object will be viewed up close though, then a high res texture can be preferred. This is exactly why I say a human being will make a better choice than some piece of machinery. I expect the GPU to adjust the texture to the size of the object on screen. Object twice as small, next step in mipmap. But some objects escape our attention when not in our face, so the texture size could regress faster than that. I also don't think mipmapping takes LoD changes into the calculation.

I built an exterior of a 64x20x20 or so building... 8 prims, it's not finished and it will be more, but the normal prim build it replaces so far was 64 prims. All you really have to model at those sizes is LOD0, the rest can be as small as possible.

You're mixing two things up now. According to what you said earlier the GPU doesn't have to do any mipmapping, or hardly, since the viewer sends the reduced texture in the first place. Still a question what happens if you walk away from an object instead of walking towards it, since then your viewer has received the bigger texture, maybe there's some mipmapping then. Anyway, the example. You have a necklace made out of silver chainlinks and you use one full unwrap on it, no repeats (which would in most cases be stupid, but it's an example). As soon as people are 10 meters away from you(probably a lot closer even), they won't see any detail in the texture, but the entire texture area is still pretty big. In that case I would say it's better to make the necklace a plain color than a reduced version of the high res one. Again..again..again... it's all very academic, since the performance gain would be so small it won't be noticable next to the other textures.

Where are my glasses?

Good luck!

Jarmade Spires wrote: Thats so strange! I set all as smoothing group 1, and it shows normal vertices. Set it with no smoothing at all. and it shows 11k vertex. So.. smooth stuff costs less to render? (less prims at least) O_______O Yes that's what I said, if you have no smoothing groups, the object is treated as seperate faces. It has got to do with the normals. a smoothed vertice has one normal, so SL can calculate the lighting/reflection between all verts making up a face. If you have a hard edge there are more normals, one for each smoothing group. i understand your surprise..better looks cost less? welcome to mesh! This is often the case.

the smoothing groups will have a far bigger impact, since all your triangles now have 3 verts where the ratio of triangle/vert is usually 2:1, not 1:2 (something like this anyway, depending on the shape) With no smoothing groups, the UV can't have any impact, it's as bad as it can get right now... Also try that imposter/billboard thing and get the triangle count under 10 in your lower LoDs..now that is optimizing and will let the LI drop tremendously. Just guessing, but I think you should be able to get the LI under 5, depending on the size. Oh and yw ofcourse!

Jarmade Spires wrote: the blender dae has smoothing groups too. and its vertex count is normal? I simply tried to import the .dae into 3ds and export it back out as .dae, it shows 11k vertices with no changes. Well what I said should be the case, it's what I hear and see all over. Maybe the UV maps were changed between blender and 3ds, or the smoothing groups were ignored. Or there are disconnected faces. What I am curious about though is why the 3ds model has more verts with LESS faces. Make sure all the vertices are welded together and check your smoothing groups. I would be very surprised if you could get a box from blender to upload for 8 vertices.

This is expected behaviour. All vertices on the edge of a smoothing group or on a UV seam are counted for every "surface". So a box is not a box, but due to its smoothing groups (hard edges) it is really 6 square planes. 6x4 = 24 vertices. Edit..talking about planes... you could use a plane for the lower LoDs with a picture on it instead of reduced geometry and see a dramatic drop in both landimpact and render weight. It will look better aswell I suspect.

Prim Composer That will work with 3ds max.

Tari Landar wrote: Because sometimes when I scale things down, like a ring I was working on earlier for example, the prims aren't quite aligned the same way they were when it was big. Yes depending on the item you're working on, that can happen, it quite often does actually. In some cases it works really well though. Another advice that won't help out in most cases, or better phrased, not for most people, is build in mesh instead. you can build as small or big as you want without ever having to worry about allignment.

leliel Mirihi wrote: I think we drifted into talking about different things. At first you were talking about simulating mipmaps using separate materials, which honestly, is a horrible idea (except for tricks like using a billboard for the lowest LOD of an object). Yes since the first wasn't usable for various reasons, I took a next possible step. I'm just thinking out loud and any feedback will help speeding up that process a lot or fill in some blanks... Using a billboard or imposter isn't anything like mipmapping, but it is a fine example of how you can reduce data load on the servers without losing any looks, in fact they can improve them quite a bit. I am just thinking out loud about other possible ways to reduce load. btw, imposters can be used in far higher LoDs than just lowest. I've made a hanging chain with imposters for all LoDs except highest. The result was far far better in looks than any geometry would have been. You can imagine the landimpact was pretty good aswell. At a size of 5x5 or so meters and close to 50 links, it has a landimpact of 2 and LoD changes are as good as invisible. (The pic is the highest LoD) I don't agree with your example tho. If a texture has such low detail that you can get away with using a significantly smaller image than what a given mip level would call for then wouldn't that mean the full res texture is too large? That's where the difference between a GPU and a human brain is important. The GPU only has numbers to work with. The endresult of an object on screen isn't determined by numbers though, but how it looks. A human can see that so I'm pretty sure that human will make the better decision. If all the GPU does is mipmapping, it means it uses the high res texture as a base, with all its colours and details. Use a smaller texture and less colour variation, possibly to a point where there is no variation at all, and the GPU can mipmap with that. I don't see how this technique has got anything to do with the highest LoD texture being too large. JPEG2000 inherently creates mipmaps due to how it works (wavelet transforms). The spec takes advantage of this to enable some cool features, the main one being partial downloads. You can download part of the file and decode it to a lower res image than the main one. This is in fact the main reason LL chose jpeg2k over other formats despite its high processing requirements at the time. The viewer uses partial downloads so it only has to get textures up to the resolution it needs, instead of having to download the full res version of every texture in sight. The viewer caches however much of the texture its downloaded so far. Yes that's what I was asking. Pretty smart and it means the original idea I had, isn't useful, even if the lower LoDs didn't need all materials.

Yes for your normal meshes it's not needed, in fact it can be quite annoying if you reset Xforms, since it will set the object position to 0,0,0 no matter where it is in your scene. It can be helpful though if your pivot is mirrored or rotated. btw, the ediable poly and collapsed stack are also not needed for unrigged mesh. You can use editable mesh, editable patch or even the basic shapes.

Jean Horten wrote: For those who are interrested, I can send you some links to memory access related crash LL Jiras. Just post them here, that's a lot easier for everyone.