.jpeg.be6345390d044cf9d706b56748add11c.jpeg)
Beq Janus
-
Posts
640 -
Joined
-
Last visited
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Beq Janus
-
-
2 minutes ago, Henri Beauchamp said:
This would avoid having to send messages to the server (to remove the PBR material then reinstate it after editing), and risk a loss in the transmitted parameters due to race conditions or bad network...
I meant removing it locally by sidestepping the PBR rendering, the job is on my TODO list and I've not looked at it yet, so I will almost certainly explore your suggested route as that is basically and existing version of what I was going to reinvent 🙂 thanks for the heads-up Henri, appreciated as always.
-
1
-
-
2 minutes ago, Extrude Ragu said:
To be honest I think the whole out of band viewers using Albedo as a fall back is really paving the path to hell with good intentions.
A short quote, but a reply that I think applies to the entire post from @Extrude Ragu. I am in general agreement. Albedo is not a valid fallback texture. The right solution is to provide the ability for creators to give a fallback texture to an item (I originally proposed that this be a feature such that even with full PBR support we can display a fall back texture in lieu of the grey mush while the other maps are being pulled down and the PBR materials assembled).
The proposal to "auto fallback" using the albedo does not, to my mind, move things forward; the "non PBR" users then start to ask for diffuse and the creators bow to the pressure and bake shadows into the albedo, thus polluting the PBR for everyone else. this is the kind of mistake that was made before. By promoting "ALM off" as a first-class preference, it enabled users to turn off all the good features far too easily (when in reality, much of the time they really only needed to kill the shadows), this in turn lead to a high proportion of users complaining that they could not see normal maps and materials in general, which in turn led to the baking of light into the diffuse more than was necessary (a diffuse should only really have ambient occlusion baked in). More than this it led to the appalling habit of modelling all the fine details instead of using a normal map because "if I don't model them, half my customers can't see them", which is, of course, the bane of performance issues, leading to heavy choke points in the CPU and GPU and massively inflated overdraw behaviour....
<rant time>
I was at an event yesterday (Warehouse Sale) where I had gone to specifically look at a gorgeous-looking steampunk-esque hat with flowers on it. A nice spring-time addition to my wardrobe. When I got there and found the item I zoomed in and the display vanished... This is a known issue when the render pipeline buffers "overflow" due to heavy vertex load. It was clear that the display panel was not at fault, it was simply the victim. I looked at the hat and found that it was well over 500,000 triangles. Needless to say, the hat will not be joining my wardrobe.
https://gyazo.com/dcf92bdca3584c5d88e219cd1ecdab3f
It is not an isolated example they are coming thick and fast and I fear that PBR is making it worse in the sense that irresponsible or ill-informed creators can produce beautifully detailed, stunning creations in an external tool, press a few buttons and import it into SL with no consequences to them, the pain becomes everyone else's. I had another case reported today where a "secondary" creator, one who does not create mesh themselves but who purchases template mesh full perm and decorates it had bought some meshes that were so complex that even in wireframe, you thought they were solid. They've paid good money for a product that is frankly not fit for purpose, from a so-called "reputable and well-known" creator.
</rant time>
Despite years of requests, there remains no good way for a non-technical user to determine whether an asset is well made and efficient; complexity is a broken misleading value that people still insist on citing, and of course, LI has no place for rigged mesh (even assuming LI was appropriate)
-
2
-
1
-
-
7 hours ago, Henri Beauchamp said:
Since this is a Firestorm thread, and Firestorm got such a huge impact in SL given it's enormous user base, let me here beg for FS devels to do what I just did in my own viewer: remove all the limits to edit legacy material and diffuse maps when a PBR material is already set on a face from the viewer code !
This is already a work in progress. The UI aspects were being tested before Xmas, but you also need to have the ability to see the item in "legacy render" to make it a sensible feature. We have made it clear that we will not be opening up a long-term "ALM off" type feature because of the burden it places on creators and, ultimately a cost to us all. We plan to have it remove the item being edited from PBR while editing the Blinn-Phong (did I ever mention how I hate how technobabble has polluted the build tools) so that the creator can see what the fallback looks like.
Last I heard the new SL mobile client had no support for PBR, is that still the case? If so the attitude of "everyone can see PBR" seems rather misplaced. I may well be out of date on the mobile viewer status though.
-
4
-
-
7 hours ago, Monty Linden said:
Are the timeouts consistently to the login endpoint host (login.agni.lindenlab.com)? Worst-case metrics look good there so it's either stuck in front of the service or some *really* unhealthy instances.
For me, it is always on the login. I am not necessarily the best canary for this mine, though, as my online time is frequently spent in one place while I code.
I just spent a while hopping about places. A mixture of busy venues, script-heavy shopping regions and numerous texture and asset-heavy scenic places, no issues at all.
-
1
-
-
Today, I have had repeated failures. Sometimes 2 or 3 attempts are enough; other times it might take 5 or more. Keep banging on the door, and it will eventually open.
@Monty Linden these are not DNS lookup failures but timeouts in the curl request.
2023-12-19T00:38:42Z WARNING #CoreHttp# llcorehttp/_httppolicy.cpp(403) LLCore::HttpPolicy::stageAfterCompletion : HTTP request 000001EEF4197E40 failed after 0 retries. Reason: Timeout was reached (Easy_28) 2023-12-19T00:38:42Z WARNING # newview/llxmlrpctransaction.cpp(266) LLXMLRPCTransaction::Handler::onCompleted : LLXMLRPCTransaction error 0000001c: Timeout was reached 2023-12-19T00:38:42Z WARNING # newview/llxmlrpctransaction.cpp(268) LLXMLRPCTransaction::Handler::onCompleted : LLXMLRPCTransaction request URI: https://login.agni.lindenlab.com/cgi-bin/login.cgi 2023-12-19T00:38:42Z INFO #LLXMLRPCListener# newview/llxmlrpclistener.cpp(344) Poller::poll : login_to_simulator result from https://login.agni.lindenlab.com/cgi-bin/login.cgi: status CURLError, errorcode OPERATION_TIMEDOUT (Despite our best efforts, something unexpected has gone wrong.Could we have an unresponsive login instance in a load balancer or somesuch?
This has been dragging on for a while suggesting it is something more than transient network issues. Notably, I am seeing no issues with any other connectivity outside of SL.
A DNS lookup resolves as follows:
Name: a403.b.akamai.net Addresses: 62.253.3.195 62.253.3.240 Aliases: login.agni.lindenlab.com login.agni.lindenlab.com.edgesuite.net-
1
-
-
@Monty Linden I've been asking people in FS Support to send me LMs for a while it appeared to be exclusively RC, but on such a small data set that was inconclusive and I 've just had 3 contrary indications. So no pattern so far.
Meanwhile, I am not seeing the issues.
Other symptoms reported by those with issues are slow responses when accessing profile data, and when opening an object, very slow retrieval of contents.
-
1
-
-
I've had muiltiple other confirmations that this is not just "the new FS" (you have no idea how much that relieves me).
As @Monty Linden suggested, please reach out to LL support by raising a ticket https://lindenlab.freshdesk.com/support/home
-
1
-
-
Can you confirm the region you are trying to login to please.
5 minutes ago, Karsheur said:Hi Beq , its the same Problem on the SL viewer than FS :
-
3 hours ago, Aishagain said:
OK this is odd. I got in with absolutely no issues. I'm running FS 6.6.17 70368, which is the latest release,but it was an RC when I d/l'd it. I wonder if the login bug-fix mentioned in the notes is the cure? Or am I somehow special?
ETA at 7:54 SLT: several TPs later I'm still OK.
You are always special @Aishagain😉
However, it is unlikely, the login bugfix is the cure, as it was very obscure and triggered if the user had previously logged out with the ctrl-shift-1 statistics bar open. Moreover, people are seemingly seeing this on other versions and other viewers. Never say never though, which is why I need people affected to try on other viewers and other locations.
-
1
-
-
If you are having issues with login (esp if you are on the new Firestorm 6.6.17) please download the latest LL viewer and try that for a while. There is no obvious reason why the FS update should cause problems, so we need to understand if it is isolated to the viewer.
-
This is an interesting conversation.
When I first encountered a relay in a group chat I was surprised and a little disconcerted at not realising there were people outside of the room listening in, but I was also rather impressed at how well it worked and at a purely technical level, enabling an extension of SL presence to Discord makes a lot of sense.
Technical kudos and support convenience aside, this is almost certainly a TOS violation, as mentioned by many already, the fact that your chat is being echoed into a public forum that you may well have no access to, that you have not signed up to and that you may not even be able to trace is a breach of trust and is clearly not allowed. Someone (the OP perhaps) mentioned that a local chat relay, broadcasts when you first say something, this does not happen in the groups that I know are relayed, nor would it change the facts of the issue. Being told is not the same as being asked and getting your permission.
Personally, I have no problem whatsoever with many groups to which I belong (such as BB, whom I have nothing but the highest regard for) using a chat extender to mirror my chat between Discord/Slack/whatever and SL (and to be clear, if the option to opt-in to that was available for those groups I would enable it); however, I almost certainly do have an issue with some other groups that I am part of doing the same as I consider my membership of those groups less public (and by the same measure would choose to opt-out or leave those groups were I made aware/given the choice). The fact that I have no control or visibility of this is troubling.
Of course, anyone can do this at any time, if someone wants to copy/paste chunks of what I am saying into another forum then they will TOS or no TOS and as such I should be careful of what I say and do, we all have a responsibility in this regard, but as @Henri Beauchamp pointed out, there is a difference between having a rumour of a conversation overheard in a pub, where the audience was limited, and a full recording of that same conversation taken without permission and echoed to the masses. When we chat in a group we have an "expectation of privacy" and assess the risk of that privacy being broken based upon those present etc. Once we accept that actually any group may be extended to an unknown/unseen audience we have given up any illusion of privacy.
The big issue here is not so much the siphoning of chat to another service, but the fact that we are not being given any warning or opt-out. There are clearly big gains in terms of customer support from using a rich communication platform such as Discord, it would be useful (as is demonstrated by the mostly well-intentioned and increasingly widespread use of relays) to have proper tools to deal with bots and relays inside a group chat.
-
2
-
4
-
-
TL;DR: Firestorm should remain unaffected. Due to our three-release policy, when Win7 no longer installs the latest FS, you will have two prior releases available that will continue to work, allowing you time to choose how you resolve this.
With regards to Firestorm. Our position re:Win 7 is the same as the lab's and the same rule we apply to other aspects such as 32-bit, Linux distribution and Mac version. Unsupported platforms work by chance alone, and no action is taken to fix them when that luck runs out. We will not kill Win7 support deliberately; it might well fail at any point due to a build dependency or other change that we make, and when that happens, we will choose not to resuscitate the patient.
Now, with the specific case here, I cannot test this to be certain, but Firestorm should remain unaffected for the end user for now.
Firestorm has been built using GitHub Actions for over a year now. As with the LL builds that have newly migrated to GitHub, this enforces a higher degree of security and support awareness as GitHub retire older OS build machines (know as runners) on a well-defined basis. For example, this has seen a recent update of our Mac builds from 10.X to 11 and our Linux builds from Ubuntu LTS 18 to 20. We have been building on Windows 11 (essentially, Windows Server 2022) for a while now. In our build system, we are using (and have been using) Python 3.11 for a few releases, and given that you are only now seeing this issue, that adds a little weight to my belief that we are, for now, unaffected.
The bottom line is that Firestorm does not require Python to be installed on the end user's machine, as we do not use the LL mechanism to manage the viewer updates. FS allows you to update manually and provides three supported versions; when we do reach a point (probably sooner rather than later) where Win7 can no longer support the viewer, then those users will, in theory, have a period of up to 3 viewer releases during which they can choose how to address the issue. This should be ample time for most. I cannot, of course, guarantee this. It is always possible that a problem occurs, such as a security flaw which requires us to block all older viewers. There is no precedent for it that I know of, though.
As an aside, if and when FS does not work, you might still find that some other TPVs, those that are based on the older viewer 1.X heritage such as @Henri Beauchamp's CoolVl Viewer would still work for you. My expectation is that (in the same way as 32-bit is affected) the death of Win7 will not be due directly to the Viewer itself but a requirement of one of the libraries that we depend upon.
For those interested: The supported Github runners are always found here. These dictate the platforms we can build on, but not necessarily what you can run on.
-
4
-
4
-
-
Keep in mind that complexity is at best a guide and rarely an accurate measure of actual render cost. There are many many items that are perfectly normal, have little impact on your frame rate and yet have a "high" complexity, the number is very poor predictor these days, it was never very good and many too things have changed since it was first defined. Compare that to your typical rigged mesh hair which will frequently show low complexity but can easily be the slowest rendering part. People who insist on jelly dolling at anything under 200K are probably punishing the wrong people a lot of the time. The sooner LL discontinue/fix this crappy misleading number the better we will all be.
-
3
-
6
-
-
It's a known issue with the latest viewer. It is on my todo list. https://jira.firestormviewer.org/browse/FIRE-33157
-
1
-
-
On 9/28/2023 at 5:45 PM, Aishagain said:
@Beq Janus do you understand what is reported above?
I understand only in the sense that it is a problem that some people get; there's not always a simple answer as all of us have different hardware and network setups, and so it is very hard to do more than give a list of steps to follow and hope that the affected person is able to follow them well enough to resolve their issue.
The people best equipped for this in general are the wonderful people on our support teams. They deal with more varieties of these types of issues than any other group in SL and are almost certainly the best place to ask. ( @Toshi Exodus you can join the Firestorm Support English group and explain your issues there and one of the team will do their best to help you.) You might want to point them to this thread as well so that they can see what you have put here.
The first thing I would expect them to suggest, though is that you work through each and every step in this page (even if a step seems irrelevant, you've got nothing to lose from following it) https://wiki.firestormviewer.org/fs_media That is our primary troubleshooting guide for media issues.
There is a nuance here, which is that you have no voice either. The troubleshooting guide for voice is arguably even more extensive as there are more varieties of failure. You can find that page here https://wiki.firestormviewer.org/fs_voice. Again I would advise following through step by step.
Finally, I would note that in the lovely and not at all overly complex and convoluted world of anti virus that there is Whitelisting and there is excluding from scans, which depending on the maker of your choice of AV and in some cases even which version, may be called many different things. What you want to ensure is two things.
1) Virus scanning of network connections is disabled. This messes with all manner of things and will kill performance by effectively disabling a number of HTTP streaming capabilities. Disabling this may occur when you whitelist the folders and executables, you may have to explicitly exclude it depending on your setup.
2) Virus scanning of folders and files that the viewer is frequently updating. The cache and settings and logs being chief amongst those.
The definitive guide is https://wiki.firestormviewer.org/antivirus_whitelisting
In general, items like this are far more "user specific issues" as opposed to "bugs" so as a developer I am not equipped as well as the support team to diagnose it as they see far more of these than I, but I hope this might help a little and I strongly advise asking in support
-
1
-
4
-
-
Stepping aside from the discussions slightly.
@Monty Linden I've been using sequencediagram.org (or a tool that it is based heavily upon websequencediagrams.com) for years to capture these types of charts in my RL work. Because the charts are source-driven, they are perfect for keeping in version control, but we also might want to think about refreshing some of the wiki.secondlife.com pages that haven't been updated since the days of the original AWG.
-
The scenario generalises for non-movement region connectivity, (such as a region coming into view because draw distance increased)
I think it boils down to something like this...
The solid lines are HTTP, with the narrow arrow heads inside the groups being the messages carried as the payload of the eventqueueget
dashed lines are LLUDP, where the solid arrow heads are marked as reliable.
The example is very simplified, it assumes only one region got added, but all that happens in the case of more regions is that the eventqueue payload has an Enable/EAC for each of the new regions. I am not showing all the other noise that may well appear.
-
1
-
-
15 hours ago, Henri Beauchamp said:
Also, the tone mapping (HDR vs linear) poses an issue: HDR is best for PBR materials (on the condition you got an HDR monitor, else you'll find the image way too contrasted), but sucks rocks with legacy contents, while linear (legacy) tone mapping is not that great for PBR materials rendering, but renders legacy contents more or less like we are used to with current release viewers (with the exceptions of full bright faces, for example).
This has been the single most common complaint in these first few days. The vast majority of users do not have an HDR monitor and everything looks contrasty/cartoonish, it is proving very unpopular for that reason alone at the moment. I am trying to find a way to summarise that feedback at the moment.
5 hours ago, Henri Beauchamp said:This is not a new problem, sadly: this problem has existed ever since the sculpties have been introduced, then worsened with the introduction of meshes and, yet again, with (non-PBR) materials...
This is indeed a big issue, and I keep advocating for getting modernized build tools in SL (e.g. with mesh modification/manipulation/creation tools, like basic mesh ”prims” you could mold like clay, cut/join/intesect, a mesh ”hull” from classic prims generation tool, etc).
This is one of the issues I have had with the attitudes expressed in the creator forums on the LL discord server. There is a general view that inworld creators and those that do not wish to use the big tool-chains have no valid claim to be creators. This is both arrogant and ignorant of a whole swathe of hobbyist/non-commercial builders in SL. These fall into a number of important categories:
1) The DIY-er.
Just like in RL, there is some pride to be had in making something of your own. It might not look as slick as a "professional/commercial" product, but you made it and it has sentimental and subjective values way beyond any linden dollar price tag. There are two (arguably three if we include "TPV export as DAE") main toolchains used by creators that work inworld. Mesh Studio and Mesh Generator. While these are (obviously) limited to working with prims (incl sculpts) and not as flexible as directly working in mesh there is still a good number of people that enjoy the experience and find that the output is more than adequate for their needs. The majority are building for their own needs, be those role play props, artworks, additions to their homes or any number of personal items, there are also a few that sell their items and have a decent customer base who enjoy their products.
2) The decorator.
We all like to customise things, from buying a house in the marketplace and then filling it with our choice of furnishings and lighting that fits our tastes, to building an entire region with mix and match assets from many creators, often tweaked and enhanced with "kitbashed" prims/sculpts/mesh. PBR can still support this, we can import PBR materials that can be tiled and apply them to our inworld objects. It worries me that we're seeing suggestions that homes sold by creators should have built-in probes and lighting. This goes against what many house-dressers want and I hope will backfire on those trying to force their design identity onto all of their customers.
3) The re-seller
Mesh Creators have long had a sub-market for template mesh, meshes that come with a UV guide and other textures designed to allow their customers to apply custom materials and re-style and re-sell their product.
I am sure there are many more, examples of people that don't want or need to leap into some external toolchain every time they need something.
-
11
-
-
On 8/21/2023 at 10:01 PM, Zalificent Corvinus said:
Client side avatar baking went away years ago, replaced with SERVER side appearance baking, maybe 9 years? However many oldbies are basically completely clueless how SL actually works, and assume that all bakes are still done client side, and therefore that anyone not rezzing in properly must be "a filthy poor person with a potatoe pc and two tin cans connected by string for internet" and they will scream at you because OBVIOUSLY, it cannot be the fault of THEIR mega gaming rig, and it's connection to SL, right?
Interesting (maybe, to some, at least) addendum to the history lesson. In OpenSim, client-side baking is still a thing; it actually makes sense when you consider that the server that you are connected to may be a very low-end machine and also that the layers that you are wearing may be hosted by a different grid. The downside is of course that you are then co-dependent on your fellow potato wranglers.
Before we roll about laughing though consider that the SL bake service is behind the majority of your orange cloud experiences. I timed it recently, logging out standing next to my partner who was fully-rezzed, and then logging in again, a few minutes later, I get a swirly cloud. It took 183 seconds for the cloud to resolve itself (the timers are in your viewer log file). I have a perpetual TODO note to explore exactly what is happening but the majority of this is I believe down to fetching a large number of bake textures and the fact that the viewer is told not to try to render an avatar until all its bakes have arrived.
-
1
-
1
-
-
6 minutes ago, Henri Beauchamp said:
Provided future PBR-enabled creations will keep providing a diffuse texture, objects will look OK in ”future legacy” viewers; of course, since there is no obligation for people to add a diffuse texture to their PBR-enabled builds, there is a risk that such builds will end up spreading all over the grid. 🫣
When I asked recently about "best practices" in the Creator Discord I was generally dismissed and shouted down for even suggesting that there was a transition period. One creator cheerfully declaring that they had no intention of providing a fallback, or considering a bright pink "upgrade to PBR" texture instead. This does not bode well for the mobile users or those users for whom it will take time to save for an upgraded machine and wish to remain in SL as long as possible.
In reality, we won't know the facts about the adoption rate and thus the expected transition period until release.
-
8
-
-
59 minutes ago, Jaylinbridges said:
How long before a non-PBR viewer, third party or SL, will no longer function in SL? That's the real question.
There is a difference between functioning and giving a reasonable experience, and also to being supported. Once PBR is officially launched by LL, and once we release our first PBR viewer, then based on our normal practice there will be support provided for prior versions for 3 releases. After that support is dropped and we typically block those builds.
That suggests that probably 12 months after the initial PBR release we would expect to be moving away from the non-PBR viewers.
Older viewers should continue to function without issues, they would only cease to function if the underlying protocol that communicate with the SL servers change. At the moment, no such changes are expected.
The question then is will you get a reasonable experience, and that is going to depend a lot on the attitude of consumers and creators. As @Flea Yatsenko notes, the PBR spec allows for a legacy texture to be applied to a PBR asset such that non-PBR viewers will see a fallback texture. However, this does require the creator to provide such a texture, if not then you will see a plain white, untextured mesh
-
1
-
1
-
-
9 hours ago, Qie Niangao said:
There was a new release (7.0.0.581368) of the Linden project viewer today, after a bit of a hiatus. I wonder if this Firestorm alpha is based from that same code, or is the timing just coincidental?
Coincidental, though probably not massively different, we merged PBR after our main release (6.14) last week, so the PBR codebase that was merged was up to date at that point.
-
1
-
-
We've just released an Alpha build of Firestorm that integrates the Linden Lab PBR project viewer. I have to emphasise that this is Alpha, in the same sense that the LL version is too. This is not release quality but the hope is that many of our users will be keen to test this new technology out and at the same time provide ourselves and, more importantly at this stage, Linden Lab, with valuable bug reports and user experience feedback.
PBR server-side support is not yet ready for mainstream and is only available in a limited number of regions on the main grid (Agni), it is also present on the beta grid (Aditi).
This is a shiny, fun, bug-hunting spree. The more we find now, the less painful things are later on.
For bugs, please use JIRA (if this is clearly a core graphical bug, I would suggest going straight to the LL JIRA https://jira.secondlife.com )for others then do use https://jira.firestormviewer.org
For more general comments on the PBR experience then these forums have a number of PBR discussions; you can also comment here of course. Please do remember that this is not intended to be release quality; constructive feedback is appreciated.
https://www.firestormviewer.org/see-the-future-of-second-life-graphics-firestorm-pbr-alpha/
The download links are available in our preview group (Phoenix-Firestorm Preview Group secondlife:///app/group/7ba4569c-9dd9-fed2-aaa7-36065d18a13c/about) this is also where inworld support is given, we cannot support this viewer in our main support channels as it is not a release build.
Enjoy.
-
5
-
2
-
-
update: There is a Jira for this raised by Asher, please add you details to that. https://jira.secondlife.com/browse/BUG-234248
Facebook
Instagram
Twitter
YouTube
Flickr
Firestorm PBR Alpha viewer
in Second Life Viewer
Posted
why so? Taking the albedo, which is a fundamental property of the PBR model and baking it with other aspects that belong in separate maps detracts from the PBR rendering model, messes with the shading thus is muddying the whole concept. I am perfectly happy with my choice of words as I honestly think it is the correct term.