Virtual Landmarks: solving an age-old problem?

On July 24th, Toysoldier Thor posted about an idea he calls “virtual landmarks” in the Merchant’s forum. It’s a potential solution to an age-old problem most of us in SL face at one time or another: making sure all landmarks relating to your location in Second Life are always up-to-date.

Whenever we move in SL, we’re faced with the fact that every LM we’ve ever given out for our old place is now worthless, and we have no choice but to start issuing new ones. For some, this isn’t a problem – but for others it very much is.

Merchants, for example, are faced with the fact that every single landmark they’ve ever placed within a package contained in a vendor server or magic box or in a Marketplace folder or used within landmark givers they’ve placed around the grid (at malls, satellite stores and so on), now needs to be individually replaced (and in the case of Marketplace folders, each folder manually re-linked to the relevant listing). For some this can run into several hundred items and many hours of additional work. Nor are merchants alone – the likes of role-play groups, clubs, and so on, can face similar issues, both in terms of updating landmark givers, etc., and in terms of ensuring patrons get updated LMs.

In short – it’s a nightmare.

The issue: change your SL location and old LMs no longer work – click to enlarge (credit: Toysoldier Thor)

Toysoldier Thor’s idea is so elegant and (in some respects) obvious, one is tempted to ask why such a system wasn’t developed for Second Life from the outset. He calls it Virtual Landmarks (VLMs), and it essentially works in a similar manner to how we navigate the web. He describes the idea thus:

The concept of a VLM would be identical to the critically important Internet service of DNS (Domain Name Services) in that Internet users can create and use easy to understand HOST NAMES to access all Internet services where the HOST NAME actually masks the underlying required IP Address that is needed to actually route and connect their computer to that respective host.

Well the same would hold true with VLMs.  A VLM would be the equivalent to a DNS HOST NAME and the LM that is configured to be associated to this VLM would be equivalent to an IP ADDRESS.

One Change

In his proposal, rather than creating and distributing a landmark, a store-owner (or whomever) would create a user-friendly VLM (e.g. “My Wonderful Store”) which is then associated with the actual landmark for the store itself. This association is stored in a new service Toysoldier calls the “VLM Mapping Service”, and it is instances of the VLM – not the original – which are given to people or placed product packages, landmark givers, etc. When someone uses the VLM, their viewer sends a request to the Mapping Service, which  looks-up the physical landmark associated with the VLM and sends the information back to the viewer, enabling the user to be teleported to their desired destination.

The beauty here is that if the underlying landmark is subsequently changed (because the destination store moves, for example), all the creator of the VLM has to do is associate the VLM record stored in the Mapping Service with the new landmark – and every instance of the VLM in existence will automatically route people to the new location when used. There is no need to pass out new LMs, replace existing LMs or anything else; one change, and that’s it.

The solution: VLMs and the Mapping Service – click to enlarge (credit: Toysoldier Thor)

There are further benefits of the idea, as Toysoldier points out:

  • The system could be developed such that a single VLM could be associated with multiple landmarks (such as a primary store location, a secondary store location, etc.). Then, should the primary location be unavailable for any reason, the person using the VLM would be automatically routed to one of the alternate destinations
  • A round robin capability could be included, such that a single VLM is linked to a number of arrival points at the same destination (such as a club or an event that is liable to be popular, etc.). People using instances of the VLM are then automatically delivered to the different arrival points in turn, helping to prevent overcrowding at one particular point
  • Duplicate names could be supported for VLMs through the use of asset UUIDs (so there could be many VLMs called “My Beautiful Store”, and asset UUIDs could be used to ensure a VLM sends a user to the correct destination
  • As with LMs at present, VLMs held within peoples’ own inventories can be renamed without affecting their function
  • The system does not prevent the direct use of landmarks.

While there is some potential for griefing within the proposed system (people maliciously creating an VLM with the intention of flash-mobbing a venue or mis-directing people to a location, for example), the risk is probably no greater than is currently the case with the use of landmarks. Griefing via the use of VLMs might even be easier to limit, as LL would have control of the Mapping Service and so could effectively remove / disable VLMs shown to have been created with malicious intent.

Continue reading “Virtual Landmarks: solving an age-old problem?”

Mesh content creation: morph targets proposal

The Content Creation Improvement Informal User Group has started work on putting together an exploratory proposal for consideration by Linden Lab on the subject of morph targets.

Morph targets (also known as shape targets, per-vertex animation, blend shapes, shape interpolation in some 3D applications) are generally used for complex animations that would otherwise be hard to accomplish with skeletal animation – such as facial animation and avatar customisation. In this latter respect, the SL viewer already uses morph targets to a degree.  The proposal being drafted is aimed at the implementation of a more widespread use of morph targets, for use in such areas as:

  • Complex facial animations on rigged meshes
  • Additional ways for a user to customize the appearance of their avatar
  • Animating the surface of a prim without the need to use a custom skeleton
  • Fine grained control for content creators over how their clothing and avatars deform
Morph targets: animating facial features

It is with regards to this last bullet-point that morph targets are particularly interesting to content creators, as they are seen to have significant potential advantages for clothing deformation than might otherwise be offered by either the parametric deformer, or RedPoly’s alternative approach.

The proposal outlines some of the drawbacks in the latter two approaches, and covers some of the advantages and issues in adopting morph targets. One advantage in using morph targets is that they would allow a content creator to “sculpt” how a morph target should appear, directly within their 3D application of choice, thus giving them the ability to directly control over how a mesh deforms around an avatar (or how a rigged mesh replacement avatar deforms around the base avatar). A potential issue with the approach is that morph targets require additional information to be encoded either within a mesh, or within a texture. This means that additional bandwidth will be required to transmit any mesh which uses morph targets.

Morph targets: a better means of getting mesh clothing to deform?

As it stands, the proposal is in its early phase, although the intention is to complete it and submit it to LL for consideration and feedback as soon as it is felt enough information has been put together. Geenz Spad, co-chair of the CCIIUG, is aware that at the moment, much more input is required in order to get to that stage.

“There could be more input with regards to the content creator’s and the technical perspectives,” he commented to me in discussing the proposal, “The biggest bottleneck is just getting enough input to finish the proposal at this stage.” Of the two perspectives, Geenz feels that it is the technical side of things that is perhaps the more lacking of the two and he would like to see more input from those of a technical mind in terms of potential feature implementation, advantages, disadvantages, possible issues, and so on.

If you are in a position to provide input to the proposal itself, your views would be most welcome, as would your presence at the weekly CCIIUG meetings, which take place every Tuesday, from 15:00SLT at the Hippotropolis Auditorium.

Related Links

Mountain Lion issues for SL viewer

An issue has emerged trying to use the Second Life Viewer on Mac systems running OS X 10.8 Mountain Lion.

Notification of the issue has been posted to the Grid Status Page, which reads:

Issues Opening the Second Life Viewer in MacOSX

[Posted 8:30am PDT, 1 August 2012] Some residents may be experiencing problems opening the Second Life Viewer in a MacOSX Mountain Lion environment. This is due to a security feature of this operating system which is misidentifying some programs as potential security risks. While this is not indicative of any actual issues with our software, we are working on an update to our viewer which should address this. In the meantime there are instructions on how to bypass this feature temporarily, as well as an explanation of the cause of this issue, here:

http://osxdaily.com/2012/07/27/app-cant-be-opened-because-it-is-from-an-unidentified-developer/

Please note that this is not a problem with the viewer, and that we are not responsible for the workaround above – we are merely providing a link to a possible fix posted by a third party.

If you are experiencing issues using Second Life on Mac OSX, you might try the workaround noted above – but again, please note, as the report states, it is a link from a third-party, and Linden Lab (nor I) cannot be held responsible if the workaround fails or causes other unforeseen issues with your computer.

LL announce “first set” of advanced creator tools now live

Yesterday, as I reported, Linden Lab rolled-out the first pass of the advanced creator tools across the main release channel for the grid. These are the functions that lead to an outbreak of griefing when they were first rolled-out on the Magnum Release Channel back in June.

Since then, the code has been revised – and now includes a “master switch” that allows Linden Lab to disable the functionality should anyone try to get up to mischief using the tools. The code was in fact enabled on both LeTigre and BlueSteel last week without major incident, and so the code was rolled-out to the main channel in an enabled mode on July 31st.

Today, LL has formally announced this initial release of the tools via a new blog post. This initial release comprises three new functions:

These functions should allow a range of new experiences to be created, some of which are demonstrated in the Linden Realms game, wherein the attachment option is used to attach the game HUD to avatars and the teleport options are used in conjunction with things like the rock monsters.

Linden Realms HUD (top left): attached using the full experience tools

The functions are also designed to be used with a new permissions system, which has yet to be rolled-out across the grid. This means that until the new permissions are rolled-out, some of the functions will not operate as transparently as they eventually will. For example, rather than something like a HUD being automatically attached to your avatar (as is the case with the Linden Realms game, which does use the new permissions system), you will be prompted to accept the object first (thus making you the owner) in order for it to attach.

It’s not currently clear as to when the new permissions system will be rolled-out, but with the “master switch” at their disposal, Linden Lab are confident that the kind of issues that marred the June RC roll-out can be avoided.

The official blog post includes a video from Torley.

Lab offers snapshot “tiling” fix

Update: The tiling fixing reached the SL viewer in December 2012, and has subsequently been incorporated into the majority of TPVs. Please refer to your preferred TPv developer for information on the fix (MAINT-628), if unsure.

The ongoing issue with taking high-resolution snapshots resulting in “seams” appearing in captured images may have a final fix on the way.

The issue was initially reported in JIRA MAINT-628 at the end of 2010, and has impacted viewer releases since then, becoming the subject to intense investigation by users and LL alike. The problem has tended to make itself known when taking images at a higher resolution than that of your monitor, resulting in lines breaking-up the captured image, as shown below.

The problem (image courtesy of Dil Spitz)

In reporting the fix, which has a couple of limitations, Runitai gave the following update on the JIRA:

Runitai Linden added a comment – 18/Jul/12 1:57 PM

Fixed in viewer-cat

Fix was to use a large render target for snapshots that are larger than the window, but only when lighting and shadows is enabled. Screen space effects will still show seams when lighting and shadows is disabled.

If the graphics card is unable to allocate a single render target large enough for the high res snapshot, the old method of tiling is still used. On my GTX 580, I could take artifact-free snapshots up to 3500 pixels wide, but could not allocate a full set of render targets at 4000 pixels wide, so the old method is used.

Changes involve an invasive set of changes to LLRenderTarget, so QA should be careful to check various shadow modes, ambient occlusion, depth of field, and anti-aliasing with lighting and shadows enabled. Running with Debug GL enabled will likely cause a crash now when taking high-res snapshots (expected and acceptable behaviour), since the driver reports “out of memory” when trying to allocate a large render target. When Debug GL is not enabled, the viewer handles this error condition gracefully and continues to function.

The code is in a changeset, and will be going through LL’s QA testing. If all goes well, it will hopefully progress through viewer release cycle soon.

CCIG: Calling builders and devs

As I’ve previously reported, the informal Content Creation Improvement Group this week had its second meeting, the majority of which revolved around mesh deformation and the available / potential options.

While the current emphasis on mesh is understandable given all that is going on, the focus of the group shouldn’t be thought of as being “only” about mesh. As I commented in my piece announcing the group:

 It is intended for developers and content creators alike, with the aim of providing a collaborative atmosphere which will allow members to discuss features, workflows, and modifications with the aim of enhancing content creation for everyone on SL. As such, the focus of the new group will be:

  • To provide a forum in which content creators can voice their ideas and / or concerns about the overall state of content creation in SL
  • Encourage the spread of knowledge about content creation methodologies and tools
  • Suggest / discuss new ways to facilitate content creation in SL (including the use of new tools or possible improvements to the viewer)
  • To provide a focal-point where content creators can have questions answered and issues highlighted that might otherwise go unanswered in other user groups.

This being the case, Geenz Spad, the CCIG’s chair is keen to see more participation in the group from TPV developers – to whom he put out a request in this week’s TPV/Developer’s Group meeting – and from content creators and builders from across the grid, “It would be nice to have some feed back on other content creation issues that don’t necessarily centre on mesh,” he commented to me immediately prior to the TPV/Developer’s meeting on Friday, “I’m sure there’s plenty of builders who’d like some progress in making their workflows easier as well.”

One potential area for discussion is that of the build floater. This has already received various degrees of attention within various TPVs, with some adding extra tools and capabilities (such as the prim alignment tool) others even giving it a complete overhaul in terms of presentation. Capabilities such as pathfinding, which sees an additional information panel added to the Build floater, stand to make it even more crowded. So there is a question to be asked as to what might be done to update / improve the floater in order to provide better access to tools and options – and this potentially falls into the remit of the CCIG.

The current official build floater (l) and the Pathfinding build floater (r)

Of course, TPVs are free to determine how they wish to develop floaters, etc., for their audience – and they do take a lot of feedback from users in doing so. But the CCIG offers an opportunity for developers and creators to work together on ideas and to develop proposals that can be fed back to Linden Lab and possibly influence their thinking on things – and even help them determine what needs to be done in order to make the tools and floaters with the viewer more accessible and user-friendly.

Given the CCIG is still formulating itself, now would be an ideal time for builders and creators who haven’t previously attended meetings to pop along and get a feel for what is going on.

There is a wiki page which contains the meeting agenda and links to meeting transcripts. If there is something specific you would like to see discussed, drop Geenz Spad a line in-world to have it added to the agenda. Meetings themselves take place every Tuesday at the Hippotropolis Auditorium in SL, commencing at 15:00 SLT. See the links below for more details.

Related Links