Category: SL Tech

Mesh deformer and standard sizes: Qarl speaks

Posted on by Inara Pey

There has been much in the way of heated debate on the subject of the mesh parametric deformer and standard sizes for avatars of late. So much so that in this week’s Metareality podcast, Kimberly Winnington (Gianna Borgnine in SL), deformer coder Karl Stiefvater (Qarl Fizz in SL) and in-world content creator Cathy Foil discussed the debate at some length and touched on other aspects of the deformer project.

The following is a summary of the core aspects of the discussion, presented in the panelist’s own words. My thanks to Kimberly for allowing me to produce this piece.

[2:10] Kimberly Winnington (KW): As it stands now, mesh items have to be built to the default avatars like the Ruth Avatar and then be deformed.

[2:32] Karl Stiefvater (KS): There’s a slight difference between Ruth, the actual Ruth – a lot of people call different shapes “Ruth”,  so that’s a bad term to use – and the important shape, the one that you get when you say, “Hey, I want to do a shape!” and you don’t touch any of the other dials … and I call that the “default shape”.

[2:58]  KW: So as it is now, clothing has to be built to that default shape before it can be deformed.

[3:04] KS: Right.

[3:05] KW: And it’s been suggested it should … that group of things like the default avatar should include some sort of standard size as well, even though that’s not officially a feature at this time.

[3:22] KS: That is correct. The rationale there is the deformer isn’t perfect and if you start with a shape that’s closer to your end shape before you actually tweak it, you can get superior results … Even if the deformer worked perfectly, when you design a shirt with a floral print … and you put it on someone with their body weight turned all the way up … the floral print is going to be distorted … So with the new system, the artist could say, “I’m going to repaint that floral print so it doesn’t get stretched out.”

[4:19] KW: There’s this fight going on. Emma Gilmore, also known as Elie Spot – she is of course on the standard sizing side, she was one of the people who worked with a bunch of other designers and came up with the standard sizes. And then I guess on the other side of the argument is Maxwell Graf … he’s on the side that the standard sizing is a marketing ploy and is awful and we shouldn’t even tolerate its existence. And I guess I’m somewhere in the middle of those two arguments on the basis I kind of agree with the standard sizing – not as the official solution because I don’t want to change my avatar …  so I’m all for the deformer and do not want to have standard sizing as the only solution.  However, I would have a much better chance of fitting into something without a lot of stretching if I stretched from a size that was closer to my avatar than the default avatar …  But I still think that it’s at least a solution that should be discussed; where the starting-off point for the deformer should maybe be closer to a standard size.

[6:56] KS: It sounds like you and I are in agreement …

[7:15] KW: The other thing that came up was … Emma was talking to you about possibly having a way they could convert current meshes without having to re-upload, and you had suggested to her that she post on the JIRA and get some feedback from some other people. So the problem became she posted on the JIRA and she posted a Plurk about both these issues. like let’s discuss where we should start from and lets talk about whether we should be re-uploading or converting and how should we do that … So it started this huge fiasco where everybody kind-of attacked her both on the JIRA and totally all over Plurk, and were like, “you’re wrong, you shouldn’t be posting here…” … I actually agree with her and think she has a good point; but whether you agree with her or not, the topics she brought up are important for us to discuss as a community, especially designers and people who want to wear mesh. Because once the thing is final – you know how things go in Second Life; it will come out and everyone will be unhappy with it but it will be too late to do anything about it. So you have to do it now …

[9:59] KS: The deformer isn’t perfect. There are problems and what she’s proposing … is an extension … so it doesn’t take anything away from what you had before; it’s just adding new features. So how can you hate something that has everything you want but has this extra thing that somebody else wants? How does that engender white-hot hatred? I don’t understand.

[10:36] KW: I think there’s two things. I think the first on is not understanding that it works in collaboration with the deformer. So I think there’s a lot of people…they hear “standard sizing” and they are automatically like, “No”, without understanding that it’s not going to work like standard sizing is now … that you have to fit to that standard size.  This is just in collaboration with the deformer, and I almost want to name it something else….

[11:03] KS: How about “alternate bases”? … Alternate bases, everyone.

[11:14] KW: The other thing that comes up is that a lot of people feel like that if we make a solution that fits … then Linden Lab will stop trying to think about trying to create a new overall avatar mesh.

Karl Stiefvater (Qarl Fizz)

[11:47] KS: I don’t thing that we’ve forced them to do anything ever … They’ve never given in, ever! So I don’t see that as a smart strategy … One thing I want to add to this, tho, is this other aspect  that I don’t think anybody knows about. And that is, Linden Lab, internally, is … struggling with a question that is probably going to delay the deformer even more. And that is, they don’t know if they like the default avatar as the base. They think there might be a better base. … Then the question is, so how do you pick a better base? Some of them are suggesting … that adding curves is easier than removing curves, so if the base was something that had no boobs, that had no curves or shapes whatsoever, that might perform better … But they have no system in mind for making this call. So this is like one of those objections that can never be necessarily resolved, which is very dangerous for the project. So one of the things I like about this alternate bases idea is it neutralises this potential problem, because if they think there is a better base avatar, we can just add it later. As soon as they decide what that perfect base is, we’ll just add it to the list. So it’s beneficial for reasons completely unrelated to the whole fight right now, so that’s something to keep in mind. That’s mainly why I’m sort-of leaning this way … because it kills two birds, and one of these birds is otherwise potentially project destroying.

[14:23] Cathy Foil (CF): Is it possible to have the content creators load-up their own custom bases for their mesh? Would that be possible? Or would they have to create their own blend shapes so they work with the sliders?

[14:40] KS: No … they would have to use the existing shapes, the existing parameters. But they could specify their own set of parameters; that’s doable, but I’m a little bit afraid that that’s over-designed … so I think that maybe down the road that’s a good option, but I think for right now just a set … just six or seven different bases….

[15:16] CF: I did have a wackadoodle idea I wanted to put forward. I know it’s probably way too late in the development … right now you have the avatar mesh is driving the deformer of the mesh clothing, and I thought of the idea of having “deformer underwear” so to speak,  an invisible mesh that you wear so that the avatar’s mesh deforms the underwear but then the underwear deforms the clothing mesh … so that the designers could create custom underwear that would only fit over certain parts of the avatar if they wanted or they could have more vertices in the underwear that would spread out the deformer so that they would deform the clothing mesh maybe a little bit more evenly.

[16:08] KS: That’s a clever idea … but no it’s too late for that! [laughs] But that’s interesting and that could definitely be in version 2 … Then clothing could work on avatars that are completely alien, you know, something you couldn’t dial around … like an elephant .. you could create an elephant avatar and then your hoodie or your dress would fit…

From here, the discussion moved out to talk about design techniques before moving on to the remaining topics of the podcast. For those interested in the mesh deformer and the ongoing debate, I thoroughly recommend listing to the podcast in its entirety, which also includes issues such as DMCA, copyrights and a discussion about the use and impact of the SL Marketplace.

Related Links

Viewer release summary 2012: week 20

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.

A very quiet week!

Updates for week ending: 20 May, 2012

  • No changes to any of the major SL Viewer releases
  • Zen Viewer released version 3.3.3.4 on May 15th
  • Niran’s Viewer rolled through release 1.37 (14 May) to 1.38 (21st May, close enough to make this update)
  • Cool VL Viewer rolled to 1.26.4.13 on 19th May, with change log here
  • Group Tool made a release on May 20. Due to issues with the trial licence, still unable to test / review.

Related Links

Viewer release summary 2012: week 19

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: 14 May, 2012

  • No changes to the official release of the SL Viewer
  • The Beta Viewer rolled to 3.3.2 (255742), complete with the contributed Local Textures capability
  • The SL Development Viewer rolled to 3.3.3.255954 on May 8th
  • The Pathfinding Project Viewer rolled to 3.3.2.256513 on May 11th
  • Niran’s Viewer rolled to version 1.36 on May 9th
  • Zen Viewer released version 3.3.3.3 on May 9th
  • Cool VL Viewer rolled to 1.26.4.12 on 12th May, with change log here
  • Lumiya released version 2.0.0 on May 11th, with the addition of a 3D in-world view capability

Related Links

Lumiya Android client adds in-world rendering

Posted on by Inara Pey

Further update, 13th May: Alina Lyvette, Lumiya’s creator, passed word to me on the “long touch” issue with objects in the 3D view: “Yes, it’s not 100% reliable at the moment, it uses a makeshift solution of reading back the frame buffer instead of true collision test, and it’s known to fail unpredictably on so many phones. I’ll do a true collision test for the next release and it will be rock-solid, just need time to do that (and a few interesting tricks to make it work within Android limitations ^.^

Updated 13th May: Susie Bagley and Lirusaito have both commented that object information can be displayed in the 3D view; something I was unable to do on my own phone. This article has therefore been updated to reflect the capability. 

Lumiya, the SL client for Android, developed by Alina Lyvette  follows Radegast in becoming the second text-based SL client to offer a 3D rendering capability – and is the first to offer such a capability to mobile devices running the Android Os, with the release of version 2.0.0.

There are limitations at present – but this is an initial release, so please bear that in mind. The release notes describe them thus:

  • No true avatar rendering (yet), avatars are displayed as default faceless figures.
  • Terrain and sky are not textured.
  • “Mesh” is not supported. Sculpted objects are (mostly) supported.
  • Particle systems, local lighting and other fancy features are not supported.

I took the new version for a quick spin using my CTA (Crash Test Alt), after Latif Khalifa tickled my ribs about the release via Twitter.

Accessing the 3D renderer  is simple and straightforward: simply tap the 3D View button at the top left of the screen  after logging-in to SL via Lumiya. This will take you directly to the in-world view (which may take a little time to load, depending on your phone / connection). The view itself has two further buttons in the lower right corner, with up (move forward) and down (move backwards) arrow icons.

Once rendered, the View delivers a lot of detail, and managed to capture my PrimPossible piano perfectly, as well as other sculpts without problem, despite the caveat given against sculptie rendering in the limitations. You can pan left / right by dragging a finger across the screen; your avatar will also turn as you pan around (circular panning) – and your avatar will be seen to turn by Viewer users around you. The scene doesn’t currently pan up / down at present, but this doesn’t limit use. Avatar movement is a simple glide, rather than having any form of animation at present, but again, that in no way impacts on things.

Lumiya 3D View on a Samsung Galaxy S2

As one would expect, rotating the phone will cause the scene to rotate as well, so for those with large screen sizes, the 3D view can be used in landscape mode, providing a wider field of view. About the only disconcerting thing some may find with the 3D View is that the default avatar form is a grey male – although we can expect this to improve as the capability is enhanced.

An in-world scene captured by Lumiya (click to enlarge)

The view isn’t interactive, so there’s no actual touching of in-world objects to obtain menus, etc; for this you have to use the existing touch option, which does mean a certain amount of screen swapping, but again, nothing that is in any way problematic (although I did have a habit of tapping my ‘phone’s Back button once too often and ending up back in an apps window – but that was operator error, nothing to do with Lumiya!).

However, pressing on an object displayed in the view for a few seconds should display information about the object across the top of the screen (my thanks to Susie Bagley and Lirusaito for pointing this out, as the feature has not been working on my Galaxy S2).

Tapping your ‘phone’s Menu button will display options to open Lumiya’s settings screen (where you can alter your Draw Distance, for example), and to log-out of Second Life & Lumiya.

Performance

The Lumiya website notes:

  • On modern phones and tablets with Tegra 2 chips and comparable hardware, it will give you around 5-10 FPS in quiet locations. Initial world generation takes a few seconds.
  • On older generation phones with CPU frequencies in 300 MHz range, it will give you around 1 FPS at best, and initial world generation takes tens of seconds. It may still be useful to give you a brief idea of your surroundings.
  • Draw distance can be reduced to improve performance, but not much.

I found that the 3D View ran very smoothly on my Galaxy i9100 S2 over my home wireless connection, with no lag or delay in processing. When running via 3G, things were obviously slower, with both initial rendering and actual movement showing lag, which leading to some amusement as my CTA, when seen through a Viewer, appeared to shoot across a room and proceed to repeatedly wallop a wall while still standing still in the Lumiya display. Light taps on the movement keys recommended to give the network a chance!

Bandwidth-wise I ran Lumiya on 3G with the 3D view enabled for 5 minutes while wandering around, which totted-up 2Mb of data usage. Hardly an intensive test, I know, but it gave a rough feel for things.

System Requirements

The Lumiya website notes the following on system requirements for running the 3D view option:

  • It can work with plain old OpenGL-ES 1.0 without VBO support, but the performance will suffer a lot. Modern phones usually have VBO support, and Lumiya will use it when it is available.
  • The native code parts are compiled for ARM processors (Alina notes that if people have Android ‘phones using other processors and would like to see the 3D rendering option on their ‘phone, they should contact her directly).

Opinion

It is early days for this aspect of Lumiya, and I’m curious to see where it goes and what else can be included (and added to the client as a whole). As it is, Alina is to be commended for what she has achieved; this is really quite a remarkable client capability to have, and really shows huge potential and promise.

Related Links

Local Textures: coming to a Viewer near you

Posted on by Inara Pey

Update 14th May: My thanks to Oz Linden for pointing out that if you apply a Local Texture in-world, and then modify the original image file in a suitable editing tool and save it again, the viewer picks up the change and automatically applies it in-world (see Comments). I’ve also clarified that Local Textures can be used for clothing and skins within the text of this article.

Local Textures is a means by which textures stored on your computer can be applied to in-world objects on a temporary basis, allowing you to judge their suitability for use prior to uploading.

In this, it combines functionality currently found in many third-party Viewers (TPVs) in the form of the Local Bitmap Browser, with the added capability of being able to apply a selected texture directly to an object in-world within your own world-View.

The option, contributed by Vaalith Jinn, the originator of the Local Textures Bitmap, has been available within a number of recent Development builds of the official Viewer, and is now available in the latest Beta release (255742), so expect to see it in a mainstream release very shortly. (It should also be noted that the option is already available in both Dolphin and Niran’s Viewer.)

Using Local Textures

Local Textures is accessed from the Texture tab of the Build floater:

Texture picker: note the Local radio button (circled)

Note that there are now two new radio buttons on the Texture Picker itself – Inventory and Local. The former will, naturally, allow you to browse the textures within your SL inventory as we’re all familiar to doing.

Clicking on the Local option, however will change the Picker to display the following:

Local texture panel

This contains three new buttons, described below.

  • Add:  Opens a window allowing you to browse your hard drive(s) to find textures.
    • An individual texture can be selected by double left-clicking on it or by left-clicking once on it and then clicking OPEN
    • Multiple textures within a folder can be selected using either SHIFT-left-click or CTRL-left-click (which can also be used to de-select individual items from a multiple selection
    • Selected items are added to the list panel to the right of the buttons
    • You can browse as many folders as you wish and add items to your list, but you cannot select folders themselves
  • Remove: (only available if a texture is selected in the list panel) removes an unwanted texture from the list
  • Upload: (only available if a texture is selected in the list panel) will open the usual texture upload panel, allowing you to upload the selected texture to your inventory with the usual L$10 fee and use it from there. Note that bulk uploads are not supported from the button.

When you have added one or more textures to the list panel, clicking on an individual texture within the list will apply it to the selected object / object face. Note that as these are only local file associations, the applied texture will only be visible to you; no-one else will see the texture (the object/face will remain untextured in their view).

Applying a local texture – only visible in your own world view

Textures added to the list panel will remain available to you until such time as you log-out of Second Life, at which point this list will be emptied.

Note that clothing and skins can be tested in the same way – just use the Edit Appearance floater and the New Clothes / New Skins options.

Local Textures and Temporary Textures

Local Textures might also sound like the Temporary Textures upload capability also found in many TPVs, but there are notable differences:

  • Temporary textures appear in your inventory, usually with the prefix “temp” for the duration of your current session in SL, then they are lost
  • Temporary textures can be see in-world by people other than yourself; this makes it ideal for things like collaborative building, where joint decisions need to be made prior to the selection and upload of textures

There have been rumours that LL are looking to “break” temporary texture uploads with the release of Local Textures. This does not appear to be the case at present; LL have so far given TPV developers no indication that they expect to see Temporary Textures removed from Viewers. Certainly, Dolphin is running with both Temporary Texture uploads and Local Texture; providing LL do not indicate they have a problem with this, it is likely that other TPVs will opt to do the same.

However, it might be worth noting that Temporary Textures do rely on using a feature in a manner in which it is not intended to be used, and which is specifically related to avatar baking. LL are currently looking into ways in which to make avatar baking more robust and less prone to problems such as bake fail (when your avatar fails to rez correctly). One of the options being considered in this regard is moving the bake process server-side.

If this does indeed happen in the future (and it is not a trivial change), then it may result in Temporary Texture uploads being “broken”; but again it is important to emphasise that no actually decision on how to deal with avatar bake issues has yet been taken.

In the meantime, expect to see Local Textures in your preferred Viewer in the near future!

With thanks to Innula Zenovka for raising my awareness that Local Textures had reached the Beta Viewer (forum post), and to Latif Khalifa  and Trinity Dejavu for input to this piece)

ETA contributor’s detail, supplied by Mobius Ryba. 

Exodus and Niran’s Viewer appear on the TPV Directory

Posted on by Inara Pey

I received a short note from Oz earlier this evening:

Both Nirans and Exodus added to the directory this morning… thought you’d like to know.

Running a quick check on the TPVD page reveals both are indeed there, tucked in below Firestorm:

Exodus and Niran’s now TPVD listed

Niran’s Viewer had been accepted for TPVD listing with release 1.33. A new release of Exodus is in development and should be available in the future.

Congratulations to both Viewers.