Jump to content

arabellajones

Resident
  • Posts

    146
  • Joined

  • Last visited

Everything posted by arabellajones

  1. There is a lot of poorly-made Mesh out there on the marketplace. And I don't know of any way, short of a demo, that you can check a mesh without buying it. I have just spent a while going through my outfits, replacing some high-complexity boots with equivalents from the Library avatars. One pair of pre-mesh boots ran to about 24k complexity for each boot. One of similar library boots from the newest mesh figures was about 0.8k for the pair. The complexity number is the same as the render weight, and one of the big factors in that is the triangle count. It's not the only thing, a smaller texture can make a difference, and for something the size of an ankle boot it's hard to get the camera close enough that screen pixels are even close to the size of texture pixels. Anyone thinking of making Mesh stuff maybe needs to look at those Linden avatars for an idea of what works. I have a suspicion that some people are looking at meshes made for programs such as Poser, which have wonderful detail, but are not made for live animation. As far as making stuff is concerned, SL is a game.
  2. Which viewer are you talking about? I use Linux, and if that feature depends on Havok code, I'm not going to be getting it any more. (I could rant at length about the Linux version of the LL Viewer. Apparently, it is still a beta, with no support, and no Linux viewer has the full Havok support needed for the mesh import features) Both Wings3D and Blender let you decide whether specific edges are hard or soft. Now the Wings3D bug on .dae export seems to be fixed, I don't have to worry about how the viewer can do this. I have control. I like being in control, rather than relying on some automatic magic
  3. A couple of times, recently, I have had occasion to ask whether something that happened with a viewer was supposed to happen. There seems to be a lot of guesswork by users. I was advised that the only way to find out whether something was supposed to happen was to see if it happened in the official Linden Lab viewer. I was a little surprised that nobody seemed to know. I downloaded the Linux version of the viewer. It keeps crashing. I was told it isn't supported, it's a Beta. This is all starting to seem less than competent. I don't even know if what happens can even happen in the LL viewer. Going by what I can find, no parcel boundaries are shown by the LL Viewer, but the documentation, such as it is, is horribly out of date.
  4. More prims per region will be nice, but how will it affect the ancient bug associated with vehicles region-crossing into a full parcel? There's a general pool of prims per region, used for things such as vehicles, but it isn't applied in that specific situation. And I know it is one of the oldest acknowledged bug in the game. OK, this might be a temporary fix. but all thos prims are going to get used. (Yes, I know the counting methiods have changed, and we have mesh and prim-equivalents and stuff. but that bug is still there.)
  5. Adding a little bit more here... There are a few things that come from the interactions between the .dae Collada format and Second Life. Way bacl in the old days there were tricks to make small prims for jewelry. and there are still pifalls around the scale aspects. Wings3D is working, but for smaller items, around the size of an AV head, there are some scaling issues. The fix seems to be pretty easy., and it ends up giving a lower render-weight/complexity. Step one: Wings3D has options to make several components, even with different texture, into one mesh part. This is an option in the Object right-click menu, Combine and Separate. One practical advantage is that the components will scale together. and maintain their relative positions. Using this will reduce the complexity a little, partly because, some effects are similar to multiple prims. You can still hit a minimum size, but this is where the detail of the export process comes in. Instead of exporting in meters, export in centimeters, and don't bother with any rescaling. A .dae file is a form of XML, and when you look with a text editor, you will see this defined bout a dozen lines in. I am guessing a bit, but it looks as though the format uses a limited number of decimal -places , and any scaling you do on import can suffer from bad rounding errors. What I got was a ring-shape, a torus, being elongated into a tube. Using the centimeters fixed that, no other effort needed, and also took away some of the size-limits I was hitting in the object aditor. If all you want is a static mesh, not rigged, Wings3D is looking to be a viable alternative to Blender. I am still feeling my way on some aspects. Using smoothing well is a bit of a trade off with the polygon count. It's still not quite at the formal release stage. but I have been able to replicate a few old prim-based attachments, and halve their render.weight/complexity. And some mesh items seem to have been made by people who think the only way to smooth a component is to use a huge number of polygons. There have been several times when my usual furry avatar has been accused of being too complicated, and lagging a sim. Sometimes the accusation has been made by somebody showing around three times the complexity.
  6. Wings3D is a free modelling program which can export 3D models in Collada format, and I have been using it for a long time. I doubt it will ever support rigged mesh, but I have had decent results for simple objects. Trouble is, while it can do smoothing, it can't export that smoothing in the Collada format, and that gives ugly results. I did find a work-around. Export in Wavefront .obj format. import to Blender, and export the Collada file from Blender. I have used Wings3D for years, since before I ever logged on to Second Life. Blender is, for me, seriously intimidating. This works, but I don't like it. Anyway, I described the problem on the Wings3D website, got a couple of brief replies, and it should be getting fixed. The current Development version does appear to have the fix. Export in Collada format from Wings3D, and it imports to SL with the smoothing. As a development version, I'd recommend caution, there's no need for anyone to switch from other software that works, but the option is now there. What's the point of smoothing? Instead of needing a huge number of facets to get a smoothly curved surface, you can make a cube look like a sphere. OK, that is a little extreme, but that can make a huge difference to the render-weight/complexity numbers. Wings3D and Blender are both free, and both import a variety of formats. Wings3D doesn't try to do everything, and, frankly that suits me. I can see how Blender has advantages, but there are alternatives.
  7. I use a Psicorps avatar a lot. But the mesh can have a worryingly high complexity, which seems to be down to sections with a far higher polygon count than they need. They're not bad. I have seen far worse in ordinary clothes for humans.
  8. Any luck? I noticed two obvious things. 1: Several of the failures to load a file were trying to load files with names of this form: /home/dennis/.secondlife/user_settings//home/dennis/.secondlife/user_settings/settings.xml That might be an error with the log, but that location for the file can't exist. Then, at the end, they report the software is a BETA. There are third party viewers which work for Linux, Like every viewer they use a lot of Linden code. But at least they work.
  9. So everyone has been telling me that I need to use a Havok-enabled viewer to upload mesh, and suddenly I don't? The Firestorm blog is either mistakenly conflating Havok with mesh uploading, or you're wrong. ("Linux because there are too few users who use Havok for mesh uploads or Pathfinding" is what they say, and no mention of it being a consequence of an LL decision.) Who do I trust? And having to go to a third party site to watch a video of a meeting to find out what Oz Linden said about an issue that nobody cares to document? It doesn't look all that trivial from here. It's maybe minor, there's so much that Linux viewers can still do, but not even mentioning it? And the way the whole internet is going, I'm wondering if I should have chosen a different account name, something such as "DeathEaterMasterMan". Is it really doing it wrong to expect software to work as advertised, and how it was doing before an upgrade?
  10. Well, that's that. Going through the usual Help function, the Wiki and the knowledge base, there is nothing. There's nothing to indicate there has been a meeting with users on the topic since 2011. although the actual web page for Open Development has been updated since then. If something was put in the Viewer Release notss, I haven't found it yet. So I tried running Windows versions of the SL Viewer and Firestorm under WINE. The installers work. The programs don't, they just hang there, doing nothing. As far as I can tell, they just seem to use large amounts of RAM. They formally decided that Project Sansar would be called Sansar, with a trademark, but the only purpose of www.sansar.com is to get the email addresses of people using expensive software. It doesn't tell you anything about Sansar. RTFM is pretty useless if there isn't a manual. And I have a computer, decently powerful, that I can create content with, but it seems I can't upload some of the content to Second Life. There some instructions, badly organised, but they assume that all viewers are the same. I did find out that LL has a Director of Global Communications, named Peter Gray. He seems to be about as much use as a bacon sarnie in a synagogue. Sansar is looking less and less appealing. Will there be anything there, or will it be an endless waste of no-content, populated by the bewi[dered, trying to figure out what to do? I expect somebody will accuse me of being negative, but what the hell else can I be?
  11. Thanks for that. I checked the link you gave for the user group. It's not wildly impossible timing for me. And they even have an archive... The last transcript is June 2011. Are you sure that meeting is still running?
  12. This started, for me, with the latest version of Firestorm, but the "explanations" suggest a deeper problem, affecting all viewers using a Linux OS/ Briefly, the Linux versions of the Firestorm viewer do not provide Mesh upload or pathfinding map editing, and the claimed reason is that this is because Linden Lab no longer pays for a Linux license for the relevant Havok components. If this is true, eventually no Linux user will be able to upload Mesh. It has been suggested that I use the WINE package to run a Windows viewer. This does work for some software, I use some that does this, but nobody seems to know whether this will work. It's one of those rather generic answers, much like relogging or rebooting a modem, which works often enough to be worth trying, but there's only one way to find out. Does the SL Viewer for Linux still support mesh upload? If it doesn't, does the Windows version get tested againt WINE on Linux (and which WINE version)? Is there any third-party viewer that gets such a test? (Secondary point here: what chance of full Linux support for Sansar?) To be honest, I am not sure I trust anyone on this. The Firestorm people have put the blame on Linden Lab, and Linden Lab are saying nothing. As usual, there seems to be a convenient dose of "Somebody else did it", And, while I use Linux and I use some software with WINE, I don't feel confident enough to install a Windows viewer using WINE to get around this problem. Nobody who suggests it mentions having actually done it, and the thought of being the first terrifies me. (And maybe we are in something of an hiatus with the promise of the 64-bit viewer.) I am trying not to worry about Microsoft buying Havok last year.
  13. It's always easier to fire things of the right calibre... (Sorry...) Programmers are not things. Neither are users. I am not a mushroom either.
  14. The flaws I pointed out are relatively minor, more library management than actual programming. And if the Marketplace code was written in a different language, so what? You hire programmers who know the language. There are people still working in COBOL for instance. That skill isn't as common as it was, but they're out there. But what I am hearing suggests that I would be a fool to have any great confidence in Project Sansar, because it looks like a rather poor competence in the higher management.
  15. I don't know if it is relevant, and some of these errors are plenty old enough, but I see that the Wiki has been locked down, for security reasons, for most of this month. What I am seeing is rather fundamental ineptitude, not getting the documentation finished. I'm not the Second Life equivalent of a Kremlin watcher, but I can't think of any well-known programmer-grade Lindens who have been around here as long as I have. If they don't even have internal documentation for the code that would be dreadful management, and I have heard a few stories from the days when Viewer 2 appeared. And user-created content with poor documentation... It explains a lot.
  16. Recent, and one of the better pages, but it would be worth making plain that Render Weight, Display Weight, and now Complexity are the same number. Picky? Well, what about search engines? Anyway, the word isn't anywhere in the page source.
  17. If a project isn't documented, does anybody know what they're doing, users of programmers or managers?
  18. I keep finding documents such as this one: Mesh/Mesh Server Weight It starts with this message: READ THIS FIRST This is a preliminary design of an unimplemented cost algorithm. EVERYTHING is subject to change, and certainly will change, during the course of implementation.It is all dated 15 April 2014, which isn't itself a problem. But if it is a stable version of the formula, currently used, why are you still using that warning? There are other instances of this sort of apparent dud info. Take the web page on Avatar complexity, which is clearly headed with a warning that it only applies to a Release Candidate Viewer Avatar Rendering Complexity If web pages such as this do describe the current situation, why do they need these warnings? And if they don't describe the current situation, why not? Can I trust anything Linden Lab say? Oh, I know I am too disorganised to be paid as an editor, and I am not a good typist, but with writing of this quality, if you wanted to organise a piss-up in a brewery, the beer would end up in a different brewery.
  19. I'm confused. Tbe MC and RC versions have exactly the same ID numbers now, yet one is described as a bugfix and one as security. And the release notes are identical. If they have the same build numbers and they're not the same code, something is broken. But it's a little worrying that the Lindens use different descriptions for roll-outs of the same code. It looks like the all-too-usual nerd/geek failure to communicate clearly.
  20. My experiences of SL13B were mixed. I struggled to find a viewer that could cope with the volume of data generated by the comination of crowds and complicated scenery, and when the Viewer didn't crash, I wondered if the organisers had forgotten that ancient piece of technology that is the signpost. I have known for a while that in busy regions, a dozen or more avatars (and the usual maximum is 40), there is slow loading of baked textures and meshes. In some cases, the sluggishness also affected script operation. It became apparent that these problems were affecting all os SL13B. I tried several viewers, besides my usual choice of Firestorm, and both the 32-bit and 64-bit versions of Firestorm. So, at first glance, there's nothing to be gained from 64-bit code. There's the same patterns of sluggishness and crashes. But then I noticed that Cool VL Viewer, right from the point of startup and login, was using far less RAM. For those who don't know, Cool VL Viewer harks back to the UI of the v1 Viewer, although it has all the code changes needed to handle mesh items, baked avatar textures, and even the new Avatar Complexity system. I am led to believe that we can only have 64-bit code if we given up on featyres, such as being able to upload a new mesh, that depend on the HAVOK drivers, which are still 32-bit-only. Which seems a bit strange, although most of these game-engine code packages still seem to be 32-bit. I have got a couple of games that are using 64-bit equivalents, and it seems to take so long to write a game that a good 64-bit game engine wasn't available when they started. I don't think Firestorm has done a good job. It looks like their problem is partly bloated code, partly a more general weakness of the 32-bit code that Linden Lab has been using since the introduction of Viewer 2. Cool VL Viewer is an existence proof of what good 32-bit code can do. Firestorm suggests that it will do no good to just take the existing source and compile to 64-bit Maybe that code quality in Second Life explains the effort on Project Sansar. If you need to start from scratch on the Viewer, why not everything? Some of the problems are bloated meshes and textures. Get rid of the old stuff, use "professional" tools. But I have some idea of what to do, how to make efficient meshes and use smaller textures, and it has nothing to do with using expensive software. SL13B pushed hard at the limits. The Landmarks for some of the stages seemed untested, delivering people to the wrong place in the region. Aim for the cluster of dots on the map, and you got nowhere close to the teleport that had been provided. I told them. One person offered me a teleport, but nobody fixed the problem. And the viewers still kept crashing as they consumed all the memory, real and virtual.
  21. That's worth doing, but Firestorm also seems to be struggling to cope with SL13B. I am seeing huge amounts of RAM being used. I've been crashing out with around 6GB or RAM used in 64-bit Firestorm, and plenty of disk-swapping space left. So I have been walking around SL13B with a different viewer. I have done work with textures, and tried to use as small a size as I can get away with. I try to keep my Avatar complexity low. SL13B seems to be made and filled by people who don't know and don't care. I;m tempted to give up on Firestorm
  22. Anything on the internet that supplies you with data from third parties can be an attack vector. I keep my viewer locked down so it doesn't play music or video or show me web pages without my explicit say-so. All it needs is a one-pixel graphic from a server controlled by the scammer, and they have your IP address. They have to have that to send the graphic. And, as well as any other signals at the internet level, they have have a set of graphics files, each unique to a particular service. I don't think Second Life would leak your account name, and not seeing that could be a give-away, but the same basic trick is also being used over advertising networks, and you IP address can be giving away the name of your ISP.. I am not sure how any of this media-on-a-prim stuff, or SLVoice, or streaming music, can be secure enough for a company that has to meet internet money-handling stndards to allow.
  23. I only have a very vague idea what this Utility Server maintenance is about. I can make a guess about some of what the servers do, and I've been seeing some sluggish behavior, but it all seems to be handled in mushroom mode. It affects logins for some people. OK. It may affect some groups. I infer that they are servers which store data related to individual accounts, and fixing that is consistent with some of the problems I have seen, but they could have other causes/ With SL13B going on, I am thinking of SL going into teenage mode and declaring, "But Ma, you don't understand!" You really should tidy your room.
  24. The big problem with the stages are that events happen at particular times. As near as I can tell from my experience, it's the graphics that are overloading. And some of them are rather garish. I;ve seen a suggestion, elsenet, that the player should wear sunglasses at the Cake Stage. Mesh: it can be horribly slow to load, The alpha maps are hopefully going to hide your naked body from the fascinated gaze of the people around you, but I have seen some mesh clothes that are gigantic, three or four times the size of the person wearing them until the last stage of the process occurs. Things such as boots and shoes are tolerable, though some mesh stuff has a crazy-high polygon count. Flexi-prims: chiefly long hair and skirts. That's another high-load class of item. Furries need to be a little bit careful, but with a little care they can have a lower render-weight than some human in a fancy dress. One thing I have done is make a version of my usual AV with several components linked into a single linkset without scripts. I use it for things such as flying, where it make a difference. My normal furry head uses six components, with various scripts for jaw and ear movement Welding them into a single unscripted linkset makes a difference for a sim crossing, and reduced the render weight a lot. Classic clothing, withoui mesh or other attachments, can look pretty good. And the texture baking system means that other people get all those clothing layers "baked" to a single texture, which helps a lot in busy places. Some people do seem to use big textures, whatever the item. There are one or two 3rd-party viewers which have 64-bit versions. That helps. They cannot be used to upload a mesh to the SL servers, and there are maybe one of two other things they cannot do, because the Havok code SL uses still isn't 64-bit, but you get better memory handling. It suggests that SL13B has turned out to be badly set up for the standard Linden viewer. I am beginning to think that the Lindens need to stop adding fancy features because they're making the Grid too complicated for 32-bit viewers.
  25. As I recall the change, most of the difference between the 650 and the 750 showed as reduced power consumption, and I can see some of that being down to the memory used. As we have gone from DDR2 through DDR3 to DDR4, the operating voltage of the RAM has dropped. But DDR4 also got a big jump in possible clock speeds. What I know of SL suggests to me that the memory bandwidth can matter a lot. It's out of my budget, but one of the side effects is that older cards will be getting cheaper, and a 9xx card will cost less soon.
×
×
  • Create New...