Talk:OpenSimulator

Fair use rationale for Image:OpenSim20070914.png

Image:OpenSim20070914.png is being used on this article. I notice the image page specifies that the image is being used under fair use but there is no explanation or rationale as to why its use in this Wikipedia article constitutes fair use. In addition to the boilerplate fair use template, you must also write out on the image description page a specific explanation or rationale for why using this image in each article is consistent with fair use.

Please go to the image description page and edit it to include a fair use rationale. Using one of the templates at Wikipedia:Fair use rationale guideline is an easy way to ensure that your image is in compliance with Wikipedia policy, but remember that you must complete the template. Do not simply insert a blank template on an image page.

If there is other fair use media, consider checking that you have specified the fair use rationale on the other images used on this page. Note that any fair use images lacking such an explanation can be deleted one week after being tagged, as described on criteria for speedy deletion. If you have any questions please ask them at the Media copyright questions page. Thank you.

BetacommandBot (talk) 14:09, 8 March 2008 (UTC)

LiteSim

I'm not sure if it's appropiate to list litesim under opensim grids as it does not actually run stock opensim. (In fact, we're slowly moving things away from the opensim platform piece by piece). Thoughts on this would be appreciated. —Preceding unsigned comment added by GarethNelson (talk) 15:09, 19 September 2008 (UTC)

History

Should there be something on it's history? How did it come about? Surely this info was gathered by the opensim team earlier in 2009? ale 10:29, 29 June 2009 (UTC) —Preceding unsigned comment added by Shomon (talk • contribs)

There are lots of amusing stories about OpenSimulator, but, knowing how the wiktators hate all the issues around SL/OpenSim, I seriously doubt that we'd be allowed to document its history here... — Gwyneth Llewelyn (talk) 01:42, 11 February 2023 (UTC)

Game engine

It should be mentioned what game engine it uses; see Talk:Second_Life#Game_engine

See also http://www.hypergridbusiness.com/2012/02/opensim-founder-goes-for-unity/ (explains that the SL viewer is technically dated compared to other engines) 109.130.176.253 (talk) 07:27, 15 September 2014 (UTC)

I'm afraid that the discussion of the game engine is irrelevant for OpenSimulator, since it addresses only the server-side of the virtual world platform. There isn't a 'game engine' per se in OpenSimulator; ultimately, one might see OpenSimulator as a glorified database with a messaging service (an API, if you prefer). Its main roles are to enable persistence in the virtual world and providing a shared, 3D collaborative environment to individual users in real-time.

In any case, that comment has been removed (?) on a subsequent revision of the Second Life talk page — probably because it is a misnomer anyway: the viewer, or the client (both designations are correct), does have a rendering engine, but hardly a game engine. The distinction may be subtle since both do 3D magic on a computer screen; but tools such as AutoCAD or Blender also generate 3D scenes on a computer screen and they are not 'game engines' — although certainly they have rendering engines (both proprietary, in fact).

The official Second Life viewer has, indeed, a proprietary rendering engine, but such claims as to its obsolescence, once popular (your comment is from 2014, after all), are harder to make in 2023. The most recent innovations in materials bring the Second Life rendering engine close to what Unreal Engine's Lumen is able to provide, using similar concepts and algorithms, but implemented from scratch; some of its characteristics (such as automatically calculating meshes for different LODs or real-time placement/movement of light sources, as opposed to pre-rendered scenes) have been around for almost a decade — even if hardly at the level managed by UE5.

However, since the communications protocol is pretty much well-known, and extensively documented (even though sometimes only in the code), it's not impossible to write an alternative Second Life/OpenSimulator viewer using UE5 (or Unity, or anything else), and expect it to render the same content with the same (or better!) quality. There are some issues regarding the way content is streamed on demand into the viewer — and dealing with partially or incompletely received content — which is where the SL viewers excel (not from the perspective of the users, of course, always complaining that everything takes too long to load). This would require some adaptation of either the Unreal or the Unity engines to be able to deal with that — since, by default and by design, those rendering engines 'expect' that the content is locally stored on disk, even if it might be subject to change, namely when switching scenes, or loading new scenes, but such activities are expected to run independently one from the other — asking the user to wait until everything was correctly loaded, for instance. Not so in SL/OpenSimulator — here, the viewer has to render what it gets from the simulator servers, as best as it can, with whatever it can retrieve from its local cache, using partially-loaded JPEG2000 textures with whatever resolution it could grab, all the while striving to reach 60 FPS on low-end machines (and much higher than that on so-called 'gamer' platforms) and tracking up to a hundred avatars in the same region (i.e. within viewing distance), or possibly even four hundred (at the corner of four neighbouring regions). Granted, although such a goal is rarely achieved (especially on low-end systems!), it is nevertheless a goal, in the sense that the whole platform and communications protocol were designed for that specific scenario (if it can be achieved or not, that's a completely different question!).

Nevertheless, one should consider a few of the advantages of adopting a third-party rendering engine, such as Unity or Unreal. Both have a very extensive ecosystem of tools (while the Second Life engine has to provide 'everything' it can under the same clunky interface). Both can also use one single codebase to deploy on almost all possible platforms — from mobile to console, with desktops and platforms in the middle, including a Web-based solution — as well as different operating systems and underlying hardware (x86 vs. ARM, high-end multiple-core GPUs, and so forth). By contrast, the official viewer is mostly targeted to only support OpenGL for basically every platform — and that means a C# building environment for Windows, an Objective-C environment for macOS, and a C++ (currently discontinued, but persisting among third-party viewers) for Linux. All two (or three) had to be supported by different codebases and different programmers in parallel — because, well, Linden Lab just thought about using OpenGL as the 'unifying', multi-platform component, instead of thinking about how to address all platforms with the same codebase (using, say, Qt to deliver the same visual environment to all platforms, using a single codebase). Here is where the Linden Lab rendering engine can be considered to be 'technically dated', compared to the 'one-codebase-runs-everywhere' approach of Unity or Unreal; and it's hardly easy to change everything from scratch.

Nevertheless, there are a few (very experimental!) attempts from independent developers to provide exactly that. Command-line access, for instance, has been a reality since 2008 or so — with all its limitations, of course (you can connect and even move around and chat to others, and they will see your avatar moving & talking, but obviously you will not 'see' anything on a terminal console — except possibly for lists of objects with their names and keys).

Anyway, this is a far too long rant for Wikipedia. The point is that the viewers able to connect to Second Life and/or OpenSimulator have been open-sourced eons ago, but nevertheless those independent developers can hardly replicate all that effort and start from scratch with a popular rendering engine and retrofit whatever is required. If that were easy to do, it would have been done already.

— Gwyneth Llewelyn (talk) 00:30, 11 February 2023 (UTC)

Compatibility with official Second Life viewer

The official Linden Lab Second Life viewer can no longer be used with OpenSimulator which employs a different physics engine (ODE or Bullet rather than Havok) and has dropped the --loginuri command-line option formerly used to login to OpenSimulator grids. A number of third-party viewers continue to support OpenSimulator by way of a special edition, e.g. Firestorm viewer (also Kokua, Alchemy, Singularity, Lumiya). See http://www.hypergridbusiness.com/2012/08/linden-lab-cuts-viewer-link-to-opensim/ CastWider (talk) 22:06, 18 July 2015 (UTC)

I don't think OpenSimulator was ever 100% compatible, because of the proprietary code in Second Life. The Havok code used is one of the big problems, and third-party viewers can't get the Havok code needed for their Linux versions. Mostly that doesn't matter, but for Linux users some viewers are labelled as OpenSimulator compatible, and are used for both. — Preceding unsigned comment added by 87.113.70.26 (talk) 08:51, 14 June 2017 (UTC)

Updated Reference Link

Not sure this is the right place to write this, but the link for reference #4 is broken. The updated link is https://www.technologyreview.com/2008/08/11/219365/a-bridge-between-virtual-worlds/ --Luceviva (talk) 16:26, 2 May 2021 (UTC)