BriannaLovey

There is no way that glTF scenes will use a completely different mesh rendering pipeline from the existing one under the hood. Unless LL does that (which would be an inefficient use of their time and money,) the fix that Henri made should work for glTF scenes too with a little adaptation. It is all the same geometry at the end of the day; all that really differs is the format it is uploaded as.

I know, thats why I am baffled as to why she keeps asserting that PBR is so inevitable. Either she hardly works on the internals of the viewer at all, or she just loves licking LL's boot.

Of course they have PBR, but they won't block your viewer for not rendering it the way LL wants. OpenSim has no shared experience policy, due to the decentralized nature. And don't say "hurr durr white/gray/invisible objects," because @Henri Beauchamp's viewer has completely eliminated that problem. If you don't believe me, have a look in his codebase to see how it works, since I assume you are a knowledgeable viewer developer. The relevant code is on line 5552, in llvovolume.cpp. The entire source is here: http://sldev.free.fr/sources/CoolVLViewer-src-13223.tar.bz2

They can be, yes, since they are handled by the viewer as regular textures except during rendering. PBR materials on the other hand are wrapped in an entirely different class, though they still have texture-like data.

I forgot to mention that this function can also convert prims to mesh. So if you had an old prim creation, you could export it as DAE, clean it up in Blender to reduce the number of polygons and make proper LOD models (though hardly anyone does that lol) then reupload it. That is probably why it was originally created.

The existing "export DAE" button (which only works for objects you have uploaded/created yourself) can export unrigged mesh without PBR materials. It cannot export rigged/fitted mesh, or any PBR materials. This is likely deliberate in order to make it more difficult for high-value mesh objects to be ripped.

Someone would have to write a custom object exporter and possibly importer in order to export them.

Contact me inworld for a lesson 😄

[redacted]

Technically that is still possible with DAE import, but a lot of re-linking would be required. And this doesn't kill in-world building, but it does drive more nails into the coffin. You will still be able to build stuff in-world, but nobody will be able to compete with the professional creator class.

Paternalism is the right word. Close your eyes and just trust(tm) us because we know what is best(tm) for you.

OpenSim doesn't have Havok, no. Physics seemed a bit better than they have been previously though. Just more pirated stuff. The reality though is that most users don't care about intellectual property, and most don't care about the difference in physics.

Whatever, semantics. My point is that if people are kicked off of SL because of the viewer they use, they will go to OpenSim because it has a bunch of free stuff. This will cause a decrease in economic activity in SL.

Read what I said again. Unless they start forcing TPVs to include anticheat software or a similar measure, there is no way to enforce this. You of all people should know this. Anyways, if they do that, then there is always OpenSim. Where asset piracy is rampant and there is no real way of enforcing it. It would be a shame if people stopped paying money for the latest mesh items in SL, yes?

Eventually I plan on using the latest version of Firestorm as a base, and doing one of the following: 1) Take the Firestorm 6.6.x rendering code and put it in newer versions of firestorm, then use the same base_color trick that Cool VL Viewer uses in order to make glTF items visible without using PBR. This will ensure that all the code for fetching, caching, etc. of glTF-based assets is there, but the rendering will be the same as it was on prior versions. 2) Use the Cool VL Viewer's rendering code inside latest Firestorm. This will be more difficult, as it uses additional dependencies that Firestorm does not use, and a completely different set of settings from the Firestorm viewer. It would be worth it to do though, since Cool VL Viewer's renderer is far superior to that of any other viewer as far as efficiency goes. But since widespread invisible objects won't be a problem until further down the road, my fork will simply be based on Firestorm version 6.6.17 for now, but with the login blocking and auto update checking code disabled. I already have this part done; you should be able to compile the viewer from source right now if you want to use it yourself. I am still figuring out how to build it for Windows, which is sadly a bit harder than on Linux :c And if LL starts outright blocking viewers not on the official TPV list from logging in whatsoever...that will be a huge mistake on their part. This would mean that for people who don't want to use PBR, they would need to falsify their viewer info and possibly hardware info, both of which are trivially easy to do. For many, breaking the SL TOS is better than not using SL at all (evidence available if you contact me personally inworld.) This is not a good precedent to set, as it opens the doors to all sorts of other stuff.

I am already on it, and will work on it more once RL isn't so hectic. https://codeberg.org/arkstormdev/arkstorm-viewer While you are waiting forever for me to do that, you can use the Cool VL Viewer, or just use Firestorm 6.6.17 until I have made any progress. Its the nature of any open-source project. Schisms are inevitable if there are changes that both benefit one cohort of users and harm or otherwise disadvantage another. The only way for LL to keep this from happening is to close the source code of the official viewer and forbid third-party viewers from connecting to the grid. Of course if they did that, it would really cut a chunk out of their userbase.

The eyes may be set to Alpha Blending, even if they are BoM. If the eyes were modifiable this would be an easy fix, but I am guessing they probably aren't

There are companies that sell ATX to Dell power adapters, but I can't recommend them. Dell's (and HP's and Lenovo's) power supply pinouts can change from one model to another, so unless you do your homework about your motherboard's PSU socket specification, you run the risk of setting your computer on fire.

There is still a way to get a better GPU for your system than the GT 1030, but it won't look pretty. You will need the following parts: 1) Oculink to PCIe slot adapter: https://www.amazon.com/chenyang-SFF-8612-SFF-8611-External-Graphics/dp/B0BZW1G87R/ref=sr_1_4 2) Either of these, depending on your budget/preference: a) Oculink to host PCIe adapter (will look cleaner/fit better/be easier to install): https://www.amazon.com/Chenyang-Express-External-SFF-8612-SFF-8611/dp/B09CPNY5DH/ref=sr_1_3 b) M.2 to PCIe adapter (cheaper, since the Oculink to PCIe slot will already come with a oculink to M.2 connector): https://www.amazon.com/EZDIY-FAB-Express-Adapter-Support-22110/dp/B01GCXCR7W/ref=sr_1_40 3) Standard ATX PSU to plug into part #1 in this list as well as your GPU (wattage depends on your card of course.) 4) Standoffs for part #1: https://www.amazon.com/Mounting-Circuit-Standoffs-Hardware-Motherboard/dp/B0BRQ8T4RY/ref=sr_1_3 5) Something to hold your GPU in place. There are various external GPU mounting brackets for sale, but I can't guarantee that they will fit oculink adapter board. If it were me I would just make my own bracket out of wood or something. Of course you could buy/build a new system too, but where is the fun in that? Edit: Mining risers are a cheaper option than oculink (especially now that crypto mining with older GPUs is dead,) but only provide 1x bandwidth as opposed to 4x from oculink. Whether or not that is good enough for you is your choice. They sell for dirt cheap right now: https://www.ebay.com/sch/i.html?_from=R40&_nkw=mining+riser&_sacat=0&_sop=15 Supplying power to these will require adapters of various sorts, depending on the mining riser's power socket. If the riser you buy has a 6-pin PCIe power socket for example, you will need an adapter like this: https://www.amazon.com/IOTSES-Adapter-Switch-Graphics-Cards（1/dp/B0BWQ1GFRV/ref=sr_1_4 I highly suggest that you avoid anything that takes power from a SATA cable, as these are often fire hazards. That includes any SATA to 6-pin adapters included with these devices; just throw those away.

Give idiot creators an inch, and they will take a mile. Many people have said that PBR will compensate for high-poly mesh by allowing people to create material maps for use in place of the extra geometry. The competent ones will do this, but the vast majority will not; in fact, they will probably use high geometry, multiple high-res PBR materials, and mirrors all in the same object!

Doesn't affect my desire whatsoever. I don't care if the timer runs out and people see me naked lol

And that is the beauty of open-source software! Most other virtual worlds don't have this type of freedom because their client software is closed source (for example, VRChat, which not only is closed-source but also uses anti-cheat to discourage users from modifying their client.)

I do the exact same thing with /dev/shm on Linux. You do have to copy it back to your disk every time you shut your computer down if you want it to be persistent though, which can be either done manually or via bash scripting.

Find random people inworld and give offer them a small amount of L$ for their time.

Same here. I've been using it ever since PBR was announced because of the dual rendering engine, and recommending it to any of my friends who also can't run PBR viewers.