Jump to content

Why I Don't Like PBR


You are about to reply to a thread that has been inactive for 87 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

37 minutes ago, arton Rotaru said:

Believe it or not, I never crashed with the official PBR viewer in the past 18 month. There has been done a lot to improve the performance compared to the v6 viewer. So it's not necessarily a given that performance will be worse. It can be even better for a lot of configurations.

Well, I can believe it, Arton, because I suspect you have rather better and more up-to-date hardware than I do. And quite possibly, than most SL residents do as well.

The "well, I've never had a problem and my FPS has never dropped below 60" thing is always a bit suspect -- as, in fairness, is the "I crash all the time using PBR" complaint . . . because there is a huge variation among residents in terms of hardware, internet access, use of the platform, etc.

I don't think that the alpha viewer is going to give me much grief, for instance, at clubs with a moderate number of people, but one of my main uses for the platform is taking high res pics (6000px or thereabouts) with graphics settings amped way up, and sometimes including depth of field (a frequent cause of crashes even on the older viewer). Now, I am NOT suggesting that FS and LL need to work to accommodate MY particular needs, but they should be, and I hope are, taking into account those with poorer quality machines.

37 minutes ago, arton Rotaru said:

Firestorm Devs (the few that are left) also cook only with water. They may well be struggeling to get their act together in a timely fashion rather than "doing everything right", which implies that the Lab would be doing everything wrong.

I don't think LL got every thing "wrong" by any means. The performance on their new viewer is decent (if not as good as on the pre-PBR one, at least for me). But there are things that need fixing -- editing PBR on objects in-world, for instance, and the glitches with reflection probes at higher altitudes. Oh, and EEP is kinda broken too. And water.

I don't know if FS can, or will, address such things (possibly not, as they may not be client-side issues?), but I hope someone, somewhere, is looking into them.

Edited by Scylla Rhiadra
  • Like 3
Link to comment
Share on other sites

15 minutes ago, Scylla Rhiadra said:

But there are things that need fixing -- editing PBR on objects in-world, for instance, and the glitches with reflection probes at higher altitudes. Oh, and EEP is kinda broken too. And water.

The glitches with probes above 64 meters should be resolved already in the LL RC build. Since that is now a couple of weeks old, FS most likely has included that fix already in their latest alpha.

It's unlikely that TPVs will address the rendering issues on their own. LL will work through them, though. Unlike TPV Devs, they get at least paid to do so.

  • Like 2
Link to comment
Share on other sites

2 minutes ago, arton Rotaru said:

It's unlikely that TPVs will address the rendering issues on their own. LL will work through them, though. Unlike TPV Devs, they get at least paid to do so.

I wonder if the Firestorm team regrets getting their alpha out to so many people already because I imagine they're fielding mostly jiras for Lab defects. (I've been testing with both and frankly haven't found a Firestorm-specific defect to report.)

  • Like 5
Link to comment
Share on other sites

4 minutes ago, Qie Niangao said:

I wonder if the Firestorm team regrets getting their alpha out to so many people already because I imagine they're fielding mostly jiras for Lab defects. (I've been testing with both and frankly haven't found a Firestorm-specific defect to report.)

Well, the level of knowledge in the FS "Preview Group" is certainly not very high. I'm listening, as we speak, to a discussion about whether or not you can turn off ALM in the viewer.

  • Like 2
Link to comment
Share on other sites

19 minutes ago, Qie Niangao said:

I wonder if the Firestorm team regrets getting their alpha out to so many people already because I imagine they're fielding mostly jiras for Lab defects. (I've been testing with both and frankly haven't found a Firestorm-specific defect to report.)

That may well be the case. They had some performance issues in previous builds that weren't present in the official build. But for those who were participating in the development of the LL viewer, anything below a nightly build is considered outdated, and not worth testing against.

That most TPV can't keep up with the pace of the Lab isn't a surprise, though. Henri is an exception. Henri is special, and so is his viewer. And I mean that in the most positive way.

Edited by arton Rotaru
  • Like 3
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

7 minutes ago, arton Rotaru said:

That may well be the case. They had some performance issues in previous builds that weren't presen't in the official build. But for those who were participating in the devlopment of the LL viewer, anything below a nightly build is considred outdated, and not worth testing against.

That most TPV can't keep up with the pace of the Lab isn't a surprise, though. Henri is an exception. Henri is special, and so is his viewer. And I mean that in the most positive way.

I would think it is because the Lab insists on leading the way and the TPV's have to follow and merge in crappy updates they know won't work out well. The SL viewer is also a very basic viewer and what few options they do allow came from a TPV dev to begin with. We'd probably be further ahead if the TPV dev's were allowed to have more input on the direction of the new features.

  • Like 2
Link to comment
Share on other sites

1 minute ago, Arielle Popstar said:

I would think it is because the Lab insists on leading the way and the TPV's have to follow and merge in crappy updates they know won't work out well. The SL viewer is also a very basic viewer and what few options they do allow came from a TPV dev to begin with. We'd probably be further ahead if the TPV dev's were allowed to have more input on the direction of the new features.

I'm afraid you're totally overestimating the capabilities of TPV Devs. Or let me phrase it the other way around.

I'm afraid you are totally underestimating the capabilities of the Linden Devs.

  • Like 2
  • Thanks 1
  • Haha 1
Link to comment
Share on other sites

2 minutes ago, arton Rotaru said:

I'm afraid you're totally overestimating the capabilities of TPV Devs. Or let me phrase it the other way around.

I'm afraid you are totally underestimating the capabilities of the Linden Devs.

I doubt it, I went to the TPV meetings for a few years and watched them in action.

  • Like 2
Link to comment
Share on other sites

On 1/3/2024 at 9:07 AM, Prokofy Neva said:

I always marvel at the way people align themselves with the powers-that-be in SL in ways they never would in RL.

This has been an entertaining thread. You're an extraordinarily talented troll.

Link to comment
Share on other sites

15 hours ago, Qie Niangao said:

The process of getting new access to the beta grid is pretty well known

Here on the forums anyway. Not so much amongst non creators in-world.

 

15 hours ago, Qie Niangao said:

if there's something interfering with folks getting word of new posts to the Featured News blog, we should probably let Strawberry know about it

"Dear Strawberry, FYI, most SecondLifer's do not make a regular habit of reading the news blogs, ever."

 

 

  • Like 2
Link to comment
Share on other sites

6 hours ago, arton Rotaru said:

I'm afraid you're totally overestimating the capabilities of TPV Devs. Or let me phrase it the other way around.

I'm afraid you are totally underestimating the capabilities of the Linden Devs.

Hmmm.

Who was it that invented "Fitted Mesh"? Was it LL dev or, users.?

Who pointed out to LL that their early Animesh test program, caused a 50% hit in FPS, told LL what was wrong with it, and how to fix it? Was it TPV devs?

One of the reasons why Catznip was so late rolling an EEP version was that Kitty spent a lot of time trying to FIX some of the problems, with EEP it's self, and with the bloody awful EEP UI.

FS regularly, in it's history has delayed putting in some LL merge, because it's got severe problems they don't want in their viewer until they find a way to mitigate them.

 

I remember seeing a post on one thread here on the forum, in which a poster casually mentioned a thing where if you had too many attachments on one point, sometimes during TP's, one of them would pop right off your avatar. Apparently this had been a known thing for years.

One of those LL devs you claim we're "underestimating" asked if this was some new thing as they had never heard of it, and was told NO, it's not new, it's been a problem longer than the NINE years you've been with the company.

 

THAT is part of the problem. Devs who basically do not use the main grid on a regular basis, they loiter on the beta grid in empty regions, and hurridly test things under conditions that do not match the live grid in anyway, announce that it works fine, then WE get to find out that it barely works at all under real load conditions.

 

Remember "200 avatar event regions", that got down graded to 175 avi regions, and were limited to 65 avis for the shop and hop, and which crashed and burned in last years "free heads" giveaway if they allowed more than 110 avis on the region.

 

I still remember the LL devs saying they didn't ACTUALLY test 200-av regions with 200 ACTUAL avatars, they "simulated that" on the beta grid and it "worked fine", but here in OUR world, it's NOT our imagination that they fail at 110 avatars. They also dropped the price from $900 a month for a 200-av region to $450 for a 175-av region that fails long before that target.

 

We're NOT underestimating, we're going by past experience.

 

Edited by Zalificent Corvinus
  • Like 1
Link to comment
Share on other sites

11 hours ago, Scylla Rhiadra said:

Well, the level of knowledge in the FS "Preview Group" is certainly not very high. I'm listening, as we speak, to a discussion about whether or not you can turn off ALM in the viewer.

This is why I like the Forum so much, just from reading posts I feel smarter!

Just imagine if everyone read more..

(OTOH, some things you read are so dumb they just make you sad. But so much of the PBR discussion is educational, once you sort out the nonsense and rants.)

Edited by Love Zhaoying
  • Like 1
Link to comment
Share on other sites

7 hours ago, Love Zhaoying said:

This is why I like the Forum so much, just from reading posts I feel smarter!

Just imagine if everyone read more..

(OTOH, some things you read are so dumb they just make you sad. But so much of the PBR discussion is educational, once you sort out the nonsense and rants.)

I've actually referred people to the PBR WOW thread in the FS group chat: it's full of great information, if you take the time to weed out the less-than-useful posts. I doubt that anyone has bothered to follow that up, though.

Link to comment
Share on other sites

On 1/4/2024 at 12:43 AM, Love Zhaoying said:

Ah, the good old days.

..When Bing stole search results from Google.

..When there was a FIlipino version of "Yahoo" called, "Yahay"

Yehey, not Yahay. :D

  • Thanks 1
Link to comment
Share on other sites

47 minutes ago, Conifer Dada said:

One of the fixes in the release notes was fixing ”massive performance loss”. Sadly, for me the update has made no difference.

This was due to NVIDIA driver viewer profile under Windows (see BUG-234706) that lacked the enabling of the OpenGL ”threaded optimizations” which can easily bring +50% in frame rates.

If you are not running the viewer under Windows, or do not have an NIVIDIA card, or already had its driver configured for system-wide threaded optimizations, then you won't see any difference in performances.

Edited by Henri Beauchamp
  • Thanks 5
Link to comment
Share on other sites

That explains it - my graphics card is Radeon.

I don't have too much of a problem with frame rate - although it's quite low it still gives smooth movement. The problem is more to do very slow rezzing of textures of environment and even slower rezzing of avatars. As I've said before, this is even the case when I reduce graphics setting to minimum.

Link to comment
Share on other sites

41 minutes ago, Conifer Dada said:

The problem is more to do very slow rezzing of textures of environment and even slower rezzing of avatars. As I've said before, this is even the case when I reduce graphics setting to minimum.

I explained why some people encounter this (PBR-unrelated) issue in this post.

  • Thanks 1
Link to comment
Share on other sites

24 minutes ago, Henri Beauchamp said:

I explained why some people encounter this (PBR-unrelated) issue in this post.

I re-read that post. 

I'm not against PBR, I want to see it work well on my computer. The slow rezzing of textures might not be caused by PBR directly, but the change to texture fetching was bundled in with the viewer. My computer is 5 years old and it was quite high-end when I got it and there has been no deterioration in its overall performance, only the problems with the PBR viewer. I have a fast broadband connection (578 Mb/s).

The only thing I can think of that might be suspect is the connection between computer and monitor, which I'll check again! 

Edited by Conifer Dada
Link to comment
Share on other sites

13 minutes ago, Conifer Dada said:

I have a fast broadband connection (578 Mb/s)

It's worth noting that in addition to what Henri said, you can have the best connection speed ever and still have SL slow to load.

In part, this is because the method SL uses to fetch assets (HTTP 1.1 Pipelining) is a long depreciated method of asset streaming which is known to cause a lot of problems at both the consumer level and ISP level. HTTP/2 Multiplexing solves this issue, but isn't enabled on SL's CDN (although, this should hopefully change this year).

This isn't a PBR issue (i.e. viewers 6.x and below encounter the same issue).

  • Thanks 1
Link to comment
Share on other sites

1 minute ago, Jenna Huntsman said:

This isn't a PBR issue (i.e. viewers 6.x and below encounter the same issue).

20 minutes ago, Conifer Dada said:

The slow rezzing of textures might not be caused by PBR directly, but the change to texture fetching was bundled in with the viewer.

Is there somewhere to read about the "change to texture fetching" that coincided with the PBR viewer? Or can we cast about for some other explanation for why your textures might load more slowly? Like… maybe the viewer installation reverted to some "recommended" setting or something? Or just that the viewer has a larger memory footprint (if it does, I have no idea)? Or something?

The reason I'm so curious about this is that I regularly experience very slow texture loading for weeks on end, starting long before PBR. And then it magically improves for a while, even in crowded settings. For a while I thought it recovered with each "clean" install, but that doesn't seem to be reliable, so now I just live with it until the next happy lightning strike. I'm just hoping to someday learn how to reliably reproduce that magic.

Link to comment
Share on other sites

1 minute ago, Jenna Huntsman said:

Henri's post covers that topic -

Oh, Conifer was mentioning that texture fetching, I misunderstood. Sorry; grasping at straws, I guess.

Still, something must account for Conifer's performance hit coinciding with the PBR viewer but not affecting frame-rate so much as rezzing time.

In theory, the outdated Pipelining asset streaming could hit PBR assets more if there are simply more of them to stream, but that wouldn't seem the situation (at least not yet).

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

18 minutes ago, Qie Niangao said:

In theory, the outdated Pipelining asset streaming could hit PBR assets more if there are simply more of them to stream, but that wouldn't seem the situation (at least not yet).

It's definitely a contributing factor.

In viewers with ALM disabled, the viewer would only need to fetch diffuse textures for objects. This is pretty much the bare minimum amount of assets needed to display the scene.

In viewers with ALM enabled, you effectively times that number by 3.

In the PBR viewer, ALM is always enabled (and cannot be disabled*), you times that number by 4 if the object is using a PBR material.

Pipelining suffers a lot proportionate to the amount of assets needing to be loaded as the assets must return in the order that they were requested. This means that if you're downloading an asset of 4MB, and then the rest of the assets in the scene are say 300KB, if that 4MB asset is taking a while to download or even gets stuck, the rest of the scene can't load until that download finishes.

Multiplexing fixes this issue as assets can return in any order (not just the order they were requested in), among a bunch of other issues - so this means that if that 4MB asset gets stuck, the rest of the 300KB assets can continue loading.

Edited by Jenna Huntsman
  • Thanks 1
  • Sad 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 87 days.

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
 Share

×
×
  • Create New...