Henri Beauchamp
-
Posts
1,180 -
Joined
Content Type
Forums
Blogs
Knowledge Base
Posts posted by Henri Beauchamp
-
-
8 minutes ago, Jenna Huntsman said:
all I can say is that I'm sure LL would appreciate a PR for your fix.
Sorry, but the changes involved would be too large, not to mention my viewer is a (true) fork, and its code diverged so much, over the past 17 years, from LL's, that you just cannot 'diff' it to produce a PR: it would require a manual, line by line backport of all the changes, and I have no time to do this in place of LL on their code: if they want my fixes, they can just grab my sources and do the backport by themselves.
-
1
-
-
52 minutes ago, Jenna Huntsman said:
this is the quote I got from the Lindens:
QuoteHTTP resources are allocated to whatever is highest priority at the moment the HTTP resource becomes available, but what it doesn't do that it used to do is allow a single texture to issue a request before the previous request finishesthat was making an infinite loop of dropping data on the floor when moving the camera aroundi.e. one texture would ask for its 1024 version, then decide it didn't need it and would ask for the 512 versionthe 1024 version would finish downloading, then it would drop that data and the 512 version would get downloadedwhich was insaneWell, I'm afraid the Linden in question did not quite understand how the texture fetcher worked, and got mistaken by the yo-yo effect in the texture discard bias algorithm.
First and foremost, when you got the full size texture downloaded, you do not need to re-download a lower resolution of that texture, since the JPEG2000 format allows to derive all lower LODs from a higher LOD: once the higher LOD in cache, the texture fetcher just reuses that cached raw image to decode a lower LOD from it, and there is no need to fetch anything from the network. Equally, when a low LOD gets downloaded, the HTTP fetch is simply done on part of the JPEG2000 texture file, and if a higher LOD is needed, the HTTP fetch is resumed from the point where the next LOD starts in the file, thus not requiring to re-download everything.
As for the ”infinite loop”, it is only happening due to the yo-yo in the texture discard bias algorithm: this yo-yo happens when the texture memory (or VRAM) fills up to the point when the discard bias (which determines what lower LOD to use for textures when memory gets short) raises to its maximum (5.0 in the old algorithm), causing a ”panic” mode in which all textures are re-decoded at their lowest LOD (to free the VRAM and texture memory as fast as possible), before seeing their priority reevaluated and a proper LOD (taking into account the higher discard bias) is applied.
Thing is, the original discard bias algorithm was very crude, and did not anticipate anything. It was also not amortized at the code level, i.e. it simply reacted to the filling up and freeing of the memory, without taking into account the memory usage variations from one frame to the next, neither extrapolating the usage for the next frame, and it relied entirely, for amortizing any yo-yo effect, on the textures download and/or decoding delays (which introduce an ”inertia” in the discard bias changes). To be fair, that algorithm was designed in a time when the network bandwidth was small (ADSL, with 512Kbps at best) and CPUs were much slower to decode textures (not to mention they were mono-core CPUs), so the yo-yo effect (AKA texture trashing) was not happening as much as it can happen today.
However, once the discard bias algorithm rewritten, with finer grained discard bias steps, extrapolation of memory usage based on past variations, and proper amortizing of the bias variations (e.g. do not decrease bias when texture memory did not decrease yet, and do not increase it when memory usage is in the process of decreasing), the prioritized texture fetching works very well, as the Cool VL Viewer can demonstrate to the skeptic ones...
-
7 hours ago, Jenna Huntsman said:
I briefly spoke with one of the Lindens about this, and the answer is a lot more nuanced than this. The old way of doing things actually fell over often as, by the time that something was pushed to the top of the fetch queue it'd then need to drop to a lower mip level, meaning the texture would then drop to the bottom of the queue again, while rapidly filling your cache with unused textures.
That's not to say there isn't merit to what Henri has said, but that the algorithm was changed for a reason.
The problem is that, instead of addressing the actual issue, by avoiding to make every boosted texture ”no delete”, and refining the texture bias algorithm (which was very prone to ”yo-yo” oscillations), LL adopted a naive algorithm which also falls short for many people, in term of rezzing speed.
On my side, I tried and addressed the shortcomings of the old algorithm, and if you do try the Cool VL Viewer, my bet is that you will have to admit it performs quite well in term of memory usage, including in complex scenes, while not ruining the rez time (much to the contrary). 😜
-
1 hour ago, Luna Bliss said:
Ahhh...so you can turn off shadows but not ALM in the newest viewers.
ALM (Advanced Lighting Model) is a renaming of the deferred rendering mode that happened when LL introduced (now legacy) materials.
Prior to the materials introduction, the deferred rendering mode was only required to render shadows, so basically no one ever bothered enabling deferred rendering when they did not want shadows either, especially since the forward rendering mode was so much faster on the GPUs that were available at that time, and the forward rendering mode got (still today) the immense advantage of a gorgeous native (hardware) anti-aliasing mode (SSAA, sometimes also quoted as FSAA) which does not blur the textures details.
Just like legacy materials, physically based rendering (PBR) requires the use of the deferred rendering mode. And since the fallback forward rendering mode got removed from LL's PBR viewer code base, you cannot ”switch off” deferred rendering (AKA ALM) any more.
In the Cool VL Viewer, I kept the old (Extended Environment) renderer, with both its deferred (ALM) and forward modes, and added the PBR renderer, allowing to switch between the two on the fly.
-
1
-
-
2 hours ago, BilliJo Aldrin said:
When it was first introduced, RLV was called restrained LIFE viewer, but LL put a stop to that.
Both the Cool SL Viewer and Marine's Restrained Life viewer existed for many months already, when LL came up with a new rule forbidding to use ”SL”, ”Second” or ”Life” in any brand/product/software name in use for Second Life...
We had to get inventive then, even though the anteriority rule could have been opposed by us to LL, but we are adult, responsible people and not here to impair SL or LL (but on the contrary to contribute in a constructive way). 😜
-
2
-
-
1 hour ago, Qie Niangao said:
It sounds (heh) related to a simulator bug,
No, that simulator sound spamming bug is something else: the problem with that simulator bug is that the collision sound which gets spammed (SND_STONE_DIRT_02, apparently, see sound_ids.h/cpp) is not accounted as a collision sound (between objects or avatar/object) and thus cannot even be muted via ”EnableCollisionSounds”.
For the next Cool VL Viewer release, I added all SND_STONE_* sounds to the collisions sounds list, so that they can be muted like the rest; but hopefully, LL will fix that server-side bug soon. 😜
-
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.
-
1
-
-
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.
-
5
-
-
11 minutes ago, BartPitcher said:
LL made huge improvement steps, true, especially for sailing and other inter-sim activities
Sadly, in its current state, the PBR viewer is a BIG step backwards for sailing, with ugly sky-blue water and broken water reflections (WL waters looked way nicer, including with just ”minimal” reflections, i.e. all but sky turned off)... Another of the things among the many rendering glitches that should have incited LL to keep the PBR viewer in a RC state a little longer. 🫤
Let's hope they will fix waters quickly so that we can again enjoy sailing on SL seas !
-
2
-
-
- ”Why” is a very poor choice of a forum topic... 🫤
- What you are hearing is a collision sound, here triggered by your avatar's feet on each of the steps of the stair.
- The fact you can hear such sounds on some stairs and not others, depends on the physics hull (the mesh taken into account, server-side, by the Physics engine of SL): in this particular case the hull is likely the same as the stairs (rendering) mesh. Some creators will create a physics hull with a plane placed on top of the steps instead, preventing to physically ”bump” into each step.
- If you get annoyed by collision sounds, you may disable them in the viewer (depending on the viewer, this can be found somewhere in the Preferences floater, or at worst, via the debug settings as ”EnableCollisionSounds”, which you can toggle to FALSE).
-
2
-
5 hours ago, animats said:
There are tools for this, but not for SL. Anyone tried Mesh Baker?
This won't work for real-time mesh baking. This is for games with pre-defined assets, not for SL... Plus, it's closed source and a commercial (paying) software.
Note also that the SL viewer does make use of (moderate) mesh optimization (see LLVolumeFace::cacheOptimize()), itself recently updated to use meshoptimizer, but this optimization step, happening each time a new mesh is loaded, won't combine meshes together...
-
57 minutes ago, Silent Mistwalker said:
Something like that.
In fact, there are three implementations...
In order of appearance: Marine's, mine (*) which is very close to Marine's, and Kitty's RLVa.
(*) The Cool VL Viewer (or rather Cool SL Viewer as it was named back at that time), was the first TPV to implement RLV after Marine's; it was back in November 2007, and my fork started as v1.00a (a fork from Marine's RLV API v1.00) in the Cool SL Viewer v1.18.4.3. The fork diverged over time in the underlying code/implementation, but still implements/obeys Marine's API (with some additions of mine).
-
1
-
-
Monty is making mention of BUG-234561.
During the AISv3 protocol update which was necessary to implement inventory thumbnails, the legacy UDP message for creating inventory links got somehow broken server-side.
In the event the limitation you are seeing in Catznip would be related to this breakage, it would be possible to ”fix” the viewer code by using AISv3 to create the inventory link instead.
-
1
-
-
23 minutes ago, Beq Janus said:
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.
It would be possible, instead, to temporarily (while it is edited/selected) override the PBR-bearing face rendering draw info, so to render the legacy texture channels instead.
It is a piece of cake, reusing the media texture override (and USE_FACE_COLOR face state) code to do the trick. This is what I am using in my viewer (but the other way around: to render in ALM/forward modes the PBR-bearing materials with missing/default diffuse texture using the base color texture instead). See the LLVolumeGeometryManager::registerFace() and LLFace::getGeometryVolume() in the Cool VL Viewer v1.32.05 sources.
The trick to render the legacy maps on the edited face could then be automatically triggered depending on the texture channel combo selection in the Texture tab of the Edit/Build floater...
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...
-
1
-
-
45 minutes ago, Flea Yatsenko said:
So you'll have to relog into a non-PBR viewer to check your legacy build, and if you forgot one you have to go through all the hoops.
I know at least one viewer that lets you see everything (PBR, legacy ALM, legacy forward) without needing to relog... 😛
And guess what... The other PBR viewers could implement a way to see diffuse/legacy material while editing a face (i.e. when the face is selected via the Build/Edit floater), by using the same trick I used in my viewer to render the base color map instead of the diffuse map in non-PBR rendering mode (it would be ”the other way around”, but would work with the same trick at the code level): if TPV devs are interested in how I implemented this, they can ask me, in excess of having a look at my viewer code and incremental diffs...
-
1
-
-
4 minutes ago, Love Zhaoying said:
Based on my understanding, I assume you meant ”two different builds” of the objects being created/sold by merchants, not ”two different builds [for/of] the viewers themselves”. (Since ”builds” + ”viewers” sounds like ”versions of the viewers”.)
Thanks. I replaced ”builds” with ”items”, which is hopefully making things clearer/unambiguous.
-
1
-
-
2 hours ago, Qie Niangao said:
We're entering a transitional interval where creators can only serve their markets by providing their content textured with both ALM and PBR materials. (It's silly to suggest doing that with separate versions of the product. That would force the buyer to choose the non-PBR version because it's the only one visible to all visitors for as long as there are pre-PBR viewers in general use.
Entirely seconded. I cannot attend (*) the SL creators user group meetings, but had I attended the last one (for which I could at least read the summary on Inara Pey's excellent blog), I would have loudly opposed to this totally silly statement about providing two different items for PBR and legacy viewers, when all viewers can render (even if differently) a combined PBR plus ALM (or diffuse only) bearing face !
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 !
2 hours ago, Qie Niangao said:These synthetic diffusemaps might be further enhanced (I think) by also ”baking in” the occlusion channel from the glTF ORM map as ambient shading. It however may not be a big enough win to spend the cycles of these underpowered machines.
Yes, and I did consider doing one-time (on texture fetching step only, so to avoid excessive overhead) baking of a diffuse texture for PBR materials in non-PBR rendering modes; however, I am not a 3D engine programmer, and know close to nothing to shading, OpenGL, etc... So, this would have to be coded by someone else than me. But it definitely is possible; LL could have kept a forward rendering mode with such a backing for PBR materials in their viewer, but they instead opted to ignore people with ”weak” hardware.
And you know what ?... Such a diffuse texture baking could even be necessary (or at least interesting/useful/faster) for mobile viewers. And it could even be extended to legacy materials !...
Maybe this baking could be done server side, even (at PBR material application time on a face, with automatic generation and applying of the diffuse texture) ?
---------
(*) Sorry, but I cannot understand well enough spoken English, and myself ”speak” it (or ”moo” it, rather) in ways that no one would understand either, so voice meetings are a no-no as far as I am concerned.
PS: when mentioning my viewer name, please do use the three words making up that name (i.e. ”Cool VL Viewer”), just like you would use the four words making up the ”One World Trade Center” name. 😜 Thank you !
-
1
-
1
-
-
21 minutes ago, animats said:
You can build the SL viewer from source with Tracy tracing enabled, if you want. It's a build option. Then you can run the Tracy profiler while the viewer is running and capture this data. Firestorm can also be built that way.
So can the Cool VL Viewer. Eg, under Linux: cd linden/;./linux-build.sh --tracy
The Tracy profiler is then started on demand from the Advanced -> Consoles menu, or CTRL SHIFT 8
-
1
-
-
I would have preferred a ”Why I don't consider PBR ready” subject for this thread...
Because, you know, the fact you do not like it is due to how unpolished (pun intended) it is right now, with ugly rendering issues for legacy contents (or vanished shadows, or glitchy/ugly (sky blue !) water surfaces, etc) and glitchy and incomplete UI for editing PBR stuff in the viewer.
It is indeed, at best, at ”beta” quality and should never have been pushed to release by LL before all those nasty issues are solved.
Sadly, what is done is done, and we will now see PBR contents starting to be sold by creators, with prerequisites (such as custom environment settings) that will make that contents incompatible with future fixes (e.g. a ”fixed” EE setting to stop shiny surfaces to appear blue will become a handicap after LL will finally fix that bogus blue shine that also ruins shiny legacy contents anyway).
However, PBR, in itself, is a good thing for the future of SL.
It is simply just as disruptive as Windlight has been when it got introduced (excepted that Windlight did not ruin the rendering of legacy contents), especially the PC power required to render it... Yet, would you consider, today, that Windlight was an error and has ruined SL ?... I doubt so !
-
1
-
2
-
-
I already explained it to you, in this post.
Simply increase the ”RenderMaxNodeSize” debug setting (start with doubling it)...
-
2
-
-
13 minutes ago, Love Zhaoying said:
I wonder how PBR will impact the ”OpenSim” and similar ”Non-LL” grids? Those grids don't have the server-side LL code needed for PBR.
And also, any TPV's that support ”Non-LL” grids would need to continue to suppose pre-PBR..
Yes? No?
I has teh dum (as all wayz)
If the PBR viewer cannot find the corresponding PBR-related capabilities and does not get the sim message for PBR materials and objects updates, it will just render like if there is no PBR object in a SL sim (or during the transition, when only a few SL sims had PBR enabled and you could yet use the PBR viewer everywhere).
This is not a problem.
-
1
-
-
52 minutes ago, Flea Yatsenko said:
I don't think the slow rezzing has to do with PBR. I think it's an unrelated problem that SL broke something that happened to be included in the PBR release.
I explained it in this previous post.
-
2
-
-
15 minutes ago, arton Rotaru said:
That's what I thought would be the case as well. But I just tried it again. Fully empty cache, logging in, waiting until everything is loaded, removing all the PBR materials at once from an object, all the underlaying blinn-phong material maps are right there without any grey, or blurriness. So this looks pretty much as the legacy texture maps have been downloaded and cached already to me.
If they exist on another object without a PBR material; this is normal...
There might also be a possible race condition happening on login (when PBR materials data has not yet been received), or because of the object cache data for that object (did you wipe out the object cache as well ?).
Anyway, when not in use for rendering, a texture will end up being evicted from memory (and VRAM).
-
1 hour ago, Qie Niangao said:
There might be uncertainty about a PBR viewer's texture loading speed, on the theory that it could be delayed ”looking for PBR textures” or something. In fact, I'd appreciate a detailed, step-by-step description of the whole materials loading process with and without PBR.
PBR materials presence and reference (material UUID, face index) is transmitted via a new Extra Parameter (like for flexible, lights, sculpts, meshes, etc), in UDP Object Updates messages; this also includes reflection probes data for reflection probe objects.
The PBR materials data itself (texture maps UUIDs, PBR factors, scales, offsets, rotations) is transmitted separately (and sometimes before the UDP object update message) by the sim via a new UDP message. This data is also cached on disk by PBR viewers, as an extra object cache file (one per sim, like for the object data above).
PBR maps (textures) are fetched on demand, when the object is rendered, via HTTP fetches (like for other textures), via the CDN assets server.
1 hour ago, Qie Niangao said:Like, a PBR viewer needn't download all the non-PBR maps for surfaces with a PBR Material, so it doesn't, right?
The textures themselves are only fetched when in use: if your viewer is a PBR one, it will not fetch the legacy material textures for faces also bearing a PBR material. But the data associated with the object itself will still contain a few fields (UUIDs, texture entry index = prim face, diffuse texture scale and offsets, etc) dealing with legacy materials.
-
1
-
Facebook
Instagram
Twitter
YouTube
Flickr
Obscure question: when does the simulator send EstablishAgentCommunication to the viewer?
in Second Life Server
Posted · Edited by Henri Beauchamp
That's what I inferred, from what I could see viewer side; here is a quote of an IM to @animats about it:
Perhaps we would need an ”arbitrator server” (a role that might be playable by the presence server, or whatever you call it): the latter would receive a copy of all the traffic during simulators handovers of an avatar/viewer, and when one of the involved parties is left in the blue (and gets a timeout waiting for a message), it would report to the arbitrator the step it got stuck at, and the latter would ”kick” the simulator(s) into resending the appropriate data to the appropriate party(ies)...
This would allow to keep the current protocol (to avoid breaking legacy viewers), while allowing updated servers and viewers alike to use a ”panic” mode where they ask for help to the arbitrator when left in the blue.
Alternatively, a new protocol with a robust handshake could be implemented. In this new protocol, you would have new sets of messages and each message is acknowledged by another ”cando” (or ”no go”, e.g when there is a ban wall in the way or a restarting sim) or ”done” message to the same pole. Example:
If any message is lost, it is then easy to resend it, since we have a fixed operations order and appropriate handshake.
Also, when vehicles are crossing sim corners very close to the corner (like in a 3m circle around the corner, or rather a radius depending on the vehicle speed), there should be an algorithm in sim servers to send the vehicle and avatar data directly to the opposite sim instead of sending it to an adjacent sim which will itself have to handover that object/avatar to the final destination sim only a couple seconds or less later (a 2 seconds stay in the intermediate sim is usually safe, but below this duration, your risks to fail the crossing increases exponentially). All it would take is to extrapolate based on the vehicle speed vector and see where the vehicle is going to ”land” in the end... This would avoid many double-sim-crossing failures with the current protocol unchanged.