Jump to content

leliel Mirihi

  • Content Count

  • Joined

  • Last visited

Community Reputation

26 Excellent

About leliel Mirihi

  • Rank
    Advanced Member
  1. PyroSteel wrote: couple things going on here. The user created stuff isn't the problem. In a dense population area my vert buff is only hitting 5-7k. <-- this is super low. On a modern game, the main character can be 12-25k verts, while the whole scene can go as high as 2-5 million verts. You either hang out in empty sims or you misread something. Heavily built up sims are usualy pushing 700k-1m tris without shadows. The sim I'm standing in right now has 3.3m tris on ultra and that's with no avatars in view other than my own (draw weight of 14336). Get your facts straight before you
  2. Drongle McMahon wrote: Normal and spec maps have their own LOD known as mipmaps that would hide that detail. I don't think that' can be generally true. The switches are not coordinated, and simply interpolating the higher res normal map doesn't necessarily make the right kind of adjustment. I didn't mean to say the switches would be coordinated. The two LOD systems were created to solve two very different problems and as such are implemented separately. As for making the right kind of adjustments that's a rather subjective mater that I think needs to be taken in to consideration when m
  3. Drongle McMahon wrote: Yes. They stay on the same faces, just like the diffuse texture. That can be a problem with the normal map because the map specifies the difference between the geometric normal and the normal to be used by the shader. If your lower LOD removes detail, or removes edgeloops used to sharpen corners, then the normal map for the high LOD won't be correct for the lower LOD. That's just an extra thing you need to check if you are using materials. Normal and spec maps have their own LOD known as mipmaps that would hide that detail. The best way to see exactly what's going o
  4. ChinRey wrote: So SL has several mechanisms for reusing data although it can hardly be called true instancing. That sounds like a no true Scotsman argument to me. How about you define what true instancing is first then claim the view doesn't do it. I would assume you're talking about functions like glDraw*Instanced*(). The viewer doesn't use those becuase they don't make much sense within the context of the kind of content we have in SL. Then perhaps you're talking about glMultiDraw*Indirect(). The viewer doesn't use those because they were just added in OpenGL 4.3 two years ago and a
  5. The problem with this kind of stuff is there's no feed back loop. When people see performance problems there's no obvious cause for them and the community basically indoctrinates people to blame LL for everything. Most people just don't even realized it's their own content that's causing the problems. When you try to bring up the issue many people take it as a personal insult and downplay, brush off, shift blame or just get hostile. Increasing public awareness through frequent educational campaigns while expanding the performance metric systems in the viewer is the only long term solution I c
  6. Works for me and plenty of other people. Rare problems are just that, rare.
  7. Jake Koronikov wrote: The SL shader system does not have any special solution for these kind of objects. Some other game platforms have special shaders to render those. At least those shaders can be coded. Those games use alpha masking instead of alpha blending, SL now has alpha masking as well. Give it a few more years and most well made content will use it making over draw much less of a problem.
  8. Medhue Simoni wrote: I'll show an example, and then you all can rip me apart, and tell me to stick to animating.Triangles - High 2814, Mid 1406, Low 350 This model was 1 of my first decent model, but I recently decided to sell it for Unity also. It's a little hard to judge from that one picture so take this with a grain of salt. High LOD looks fine for the most part. The only problem I see is the receiver, it was literally just a box with stuff bolted on. Yours is too high poly for that. Mid LOD seems a little higher than it needs to be but I'd have to see how it behaved in SL
  9. Pamela Galli wrote: I am not bitter about it, quite the contrary. I agree with the above points about LI accounting, but I dont find it that hard to work around. Sorry if it seemed like I was calling you out. I was replying to the thread as a whole and your post just happened to be the last one at the time so I clicked reply to it.
  10. I think a lot of you guys are asking too much from the LI system. One of the design constraints of LI was that it wasn't too radical of a change from the prim system. LI doesn't count textures because the prim system didn't, LI doesn't include avatars because the prim system didn't, LI doesn't account for instancing because the prim system didn't. LL wanted a mesh object to have an LI of roughly the same as an equivalent prim object but that's never going to happen if the LI system is counting all kinds of crazy things the prim system never did. There's also the issue of user training. It's t
  11. You have no idea how avatar imposters work do you? What it's trying to accomplish or how effective it is. I'll give you a hint, you are the problem avatar imposters is trying to mitigate against. In other news tragedy of the commons is now playing in theater near you.
  12. Flexi pre dates Qarl by a year. Also while you could blame some of that on Qarl LL has made the same mistake dozens of times throughout all aspects of SL. The company has a history of rolling out proof of concepts that were poorly thought out and often caused more problems than they solved. I think it's more a structural problem within the organization than the failings of any one person other than their inability to fight the system.
  13. Kwakkelde Kwak wrote: Anyway, I am talking about the maximum of 512 MB reserved for textures. No matter how muh memory a vertex uses, it doesn't qualify or is used as texture memory. If it is, the term is chosen poorly at best. Texture memory is an artificial construct of the viewer that is completely disconnected with reality. On the hardware side dedicated texture memory fell out of favor almost 15 years ago. The reason why the viewer can't use all the vram modern cards have is because it still clings to this out dated concept. LL knows this system is broken and needs to be removed bu
  14. Drongle McMahon wrote: "That means your normal map is too big." I don't think I can entirely agree with that assertion, so far. The density of geometry can be highly variable. In my example, it's mostly in rounded bolt heads that occupy less that 2% of the surface area. The remainder doesn't use much geometry, but the normal map has to be uniform and of sufficient resolution to give the required detail for the bolt heads. In other words, the normal map resolution is determined by the finest detail to be represented. If the distribution of detail is non-uniform, that means it has to ca
  15. Kwakkelde Kwak wrote: Of course when you compare a high poly model to a low poly model with normal maps, the low poly will be better memory wise. Normal maps are textures though and Second Life has a very limited amount of texture memory. In other words, if you have a lot of VRAM, SL will run out of memory before your graphics card does. Vertex date takes memory too. Develop -> Show Info -> Show Render Info to see how much. I'm shure everyone has heard about the GDC presentation approaching zero driver overhead by now. It's worth pointing out that many of their examples were bandw
  • Create New...