BilliJo Aldrin Posted May 21, 2016 Share Posted May 21, 2016 ChinRey wrote: "Time is running out though because as soon as people get the impression that it's just another overhyped LL blunder - and they will the way it works today - they'll just deactivate it and then all the work will have been in vain." Too Late Link to comment Share on other sites More sharing options...
BilliJo Aldrin Posted May 21, 2016 Share Posted May 21, 2016 I guess i'm safe after all, i stripped nude, and with my flexi prim hair my total was about 72,000 yay me Link to comment Share on other sites More sharing options...
Torrie Mint Posted May 21, 2016 Share Posted May 21, 2016 Agress with everything BilliJo said. Link to comment Share on other sites More sharing options...
Nova Convair Posted May 21, 2016 Share Posted May 21, 2016 polysail wrote: Ahh!! Thank you!!! Seriously thank you! That clarifies what people were saying by a lot and contradicts my own personal experiences muuuuuuuch less. ( I've lagged entire sims with some of my script projects ) So ~ just so I make sure I get this straight. Script count, as long as they're not doing anything don't induce much lag on their own. But having a enormous mess of scripts does increase the statistical probability that some of the scripts that you are wearing might be taking up serious amounts of server resources? ( by manipulating prims etc )? I've always been taught that leaving listeners open induced tremendous amounts of sim lag. Hence why the 255 prim jewelry with a resizer script with an open listener in each one are so bad. I'm guessing that it ~ in some capacity place demands upon the sim? Or is that an age old myth? ( The programming wiki stresses turning them off when un-used ) If you have a sim full of stuff and avatars it will be full of scripts as well. You don't get one without the other. That means you can not blame something for the lag by observing. Makes no sense here since you have multiple factors playing all together. Scripts themselves will not lag the sim but thats possible in an indirect way. If you move around a few 100 objects with scripts the scripts have no effect on the sim performance. But the sim will update all viewers in range with the new positions of this objects. That will increase the network traffic and that has an effect. If the objects are scripted by using omega rotations and keyframed motions then it will have NO effect on the network traffic by the way. (data transmitted once, moves done by the viewer) So it depends on the scripter if this things cause lag or no lag. Listeners: I made tests a while ago. A sim with no avatars but me and a pile of objects with 1000 listeners. Has no visible effect of course. Now I trigger all 1000 at once - 1000 times. Hmmm not really a noticeable effect. The script performance goes down a bit. I repeat with 5000 scripts. I felt a great disturbance in the force - ummm ... I mean in the script execution of course Avatar movement and teleportation is not affected = no lag except ulra slow scripts. Takes a bit until the 5 million events are worked off then the sim is as good as new without restart. I stopped here before a Linden shows up and asks me what I'm doing. Is a while ago - I should repeat the performance test. Link to comment Share on other sites More sharing options...
Phil Deakins Posted May 21, 2016 Share Posted May 21, 2016 polysail wrote: So ~ just so I make sure I get this straight. Script count, as long as they're not doing anything don't induce much lag on their own. But having a enormous mess of scripts does increase the statistical probability that some of the scripts that you are wearing might be taking up serious amounts of server resources? ( by manipulating prims etc )? No, you haven't got it straight. There is a finite time in each frame for all scripts to do their bits. If they don't manage to do all their bits, they don't get them done. The time allowed for all scripts to be run per frame is capped. It's finite. That's why scripts can no longer lag a sim like they used to be able to do. I can't point you to any documents about it but the change was made public a few years ago, and we all knew about it. Scripts haven't been the culprits since then. Link to comment Share on other sites More sharing options...
Theresa Tennyson Posted May 21, 2016 Share Posted May 21, 2016 ChinRey wrote: Aethelwine wrote: Whilst their ARC formula seems so badly flawed, is it really going to be of any use? Well, they just have to fix it, and fix it fast. Oz, are you reading this? One very obvious flaw that has turned up, is that QuickGraphics isn't actually based on the actual ARC at all, it's based on the ARC aproximation built into the viewer. I did some quick tests and found differences as high as 50% between the vierwer's and the sim server's readings. That was quite a shock and of course completely unacceptable. Easy to fix, add the actual ARC formula to the viewer, or alternatviely use the server's data instead. But a bug as basic as that should never ever have survived all the way to an official release anyway and the fact that it did casts serious doubt on the quality of the project as a whole. Please provide evidence to show that the numbers from the "server" are accurate at all. Personally I doubt that the server calculates ARC - it's just not designed to do it. Take a sculpted prim, for instance. All the server knows is that it is a 3D primitive with a texture of a certain UUID on it. Determining the number of vertexes, etc. would be a waste of cycles that the server needs to calculate physics interactions, etc. The server should logically let the viewer figure that out. This suggests that the "server" numbers are actually those sent from the connected viewers. With earlier viewers I've noticed that with sculpt/flexi items the ARC displayed often varied quite a bit with the same item. Now that I'm running the current jellydoll viewer some numbers seem different than before but are quite consistent, and higher than I remember before from the same items. This suggests that the current viewer calculates ARC differently than previous viewers. The numbers reported by the server are from a wide variety of viewers. I suspect that it's actually the current viewer figures that are accurate and the server numbers that are inaccurate. Link to comment Share on other sites More sharing options...
Drake1 Nightfire Posted May 21, 2016 Share Posted May 21, 2016 BilliJo Aldrin wrote: I guess i'm safe after all, i stripped nude, and with my flexi prim hair my total was about 72,000 yay me Pics or we don't believe you... Link to comment Share on other sites More sharing options...
Phil Deakins Posted May 21, 2016 Share Posted May 21, 2016 Seconded. Of course, we can't take just one person's word for it, so we need more people to see and provide evidence. It will be a bit of a chore but I volunteer to step up and see. So Billijo, pics to me as well please. Link to comment Share on other sites More sharing options...
ChinRey Posted May 21, 2016 Share Posted May 21, 2016 Theresa Tennyson wrote: Please provide evidence to show that the numbers from the "server" are accurate at all. Wow! I may often disagree with LL's decisions but even so, I do actually belive they are honest and that when they do things like updating the llGetObejctDetails() function to include render weight, they make sure they get it right. This is the kind of things they know everything about. But if you want irrefutable evidence, you'll have to ask some Linden. Only they have access to the source code for the server software. We do have access to the viewer source code though. Drongle McMahon took a look at it for me once and here's what he found out: https://community.secondlife.com/t5/Mesh/Render-weight-weirdness/m-p/2919984#M31169 Theresa Tennyson wrote: Determining the number of vertexes, etc. would be a waste of cycles that the server needs to calculate physics interactions, etc. The server should logically let the viewer figure that out. This suggests that the "server" numbers are actually those sent from the connected viewers. The server reading is not the same as you get from any viewer. As I mentioned in an earlier psot, I've seen differences as high as 50%. And yes, it is considerably slower to update. The viewer's figures are updated almost instantly while the server's can sometimes take almost a minute. Link to comment Share on other sites More sharing options...
Theresa Tennyson Posted May 21, 2016 Share Posted May 21, 2016 ChinRey wrote: Theresa Tennyson wrote: Please provide evidence to show that the numbers from the "server" are accurate at all. Wow! I may often disagree with LL's decisions but even so, I do actually belive they are honest and that when they do things like updating the llGetObejctDetails() function to include render weight, they make sure they get it right. This is the kind of things they know everything about. But if you want irrefutable evidence, you'll have to ask some Linden. Only they have access to the source code for the server software. But apparently you also believe when the same Lindens issue a new viewer specifically engineered to work with avatar rendering and muting, they get it "wrong". There have been a number of tweaks to how the latest viewer calculates avatar rendering cost in the new viewer in the run-up to its release, so it may well return different numbers. Servers are limited in what they know about the "world", particularly on the graphic end. One bone of contention for years is that if you poll the servers to tell what height an avatar is, it will give you a number that doesn't match the actual dimension of your avatar from the top of its head to the bottom of its feet. This is because the only information on this that it can put its little electronic fingers on quickly is the avatar bounding box dimension, which stops at about eye level, and it can't be jazzed to process slider information to get the actual avatar mesh dimension. ETA - Looky here, where the Wiki mentions that llGetObjectDetails returns numbers "based on values reported by nearby viewers." It may poll a number of viewers and average the number so that a malicious viewer couldn't claim that a graphics crasher is Super Innocent and Small. Note that this entry was written and only edited by Maestro Linden. http://wiki.secondlife.com/wiki/OBJECT_RENDER_WEIGHT Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 21, 2016 Share Posted May 21, 2016 polysail wrote: I've always been taught that leaving listeners open induced tremendous amounts of sim lag. Hence why the 255 prim jewelry with a resizer script with an open listener in each one are so bad. I'm guessing that it ~ in some capacity place demands upon the sim? Or is that an age old myth? ( The programming wiki stresses turning them off when un-used ) It depends... A listener on it's own doesn't cause much lag (though, each frame, the simulator has to check to see if anything's been said on the channel the script is listening to, which takes some time). If the script is listening on a channel that nothing else is using, or is likely to use, then that's not a big deal. If, however, it's listening on a busy channel, then the simulator has to decide whether the object containing it is close enough to hear the message and then, if it is, if it passes the filters in the listener. Then, if the simulator decides it needs to send the message to the script, there's some more script activity while the script decides what, if anything, it should do about the message. So an open listener on channel -94244985 isn't going to be much of a drain on the simulator's resources, while an open listener on 0, the general chat channel, will cause activity every time anyone on the region says anything (which, I am sure, is one reason some Gor regions have problems with lag -- there are so many listeners on channel 0 running in people's collars and weapons). See the Notes section in the wiki entry on llListen() for further details and a link to Kelly Linden's explanation of how listen events work. This is not to say people shouldn't use open listeners on 0 when they have to (e.g. some vehicles) but that they should avoid using them unnecessarily. But if you're listening on a channel you can be pretty sure will be used only for messages you want to hear, then sometimes it's more trouble than it's worth to keep turning listeners on and off. Link to comment Share on other sites More sharing options...
ChinRey Posted May 21, 2016 Share Posted May 21, 2016 Theresa Tennyson wrote: ETA - Looky here, where the Wiki mentions that llGetObjectDetails returns numbers "based on values reported by nearby viewers." Really interesting, LL can't have overlooked something as obvious as this, can they??? As I said, I can't give any irrefutable evidence but a quick reality check is easy enough to do. Here I am all alone in a sandbox. According to my viewer, my ARC is 81718. The gadget in front of me uses llGetObjectDetails to read it as 59616. Where did it get that number from? Definitely not from my viewer. The nearest other avatar is more than 300 m away and in a different sim. I find it very hard to believe his/her veiwer played any part. A far more likely explanation is that the server software has been updated since Maestro Linden wrote that documentation. However I redid the test at home on my own work platform. This time my ARC was 72501 according to the server: This time there was another avatar in the sim but she was down on the ground, 2300 m away from me, not exactly what you'd usually call "nearby". The sandbox I used is on a regular SL sim, my workshop on Blue Steel. I don't know if that makes any difference. This test doesn't prove it but it's definitely a strong indication that the servers no longer get render weight data from viewers. Unfortunately, what it does prove beyond any doubt is that whatever method they use now is no more reliable than the viewers, it may actually be even worse. I think I should mention another test I did - or rather happened across - too. Yesterday I tried to wear nothing but a full body alpha from the Library folder. With a compeltely invisible avatar my viewer gave my ARC to 1000, which is what the formula would have given too. Today I tried again with a full body alpha I made myself for my Jellybean Avatar. This time the viewer gave my ARC as 0. I haven't noticed any viewer updates inbetween so apparently this means if you wear a full body alpha (as you would if you use both a mesh head and a mesh body) you may or may not get a 1000 point ARC bonus/penalty depedning on random whims of the viewer. Theresa Tennyson wrote: There have been a number of tweaks to how the latest viewer calculates avatar rendering cost in the new viewer in the run-up to its release, so it may well return different numbers. I rechecked the items from last years thread. Same result today as then. I also took a look at other pairs of items that should have the same render cost according to the formula. They often gave very different readouts. So no, it doesn't look as if that flaw has been fixed. The inevitable conclusion is: The render cost data that we can see and that are used as the basis for QuickGraphics is nothing but rough, semirandom guesstimates loosely based on an outdated formula that doesn't look very convincing in the first place. And I still believe QuickGraphics has value. We need a way to regulate avatar render load and it's the only thing we've got! But Linden Lab, you're testing my faith now. This is shoddy work, really, really shoddy work. As a teacher I'd give you an A for intitiative and idea but an F for performance. Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted May 21, 2016 Share Posted May 21, 2016 ChinRey wrote: I think I should mention another test I did - or rather happened across - too. Yesterday I tried to wear nothing but a full body alpha from the Library folder. With a compeltely invisible avatar my viewer gave my ARC to 1000, which is what the formula would have given too. Today I tried again with a full body alpha I made myself for my Jellybean Avatar. This time the viewer gave my ARC as 0. I haven't noticed any viewer updates inbetween so apparently this means if you wear a full body alpha (as you would if you use both a mesh head and a mesh body) you may or may not get a 1000 point ARC bonus/penalty depedning on random whims of the viewer. It depends on how the alpha layer is created. A naked avatar wearing a full body alpha created by ticking all the tick boxes for each texture thumbnail with have a complexity reading of Zero. If the alpha layer uses a transparent texture for each texture, the avatar will have a complexity reading of 1000. Link to comment Share on other sites More sharing options...
ChinRey Posted May 21, 2016 Share Posted May 21, 2016 Whirly Fizzle wrote: It depends on how the alpha layer is created. A naked avatar wearing a full body alpha created by ticking all the tick boxes for each texture thumbnail with have a complexity reading of Zero. If the alpha layer uses a transparent texture for each texture, the avatar will have a complexity reading of 1000. Thank, Whirly. That explains what happens in that particular example then. Have the people who make outfits that need alpha layers been told? And does the difference have any effect on the actual render load? A 1000 ARC points difference is often more than enough to determine whether an avatar is rendered in full or as a Jellybaby. Link to comment Share on other sites More sharing options...
Pussycat Catnap Posted May 21, 2016 Share Posted May 21, 2016 polysail wrote: It's a cumulative effect. The 80K limit is the default. If you personally feel your hardware is capable of handling more than that, then that's why the slider exists. You can increase it. It's true that ARC cost de-rendering hits non-human AV's particularly hard Well... My furry avatar comes in at under 10,000. Maybe 6,000. My Neko look is about 30,000, give or take. My current forum profile image, of me in a red beret - is one of my most laggy outfits. It rates about 60,000. Well done mesh is VERY FORGIVING on Arc. Mesh STOLEN from other video games though, has a tendancy to rate very poorly... And Sculpty is a technology best not used. LLs ought to retire it and make all sculpties render as plain prims - but they really don't like obsoleting old things. This Jelly Solution is the perfect way to encourage the residents to do it themselves. Basically you can ignore the Jelly thing, dial up your complexity limit... and then go get in line at the local computer store to buy a new computer after your graphics card fries... Or you can accept the deault, and get yourself under it, and get your friends to get under it, and not have to go buy a $3000 gaming rig. Choices. Make one. polysail wrote: I know Black Dragon has already adopted the Jelly based auto-derendering thing. I imagine Firestorm will~ with a modification here or there soon enough as well. I can't speak to their actual release schedule, but I imagine you'll be seeing this in most major viewers ( Firestorm included ) by the middle of June or early July. Possibly even earlier than that! It is already in Firestorm and all other viewers, in the debug settings, and can easily be added to quick preferences: https://catnapkitty.wordpress.com/2016/05/14/firestorm-use-quick-prefs-to-set-up-lag-blocking-of-graphics-heavy-avatars/ But it has yet to make it to the default preferences / graphics preferences window. Conifer Dada wrote: I think the jelly babies are great! I've set my limit at 150,00, so there's usually a few at any busy club I visit. It certainly seems to reduce lag. What I wonder is how to get the message across to people that if they load their avs with too much stuff, some of the people they're trying to impress will see them as jelly babies! The viewer itself will tell them things like: "19 of the 19 people in range of you cannot see you." And then they will just have to sit there alone in their own amazingness... while the rest of us don't have to buy new graphics cards anymore. Whirly Fizzle wrote: It depends on how the alpha layer is created. A naked avatar wearing a full body alpha created by ticking all the tick boxes for each texture thumbnail with have a complexity reading of Zero. If the alpha layer uses a transparent texture for each texture, the avatar will have a complexity reading of 1000. If you have 1000 and are invisible. Log out and back in, and it will be 0. Link to comment Share on other sites More sharing options...
Whirly Fizzle Posted May 21, 2016 Share Posted May 21, 2016 Pussycat Catnap wrote: If you have 1000 and are invisible. Log out and back in, and it will be 0. Hmm that doesn't reproduce for me, still 1000 after a relog on Second Life 4.0.5.315117 (Second Life Release), wearing a full body alpha using the default transparent texture for all sections. Link to comment Share on other sites More sharing options...
wherorangi Posted May 22, 2016 Share Posted May 22, 2016 here is me nekkid and just wearing my flexiprim hair. And wearing my most see-thru outfit. And only 75k complexity (: Link to comment Share on other sites More sharing options...
ChinRey Posted May 22, 2016 Share Posted May 22, 2016 wherorangi wrote: here is me nekkid and just wearing my flexiprim hair. And wearing my most see-thru outfit. And only 75k complexity I had to try that myself. So one more reality check: + Standing on a blank sky platform above an empty sandbox wearing nothing but a full body alpha: ARC: 0 Client fps: 84 + Adding an old flexi hair: ARC: 75801 Client fps: 76 + Removing hair, adding a well known fitted mesh body (just the body, no hands or feet or head): ARC: 5162 Client fps: 73 Link to comment Share on other sites More sharing options...
wherorangi Posted May 22, 2016 Share Posted May 22, 2016 yes. Is my experience so far as well while the complexity rating for old school prims can easy put you over the complexity redline, in actual terms (FPS) then prims and flexiprims are still pretty efficient to render so if anybody reading who does wear oldschool then dont fret about the redlining over your head. And if run into a arcanazi inworld who goes mental at you then tell them to basically bite themself, bc they dont know what they are talking about Link to comment Share on other sites More sharing options...
ChinRey Posted May 22, 2016 Share Posted May 22, 2016 Oh well. Right now QuickGraphics seems to be dead in the water. Not even good for target practice. Shooting it to smithereens is just way to easy to be an itneresting challenge. Almost 15 times the ARC and lower actual lag. You might as well just derender avatars at random. But we need more data. This is all from one computer and it may be some sort of special case. And we need to hear what LL has to say to their defense. So let's hold the fire until Monday, Ok? Link to comment Share on other sites More sharing options...
wherorangi Posted May 22, 2016 Share Posted May 22, 2016 i just post this one as well this is me blinged out with mesh clothes, sculpt and mesh accessories, flex hair and tail. Jumping round I am. 187,709 complexity I am running 660GTX. Max graphics everything except shadows off. My monitor is a 1920x1080 locked at 60hz (60 frames per second max.) The pic is taken with the viewer screen maximised Link to comment Share on other sites More sharing options...
Innula Zenovka Posted May 22, 2016 Share Posted May 22, 2016 That tells us about what's happening client-side but -- though I may be wrong -- I think that's only half the story. The simulator has to deliver all the information about your avatar to other avatars (I'm not sure what the criteria are for deciding who on the region and on child regions gets the data -- common sense would say it's people within draw distance but I'm told that experiments with the debug console suggest you get sent textures, at least, from new arrivals at ground level even if you're in a skybox 3000 metres up), at the same time it's sending all their data to everyone else who needs to receive it. The load on the simulator has to be a potential pinch-point, I'd have thought. I would be interested to see what the fps figures look like if there are 20 or 30 people close to you, all similarly blinged out, as you put it, and jumping around. Link to comment Share on other sites More sharing options...
arton Rotaru Posted May 22, 2016 Share Posted May 22, 2016 Innula Zenovka wrote: I would be interested to see what the fps figures look like if there are 20 or 30 people close to you, all similarly blinged out, as you put it, and jumping around. I was also wondering what that screenshot should tell us? Link to comment Share on other sites More sharing options...
ChinRey Posted May 22, 2016 Share Posted May 22, 2016 Innula Zenovka wrote: That tells us about what's happening client-side but -- though I may be wrong -- I think that's only half the story. Not really. Render weight is all about the load on the client's gpu. Server and connection load are covered by the other three weights, server, physics and download weight. Innula Zenovka wrote: The load on the simulator has to be a potential pinch-point, I'd have thought. Throughout all these tests sim fps remained at a fairly steady 45, never more than 0.2 or 0.3 from that. That's not surprising. A sim server will have to be seriously overloaded before its fps starts to drop. Just as a quick check, I went to a sim with 60 avatars and a not particularly low lag environment. Even there sim fps stayed well into the 40s most of the time with only occasional drops down into the high 30s. It is important to note that most of my "reality checks" were done in very low lag environments. I had to do that to eliminate as many uncontrolable variables as possible and the point was always to illustrate the difference between the various figures, not their absolute values. Innula Zenovka wrote: I would be interested to see what the fps figures look like if there are 20 or 30 people close to you, all similarly blinged out, as you put it, and jumping around. Oh yes. I do think my informal demonstrations are enugh to conclude something is wrong with the way render complexity is calcualted and thus the way QuickGraphics works. The deviations are simply too big and to consistent to be written off as flukes or special cases. They don't even begin to explain what is wrong though, we need much more thorough testing to figure that out. But that is something that should be done by the people who are actually paid to do it. You can't expect volunteers to take on a task of that size, even my quick little reality checks stole far too much time. Innula Zenovka wrote: ...but I'm told that experiments with the debug console suggest you get sent textures, at least, from new arrivals at ground level even if you're in a skybox 3000 metres up That isn't really directly conencted to render cost but yes, I've tried that and it's actually just the start. A slightly easier way to test whish textures are actually downlaoded is clear your cache, log on and see what turns up in your cache folder: Every single texture, sculpt map, normal map and specular map found anywhere in the sim, at least most textures etc. found anywhere in the neighbor sims, the profile pics of everybody on your friends list, every group you're a member of and everybody logged on to a group chat you're in, lots of skin and clothes textures that haven't actually been used by a viewer since SSB rolled out in 2013, clothes and skin textures and profile pics for people you can't for your life understand where they come from, all the graphics used by the viewer interface.... the list goes on and on and on. Link to comment Share on other sites More sharing options...
wherorangi Posted May 23, 2016 Share Posted May 23, 2016 by jumping I mean I am playing scripted dance animations which can be seen in the variance of FPS on the gfx card. The FPS range is about 50 to 80 average 58.4. The variance is wide due to: a) occlusion (more or less) triangles in the view as avatar turns and moves, and b) the work the main processor (i7 in my case) has to do to prep the data for the 660, and c) the time taken to transmit data over the internal bus, and retrieve data from memory and/or from cache seems to me that while mesh objects can contain less triangles than oldschool prims, it takes longer for the main processor to prep the data than it does for prims, due to the organic shape of mesh clothing (more math calculations) seems to me also that in the metric calculation there is a understatement toward mesh and away from prims, meaning that I am not sure that the work that the main processor has to do (in a type vs type comparison) has been factored in as well as it might be adding more avatars to the view doesnt change the basics of this. There's just more data of each type to manage and render + is what I mean when I said earlier that if we do wear oldschool prims then don't overly fret about it too much when the color of the default metric over our head is not green the metric is just a guide to what the software estimates the load to be on our rigs/computers, and we can adjust the metric coloring by moving the slider up or down, tuning it ourselves to suit as we go (presets and that). In the pic I moved the slider to the max 350,000 and now is green if another person sees me inworld as a jellybaby (or even completely derendered) then I am ok with that, if this helps them to have a SL conversely tho I am not going to not wear what I want to have a SL myself. For sure when choosing stuff to buy/wear going forward, then I will be mindful of the overall metrics. However if I like it and I want it and it can run ok on my rig, and there is no similar alternative available, then I am going to get and wear it when I do use the metrics then I will compare stuff against each other by type. Mesh vs mesh. Prims vs prims. And not use the metrics (as wrote) to compare mesh to prims in terms of performance on my screen + about FPS from our pov as users is all pretty much about the FPS (once all the data relevant to us has been downloaded from the servers, and when our network connection is running stable) in my case FPS above 60 is a waste of electricity as my monitor only runs at 60hz (60 FPS) so is zero benefit for my gfx card to be outputting higher than this lower than 24FPS (below TV rates) then things become overly noticecable to my eyes. So while it stays between 24 and 60 then I am good NVidia has a goal for the new 10 series card to have all the top selling game titles running at least 45FPS, and NVidia do a lot of work on their drivers to assist with this. Not all of the games do yet, even on the 10 series (nevermind the earliers) despite what some gamers say when they are comparing SL to these other games So I think the LL devs have done a pretty good with SL rendering overall, given the extremes of users having a go at creating content vs game titles that exclusive use professional content + the whole idea of this project is to allow people with lower spec rigs to actually have a SL and I am ok with that and I only have a 660 so is not like I am a high spec user myself. I just try to get max performance out of what I do have and is all good Link to comment Share on other sites More sharing options...
Facebook
Instagram
Twitter
YouTube
Flickr
Recommended Posts
Please take a moment to consider if this thread is worth bumping.
Please sign in to comment
You will be able to leave a comment after signing in
Sign In Now