leliel Mirihi

Jean Horten wrote: Fully featured browser based viewers would not make too much sense at this time, they would be slow and irresponsive. WebGL for example is 90% slower than OpenGL, and I am sure that noone would like to use a browser based 'viewer' that delivers stunning 2-5 fps in low graphics J. https://a.cloudparty.com

Peggy Paperdoll wrote: You are running a laptop that has the CPU intergrated video chipset (the HD4000 video). You, apparently, also have the discrete GTX 285 video card. You do know that desktop CPUs can have an integrated GPU as well, right? The OP never said anything about using a laptop, and as you noticed he's using a GTX 285 which is a monster of a card some 10 inches long and pulls 204 watts. Do you really think he's using that in a laptop? Jumping to conclusions is bad, m'kay. Peggy Paperdoll wrote: Your computer is designed to auto-switch from the HD4000 onboard chipset to the discrete card when the video demand warrants it..........with the more recent CPU's with the auto-switch technology that happens very well (it didn't used to be the case because it simply didn't happen all the time.....the HD4000 video says your computer is a recent one). It's an either or thing............the two video adapters do not work together. The HD4000 works when the video demands are low and the GTX 285 works when the demand is high. Then never work together (if they do, then that might be your problem). And here I thought the OP was pretty clear about what program he was using.

Innula Zenovka wrote: Phil Deakins wrote: LL releases viewer code but I'm not up to date with how they deal with third party viewers. Does LL have a list of TPVs and only those viewers can be used with SL? If that's the case, has LL removed the OS viewer from the list? If LL is now preventing the OS viewer, there must be a reason, and it can't be merely that pathfinder exists, because other viewers are not prevented. Separately from releasing the viewer code, LL allows approved TPVs indirect access to the closed source Havok technology; see the wiki official article on the Havok Viewer Sublicence. The actual Sublicence agreement that devs are required to sign actually goes further than that, saying that the "Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company" (i.e. LL). Separately, but in an apparently related measure, LL removed support for the -loginURI parameter in the official viewer, which means that you can no longer use the LL viewer to connect to non-LL grids and that TPVs have to put the parameter back in if they want their viewer to connect to other grids. Some TPVs (e.g. Firestorm) are producing two versions, one -- with Pathfinding support and without the -loginURI parameter -- for the main grid and one, without Pathfinding support, that will connect to other grids. Other viewers have decided that they can't maintain two separate branches of the viewer, so have dropped support for other grids. In effect, all this means is that if I want to log in to Open Sim I have to use something like Kokua (the V3 successor to Imprudence) or the Open Sim edition of Firestorm, and when I get to one of these grids I won't have access to the viewer functions to manipulate the navmesh that I would need if I were setting stuff to being walkable or not on the main grid. Since I don't think Open Sim has pathfinding anyway, that doesn't seem any great drawback -- particularly, I would have thought, to someone like Mircea who regards pathfinding as a waste of time anyway. TL;dr. If you want to log into Open Sim you have to use a TPV, and possibly a special edition of one. Nothing to stop OS devs compiling their own viewer primarily for use by people who want to access third party grids, of course. I'm shure some people will cry foul at this but in the long run I think it's for the best. OpenSim was never going to 'go' anywhere as long as they were just following in SL's foot steps. I hope this will motivate them to spread their wings as it were and innovate, instead of just being a me too clone that's months behind. Not to say they haven't innovated in some ways, but maintaining compatibility with SL limits what they can do quite a bit.

Pamela Galli wrote: From a pedagogical POV, Google is indeed almost always the place to begin, unless everyone's time is worth next to nothing. This, this, this and this some more. I understand some people prefer human interactions but when it comes to basic questions you really are wasting everyone's time. In the time it takes you to post on a forum and wait for some one to type up a reply you could have googled it yourself a dozen times over. This is especially true when some one asks a generic and vague question that more often then not requires a very lengthy answer to explain properly. If people have to write a short essay to answer your question then you aren't asking the right questions.

Nefertiti Nefarious wrote: I was disappointed because altrhough it may look OK for some things, when you sit in a mesh skirt it bulges up (doesn't follow gravity) and lumps up in your lap. A deformer is not going to fix that. We'll need flexible mesh with custom bones or full fledged cloth simulation to fix that problem.

My concern isn't the UI, it's 3d performance. IMHO the only real selling point of sl is the shared virtual space full of user made 3d content. If you can't see and interact with that 3d content at a reasonable level of quality then there's just no point in using sl as opposed to say msn, irc or a mud. So with that in mind there's a minimum level of 3d performance that I consider required in order for something to be called a fully functional graphical viewer. Last I checked tablets just weren't up to the job, I don't even think older desktops with intel integrated graphics are up to it for that matter. Admittedly I haven't tested the latest generation of tables so maybe they are good enough, but given the kind of performance I saw last time I tested and some rough guesses based on moore's law and the hardware specs I've seen I don't think they are. I'm not saying a mobile viewer is worthless, obviously you don't need to see the 3d content every single time you log in. There's lots of tasks that only need a viewer with limited graphics or even just text. I'm just saying I don't think they're good enough for anything more than those limited tasked right now.

Kwakkelde Kwak wrote: Zoe Aria wrote: Lumiya runs on Driod tablets and phones that clearly do not have the horsepower of a desktop/lap top machine so there goes that theory. You can see your avi, inventory work poseballs etc ... I have a feeling LL won't be the ones developing it. We just need someone to writie it for the IOS platform and not just a chat client. There goes what theory? In my post I even link to Lumiya. I said it WOULD be possible to write a viewer for tablets. I also said it can't be a simple port of the normal viewer which only runs so so on a high end desktop with tons of memory, fast CPU's and powerful GPU's. All of which aren't found on a tablet. That means there are compromises. Anyway, good to see Alina is making progress with her viewer. Since this thread has already been necro'd I'll chime in an add that the screenshots from Lumiya are a good example of those limitations. Notice in those screenshots the drawdistance is limited to 16 meters at most. The web site also says the following. Limitations: Terrain and sky are not textured. "Mesh" is not supported. Sculpted objects are supported. Textures are heavily downsampled to comply with Android memory usage limitations. Particle systems, local lighting and other fancy features are not supported. That's hardly what I'd call a fully functional graphical viewer. It is not intended for exploring or viewing any of the wonderful creations people have made in sl. It's a glorified text browser that has a very limited 3d viewport solely to allow you to interact with objects. Content in sl is horrendously unoptimized and hand held mobile hardware just isn't up to the job yet.

Pussycat Catnap wrote: Open Source is the "wonderful utopian idea" that code will improve from all sorts of people contributing and will remain safe and clean because anyone can check it. BUT... if that was really true, how did Emerald get away with what it was doing for so long? How did that code even make it into the live release when there was suppossedly a whole team there that would have found what the one person did? Those Emerald devs got away with it for so long because the project wasn't actually open source. The source code repository they showed to the public didn't compile into the same binary they put up on there web page. That was one of the pieces of evidence that something fishy was going on. Add to that the fact that most of the Emerald devs themselves didn't even have access to the true repo, all access to the real source code for the project was controlled by just two developers, who just happened to be known griefers with very shady pasts. It's a wonder anybody ever used that viewer at all. There was plenty of evidence to show that those Emerald devs were up to no good many months before the end, but the viewer was so popular, and LL's viewer so hated, at the time that many people just refused to believe it. Emerald is a prime example of people willfully ignoring loud and clear signs of danger for the sake of comfort and features. It's a black stain in the history of SL that should not be forgotten.

Teagan Tobias wrote: I'm not putting off getting Mesh waiting for the deformer, I am holding off because 95% of it just flat does not fit me. I have a very large folder of Mesh Demo stuff and I will never say, well that's close enough. Why not? I've been saying that's close enough for prim and sculpty clothing for many years now. And don't even get me started on hair, that stuff never fits right, it always looks like a wig. As the old saying goes, if you want it done right do it yourself...or learn to accept the imperfections of other peoples' work.

LL has adjusted the heuristics several times since the feature was first added in v2. I can't remember what the exact values are now but basically something like 'if overall alphaness is less then X use alpha testing'. It's supposed to look for alpha channels tha have very little grey in them and are thus mostly black and white since those would be the least changed when using alpha testing. It seems to work well enough now in v3 but I've never really tested it. Anyway that's kind of off topic. The real feature that was being asked for was a per material flag to specify whether to use alpha blending or alpha testing. I think this is a worthy addition that should be at the top of the list along with normal and spec maps. It would greatly increase the amount of flexibility creators have, allowing them to both optimize for performance (alpha testing is much cheaper then alpha blending), as well as give them the best tool they'll ever get for minimizing alpha sorting problems. It's also an indirect prerequisite for using the 'true' solutions to alpha sorting. There are several ways to fix alpha sorting but they either require tight control over the content creation pipeline, which is not possible or wanted in sl, or they have high performance costs that make them impractical to use in sl. By allowing creators to specify which to use, and encouraging them to use alpha testing instead of blending whenever possible, would greatly lower the performance cost of the true solutions (i.e. the less there is to sort the cheaper it is). Honestly I'm rather disappointed that LL still hasn't added this feature, or even talked about it other then a few odd comments in jira. It's not exactly a hard thing to add, assuming they don't have to change the wire protocol to make room in the object description packets for the flag.

Chosen Few wrote: What you're referring to is properly called a 1-bit alpha map, as opposed to the 8-bit alpha maps that SL currently supports. 1-bit alphas are pure black and white, no grayscale. The transparency per pixel is either full on or full off, no blending. [...] I've never seen it referred to as a "hard alpha" before, by the way. Out of curiosity, where did you pick up that term? It's normally referred to as alpha testing. Kwakkelde Kwak wrote: SL already supports 1 bit alpha. Since "the olden days" it has linden trees. Since more recently SL turns 8 bit alpha channels into 1 bit sometimes. Someone explained when and why, I'm sure someone will respond again. It's not a setting you can turn on and off though and I think it only works with either certain viewers or certain display settings. More correctly the viewer doesn't turn anything into 1 bit, it just switches from alpha blending to alpha testing (i.e. the data stays the same, it's just changing how it's drawn). The settings are called 'Automatic Alpha Masking', there's separate ones for deferred and non-deferred. You can find them in develop->rendering.

The cheesecloth look is most likely from FXAA, it's the type of anti-aliasing the viewer uses when lighting and shadows is enabled. FXAA stands for fast approximation of anti-aliasing, as it's name implies its not true AA. It's actually just an edge weighted guassian blur with some other fancy stuff so it has the tendency to make everything a little blurry. Anisotropic filtering is a special way of doing texture filtering for triangles that are at oblique angles to the camera to minimize distortion. Without AF on textures on the far end of objects tend to look like mush.

Why would you ever have anisotropic filtering turned off? It has a minimal impact to performance but a major impact to visual quality.

The bulk of the changes are here and here. It looks like LL finally adopted my suggestion of using a finer grained class system, trying to fit 12 years worth of graphics cards into 4 classes just wasn't working anymore. Looks like they're also now doing some kind of automated performance analysis to rank GPUs, this should be a good thing in the long run but will probably have some bumps along the way. On the down side it looks like they removed some of the fancy regex I put in to work around the horribly mangled (or just varied) strings some drivers returned.

Osprey Therian wrote: One thing you might check is in Preferences>Graphics>Hardware. The default setting for Anistrophic Filtering [used to be and maybe still] is ON - which impacts fps for no good reason. Any GPU made in the last 7 years can do anisotropic filtering with no performance lose. And if you want to see what it does just make a 10x64 prim and put a checker board texture on it and stand on one end and look at the other while turning AF on and off.

Toysoldier Thor wrote: And that is the argument brought up here when someone said that the script in question IS a violation of Privacy. Its not a legal violation of privacy ... its just a violation of an old outdated and weak "pretend I am not here" privacy that LL put in the viewers long time ago but that every SL Resident has known for a long time how to bypass - with or without this new policy and breaking of the LSL script. All you have to do is ping an avatar via IM and depending on the respone, you know right away if the person is just hiding from you or really not logged in. It may not be a violation of privacy in the legal sense, but it is not old and outdated. Off the top of my head I could list 2 dozen current programs and services that have the exact same option that work at you'd expect. IMing people to see if they're online could be fixed in the same way so that's not much of a counter argument. No one arguing that LL should find a better and more fool proof method that allows a specific Avatar account to look as if they are not online when they actually are. They current idea is STUPID. Fixing this requires breaking scripts, there is no way around it. Not saying it's the right idea but we can't have our cake and eat it too.

I see a lot of people arguing about the merits of the UI in v1, v2 and v3, but honestly none of that matters. The fact is there are several known exploits against 1.23.5. There are many different ways to upload animations that will instantly crash 1.23. There is even a way to upload sounds that will instantly crash 1.23 and allow for arbitrary code execution. Yes, that's right, people can install malware on your computer just because you log into the grid with 1.23. I don't care if the UI in 1.23 is God's gift to mankind, that doesn't sound like the kind of viewer I want to be running. I also see a lot of people coming up with conspiracy theories about LL trying to force people to use v3. But you know what, LL kept 1.23 on the download page for almost 2 years after v2 was released. They gave you time to find an alternative but now your time is up.

In the thread I'm referring to I don't think I ever said they should by 2 $500 video cards either. I've never told people to buy $3000 gaming rigs, I've even tried to discourage people from getting such machines. I don't know where you got this idea from but it wasn't from my posts. To each their own indeed.

How should I respond when I don't agree with part of what you said? What should I do when I see you telling a guy with a 10 year old computer that wants to run sl on ultra that he should buy some ram and a video card for his old machine when I know full well that those upgrades won't get him anywhere near his goals. That such upgrades would just be a waste of money in my opinion.

Peggy Paperdoll wrote: What is better does not necessarily mean what is best on the market, It most of the time means what is best for a particular need. The "best" is certainly not necessary for SL.......you don't even need the best GPU to have great performance. We've had a similar discussion...........your "best of the best" has been noted. I disagree, as you know. Let's just let it stay at that. Okay? I think you've missunderstood me in this and other threads. Nowhere have I ever told people they need to buy high end hardware. I agree with you that SL doesn't need much. But in this case there is only one right answer. Bulldozer is a bad chip, it runs hot and performs worse than AMD's previous CPU yet cost the same as Intel's CPUs which out perform it by a wide margin. I would not recommend some one by a Bulldozer for any reason what so ever.

Preferences->Advanced

I quoted you post and cherry picked parts of it because the OP was specifically asking about the FX-8120 vs. i5-2500K.

Set the cache size to the max and lower the draw distance as much as you can stand.

Peggy Paperdoll wrote: Games (including SL which is not technically a game) do not put a lot of load on a CPU........it's all about graphics. Try running BF3 on an old dual core. Go with what you think you need. If cost is important, then AMD is probably the way to go. If you like Intel (as I do) than go with the i5. Both will perform way better than necessary for SL. The i5 is cheaper and noticeably faster at everything. That's all the OP needed to know.

Qwalyphi Korpov wrote: (BTW - I'm not sure it PC to say LL is slow) If LL moved any slower time would actually move backwards. With out a doubt, my biggest complaint about LL is the fact that it is impossible for them to get off their butts and actually do something.