Category: OpenSimulator

Load region content

You can load content onto regions by using the load oar command. To load individual OAR files into each region, use the ‘change region [regionname]’ command and then ‘load oar [oar-location]’.

http://secondstrife.com/region_ini_generator.html

Wow! I got a tremedous progress on designing landscpae in OpenSim. Thanks a lot for Linda Kellie’s help with all pre-configured oar files. They are awesome. I will look into details of each artifacts and decide which can contains learning elements.

Linda Kellie: http://www.lindakellie.com/

 

 

There is a problem of loading a large asset at one time due to MySQL failure creating assets.

I found a solution of this by

change “max_allowed_packet = 1M” to “max_allowed_packet = 32M”

Phoenix Viewer that I explored recently is awesome with uploading mesh!

One important thing of using Phoenix Viewer is setting up allow login to other grids

Viewer – Advance – allow login to other grids

An article explaining Mesh from http://opensim-creations.com/2012/02/24/how-to-import-meshes-into-opensim/

What is a mesh? A mesh is a description of a three-dimensional object in a simulated space. It’s not “prim vs. mesh”, or “sculpt vs. mesh”, since both prims and sculpts are meshes, albeit special ones.  Thus, everything we encounter inworld, be it avatars, objects, wearables, prims, sculpts, whatever, are meshes. The easiest way to understand this is to turn on wireframe mode in the viewer (ctrl + r on PC, cmd + r on a Mac). This will remove the surface textures and show the vertices the world is made up of. These triangles describe the shape of the world, they form the “mesh” of surfaces that the viewer displays to us and which we perceive as three-dimensional objects.

In contrast to any other meshes, primitives (or “prims”, as they are usually called) are simple, predefined 3D-objects whose shape cannot be altered by editing the vertices themselves, but only in simple, preconfigured terms (like the in-world editor). They are great to start building right away without knowing anything about vertices or 3d-modelling, but they will not allow the freedom and level of detail that mesh-modelling allows.

Sculpted prims are a special kind of mesh, whose vertex positions are defined by a texture. Unlike primitives, they allow direct editing of their vertices, but are limited by the specific way they need to be represented, i.e. as a uv-texture. They cannot have any number of vertices, but need to conform to the image sizes and resolutions, as well as the positions on the image file.

By supporting other mesh types, these restrictions finally have been overcome. Now, basically any shape, detail and complexity is possible in both Second Life and OpenSim, which brings along its own kinds of problems and possibilities. To leverage them better, SL introduced a new mode of calculating the “land impact” (the impact an object has on the server) which is based on its complexity (both visual and physical) and size (both in data and in-world simulated size). OpenSim does as of today not support this new impact calculator, which means every single mesh object counts as 1 prim. It is therefor up to everyone’s own discretion to keep an eye on the complexity of their objects, (as it was with prims and sculpties before).

Still, with all the freedom of mesh, there are still some conditions that apply: Firstly, only meshes that are saved in the Collada format (file extension .dae) are supported. Collada is an open standard for 3d-objects, which makes mesh support pretty much platform-agnostic, since most (if not all) 3D modelling software supports it. If you have objects that are in a different format (like Wavefront, 3D Studio, Blender, Lightwave, etc.), you will need to convert them into Collada meshes first. Then, while a model may consist of several discrete objects (for example, an avatar can have a separate object for its head, each limb, and the torso), no single object may have more than 65,536 vertices.

If your model conforms to these conditions, you can upload it to any OpenSim grid that supports mesh. (While the latest version of OpenSim supports mesh out of the box, some grids are running older versions or have forked off from core and may not support mesh at all.) To upload meshes, your viewer needs to support it as well. While all viewers that are based on Second Life’s viewer 3 (like Firestorm, Kokua, Exodus, etc.) will automatically support it, most Viewer-1-based viewers will not (unless the developers made a special effort in porting it back to the V1 codebase, like in the Cool VL Viewer).

If you have a viewer that supports mesh, your “upload” menu should show “Mesh Model” as an option. Once clicked, it will prompt you to select the .dae file you want to upload. After that, it will display a pretty extensive interface displaying the model in a preview window to the right, as well as some data about the vertices and triangles in the center. Every 3D-object has several levels of detail (LOD), and depending on the distance of the camera to the object it will be displayed in a different LOD. This is to keep complexity for far away objects low, as you would not be able to see the details anyway when the object is far, and it would unnecessarily slow down the graphics. By default, the viewer will calculate the different levels of detail itself, and unless you have optimized LOD versions of your mesh object, you shouldn’t make any changes to these settings.

Next to the LOD tab is the physics tab. Just as objects have a mesh to display their surfaces, they also have a mesh that defines their physical behaviour (for example to determine which parts of a mesh are permissive, and which parts will block an avatar). In the above example snapshot, we want the space between the legs of the chair to be permissive, to allow small avatars (or even large ones, depending on the size of the chair) to walk between them. By default, the physical shape of any mesh object is a bounding box, i.e. an invisible box-shaped barrier that contains all of the mesh inside itself. The bounding box is a rather primitive shape and will only work well with relatively box-shaped objects, or such that don’t require collisions (like attachments). For our chair it is not sufficient, so we will have to change the physical mesh to either high (which will make the viewer calculate a physical mesh based on the highes LOD of the mesh) or select “from file” and choose once again our .dae file, which will make the physical mesh the same as the surface mesh.

The last tab “upload options” allows you to define the size of the object, once it’s been uploaded (which isn’t that important, since you can stretch and scale it in-world later as well) and the option to include textures with your upload, which will automatically apply the texture of your mesh, if it comes with one. If not, it will show as a white object inworld, and can be texturized in the edit menu, just like any other prim and sculpt. Note that, just like sculpties, meshed objects have only one face to texture, so all textures you apply will be “wrapped” all over the object. This can cause a lot of confusion and frustration, as most objects will require a matching texture map that, which in itself can be just as difficult to make as the object.

Once you made all the settings, click on “Calculate weights & fee”, which will try to get the land impact from the server based on data about the object. This works well in SL, but since OpenSim does not support it, will not return a result here. Nevertheless, it might take several minutes until the button changes to “Upload”, which will then allow you to upload your object. This, again, might take a long time (some mesh files can be more than 10 MB in size), but once it completes, your object will show in your “Objects” folder in your inventory, and can be rezzed like any other object. If you rez it the first time, give it some time to load into the scene and be displayed by the viewer; also, the object might be very small at first, so you might need to scale it a little until it is visible at all.

A very interesting article explaining 4096 bug in OpenSim.

From: http://www.hyperica.com/why-are-regions-marked-upper-lower-and-middle/

There is a bug in OpenSim — and in Second Life — known as the “4096 bug.” Or maybe in Second Life it’s known as the “4096 feature.” It keeps you from teleporting more than 4096 regions in any direction.

Every region has a grid coordinate, similar to a longitude and latitude on a regular map. Most grids cluster their regions around the 10000, 10000 mark. These grids include OSGrid, Cyberlandia, Grid4Us, MyOpenGrid, and most other public grids.

ReactionGrid centers its grid around 1000, 1000. This means that there are 9,000 regions between the center point of OSGrid and the center point of ReactionGrid — too far to jump in one hop. Fortunately, there are plenty of regions midway between these two points, to make the jump easier.

Why hasn’t this been fixed yet? The folks working on the OpenSim server software blame the viewer. The folks working on the viewer software blame the server. The two groups aren’t allowed to talk to each other directly because the viewers and the server are under different, incompatible open-source software licenses.

If this was on the Internet, this would be the same as not being able to jump directly from Amazon.com to Yahoo.com because they are too far apart in the alphabet!

Someday, we will laugh about it, and tell our kids about the old days of the metaverse, where we had to jump in tiny hops, and half the teleports would fail, and we had to walk uphill both ways.

OpenSimulator Inventory Archives (IARs) are a means by which inventory folders and items can be saved offline to a single file (an IAR). This file can then be loaded into a different OpenSimulator installation.

Like OpenSim Archives, IARs save all the necessary asset data required to fully restore the items including textures, sounds, schttps://blogs.ubc.ca/immersivelearning/wp-admin/post-new.phpripts and objects contained in the inventory of other objects.https://blogs.ubc.ca/immersivelearning/wp-admin/post-new.php

An IAR can be reloaded to an OpenSimulator instance with the load iar commad:

———————————————————-

load iar <user name> <path> <password> [<filename>]

————————————————————

• <user name> is the name of the user to whom to load the inventory

• <path> is the path to which the IAR should be loaded. This has to be a folder which already exists in “My Inventory”. See the save iar command for more details.

• <password> is the password of the user.

• [<filename>] is an optional filename for the IAR. If none is specified, then the filename is assumed to be user-inventory.iar in the current directory.

Example:

Suppose that “David Hume” has recieved the my-items.iar saved containing FolderA, FolderB, ItemX and ItemY. David Hume already has an inventory structure like this.

My Inventory
  |
  +-- Folder1
        |
        +-- Folder2
        |
        +-- Folder3

———————————————————-

load iar David Hume Folder1/Folder3 password my-items.iar
------------------------------------------

The below command is for the purpose of loading an archive at the console of OpenSim. the location can be a filesystem path or an HTTP address to load an oar directly over the web.

load oar [–merge] [<location>]

load oar oars/3rd-party.oar

or load oar http://path.to/oarfile.oar

—————————————————–

By default, loading an archive will delete all the existing objects in the regions and replace them with the archive contents. When the archive is loaded, owners will be restored if the relevant uuids can be found in the OpenSim installation’s user database. The file name with the extension .oar is recommended to use.

http://opensimulator.org/wiki/OpenSim_Archives