Category: SL Tech

Pathfinding: llVolumeDetect(TRUE) and Land Impact changes

Posted on by Inara Pey

There are a couple of changes in the works relating to the forthcoming arrival of Pathfinding in Second Life.

llVolumeDetect(TRUE) Exploit

In the first, the use of llVolumeDetect(TRUE) to create partially phantom linksets will no longer work. Always something of a system exploit / hack, this approach has nevertheless seen widespread use across SL in buildings and vehicles. So much so that when it was discovered that the hack no longer worked in the Pathfainding test regions, it was initially reported on the JIRA as a Pathfinding bug (Pathbug-69).

However, as Falcon Linden points out in the “bugs” JIRA:

Thanks for your interest and passionate comments. First, let me address one of the root issues here: reliance on undocumented behavior that is known to be a bug. I realize that there are many cases of this in SL. I also realize that all of us, as game developers either in RL or SL, will do whatever it takes to implement a feature we want, even if that means exploiting known bugs or idiosyncrasies. The problem is that continued development of a platform (e.g., SL) often precludes backwards compatibility, particularly when systems have exploited “micro details” of the platform. 

Which is not to say Linden Lab is unsympathetic to the issue. Far from it; as in the same statement Falcon goes on to explain:

All of that being said, we as SL developers continue to try to preserve backward compatibility where we can. In this case, I have been able to find a compromise between new features and existing content. Here’s how it will work:

1) If a linkset uses the hack and also uses new accounting (aka mesh accounting or land impact), the first time it is rezzed on a pathfinding sim the hacked prim will be set to physics shape type none. Since the linkset already uses new accounting, this will not negatively impact land impact (in fact, it might reduce your land impact). It may affect a small amount of content that relies on link number of higher numbered prims in collision events by way of llDetectedLinkNumber()

2) If a linkset uses the hack and does NOT use new accounting, the relevant prims will be modified such that they collide only with the terrain. Other than that, behavior should be unchanged. This may impact some land vehicles that previously had hacked phantom prims which did not collide with the terrain.

3) No new linksets can be created that use the hack, and any linking or unlinking event (other than seating an avatar) will remove the hack on existing content.

This should address most of the concerns here. In the future, to create content where only some prims are involved in physics collisions, you will have to use the physics shape type feature.

Ergo, while the arrival of Pathfinding will herald a closure of the llVolumeDetect(TRUE) exploit / hack, LL are attempting to ensure that the impact of the closure in terms of content breakage will be minimal – if it is noticed at all.

Changes to Land Impact Calculations

Coupled to the above change is the announcement that Linden Lab is looking into changing how Land Impact is calculated as a part of the overall Pathfinding roll-out. Nalates Urriah was the first to break the news on the proposal, which  will bring a greater degree of granularity to Land Impact increases.

Under the current system, adding scripts to linksets can result in a sudden (and sometimes dramatic) leap in the Land Impact value. With the proposed changes, this will no longer be the case, with changes resulting from the use of scripts being more gradual. Speaking at the Simulator User Group meeting attended by Nalates, Falcon Linden explains the proposed changes thus:

[17:00] Falcon Linden: Changes to Land Impact that you’ll actually like for a change!
[17:01] Falcon Linden: We’re changing streaming cost for prims to be capped at 1.0 and we’re changing server weight to be: 0.5 * num_prims + (0.25 * num_scripts) but capped at num_prims
[17:01] Falcon Linden: so instead of going from half prim count to prim count by adding one script, it will be a more gradual change to encourage fewer scripts
[17:01] Falcon Linden: right now it’s not capped 
[17:03] Falcon Linden: okay
[17:03] Falcon Linden: here we go
[17:03] Falcon Linden: I have here a linkset of three distorted torii
[17:03] Falcon Linden: The two child prims are shape type NONE and the root is convex hull
[17:04] Falcon Linden: under the current scheme, its download weight is 13.7, its physics weight is 1.6 and its server weight is 1.5
[17:04] Falcon Linden: total LI 14
[17:04] Falcon Linden: under the new scheme, download weight will be 3, the other weights will be the same in this case, and the overall LI will be 3
[17:05] Falcon Linden: if I add one script to it now, the server weight will go from 1.5 to 3.
[17:05] Falcon Linden: In the new scheme it will go from 1.5 to 1.75.

It should be noted that the latter change is still very much a proposal, although it does appear that it is more than likely to go ahead, given it is beneficial to both Pathfinding and the platform as a whole.

With thanks to Innula Zenovka.

Dolphin 3.3.5.23763: One for the machinimatographers

Posted on by Inara Pey

dolphin-logoLance Corrimal is keeping up a rapid series of releases to his Dolphin Viewer, averaging around one release a week of late. Most have contained nips and tucks or have been driven by SL requirements such as Direct Delivery. However, at the beginning of March he rolled out the “Fujiyama edition” (version 3.2.9.23177), aimed specifically at SL photographers.

With his latest release, 3.3.5.23763, issued on Saturday April 28th and code-named “Fellini”, Lance adds functionality to his Viewer that is specifically aimed at machinimatographers – the code-name clearly being a reference to the late Italian film director Federico Fellini

The functionality in question comes in the form of an adaptation of  Marx Catteneo’s machinima floater. In this the release is somewhat serendipitous for me, as I also linked to one of Marx Catteno’s marvellous videos on the 28th to highlight the architecture of this year’s Fantasy Faire.

In integrating the floater into Dolphin, Lance has modified it slightly so that information is tabbed for easier reference, especially when used on smaller screens, and while it may be aimed at the machinimatographer, it contains a lot of options that SL photographers are liable to find very useful.

The floater can be accessed in one of two ways:

  • via WORLD->MACHINIMA TOOLS in the menus
  • via a dedicated toolbar button called MACHINIMA TOOLS, which has a nice little movie camera icon (note that the button is not active by default, but must be dragged out of the Button Toolbox).
Using either option opens a compact panel, sized to display on laptop screen as well as larger monitors.
Machinima Toolbox with Graphic tab open

The toolbox essentially provides fast, single-point-of-access to a range of Preferences options as well as to a number of other panels and functions, allowing the machinimatographer / photographer to quickly and easily carry out a range of tasks such as enabling Windlight presets for the sky and / or water, adjusting their camera / flycam, enabling / disabling lighting and shadows, adding / adjusting depth-of-field, adjusting shadow and occlusion settings and much more besides.

Each of the tabs in the label is clearly laid out, and some benefit from having certain functions disabled (grayed out) until such time as their controlling option is enabled. In the Graphics tab, for example, the drop-down for selecting the required lighting types (None, Sun/Moon, Sun/Moon+Projectors), is disabled until the LIGHTING AND SHADOWS option is checked.

Rather than waste words describing each of the tab, here is a set of screen captures for the remaining tabs in the floater:

Camera settings
Shadows & Occlusion
Depth of Field
Glow
“Miscellaneous” – currently derendering options

The derendering options are liable to prove useful for eliminating bystander avatars who are having a detrimental impact on camera movements, etc., when trying to shoot a video, while the “Miscellaneous” tab as a whole leaves room for further options to be added, should they be required / possibly requested.

Other Updates

As well as the machinima options, the blog post for the release notes the following updates are also included:

  • Getting a worn attachment into edit by right-clicking it in your inventory and selecting “Edit”-
  • Opening a Landmark on the map from your inventory, similar to what you can do from within the Places window.

Performance

I’ve not been able to thoroughly test the release in my usual manner due to time constraints elsewhere. However, in the tests I did perform, using my home sim as usual (3 others present in the sim) and both PC and Viewer set to my usual defaults (see the panel on the right of this blog’s home page), I found this release of Dolphin performed as well as other recent Viewer releases from the majority of 3.2-based TPVs. Running with deferred rendering off (no shadows / lighting enabled), the Viewer comfortably ran with an FPS in the mid-30s at 390m, with this increasing to the low 50s at altitude on my build platform (2850m). At ground level, the rate dropped very slightly to average at around 30-21 FPS.

Enabling deferred rendering and setting the lighting option to Sun/Moon+Projectors saw my frame rates fall to around 19-21 FPS at 390m, and to the mid-teens when at ground level. This was again pretty much in keeping with recent releases from the likes of SL and Firestorm.

Overall, an interesting new addition to Dolphin which should prove to be of interest to those interested in both video and photography.

Related Links

Niran’s 1.33: super smooth and totally flexible

Posted on by Inara Pey

Update, April 30th: Niran has released a fix for the pink texture issue affecting those using ATi graphics systems. Details are on his website, with a download link.

Earlier this month I took a quick look at the Preview Release of Niran’s Viewer 1.33, focusing on the UI work NiranV Dean has been carrying out within the release – part of an ongoing project to provide a more efficient Viewer front-end. Today sees the launch for the final version of 1.33, and in NiranV’s own words, this is a “major, major release” for a wide range of reasons. As promised in my last report on the Viewer, I’ve taken time to have a nice, long play with the Windows version.

TPVD Listing

First and foremost, after a long and incredible development curve, Niran’s Viewer has been accepted for listing in the Third-party Viewer Directory and should appear there in the next week or so – congratulations to Niran on all the work that has gone into the Viewer, and to Tarnix for the development of the Linux version.

Two Versions

The 1.33 release comes in two flavours: without and with the Mesh Parametric Deformer. The reason for this is simple, the code doesn’t set well with the Viewer – which might be, as NiranV acknowledges, due to issues with the Deformer working on his development hardware, but which could also be related to conflicts between the code and the Viewer’s rendering pipe. However, as NiranV notes in his blog: “You should be able to experience the Deformer mostly normal if you activate Deferred, Shadows and Ambient Occlusion, meaning that the separate release is only for those who can run [in this mode] and [who] want to test it to give Qarl Feedback.”

Installation

The Windows installer package weighs-in at 40Mb, and now creates a desktop shortcut icon (yay! no more hunting through Explorer and shunting bits around). Installation itself is, as always, fast and smooth, with the change log displayed in the opening window for those who are curious but who haven’t actually delved into Niran’s blog to read the information there.

On start-up, and for the first time with Niran’s Viewer, I did encounter a virus threat warning from AVG. This is something that is not uncommon among Viewers, with a number of TPVs (and the odd release of the Official Viewer) throwing up warnings on occasion. It certainly be taken to mean the Viewer is up to mischief. LL themselves provide some guidance on avoiding false threats. As the alert was related to the slplugin.exe file (a common cause of false virus alerts), I felt confident in marking the alert as a false flag and continuing.

The UI

As mentioned above, the User Interface is very much one of the focal points of NiranV’s work on the Viewer, and I took a look at some of the upcoming features in my overview of the initial Preview release. As such this is the logical place to start with this look.

The first noticeable thing with this release is the on logging-in the UI is extremely clean and minimal. with both bars and buttons only appearing at the top of the window, rather than the top and left, as with earlier versions.

UI: functionally minimalist

The buttons displayed by default are Speak, Voice, People, Picks, Places, View, Inventory and Appearance, which represent an interesting mix and which, in a nod to Kirsten’s Viewer, are initially displayed in “S19” format. There’s still no option to left/right align buttons either at the top or the bottom of the window (or to the top/bottom of the window if you place buttons on either side of your world view), so I’ll keep pestering NiranV on this :).

If I’m totally honest, the top button bar is something I’m personally not overly keen on: when active, it actually blocks the uppermost section of the screen from use, so you can’t “dock” (or more correctly in the case of the 3.2 FUI align) floaters with the top bars: there will always be a gap. But this is just a personal niggle on my part.

A nice touch with Niran’s Viewer, for those who don’t use the top of the window for anything at all, is the ability to hide the Navigation Bar, etc., at the top of the screen completely when not in use (the mini-Location bar is automatically displayed in its place) by setting Preferences->User Interface Options->UI Customisation->HIDE TOPBAR AUTOMATICALLY. Introduced a couple of releases ago, this is still something I like rather a lot, given I don’t use the top button bar.

In terms of the button options, Niran’s Viewer presents pretty much the standard set of buttons that come with the Official Viewer, so there is not the massive range of buttons that are displayed by other TPVs – which itself isn’t really a problem. One Button that does make its debut with this release is the SCRIPT button, which opens the Script Information floater.

Colours

When it comes to colours, Niran’s Viewer presents the most customisable UI of any Viewer, something I’ve again covered in the past. With this release, NiranV adds a new tweak to the use of colour: to denote options in both menus and Preferences tabs which may result in Viewer issues and  / or crashes, or which should be used with caution on the part of users unfamiliar with them. Those options where caution is advised are coloured orange with this release, with the more experimental / specialised options coloured red (see right). NiranV indicates that these colours may change with a future release, but the idea is certainly a good one in terms of being a visual indicator (although there is a risk colouring an option will encourage people to “click and see”).

In a slightly tongue-in-cheek move, NiranV has coloured the option to Exit the Viewer red because after all, as he says, it does close down the Viewer and logs you out of Second Life!

Fix it!

A new addition to UI floaters comes in the form a pin icon in the top right corner of most (not all) floaters. Called “Fix it!”, this locks a given panel in the position in which it is currently displayed on-screen.  Once active, the floater cannot be accidentally dragged elsewhere on the screen. For those involved in activities such as photography, machinima and combat, I imagine this could prove a useful option. The option is also likely to appeal to those who like to have certain core panels (such as inventory) function in a similar manner to when the Sidebar was available (i.e. always appearing on the right of the screen), as they can “lock-in” the floaters to do so – although in the latter case, it should be noted that the functionality currently isn’t persistent between re-logs, although this should be fixed in a future update.

Frame Rates

All Viewers include the option to include a “lag meter” in the top right corner of the menu bar, which shows the Viewer’s performance in terms of a colour-coded graphics bar. NiranV has improved this by allowing you to toggle between the bar and a numeric frame rate display.

Again, this is only a subjective measure of performance, but for those puzzled as to whether the traditional bar is indicative of good or bad performance, the numeric display should help clarify matters.

Super Smooth

The bet way to describe using the Niran’s Viewer UI is smooth. That you’re in something very different to other Viewers is evident the first time you move your camera view – everything pans and slides very smoothly, almost as if you’re on a cushion of air, with motion gliding to a gentle halt. Of course, you can achieve the same in other Viewers by altering your camera movement options, but NiranV has done it for you, making the entire experience a lot .. well … smoother.

This approach can be seen elsewhere in the Viewer, particularly the way options and sub-panels in floaters slide gracefully in or out of view. Take a look at one of Niran’s excellent videos for a practical demonstration:

Preferences

Preferences are the clearest instance of significant changes to the UI. NiranV has done a considerable amount of work in this area to try to rationalise both the way in which Preferences presents options to us, and how we interact with it. A lot of this I covered last time around, but NiranV has continued to refine and improve.

Preferences: overhauls and rationalised

The first noticeable thing on the redesign – at least for those who used the Preview 1 release of 1.33, is that the Preferences panel now auto-sizes itself correctly according to your screen resolution; there are no more scroll options to the left / right of the panel as described in my look at the initial Preview release.

Those coming to Niran’s Viewer for the first time are liable to find the Preferences panel something of a “?!” moment when first opening it; who wouldn’t after the basic layout of the panel having remained pretty much unchanged (other than for custom tabs) almost since the dawn of time? However, I have to say that, with a couple of very minor reservations, NiranV has produced an alternative Preferences panel that makes a heck of a lot of sense and encourages fast, easy use.

At the top are five major category tabs, most of which are pretty self-explanatory. Each of these has up to three sub-tabs (displayed at the bottom of the floater) which help rationalise and order functions and options. Additionally, some tabs may have context-specific options that are only display when certain options are enabled (such as with advanced rendering in the Display and Audio tab, or many have additional toggle buttons on the right to shift between sub-groups of options.

Continue reading “Niran’s 1.33: super smooth and totally flexible” →

Mesh Deformer 0.3 code available

Posted on by Inara Pey

Update: Sometimes working on multiple posts to your blog isn’t a good idea. Between drafting and pushing this one, Qarl updated his code, as Cinders points out. Sorry Qarl! Correct link is here. 

Slightly later than he’d hoped, but keeping to his promise, Qarl has released version 0.3 of the Mesh deformer, stating:

Quick announcement – I’m releasing version 0.3 of the deformer code. Primary changes: 1) should now apply cleanly to recent linden viewer code, 2) deformation tables are computed in the background on another thread, so no frame stalls.

There appear to be a couple of elements missing from the patch – as spotted by Henri Beauchamp in a comment following Qarl’s post, so developers may want to hold-off grabbing the code for a bit.

I’ll be watching the various Viewer blogs for updates to see when the patch is incorporated. It’s likely to make an appearance in the likes of Cool VL and Dolphin very rapidly, providing the code is stable. Niran V Dean is planning to make a Full release of Niran’s Viewer 1.33 in the next couple of days, so this might also see the code included – we’ll have to wait and see.

Linden Lab had a Development Viewer in the offing for the deformer. This actually dates back to January, but didn’t get any further than an optional development Viewer due to assorted issues. Marine Kelley, who uses the V.3.2 reported that she’d removed the deformer from her last release due to crash issues, which may be related to reasons why LL never moved the code further along their Development cycle. However, as Qarl appears to have specifically addressed some (or all) of the issues, we may yet see the deformer appearing in something like an official Project Viewer sooner rather than later.

Viewer release summary 2012: week 16

Posted on by Inara Pey

This is a weekly summary of changes to all SL Viewers / clients of which I’m aware and which are in popular use across the grid / listed in the TPVD. Detailed links to said Viewers / clients can be found in my Viewer Round-up Page. The links supplied in this summary are either to change logs or to reviews within this blog.

Updates for week ending: 22 April, 2012

  • The SL Beta Viewer rolled to 3.3.1.254008 and Development Viewer rolled to 3.3.2.254043, which includes the new local textures viewer (textures can be used in builds, but will only be visible to you; other users will see them greyed-out) – both released on the 17th April
  • Dolphin reached a jumbo number, 3.3.3.23747, code-named “Armageddon”, which includes Linden Lab’s “local textures” solution integrated into it, replacing the code common to most TPVs (note this doesn’t replace the “temporary upload” option within the image upload floater), together with the single AO “button in a button” solution that has been appearing across V3.2 TPVs over the last few months. Lance explains the “Armageddon” code name in terms of a video clip, which kind-of has a link back to “747”…
  • Niran V Dean has rectified recent computer issues, making a 2nd PREVIEW release of version 1.33 of Niran’s Viewer. This includes a hosts of tweaks, a number of very cool additions (including two excellent camera presets and make a large number of fixes, include implementation of assorted STORM JIRA. I’ll be reviewing the full release of 1.33 in-depth in the near future
  • Zen Viewer passed rapidly through version 3.3.2.8, and reach 3.3.2.9 with various fixes and tweaks in both
  • Cool VL Viewer rolled out 1.26.4.9. Among the changes made are a number of LSL support updates and a fix to the Linux version to prevent the Viewer crashing when uploading rigged meshes

Related Links

Parametric deformer: Qarl updates (2)

Posted on by Inara Pey

It’s been a while since we’ve had news on the mesh parametric deformer project.  So it was good to hear Karl Stiefvater (Qarl Fizz, formerly Qarl Linden), the man behind the code, to provide a brief update on matters in this week’s  Metareality podcast:

[27:58] Sorry guys; so here’s an update on the deformer. I have been obscenely busy in the last three months work-wise, and I have not had the chance to work on it much. That said, I did start working on it again on Monday [the 16th April] and I should have a release this weekend … The deformer’s going to happen, you don’t need to worry about that. Linden Lab has committed to getting it working; if they reject it for dumb reasons, I think that would – while they’ve done dumb things in the past, I don’t think that will happen; that would surprise me.

Given that there have been unfounded rumours circulating that Linden Lab are trying to “kill” the deformer  – which seem largely based on the premise that the project doesn’t appear to be progressing as fast as some people believe it should – hopefully, Karl’s update will set matters to rights, and see an end to such rumours.

For my part, I’ll be keeping an eye on Karl’s website at qarl.com, and will relay any news that is forthcoming.

In the meantime, there has been an interesting discussion going on within the SL official forums relating to standard sizes in SL and mesh. It’s worth a read and gives pause for thought – particularly Max Graf’s very considered input to the discussion.

Related Links

With thanks to Gianna and the Metareality podcasts.