performance I think we should, collectively, be somewhat embarassed.

[Love Zhaoying]

4 minutes ago, Wulfie Reanimator said:

That's exactly what was said. 🙂 Wine lets you run Windows apps on Linux.

Then, it is counter-intuitive to use it in a post when explaining how great Linux is vs. Windows, for Second Life.

[Wulfie Reanimator]

33 minutes ago, Love Zhaoying said:

Then, it is counter-intuitive to use it in a post when explaining how great Linux is vs. Windows, for Second Life.

Not really. Henri was talking about the ease of compiling the viewer, highlighting that even though you might want to use SLVoice, installing everything you need comes down to a single step.

Besides that, Microsoft has been hard at work on getting Linux itself running on Windows -- look up Linux Subsystem for Windows. So it's not really about which is better or more reliant on the other.

Edited April 13, 2022 by Wulfie Reanimator

[Ardy Lay]

13 minutes ago, Love Zhaoying said:

Then, it is counter-intuitive to use it in a post when explaining how great Linux is vs. Windows, for Second Life.

Perhaps Vivox does not see profit in developing for Linux.  Likely doesn't help that one of the noisier Linux proponents countered by saying releasing a Linux version of the product would provide a lot of free product testing.

[Gavin Hird]

28 minutes ago, Wulfie Reanimator said:

Not really. Henri was talking about the ease of compiling the viewer, highlighting that even though you might want to use SLVoice, installing everything you need comes down to a single step.

Besides that, Microsoft has been hard at work on getting Linux itself running on Windows -- look up Linux Subsystem for Windows. So it's not really about which is better or more reliant on the other.

Microsoft only provides the Linux subsystem in an attempt to lure corporate IT to purchase Windows systems for their Linux developers. It is a pretty crippled Linux when it comes to it, and far worse than the BSD Unix 3 certified subsystem in macOS.

Building the viewer in the Cygwin command line or in macOS terminal is pretty identical once autobuild has generated the build project for you. Sure it is a mess of cmake and py files, but it works reasonably well. Frankly I don't think it is any different from building it on Linux, where the only real difference is the compiler involved: gcc on Linux, Clang+LLVM on macOS and VS on Windows. 

Somebody said they have VS issues building FS, but you have to use the Community Edition at minimum and the required features are only available once you have logged in to a MS account and registered the use of VS.

One thing to be aware of is that FS for SL use paid for licensed libraries such as KDU, Havok and Bugsplat. Without these you most likely will have to untangle those from the code before it will build. 

[Wulfie Reanimator]

32 minutes ago, Gavin Hird said:

Somebody said they have VS issues building FS, but you have to use the Community Edition at minimum and the required features are only available once you have logged in to a MS account and registered the use of VS.

That was probably me on the previous page, and it's not just FS. I mainly use Visual Studio (Community Edition) for Unity projects, so I have an account that I use to sign in.

The problems that come up are related to running multiple versions of VS (the one required for viewer development is ancient) and recently one of the required install scripts simply not seeing VS config files in the folder I know it's looking in, and where I know the files exist.

Edited April 13, 2022 by Wulfie Reanimator

[Gavin Hird]

1 hour ago, Wulfie Reanimator said:

That was probably me on the previous page, and it's not just FS. I mainly use Visual Studio (Community Edition) for Unity projects, so I have an account that I use to sign in.

The problems that come up are related to running multiple versions of VS (the one required for viewer development is ancient) and recently one of the required install scripts simply not seeing VS config files in the folder I know it's looking in, and where I know the files exist.

Yes, you can't have VS required to build the viewer coexist with another version. I build the Windows version of the viewer in a VMware virtual machine that is set up for the specific purpose. (VMware Fusion on macOS)

Edited April 13, 2022 by Gavin Hird

[Coffee Pancake]

On 4/11/2022 at 4:30 PM, NiranV Dean said:

......

OMG someone buy Niran a Raspberry Pi.

The linux command line is not hard.

[Love Zhaoying]

Just now, Coffee Pancake said:

OMG someone buy Niran a Raspberry Pi.

The linux command line is not hard.

Truly. If RPi can emulate all those old arcade and cartridge games (8-bit, 16-bit, etc. and even newer) than SL should work too, right? Right? lol!

[Coffee Pancake]

3 minutes ago, Love Zhaoying said:

Truly. If RPi can emulate all those old arcade and cartridge games (8-bit, 16-bit, etc. and even newer) than SL should work too, right? Right? lol!

I think there is a thread on @Henri Beauchamp'sforums where someone got it going.

More of a "because you can" thing I guess.

 

[Gavin Hird]

19 minutes ago, Coffee Pancake said:

OMG someone buy Niran a Raspberry Pi.

The linux command line is not hard.

Apart from the fact that RPIs are very hard to come by these days, they run Debian brilliantly and is a great learning tool.

I also have 2 RPIs running Opensim simulators. The RPI4 8GB version runs 7 standard regions (256x256) in 2 simulators. The RPI4 2GB version runs a 512x512 VAR.

Edited April 13, 2022 by Gavin Hird

[Coffee Pancake]

40 minutes ago, Gavin Hird said:

Apart from the fact that RPIs are very hard to come by these days

That might be because I have a dozen of them sitting around in half finished projects .. sorry!

[Kathrine Jansma]

59 minutes ago, Coffee Pancake said:

I think there is a thread on @Henri Beauchamp'sforums where someone got it going.

Indeed. Someone managed to port the necessary parts to Linux ARM64, so it should run on a modern Raspi or similar hardware.

http://sldev.free.fr/forum/viewtopic.php?f=10&t=2212&start=30

 

[Gavin Hird]

1 hour ago, Coffee Pancake said:

That might be because I have a dozen of them sitting around in half finished projects .. sorry!

I have a couple running idle myself, but you will be hard pressed to find anything but the 1GB RPI4 that you can buy at the moment because of chip shortage. 😀

[NiranV Dean]

5 hours ago, Coffee Pancake said:

OMG someone buy Niran a Raspberry Pi.

The linux command line is not hard.

That's what you say right now but wait until i manage to turn it into a transformer which is going on a world tour to kill everyone just because i typed in the wrong commands

[MarissaOrloff]

On 4/13/2022 at 5:02 PM, NiranV Dean said:

That's what you say right now but wait until i manage to turn it into a transformer which is going on a world tour to kill everyone just because i typed in the wrong commands

Suicide Linus is fun!

[Profaitchikenz Haiku]

Kali linux - destroy everything

[Love Zhaoying]

13 minutes ago, Profaitchikenz Haiku said:

Kali linux - destroy everything

Kali's my Ma!

[Profaitchikenz Haiku]

13 minutes ago, Love Zhaoying said:

Kali's my Ma!

Must have been tough growing up with a |Mum who'd tear you into little shreds where most would just send you up to your room.

[Love Zhaoying]

6 minutes ago, Profaitchikenz Haiku said:

Must have been tough growing up with a |Mum who'd tear you into little shreds where most would just send you up to your room.

The mantras tend to calm her.

[Beatrice Voxel]

So, my comment isn't as a developer (I think I managed to compile a few BBS's back in the 90's, that's my sum total of programming experience) but as a server/backend app support person.

LL is a client/server system.  The viewers are the clients.  

The good part of this issue is, the clients are actually all capable of presenting the content, they all have access to multithreading CPU's and parallel-processing GPU's, along with good sound and whatever I/O devices you can think up.   You think coding a viewer is hard, try coding a streaming-video player with multi-channel sound, alternate sound sources such as descriptive audio, DRM key management, and account caching... and do all that for the Amazon Firestick First Gen, or an old Roku.  "I can't get it to play 4k!" well yeah, because the damn thing has networking, processing, AND heat dissipation bottlenecks, it's not gonna happen.  

The hardware our viewers run on are top-grade, for the most part.  And for those that aren't (old Android tablets, iPads, etc) there's stripped down versions like Lumiya that sacrifice world-rendering for the simple ability to connect to the Grid and communicate.

The bad part is, we've layers upon layers of onion-skinning.  SL is built on a decades-old rendering engine that was originally used for CAD programs in the 90's, for Goddess' sake.  And we still have content inworld that was made for those early versions.  Backwards compatibility, taken to a ridiculous extreme.  Plus we have to deal with content creators (*cough* users) that A) aren't trained on proper optimization methods, B) aren't held to optimization standards, and C) aren't paid to stick around and support their work.  So there's a LOT of stuff in SL that is just plain bloated.  And since the viewers must at least try to render pretty much everything one could encounter in a given sim, we can't just deprecate flexiprims, or enforce texture sizes on nano objects, because then someone's stuff would break and they'd be upset.

Or, maybe we can. 

The idea of rendering imposters is a good one, especially cross-region.  If you're in one region, everything nearby is being rendered by the same SL server instance, but what you see across the border is being handled by a different instance.  It doesn't seem to me to be a bad idea to take 'snapshots' from the centerpoint of one region (maybe in series along X, Y, and Z axes) with all of the in-region stuff derendered, and use those to make imposters of what's out of region.  That would mean significantly less data to pass to the viewer.  Perhaps this would be done for regions further out than 'next door' if you wanted dynamic rendering a little further out, but then again, regions are decently sized to imposter the neighbors.   For the inworld texture imbalance, the viewer can determine 'scaling' by distance OR by size, if something is X meters away, or smaller than Y centimeters in size (perhaps both), the viewer would downsample textures that are "too far" or "too small" to render given the viewer's viewport size and camera position.  Cache the originals, but also cache the downsample for actual rendering. 

The same goes for scripting and animation.  If someone's avatar is too far away, I don't give a ***** about their facial expressions or finger movements, or their hair blowing about.  The fact that I can see them at all is enough.  Sure, render the details when the camera view is close enough to benefit, but until that happens, it's wasted processing on the viewer's part. 

The OTHER elephants in the room are all those "listener" scripts for resizing and retexturing and so on and so forth.  The only viewer that they should impact are those of the wearer - push those clientside as much as possible.  When they're activated, and a shape changes or a texture updates, relay THAT to everyone else.  But forcing the server instance to keep track of everyone's Mama Allpa pregnancy status when no one else is paying attention is just... it's a waste of processing time at the server level.  

This means a major overhaul to the scripting language - it would need to be broken into two parts, the server-side scripts that allow data to be communicated between avatars, or from sim-placed objects to avatars, and client-side routines that listen for inworld or client queries, and provide updates via HTTPS calls.  

And yeah, it'd be nice to work out some kind of way to get around the alpha clash issues.  Again, SL 'knows' positions of objects relative to the camera on all three axes, so I'm a bit confused on how there's still a problem of stacking order.  Given objects with alpha channel textures A and B, and non-alpha backdrop (or world sky) C,  if (A closer  B closer C), then render from C forwards. I'm sure the issue is a lot more complex than that, probably an OpenGL limitation, but... yeah.  

[Codex Alpha]

2 hours ago, Beatrice Voxel said:

The bad part is, we've layers upon layers of onion-skinning.  SL is built on a decades-old rendering engine that was originally used for CAD programs in the 90's, for Goddess' sake.  And we still have content inworld that was made for those early versions.  Backwards compatibility, taken to a ridiculous extreme.  Plus we have to deal with content creators (*cough* users) that A) aren't trained on proper optimization methods, B) aren't held to optimization standards, and C) aren't paid to stick around and support their work.  So there's a LOT of stuff in SL that is just plain bloated.  And since the viewers must at least try to render pretty much everything one could encounter in a given sim, we can't just deprecate flexiprims, or enforce texture sizes on nano objects, because then someone's stuff would break and they'd be upset.

Or, maybe we can.

We most definitely can. No file format is guaranteed forever, and yes some older models and methods and scripts will break - but so what. Some SL creators moved to Sansar which used a newer format , PBR textures, newer technology, and  you could upload FBX models and without any requirement for LOD models (loved that!).

Yet I did see some SL creators simply repurpose models I've seen them use and sell in SL and use them in game, update them to PBR, and sell them on the marketplace there too.

I understand how some creators (getting on their age) don't want to have to recreate anything or rebuild everything - but other than animations, interaction and how those are presented, it's not that they couldn't upgrade and update without starting from scratch.

SL is getting long in the tooth, and will always face this problem. On Sansar we had to deal with some major changes - it being a beta stage program - and many of us lost a ton of work and though frustrating - it was to be expected so what can you do? Just retool your clothing, skins, accessories, etc to fit the new format and hope that there aren't more drastic changes soon.

If anything now that could change the load on people's computers when entering worlds in Second Life (and from my observations using console and dev tools) that the biggest cause of lag is texture use - using too many  textures, large sizes etc, AND they are not counted into the Land Impact of an object at all.

I will be punished for uploading a 12 tri cube at 4m in Land Impact than I will a 4800 tri object that is less than 1m. Importer ignores and doesn't care if the object is textured with 1024 X 8 faces texel density, or 256px texel density on 1 material. Completely ignores it but in the world one object will load and unload from memory so much faster..

My point is : At some point "It might break old stuff" no longer carries when it is inevitable that a platform change is needed. The thing is, Sansar could have fulfilled this function, and creators could have used both (as I did), and slowly moved over to a newer technology and engine with ease. (as I did). Gotta happen sometime and delaying the inevitable is only going to make it more painful - or worse SL will simply fade away and become niche like the Sims 2 marketplace

 

 

 

 

 

 

 

 

 

 

[Wulfie Reanimator]

2 hours ago, Beatrice Voxel said:

And yeah, it'd be nice to work out some kind of way to get around the alpha clash issues.  Again, SL 'knows' positions of objects relative to the camera on all three axes, so I'm a bit confused on how there's still a problem of stacking order.  Given objects with alpha channel textures A and B, and non-alpha backdrop (or world sky) C,  if (A closer  B closer C), then render from C forwards. I'm sure the issue is a lot more complex than that, probably an OpenGL limitation, but... yeah.

Drawing back-to-front is the obvious solution, but what if B intersects with A, being both behind and in front of it? Which do you draw first, and what happens to the other?

The alpha-sorting problem spans across engines because it's an inherent problem with how the GPU pipeline and rendering process is generally designed/learned/taught, especially the fact that you generally don't sort every single triangle in the scene before rendering them. Here's one article that talks about some alternate solutions to alpha blending.

Graphics programming is a massive pit of (fun) dark magic, and the alpha-sorting problem is a big topic on its own.

[Sonic Voxel]

This thread is fantastic and disgusting all at the same time. Lots of platform fighting.

Why can't we just focus on making SL a better experience? Someone was talking about beautiful vistas in SL. That's not possible at high FPS on any platform, high end PC or outdated Mac because of so many factors.

Why does LL not focus on these performance-limiting issues? Would it really break older machines compatibility that bad? and If so, why are they so concerned with people who login once every 6 months?

[bigmoe Whitfield]

4 hours ago, Sonic Voxel said:

This thread is fantastic and disgusting all at the same time. Lots of platform fighting.

Why can't we just focus on making SL a better experience? Someone was talking about beautiful vistas in SL. That's not possible at high FPS on any platform, high end PC or outdated Mac because of so many factors.

Why does LL not focus on these performance-limiting issues? Would it really break older machines compatibility that bad? and If so, why are they so concerned with people who login once every 6 months?

You are not going to break my content or any one elses.   there is lots of love and energy put into some of the older builds.

[Sonic Voxel]

14 hours ago, bigmoe Whitfield said:

You are not going to break my content or any one elses.   there is lots of love and energy put into some of the older builds.

What exactly do you mean by "older builds"? You mean old junk that's been sitting on mainland since 2005? Who is benefiting from that?