Linden Lab has recently acquired the right to sub-licence the Havok physics engine technology used within their Viewer. This has resulted in the Lab issuing new guidelines to third-party Viewer developers wishing to incorporate advanced Viewer capabilities developed using the Havok technology within their offerings.
The guidelines read in part:
The technology is provided in the form of an autobuild package ‘llphysicsextensions’ containing header files and the required library. This does not directly expose the Havok APIs, but a set of higher level interfaces specific to the viewer. Sources for the wrapper itself will not be open source. The llphysicsextensions package includes all features that use Havok (currently convex decomposition and features related to navigation mesh for pathfinding).
This move is already a subject of debate among TPV developers and the OpenSim community, because the sub-licence associated with the guidelines appears to place clear restrictions on TPV developers, notably in clause (b) of the Conditions to Grant, which reads:
(b) Sublicensee must require the Third Party Viewer to connect only to servers owned or operated by the Company; [i.e. Linden Lab]
So if a TPV developer wishes to work on both Second Life and OpenSim, they’ll have to look at options very carefully, as Maria Korolov points out in Hypergrid Business.
Within Second Life, there is concern as to what this may mean for some TPVs – specifically those utilising GPL rather than LGPL. Such Viewers appear to be effectively excluded from applying for a sub-licence. While this will not prevent such Viewers from accessing Second Life, it does mean that they’ll be excluded from using code that implements the Havok capabilities. The requirement for TPVs wishing to obtain a sub-licence being required to be publicly listed on the Third-Party Viewer Directory may also have a negative impact in some quarters.
The flip side to this, however, is that it means Havok physics will effectively be in the Viewer itself, which could pave the way to many new enhancements and capabilities within Second Life. As such, it is far to say that the move to sub-licence the Havok engine is less about LL attempting to restrict Viewer development per se (the apparent attempt to push out V1-based Viewers not withstanding), but rather to provide a means by which they can integrated what is effectively a closed-source, licenced product (Havok) into what is essentially an open-source project (the Viewer) without breaking the terms of their agreement with Havok.
The program itself is not available as yet, and discussions within the community are ongoing, with TPV developers aiming to seek further clarification from Linden Lab on possible impacts on their work – again, specifically where OpenSim support is concerned.
Inara Pey: Living in a Modemworld 
Well, to be honest, I don’t think that the real reason is to deal a serious blow on TPVs. LL has toyed in the past with the idea of putting Havok on the viewer because it would allow them to push a lot of calculations into the viewer and not on the server. I suppose that, long-term, this might mean that the sims will be “lighter” — far less complex calculations to deal with — which has some interesting consequences: with assets pushed on the cloud, and collisions and similar physical issues pushed on the viewer (like pretty much every 3D MMORPG does…), it could mean that on the server-side this becomes so simple that LL might — MIGHT! — start seriously considering the following:
a) Increase avatar limits. If all avatar-to-avatar and avatar-to-object calculations happen client-side, the sim will not be affected with a thousand avatars in it. Of course users will experience lag: but that will all be client-side and depend on one’s computer.
b) Allow way, way more physical-based effects, as they won’t harm the sims. Think Half-Life or anything done within a modern FPS.
c) Increase Land Impact limits. After all, the server will not need to worry about all those prims any longer, just track where avatars are and what they’re doing.
d) Reduce land tier! After all, LL might be able to squeeze more sims per server. I read once that each WoW shard, running on a single server, could deal with 20,000 or more simultaneous users. This might have changed, but consider that nowadays, a 16-core-server can handle 16 sims with, at best, 1600 users (and that’s truly stretching the limits of feasability!). Maybe in the future a 16-core-server could, say, allow 10 times as many sims, and, consequently, LL could slash the costs of a whole region to 10% of the current value and still draw a healthy profit — or get rid of 90% of their hardware costs, and survive financially even if a lot of regions get dropped.
Now this is no mean feat. By assuming that the sim knows exactly what is going on inside it — i.e. where avatars are in relation to objects and its complex inter-connections, thanks to Havok doing all the calculations server-side — this makes synchronisation issues rather easy. When most of the calculations are pushed to the client side, it means a much more complex way of keeping everybody in sync with what’s happening on the sim. Of course there are several methods for doing so — after all, almost all MMORPGs out there deal with this issue — but it requires a serious revamping of SL as a whole. Rod Humble seems to have the guts to do that 🙂 but it’s too early to say. Maybe the mixed approach — keep most of the data still being churned out server-side, while pushing some of the more esoteric functionality to the client — will remain around for a long, long time.
Of course, the TPV/OpenSim issue will remain open to discussion, but, in all fairness, LL is not really a major supporter of OpenSim, and would rather prefer that all TPV developers, instead of forking the code and using their “own” version of the SL Viewer, would contribute instead to LL’s “official” viewer. But the problem here is that the TPV developers are not aligned with LL’s vision of where the viewer should go.
This is a serious problem in handling open source development. Let me give you a good example: WordPress. It’s an open source project by Automattic. Everybody can contribute code to it. In effect, nothing prevents anyone to fork the code and start doing “their” version of WordPress instead, because, say, one does not agree with the way Automattic is heading their CMS. But this doesn’t happen. Why? Because all major developers and code contributors are really “in the loop” and co-decide with Automattic what to develop and where to go with WordPress. It’s a tightly-knit community with the same interests. Anyone “disagreeing” with the “mainstream concept of WordPress” does plugins to change WordPress’ behaviour instead of forking it and starting from scratch.
This ought to have been LL’s attitude towards their open source client: a community of eager developers who know where they want to push the SL Viewer, and have LL just as “part of the solution”, by agreeing to commit the changes as supplied. It was when it became obvious that LL was not interested in most of the code submissions — from simple bug fixes to implementing things like content backup, RLVa, and so forth — that LL’s viewer started to get forked like crazy, to an extent that allegedly the main viewer on the SL grid is not even LL’s own.
This hinders LL’s progress. They cannot simply change the whole way SL works overnight and tell people, “here, download the new viewer, and welcome to a new experience” — because the majority of SL users allegedly don’t use LL’s viewers. They could impose a fast pace of improvement until 2006 because they were the only providers of a SL Viewer. These days, the problem is that they lost control over a crucial bit of the pipeline, and it means that progress can advance only on one side of the environment (the servers) and, even so, by being very careful not to break access to all other TPV viewers — whose users, being SL residents, are prone to drop everything, sell their sims, and run away if LL does anything that slightly offends them. SL residents are an unruly crowd! (But faithful customers, after almost a decade of paying tier…)
It’s a very tricky thing. What LL should be doing is a completely new viewer — 4.0. Make it completely modular — the viewport (where the 3D scenes are rendered) totally independent of the rest. The whole rendering engine would be based on plugins, to be activated at will. The interface would be completely detached from the rendering engine (not unlike what the Radegast project is doing). Then LL would focus on the core issues and let TPV’s develop plugins to change all functionality at will. But there would be only “one” product, just different ways of using it. Need XML export? Add a plugin. Want a better radar? Install this plugin. Need to tweak the whole UI? Upload this theme template and tweak it. Have better graphics cards? Add this plugin which will make the renderer push even more data out of the CPU and into the GPUs on the card. Tired of high-lag IM group chat? Add this plugin and you’ll have IRC/Google Chat/whatever inside the viewer. And so forth. A specific “set” of extensions and plugins would be delivered by what today are TPVs, downloaded and installed by each user, and giving them a completely different (and new) experience to SL.
This is pretty much what companies like Automattic did. But of course Linux, MySQL, Apache, Mozilla, and hundreds of similar projects work precisely that way. Even Novell’s Mono works like that. The “core team” works on the main issues, and the community extends the core, by adding plugins and extensions and themes and templates.
This also avoids “political issues”. Suppose that thanks to their Puritan upbringing, a LL developer refuses to add RLV to the “core”, because they see it as being “too BDSM” and feel they have the moral right to tell people how they should behave in bed. That’s ok. The community would just develop RLV as an extension (which probably everybody would use, since it can be used so effectively beyond BDSM… I’ve seen a few fashion designers to use it as a way to demo clothes, for example).
Of course, this requires redesigning the whole viewer from scratch, and I’m pretty sure that LL won’t do it. It was one of the most ambitious dreams of the Imprudence team to separate the viewport from the interface, for example, to allow the UI to be changed and tweaked at will, and be themed/extended/plugin’d. But this takes too much time; the viewer is way too complex…
What actually surprised me was how much Radegast, using this “modular” approach, evolved so quickly to the point that it’s usable (on Windows only, though; for other platforms it’s still a regular text-base client), without using any of LL’s source code for the renderer. So there might be hope yet. We’ll see…
LikeLike
Agreed on all points. I don’t see this as a move against TPVs or OpenSim – although there seem to be some commentators out on other blogs who are up-in-arms over the move as they do see it this way.
I’m no expert on things, but can certainly, just from the reading I did last night to understand matter prior to publishing this article, see the potential benefits for having physics at the Viewer end of things.
As to the modular Viewer – and without name-dropping – this is something Rod Humble and I kind-of discussed not long after he joined LL, as it has long been something I think would be highly beneficial for SL as a whole (not that I have any influence!). It was something I also managed to raise with the “Future of SL” panel at SLCC-2011. Overall there was a very positive response to the idea (Rodvik indicated Bagman Linden would like nothing better) – but as you say it’s a massive undertaking, and everyone indicated that it’s not something that is going to be undertaken easily, even it if is on the radar at all in terms of future plans.
Still, we can dream and hope…!
Radegast is quite simply remarkable. Love it to bits, and then some.
LikeLike
On some we can agree, Radegast is very helpfull and not only for Second Life.
LikeLike
Hmm … Havok physics in the client. I wonder if I’ll have to add a new dedicated processor core to keep up?
LikeLike