Jump to content

leliel Mirihi

Resident
  • Posts

    928
  • Joined

  • Last visited

Reputation

26 Excellent

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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 start pointing fingers.
  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 making the normal map just like any of the other limitations of normal maps. I was more so pointing out that down sampling 4:1 on each step of the mipmap is pretty much guarantied to average out fine detail very quickly.
  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 on is to dial in lower/higher RenderVolumeLODFactor on the Show Degug Settings dialog, rather than zooming. If it's hard to see the switches, you can use wireframe view to check (Develop->Render->Wireframe). Then, to see what the LODs actually look like with the LOD switches at a particular factor, you can either zoom or stretch/squeeze the object (that's how I did the bed ones). As far as appearance is concerned, it's the same thing. While this is good advice for looking at geometry LOD keep in mind as per above you would not be seeing the correspondingly correct texture LOD. You would have to either modify the SL viewer or write a custom model viewer to see them both at the same time. I point this out mostly to say you should take what you see with a gain of salt as that's not how it would be viewed "in the wild".
  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 significant portion of the user base doesn't have hardware or drivers new enough for them. None of that really matters tho. As soon as you have less inputs than outputs you're doing some kind of instancing and the viewer has plenty of that going on.
  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 can think of. The performance metrics displays in the viewer were originally made for debugging but they need to be brought to the for front and made easier to use and understand. Content creators and consumers can't make informed decisions without the proper data and they can't get the proper data without the appropriate tools.
  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 to properly judge it. Low LOD is way higher than it needs to be. Nobody is going to see those curves on the hand grips or stock at those distances, the barrel could just be a prism for all anyone cares, etc. Some artistic criticism if you want as well. The front hand grip is in the right place but the wrong shape and missing some parts. Also the overall gun seems a bit off assuming you're modeling the original Tompson and not the M1928 and variants.
  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 taken years to get people to understand LI, arguable we're still a long way from it being widely understood. And it's a simple system! If they had added all that stuff people would have just given up and stopped caring, I'd argue it's happening now with the type of objects that started this thread. If you're saying that LI didn't go far enough to stop the rampant resource abuse that has plagued SL for a decade then you're right. But being bitter about that isn't very helpful.
  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 but they're lazy so we should light a fire under them by abusing it as much as possible.:matte-motes-evil-invert: Anyway, the entire point is: sometimes it's better to use geometry, sometimes it's better to use normal maps. It's always good to use as little as possible. Agreed.
  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 carry a great deal of redundant information. In contrast, the geometry only contains detail where it is required. You're right about that, I suppose I should clarify. Normal maps have a high base cost but a low cost per feature. So they work best with larger objects with lots of detail that allows you to amortize the base cost accross the whole object. Also while the detail may be non-uniform on the mesh it doesn't have to be on the UV map.
  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 bandwidth limited by the PCIe bus transfering vertex data. The left object is rather heavy, with 4410 tris and 8820 verts (if it was uploaded to SL). The right object 18 and 28. Baked onto a normal map, there wouldn't be any difference though (apart from the fact you can of course tile the map of the left object, but this is an example). I'm pretty sure using a normal map for the object on the right, rather than geometry, wouldn't do you any good memory wise. Obviously there's always exceptions to everything, that goes without saying. Tho I don't think a shape as simple as a pyramid is a good example of that. btw, doesn't a normal map always use the fourth channel's memory, even if it's not used, taking up 4 bytes per pixel? No. Normal map != normal gbuffer. The viewer will use 4 bytes for normals and spec exp even if you don't have a normal or spec map because the normal gbuffer is for the whole screen. The same as how the "framebuffer" (diffuse/albedo gbuffer) always has an alpha channel even if there isn't a single alpha texture visible.
×
×
  • Create New...