Sorry gang that I've been away from the list for a few days, I sometimes
get busy. We had a board meeting tuesday, etc. OK!
This is clearly a tough issue with lots of appropriate debate. Good
example of the kind of thing we'll need to feel our way into some sort
of a process for. After reading the thread on this topic as closely as
I've had time, here are my summary thoughts:
* We need a clear and discoverable place in the UI where this feature
can be enabled and disabled. Probably prefs. Can someone take on that
design and coding? Advanced-> isn't the right home for this. We
should do that work properly and well to complete this feature.
* Can someone (Mike?) add a bit more detail on the jira task to
defend/review that the CPU impact is strictly capped. For example, what
is the LOD behavior if there are 100 avatars all talking at the same
time. We have LOD tricks for various rendering aspects of the system,
do they correctly carry through? Does the CPU load of the feature vary
by GPU? I think we need this level of documentation.
* As to the question of whether to default it on or off, clearly it is a
complex issue. I'd say lets default it on, and make sure it is easy to
find the way to turn it off. For some use cases it is very cool,
lending immersion and cueing as to speaker. For other cases you will
want it off. We are still at the point where the 'uncanny valley'
nature of the feature can make it unnerving, and that problem is
unlikely to be easily solved soon in realtime with low CPU load.
As a final note, I'd say this is a good example of a tough topic where
the right call is unclear and discussion and debate is appropriate.
Also a good case of where if need be, I can just make a call and we move
on and see what happens. Given that, why the rudeness I am seeing
here? I don't see a need to be insulting to each other over this
topic. Maybe I've missed some painful history here, but can't see how
this is helping us move forward. I wouldn't work internally on projects
at LL with colleagues that were overly rude, I don't see why it should
be any different here!
Philip
Philippe Bossut (Merov Linden) wrote:
Hi,
Thanks Moritz for the fair and clear summary of this issue. Putting in
my L$0.02, I'll add that we think it's fine to have this "turned on by
default" (which will only impact residents using voice chat as stated
in that thread) and that our BDFL already said so (may be not in
public though... Philip?). We already selected this VWR as one of the
community voted feature that we'll get in "http-texture" (aka the
"Second Life OSS" viewer).
Since I'm at it, there is a wiki page that lists the bugs and features
we (collective "we", not just Lindens...) are working on for the next
and first release of this viewer. It is there:
https://wiki.secondlife.com/wiki/HTTP_Texture_Development#Pending_merge_queue_proposals
I'll follow up on another thread on the state of that viewer so far in
a little while.
Cheers,
- Merov
On Apr 29, 2009, at 3:42 PM, Moriz Gupte wrote:
To summarize and to clarify:
I feel these are the points important to state
1. We are not discussing voice
2. Voice has always been optional
3. lipsync has negligible footprint (as Mike has patiently and
repeatedly mentioned inspite of various reflex reactions) In my own
experience, enabling or disabling lipsync has no effect on our fps
and all our machines share the exactly the same settings/I have 3
generations of hardware to work with and no impact experienced.
4. I have been challenged to provide financial info regarding
financial impact of voice on income regarding corporate/education
efforts (LL could perhaps design better survey forms to tease that
info out, I can only tell about my own efforts which is skewed
because of my audience: federal agencies. I would be using another
platform if SL did not integrate voice because this is one of the
primary requirements from RFPs or when you are putting in a
competitive bid while facing other VR platforms such as Forterra
which had lipsync for years and better web integration ) So it is not
entirely mesmerizing why LL has ignored the voice controversy perhaps
because corporations or feds don't pay in Lindens.
5. Enabling voice should trigger lipsync automatically (no need to
overload UI)
6. On a related note, I found that there was a solution for the space
navigator especially regarding vehicle controls in SL and the
integration of that patch is supposed to be for the next main client
[keeping fingers crossed, hope no controversy about this one :)].
Turns out my audience also prefer for some reason this device (I
prefer the keyboard).
7. The plugin idea is great except that it will require deeper
changes and we are still refactoring right? so while I would love to
see it happen, I dont think those tiny incremental changes should be
left out.
There is therefore some understandable frustration regarding the time
it takes for the patches to be integrated (If you find out when Aimee
actually got a handle on this space navigator - vehicles problem, you
will understand the frustration). It is clear that there are many
items with high priority (HTML on a prim is a requirement...for e.g.
and we it's coming any time :) but hey I think these little
incremental improvements are worthwhile. And yes btw, Babbage Linden
(Technical Director?) did mention Mike's work recently, as an example
of user contribution, in one of his talks recently. So I think they
might be more than a few people who like this stuff.
MG
On Wed, Apr 29, 2009 at 1:51 PM, Mike Monkowski
<[email protected] <mailto:[email protected]>> wrote:
Lip sync does not use any more CPU power than the blinking of the
eyes
does. It does not affect bandwidth at all. Perhaps you're
confusing
voice chat with lip sync.
Mike
Ann Otoole wrote:
> How ridiculous that anyone would consider forcing the default
to enabled
> on anything that would increase CPU or Bandwidth.
>
> All defaults should be OFF on anything that compounds the problems
> related to system compatibility and ISP efforts to kill
utilization.
> Such as voice.
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated
posting privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting
privileges
------------------------------------------------------------------------
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
