Category: Other Worlds and Tech

Update: It appears the video referred to in this article wasn’t for public consumption, as it has been made fully private.

High Fidelity recently started alpha testing elements of their platform, which follows-on from a public call made in January via the High Fidelity website for alpha testers. The Alpha Sign-Up form is still available, and the client and other code is available through High Fidelity’s public code repository for those wanting to give it a go.

For those that do, Chris Collins (not to be confused with AvaCon’s Chris Collins / Feep Tuque!) from High Fidelity has produced a video (no longer open to public viewing) introduction to the High Fidelity client (simply called “Interface” by High Fidelity), which is designed to get people comfortable with using some of the basics, and which provides a useful means of gaining greater insight into the platform. I’m including a link here rather than embedding, as the video is currently unlisted, so I’m not sure how far he wants it shared, although I’ve dropped him a line to obtain an OK. In the meantime, I’ve taken the liberty of including some screen shots with this article.

Chris doesn’t run through the steps required to build the client, but instead takes launching the client (on a Mac system in his case) as his starting-point, which allows the initial “what you can do” screen to be displayed – a quick overview of what can be done with the current alpha release and also – possibly – a useful way in the future of drawing people’s attention to the very basics of using a client.

An interesting aspect with High Fidelity is that even with the alpha, many optional hardware devices – such as a Razer Hydra, Leap Motion, Kinect, PrimeSense, Oculus Rift, etc. – appear to be pretty much plug-and-play.

The layout of the client is remarkably similar to that of the SL viewer 3.x UI. At the top is a typical menu bar, while to the left and bottom of the screen are a set of toolbar buttons, all related directly to building, and which can be turned off/on by tapping the Tab key.  An interesting aspect of the UI is the inclusion of a picture-in-picture (PiP) frame, which shows you your own avatar, as seen by others. Whether this frame can be repositioned around the UI window isn’t clear from the video, but it does appear to be pretty fixed in place.

Even with a standard webcam, the system will pick-up the user’s facial expressions and translate them to the avatar’s face. As voice is the primary means of communication with High Fidelity (although not the sole means of communication – text is also possible), Voice Over IP (VoIP) is enabled on starting the client, and this is reflected in a sound level bar directly beneath the PiP avatar, which is graduated between blue, green and red, with the latter indicating that perhaps the microphone is being over-driven. There’s also a mute button to mute the sound of your own voice in your own headset / speakers.

The default avatar is a little robot, and the video demonstrates the easy with which this can be changed – although as an alpha, the avatars within High Fidelity, even with their facial expressions, are very basic which compared to the like of a grid-based VW; it’ll be interesting to see how far down the road towards detailed customisation the company will go, and how much further that takes them into the Uncanny Valley should they do so. Altering an avatar is done via menu selection and file name – there are no image previews of the avatars (as yet – something that would likely be better received by users).

There is an option to upload avatars of your own – but the format and complexity of such models isn’t explored in the video.

As the video progresses, building using voxels is demonstrated, and more particularly, the coalesced nature of the voxels is demonstrated – as Chris hovers a distance from the default @alpha.highfedility.io location, everything appears as voxel cubes of varying sizes, and doesn’t make for a pleasant-looking world at present. However, as he flies closer, the voxels “break down” into smaller and smaller units and reveal more and more detail. Again, I assume the overall “big voxel blocks” will be somewhat more refined and allow greater detail at a distance in the future, vis-a-vis Philip Rosedale’s discussion of the High Fidelity architecture and use of voxels, at the moment things are terribly blocky even from what seems to be a reasonable distance, and may draw unfavourable comparisions with something like Minecraft.

Anyone familiar with building in Second Life will be instantly familiar with building in High Fidelity; voxels, in shape, are analogous to the default cube prim, and even the way detail “pops-out” at you could be said to be akin to how the shape of sculpties pop-out in an SL-style grid VW, although obviously the underpinning technology is vastly different. There are also options to import / export voxel models, although as with the avatar upload options, there are outside the scope of this initial video.

Continue reading “High Fidelity: running the client” →

I’ve been trying to keep an eye on High Fidelity of late, particularly since things like the SVVR meet-up in March and VWBPE 2014 in April, both of which featured presentations / talks by Philip Rosedale. However, I missed a recent blog post on the High Fidelity site, so my thanks to Nalates Urriah for giving a heads-up about it.

One of the things that has caused people some consternation with high Fidelity is that while there have been various demonstrations and some talk about it using distributed computing (a-la Seti@Home) as an operating model, more precise information on the architecture for High Fidelity has been lacking.

The official blog post, dated Thursday April 24th, goes some way towards rectifying this, by providing a high-level system diagram for High Fidelity and providing some additional notes on the various aspects of how it is hoped the system will work.

High Fidelity won’t, as they’ve previously made clear, be providing a virtual word per se. Rather, they are seeking to provide the software and protocols which will allow others to create virtual worlds and connect to one another, and the means for uses to connect to, and move between these worlds as they become available. The idea here is that by providing the means to create fully distributable virtual worlds, harnessing shared computing devices to scale their content and load, thus theoretically making a scalable, global virtual environment with shared resources through which users can travel.

The top section of the diagram denotes those services where High Fidelity hope to generate revenue.

• The Nameserver allows virtual world domains to be uniquely identified if the owners wish (think DNS) – so that, as a totally hypothetical example, @secondlife could be registered to allow users to quickly discover and access Second Life. The registration service for virtual worlds is optional, rather than required. This service can also supply authentication mechanisms which can be used to both restrict access to a virtual world or allow users a particular virtual world to securely disclose chosen aspects of their identity.
• The Digital Marketplace is fairly self-explanatory, allowing people to buy, sell and transfer digital goods to and from each other, and move these goods among different virtual worlds.
• The Currency Server provides the wallet services and other API’s needed to allow people to quickly and easily share their computing devices as well as buy and sell digital goods using a cryptocurrency. Whether the latter will be a recognised cryptocurrency (such as Bitcoin) or something new, remains to be seen.
• The Assignment Server, allows people to share their computers with each other to act as servers or as scripted interactive content. It monitors and analyses devices which are made available as servers in order to try to assign them suitable tasks – so that a mobile ‘phone offered as a server might be used to control a scripted agent such as a dog wandering around a virtual world, while a high-end PC might be assigned more intensive tasks. This Assignment Server will also oversee the transfer of cryptocurrency between users, so that those providing their systems to help run a world are compensated by those making use of their computing capabilities to run their world.

Another core aspect of the system, which has been covered in various commentaries on High Fidelity, is the use of voxels, and more particularly, the voxel server, which stores and serves the content that is found inside the virtual world. Voxels can be nested within one another, or averaged together, allowing for significant levels of detail to be achieved over distances than is otherwise possible. The voxel server allows elements within a world to be distributed across multiple servers, so for example, an apartment block in a cityscape could comprise apartments which are each running on their own server.

The Voxel Server, together with the remaining elements of the software (the Domain Server which sits at the heart of any virtual world using the software and protocols, the Audio Mixer, Avatar Mixer, Interactive Client, etc.), are available under the Apache 2.0 open-source licence, Further information on them can be found in the High Fidelity blog post, and they can be downloaded from High Fidelity by those who wish to play with them.

The post has drawn a fair number of comments and questions, and as Nalates points-out, they make further interesting reading – particularly Philip Rosedale’s replies (or where some questions are concerned, lack of a reply).