Jump to content

Wulfie Reanimator

  • Content Count

  • Joined

  • Last visited

Community Reputation

2,579 Excellent

About Wulfie Reanimator

  • Rank
    Passively Aggressive

Recent Profile Visitors

2,033 profile views
  1. You made me do it. It's a little more nuanced than that. Let's say you're trying to render a scene with a simple cube in it. 6 sides, 2 triangles per side, 12 triangles. Let's ignore the texture on it. Rendering one on the screen is fine. Creating 300'000 copies of that cube would mean that your computer would have to sort 3.6 million triangles* (to determine which ones are facing the camera, or behind other triangles) and then put pixels on the screen one by one. Depending how the code is written, the same pixel might be drawn-over multiple times. Infinite memory still means your computer has to spend time doing many more calculations before generating an image. This is what causes your framerate to drop. It simply takes longer to render a single frame on the screen because there are more things to take into account (mesh, textures, everything). That's why additional copies of the mesh still causes lower framerates, why heavy mesh is Bad, and why "just buy more RAM" isn't a solution after a certain point. Larger textures can also take longer to draw onto the screen, but I don't know if that's the case with SL. (It depends entirely on how the code is written.) When you start running out of memory, the problems just get worse because now instead of just "drawing an image," your computer has to spend time figuring out which textures it can discard, and possibly load new ones from the (relatively much slower, even SSD) hard drive. VRAM stands for "video memory," or "Video Random Access Memory" if you really wanna spell it out. It's the amount of memory needed specifically from the graphics card, not just the regular RAM that your processor uses. When you create copies of an object, it needs to be stored somewhere so information about it can be tracked (location, scale, rotation, etc) and sent to the graphics card. So for every copy of an object, there is some memory cost even if the mesh and textures were "100% all shared." Otherwise you'd only render one thing, or all of the things identically on the same place. * 3.6 million triangles is not hard to reach, considering how Bad most mesh content is (especially as attachments). Your naked mesh body alone can put you halfway to your first million, or more. (Looking at you Legacy...) It has become more and more commonplace to see a single avatar reach the million-mark, I would even call it the norm.
  2. Nope, I don't know if it ever was. To give a more concrete example, here's one mesh: Here's two of the same bed: Note: Faces/Triangles go up, but texture count, TMem (Texture memory) and VRAM (mesh included) remains the same. Without taking a deep dive into the memory management of the viewer (or explaining very technical details like the memory overhead of just keeping track of instances in memory), that's the easiest explanation I can give.
  3. Absolutely true, but although the VRAM usage there is listed individually, they are most likely copies of the same object or share at least some textures. In that case the memory usage is almost* nullified for each copy after the first. But just to make it clear -- 5*1024 is not acceptable for a lamp, lol. @Chic Aeon I don't know for sure but even if the mesh data was entirely duplicated for each copy, the textures on the mesh would still only be in memory once and use way more than the mesh. Mesh is pretty compressible.
  4. I'm looking at my non-stick pan and it doesn't look like either of those... both of those look like they're smooth porcelain. But I can see that one of them definitely looks more shiny, but I can't tell how much of that is because of the sun difference like you said. I'm yet to really look at EEP besides the things I've been hearing on the forum, and consistency is not one of those things.
  5. I'm not a contrarian to what you say, Prokofy. It's not that personal. I didn't respond to like 90% of what you wrote, which I agree with, I only quoted a couple very small bits of what you said because I like trying to correct misconceptions. You weren't the main reason I posted either -- when I originally read your post, I just went "yeah that's about right, moving on..." I sometimes even make the conscious effort to not respond to some of your posts because I don't want to annoy you because you'll be like this, so I can say for a fact that I'm not "always one." Or maybe I'm just being a contrarian yet again. Apparently so. You can get to "Inspect Object" by: Right-click > Object Profile > Details, but it shows no useful info compared to Firestorm. But I did find this instead: Ctrl+Alt+Q to enable the Developer menu (top bar) Select an object Develop > Rendering > Selected Texture Info Basis (Ctrl+Alt+Shift+T) This will give you a popup for each texture on the object and tell you the exact size/face they are on. (The below is the result for my bed, which is a linkset.) It may be showing a popup for the same texture multiple times if it's used in multiple links, but I don't have time to check that right now. It's something at least. And of course, this is on the LL viewer.
  6. If you need right now, shouldn't you be the one offering as high as possible, not haggle? 🤔
  7. Wanting to prevent noobs from littering is no excuse to massively inconvenience long-time users (never mind paying customers in general). Newbies can eventually learn how to use SL. The people who have already been here for years won't be reduced back to "how 2 i rezz?? where mything go?"
  8. Setting physics shape to none isn't a "trick." Having no physics shape means the sim doesn't have to consider the object's components for physics calculations. (Besides the root, which must have a physics shape.) It's an objective benefit and doesn't lower LI unless the object had higher physics weight than download (render) weight. So, if it worked for that object, it was a fixable problem. You can right-click an object and "inspect" it. The inspect window will show you the Texture Memory being used by that object's components, which you can use to estimate what size the textures might be. With a little experience it becomes very easy to tell. Asking "are you sure you removed the scripts," if that really happens, makes me think that the 'matron' is checking the contents of every object by hand, which I wouldn't recommend because it's slow and error-prone. You can right-click on an object and get "Script Info" to instantly get an exact count of all scripts in every component of the object, how much CPU time they're averaging, and how many of them are turned on/off. (I'm pretty sure it's not LL Viewer functionality, but anyway.) Removing lights also seems extreme, they can be turned off in the viewer's settings and have no effect on sim performance.
  9. [insert 3 hour tutorial video explaining only the basics here]
  10. While it's completely valid to feel upset by unsolicited interaction (literally harassment), I don't think there's any practical solution that LL can implement that wouldn't adversely affect normal use and/or break existing content. Invisprims are not a solution to privacy. Anything you rez or attach can be derendered. Any kind of user-made product that's supposed to give you privacy is an illusion that can be broken pretty easily by anyone SL-savvy, the only people they'll protect you from are people who don't spend much time with computers and/or video games. When it comes to attachment interaction (clicking on things), it's the scripter's job to impose a(n optional) limit.
  11. I will report your passive-aggressive and dramatic (since you felt necessary to let them know you're going to report them) response, so ha! Also, it's your not you're. Have a g'day.
  12. Some mesh objects are built poorly. It's a permanent problem for those specific objects. You could possibly work around it by rezzing a prim and placing it over the floor with a transparent texture, so you don't see it.
  • Create New...