Kokua catch-up

kokua-logoKokua was released on Friday 21st 2013, joining the in-development Black Dragon viewer (NiranV Dean) in becoming one of the first v3-style viewers to fully adopt Materials Processing.

I’ve been remiss in my coverage of Kokua’s development, which has been fairly steaming along over the last several months (the last update I gave was for Kokua 3.4.4 in January 2013), so this piece is a little bit of a catch-up on some of the major updates – such as SSB/A support – since then, starting with the 3.6.0 changes.

Straddling Worlds

Despite all the hoo-haw over the Lab’s move to sub-licence code libraries from Havok (a move which was incorrectly interpreted by some as being an attempt to stymie OpenSim), Kokua is one of the viewer which continues to happily straddle the SL / OpenSim divide by providing capabilities which work in both, as well as options specific to one or the other (such as SSB/A support for SL, and enhanced OSSL support and the ability ro disable SL’s build constraints for OpenSim use, for example).

Accepted onto the Linden Lab Thirty-party Viewer list in April, and listed in the Third-party Viewer Directory, Kokua avoids the Havok complication by providing pathfinding support without the navmesh visualisation capabilities (potentially no great loss to the vast majority of users) and by using the third-party mesh upload code for importing mesh objects, thus allowing it to comfortably span both environments.

3.6.0 Download and Installation

The Windows installer weighs-in at 36.3 MB, putting it towards the upper end of the installer list by file size, which is hardly surprising given the punch of extras the viewer includes. Installation itself was, for me, straightforward, the viewer neatly over-writing my previous version (I opted not to go my usual clean install route).

Firing-up the viewer yielded no anti-virus warnings from AVG Pro (which has recently being getting a little vociferous over SLplugin.exe of late with some viewer installations, despite having given it a pass in previous installs – the most recent flag going up with my installation of the latest SL viewer with materials support).

The current Kokua message of the day (MOTD) – coming from LL – raised a smile, using a little humour to underline the fact that SL users need to update their viewers.

A light-hearted reminder of the need for SL users to update to an SSB/A-ready viewer
A light-hearted reminder of the need for SL users to update to an SSB/A-ready viewer

Materials Processing Support

The release of Kokua 3.6.0 marks it as the first v3-style viewer to provide full viewer-side support for materials processing in for Second Life (if you’re on OpenSim, there are server-side updates required to make materials capabilities work, but there is already a preliminary effort to get these implemented).

The updated Texture tab of the Build floater
The updated Texture tab of the Build floater

If you’re not sure what materials processing means, please take a look at my primer provided for the SL viewer’s beta release.

As one would expect, materials support has been implemented as it is presented through the SL viewer: the Texture tab in the Build floater has been updated to provide support for normal and specular maps, which can be selected from a high-level drop-down (see right), and which include their own additional attributes (the “old” Bump and Shine options). Note that each materials map can be set with independent repeats and rotations.

Materials also includes some additional updates – the most noticeable of which is perhaps the ability to include an alpha mode when working with alpha masks. This can be set to one of:

  • None –  the alpha channel is ignored, rendering the face opaque, or
  • Alpha blending – essentially the same as we currently have for any alpha texture, or
  • A 1-bit alpha mask with each pixel either 100% transparent or 100% opaque, with a cutoff setting to determine where the threshold is (alpha masks should render faster than alpha blending, and eliminate issues with alpha layer sorting), or
  • Emissive mask – so the alpha layer is interpreted as a per-pixel glow setting.

Materials support also includes gamma correction capabilities within the rendering system. This may cause scenes to render more darkly than in non-materials capable versions of Kokua, and as reported with the SL viewer, may cause some alpha rendering issues.

Graphics Updates

Materials Processing has seen various other changes made to the viewer to improve rendering, some of which have resulted in improvements to the GPU support table, and adjustments made to the graphics defaults themselves. While these may have been included in versions of Kokua prior to 3.6.0, they’re covered here for completeness.

Graphics tab changes in Preferences and water reflections
Graphics tab changes in Preferences and water reflections

First and foremost, the Quality and Speed slider now has seven pre-sets instead of four, adding mid-point settings between Low and medium, medium and high, and high and ultra. These are designed to better reflect the capabilities of supported graphics cards and to determine whether or not a card has the ability to support materials rendering by default (whether you actually want it to do so is up to you). As such, you may find that if you’ve not updated Kokua in a while, your default graphics setting is different from previous versions.

The other notable change (again, if you’ve not updated Kokua in a while and haven’t been following SL viewer changes over the last few months) is that the “lighting and shadows” check box has been renamed “Advanced Lighting Model” (ALM), and the option needs to be checked in order for you to see materials capabilities being rendered in your viewer.

Finally, and purely by way of a side note, if you enable ALM in SL and find you’re having  issues with alphas rendering correctly with this release of Kokua (they appear entirely black), try changing Water Reflections (arrowed above) to anything other than Minimal. This may help resolve the issue for you. Another possible workaround for the “black alpha” problem is to disable ALM, click on OK to accept and close Graphics, then re-open Graphics and re-enable ALM.

Command Menu, Build Floater Updates and Look AT Options

The 3.6.0 release also sees a new Command menu implemented, which brings together those commands moved from other menus, popular commands and a number of chat commands imported from Firestorm and turned into menu options (such as “tp2cam” to teleport to your current camera location).

Additionally, the Build floater’s Object tab gets a port of the build parameters copy paste function from the (now defunct) Zen viewer as its implementation was newer than other LGPL licensed viewers, and which is completed with fine tuning tweaks from Firestorm.

The Develop > Avatar submenu also sees the inclusion of private Look At / Point At options and a “Cat mode” toggle (so the avatar’s head movements track mouse movement), all submitted by Jessica Wabbit.

Kokua 3.6.0: the Commands menu (l); the updated Build floater Objects tab with improved copy / paste (c); the new Avatar sub-menu options for Private Look At / Point At and Cat Mode (r)
Kokua 3.6.0: the Commands menu (l); the updated Build floater Objects tab with improved copy / paste (c); the new Avatar sub-menu options for Private Look At / Point At and Cat Mode (r)

Other Notable Updates for Kokua

  • Release 3.5.2 (May 2013) provided OpenSim Lightshare (think: windlight) support, with a port of Cinder Roxley’s work on the capability for the OpenSim version of Firestorm by Tx Oh
  • Release 3.5.1 (April 2013) saw Disable Build Constraints added under the Advanced menu. This feature is aimed at region operators who also build things so that the maximum prim limit can be set high in the simulator configuration and then be the prim size constraint controller. In the viewer the lower limit is zero so if the simulator limit were lowered from its present 0.001 meters very small prims are also possible. This allows large and small objects that can be transferred by the IAR/OAR procedures
  • Release 3.5.0 incorporated Server-side Baking / Appearance support for Second Life
  • Release 3.4.5 (February 2013) saw client-side animation override controls imported from Firestorm / Teapot and tested for OpenSim use,
I see no grey people: Kokua has been SSBA-ready for some time, and this image shows my CTA (l) on Kokua and myself (on the SL viewer) both rendering on Kokua 3.6.0 in the SSB/A test regions on Aditi
I see no grey people: Kokua has been SSB/A-ready for some time, and this image shows my CTA (l) on Kokua and myself (on the SL viewer) both rendering on Kokua 3.6.0 in the SSB/A test regions on Aditi


Kokua was an early adopter of SL’s Communications Hub User Interface (CHUI) update, designed to centralise communications in the viewer. I provided an overview of the initial Kokua CHUI release in January 2013, and since then the team have worked to keep pace with updates and bug fixes coming out of LL for the capability.

CHUI goes purple: the initial integration of the CHUI code into Kokua
CHUI goes purple: the initial integration of the CHUI code into Kokua


Kokua continues to be developed and enhanced at a good pace, easily matching the core development work going-on with other TPVs and even staying a few steps ahead of some of them.

Performance-wise on my usual system, it performed right up there with other recently releases by several TPVs, giving me no cause for complaints at all. Again, on a personal note, there are a few things I’d like to see the likes of Kokua and other v3-based TPVs adopt – such as the ability to left/right range toolbar buttons at the bottom of the screen (as first seen in Firestorm and more recently found in Catznip R8), and the implementation of a Quick Prefs panel of some description. However, a lack of these doesn’t detract from the viewer in any way – they are merely personal preferences.

For those who used both OpenSim and Second Life and who may not be overly enamoured of Firestorm, Kokua provides a very capable alternative with some very nice little nips, tucks, and touches.

Related Links

5 thoughts on “Kokua catch-up

  1. I’ve been a fan of Kokua for ages. I really like its simplicity, and appreciate that it keeps changes to its interface pretty minimal and cautious. It is this approach that allows it to adopt things like CHUI, SSA, and materials so quickly; it doesn’t have to wrestle with code from Linden Lab like other viewers might.

    Just a heads up for those playing with materials under OpenSimulator. It’s fun and educational, but expect it to break! The OpenSim developers are still tweaking code that affects how simulators store material data internally. The author of the materials module has expressed an interest in making it an actual release (as opposed to the demo it has been) soon, but not before next week at the very earliest.


    1. I think Nicky & co are doing a ecellent job with the viewer & in being able to comfortably bridge the gap between OS and SL.

      Re: the OS work with materials, please feel free to poke me about it as things progress (either that or I’ll be niggling you! :)), as I’d love to cover developments in more detail (I’m chomping at the bit to start applying materials to my Kitely Fallingwater build once the server-side code is out there and being adopted!).


      1. I shall wait for Simonastick to get materials, but by then it should be solid enough to rely on in SL too, I might even be able to sell some things by then (I don’t quite trust the Marketplace at the moment). I used some of this stuff in Poser, years ago, and it has potential, but I want to avoid having to make an incredibly detailed mesh so as to derive a normal map for the very simple SL version. With the right normal map, you can turn a cube of the right proportions into a wall, and the same for a lot of other stuff. Somebody needs to come up with a set of normal maps which work with the Library textures.
        (Maybe I should check the Library for changes)


        1. The question of providing the Library with sets of diffuse, normal and specular maps for building materials (walls, floors, rooftops, etc.) was actually raised a goodily while back at one (or more) of the User Group meetings. Think I actually have a reference to it buried in my Materials Processing project updates…somewhere. It was, I seem to remember, well received as an idea. Whether or not it is being followed-through, I have no idea (and actually haven’t checked).

          As to cubes and walls, that’s precisely why I’m waiting for the server-side of mats to make it to OpenSim. I have a large infrastructure set-up on New World Studio (think sim-on-a-stick but in a zip file for ease of explanation), so want to prototype there and then update my Kitely Fallingwater build (which is a “stone wall” build, so hoping to radically improve the look and feel of the place.


Comments are closed.