Seagull Islands is a full region designed by Balthasar Trebuchet and Angel Baxter which we happened across entirely by chance as a result of reading a group chat in-world. It offers an outdoor setting which might be seen as ideal for those wanting to capture the essence of summer vacations spent hiking through a national park – be it one in North America or the UK or Europe or elsewhere. It is also a place laid out in such a way as to feel far bigger than a single region.
As an outdoor location, there isn’t a set landing point, so for this article I’ve arbitrarily selected the little fishing wharf and warehouses located in the north-east corner of the region. From here, the region opens out to offer several routes of exploration. To the north, for example, area couple of secluded little beaches. Behind these, across the flat grasslands separating them from the wharf and buildings, stone steps offer a way up into the hills.
Follow these, and the route will take you past an old chapel, and on upwards into the hills. A fenced track, overlooking a steep drop, points the way onwards and – if you take the right trail – further upwards to a mountaintop lodge. this overlooks the bay and fishing area. A second path, passing via wooden walkways and narrow clefts offers a way back down to the red-painted buildings and warehouses.
The multiplicity of paths and trails are what make the region fun to explore – and gives that exploration the feeling that you’re on a hike. They lead to a range of locations from tented camp grounds to lodges, stone-built farms, and coastal walks, scattered across the lower-lying lands as well as within the inner hilly area.
Another way in which the feeling of being in an expansive parkland is through the use of region surrounds, from distant hills, to closer islands and a use of part of the region itself to form a protective bay around the quayside. Care has clearly been taken to blend these as far as possible with the region to given the impression of a continuous landscape.
Alongside of all this is the creation of a sense of history. Ruins can be found in the region and offshore: Kriss Lehmann’s Forest Ruins Tower sits on the north side of the island, while a TUFF medieval tower sits partially flooded in the region’s waters, as if caught by the slowly rising waters of a river. Elsewhere, the placement of stones give the suggestion of an ancient long ship, echoing the wreck of such a vessel lying across the bay.
This is a place which requires time to explore, as there is much hidden away under the foliage and along the paths and trails awaiting discovery, be they places to sit or to dance or simply to watch the fires at a camp site or the birds flying overhead. It’s also a place well suited to photography, either under the default daylight settings, or via a range of windlight settings – I opted to use a summer lighting for my photos here.
All told, a pleasant visit – just be sure to wear your hiking boots!
The following notes are taken from the Content Creation User Group meeting, held on Thursday, November 9th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.
Animesh (Animated Mesh)
“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.
The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.
In short, an Animesh object:
Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself.
Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
Can use many existing animations.
Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.
The major change is that Animesh linksets can now include non-rigged items (e.g. prims), and allow the root objects to be a prim rather than a rigged mesh.
Animesh objects should now render the same way as mesh attachments and generate shadows.
The viewer also includes a number of bug fixes.
[42:25-44:50 + text chat] However, while the root of an Animesh object can now be a prim, this doesn’t mean mesh objects such as pets can be dropped in-world (e.g. so someone could “pick up” their Animesh pet, carry it, then put it down again somewhere else), because the code required for “dropping” mesh is not provided on the simulator on the ground that dropping meshes can cause physics issues.
Note: there is an extensive discussion in text chat around this subject from the 13:00 minute mark which continues throughout the meeting.
[12:59-18:06] One of the major subjects of discussion with Animesh is enabling attachments to be added to existing Animesh objects (see here and here). In short, many pets and characters are created as No Modify objects, to help protect their capabilities. Thus, as No Mod objects, Animesh characters cannot be accessorized (the owner of an Animesh horse cannot add / remove a saddle from an Animesh horse, for example). As Piscine Mackenzie explains in the forum, with highlights by Medhue Simoni, making Animesh pets / characters Modify opens them to the risk of exploitation.
One proposal has been put forward via feature request BUG-139168. Vir Linden has also put forward a number of ideas. Of these, the mod key proposal (2nd bullet point in Vir’s notes and somewhat aligned to BUG-139168) is seen as a potential solution, with LlAllowInventoryDrop used to avoid the need for the root Animesh object having to be modify (and leaving it exposed to the exploits outlined by Piscine and Medhue). Vir is currently seeking further feedback from people on this being a possible approach, or if there are other potential alternatives.
[21:11-22:51] Two concerns on this approach are that a) any scripted mod key capability could be withdrawn at any time by the creator, potentially leaving users with broken content. However, there is no obvious means of safeguarding against this (unless it is made some kind of one-time function operation by the Lab, if possible); b) there is a risk the mod key could be accidentally exposed / leaked in being shared between those using it.
[25:52-26:12] The most “obvious” means of handling this issue would be to implement a change to the permission system to cater for the specific user-case of allowing attachments to be added to Animesh objects. However, the Lab is hesitant to consider such changes due to the risk of unintended impact, risk of content breakage, etc. As such a precise proposal on how to update the permissions system and the use cases it would meet would have to be properly defined for consideration.
[28:15-30:40] A suggestion is made to have a new flag “only allow scripts compiled by the object creator run on this object”. However, this could limit cases where models are built by one person, animated by another and scripted by someone else, or situations where a creator is using full permission scripts sold by another creator, etc., and so seen as potentially less than ideal.
[56:07-1:01:56] Determining whether Animesh attachments capabilities (e.g. using the mod keys idea) can or cannot be implemented relatively easily is seen by the Lab as a critical aspect to moving Animesh towards a release. If doing so proves problematic, the project will likely move ahead without such a capability being implemented. In the meantime, as there isn’t currently an available solution, creators are advised to handle Animesh the same as any other product they are developing for the time being, and focus on Animesh at the functional level.
[1:01:57-1:05:05] An example of complexity is defining how a mod keys capability would work. If it is limited to one specific group of people creating a poduct line, it is relatively easy to control. However, if a creator wants too support an ecosystem whereby other creators can all offer attachments for a product, then it becomes far more complicated in terms of keeping the mod key secure.
Given the complexity of this subject, continued discussion through the Animesh forum thread is encouraged.
Animation Playback Speed
[51:47-52:37] It has been noted that the speed of the animation depends on the distance from the viewer’s camera to the animated object – see BUG-134259 and this MP4 (note particularly the two elephants). This appears to be the result of the debug UseAnimationTimeSteps being set to TRUE (default viewer behaviour). Setting it to FALSE fixes the issue, and doesn’t appear to cause any other performance impacts.
Land Impact and Other Limits
[54:53-56:05] It’s unlikely that the current baseline limits (LI, tri count, rendering), will be altered until there is confidence that the viewer functionality is relatively stable in terms of features, bugs, etc., at which point reliable performance testing can begin. Once this point is reached, then the Lab will be able to gather reliable data in order to start adjusting / potentially relaxing the limits.
Environment Enhancement Project (EEP)
A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.
[8:25-10:32] Rider Linden is “very close” to removing the old windlight environment code from his EEP version of the viewer, allowing it to use all the new EEP assets, allowing the local environment to be set via windlight inventory assets.
Once this can be done, test regions capable of supporting the assets will be established on Aditi (the beta grid), and a project viewer will be made available for more general testing.
Bakes on Mesh
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:
The current work to update the baking service to support 1024×1024 textures.
An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
This work does not include normal or specular map support, as these are not part of the existing baking service.
[35:41-36:33] The performance testing has been carried out, and the results point to the need for additional bake host servers to account for the additional load in handling the higher resolution textures.
Other Items – In Brief
[36:30-37:29] Region crossing loads: the question is asked about what is the biggest load / cause of lag on region crossings (direct or TP). The short answer is scripts. That is, suspending them, saving their state, packaging them, handing them off to the next simulator, unpacking them alongside everything else (e.g. the avatar and / or vehicle they are running against), setting them back to running from their saved state. Obviously, the more individual scripts an avatar (+ vehicle, where used) is running (regardless of individual script size), the bigger the load placed on the hand-off process / receiving region.
[47:03-47:19] Materials system update: this is frequently requested, but currently the Lab do not have any plans to revisit the materials system.
[49:32-49:45] Cannot pathfind through a hollow object – intentional? Short answer – yes; physics simulations going into concave objects is expensive
[49:45-50:18] Will RenderVolumeLOD be revisited? – Short answer – yes, as a part of the work in re-evaluating rendering costs, land impact, etc.
The 11th annual Virtual Worlds Best Practice in Education (VWBPE) conference was recently announced, together with a call for proposals, which combines calls for presentation proposals, proposals for exhibits, and proposals for and immersive experiences (pre- and post-conference virtual experiences).
The conference will take place between Thursday, March 15th and Saturday March 17th, 2018 inclusive.
The theme for the 2018 conference is VRevolutions, with the organisers noting:
VWBPE is an ecosystem of digital spaces. While the conference is hosted in Second Life, our conference features a variety of virtual and digital spaces. To present at VRevolutions, think outside the virtual space and consider how multiple available technologies and devices redefine what it means to work, create, and learn “virtually”. The VRevolution is about doing what scares you, what excites you, breaking and creating new paradigms.
At VRevolutions, VWBPE welcomes the multifaceted communities that contribute to and expand best practices in digital and virtual spaces to support practice, creation, and learning. Regardless of the community you represent, your proposal should consider how it contributes and expands the knowledge base for innovative and revolutionary change through the increasingly complex landscape of digital technology.
Those formulating proposals for submission should keep these ideals in mind in writing their proposal.
All proposals for presentations should be made in one of the seven presentation tracks: Analytic Thinking and Complex Problem Solving; Creativity and Innovation in Design, Practice, and Learning; Essential Accessibility in Digital and Virtual Spaces; Collaboration and Distance Connections; Multimedia Communication and Multifaceted Interactions; Ethics, Responsibility, and Tolerance and VWBPE Redux.
In addition, proposals for presentations should meet one of the three conference presentations formats: Spotlight Presentations (1 hour); Hands on Technology Workshops (90 minutes) or Compass Points Roundtable Discussions (1 hour).
Full details on the seven tracks and three formats can be found on the VWBPE Call for Proposals page, together with general information on presentations and a link to the proposal submissions page.
Note that the closing date for presentation proposals is Monday, January 8th, 2018.
Exhibit proposals are open to those who wish to showcase their creative works in virtual worlds through artistic expression in order to promote their organisation or achievements. All exhibit proposals are reviewed by the VWBPE, and must apply to an already developed product for showcasing.
Exhibit proposals should be made in one of the eight exhibit tracks: K-12 Best Practices; Higher Education/College Best Practices; Field Practices; Games and Simulations; Tools and Products; Advocacy; Support and Help Communities and Artists, Designers and Builders.
Note that the closing date for presentation proposals is Thursday, February 1st, 2018.
Immersive Experiences Proposals
The Immersive Experiences category showcases locations whose main objective is interaction, immersion, and engagement for those who enter them, whether to play a game, solve an immersive problem, or engage participants in hands-on, interactive learning.
All proposals for immersive experiences should be made in one of the seven presentation tracks: Analytic Thinking and Complex Problem Solving; Creativity and Innovation in Design, Practice, and Learning; Essential Accessibility in Digital and Virtual Spaces; Collaboration and Distance Connections; Multimedia Communication and Multifaceted Interactions; Ethics, Responsibility, and Tolerance and VWBPE Redux.
In addition, proposals for immersive experiences should meet one of the two conference experience formats: Wanna Play? and Virtual Worlds.
Full details on the tracks and formats can be found on the VWBPE Call for Proposals page, together with general information on presentations and a link to the proposal submissions page.
Note that the closing date for exhibit proposals is Monday, January 8th, 2018.
VWBPE is a global grass-roots community event focusing on education in immersive virtual environments which attracts over 2,000 educational professionals from around the world each year, who participate in 150-200 online presentations including theoretical research, application of best practices, virtual world tours, hands-on workshops, discussion panels, machinima presentations, and poster exhibits.
In the context of the conference, a “virtual world” is an on-line community through which users can interact with one another and use and create ideas irrespective of time and space. As such, typical examples include Second Life, OpenSimulator, Unity, World of Warcraft, Eve Online, and so on, as well as Facebook, LinkedIn, Twitter, Pinterest or any virtual environments characterised by an open social presence and in which the direction of the platform’s evolution is manifest in the community.