[opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Jonathan Yap 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/
---

Review request for Viewer.


Description
---

Ad-hoc IMs and voice call sessions are established even though you have muted 
the initiator.  The result is that others in the ad-hoc session start writing 
back to what is usually some provocative message from the initiator and you end 
up seeing these messages.  It has been reported that many IM tabs are also 
created sometimes.


This addresses bug STORM-1731.
http://jira.secondlife.com/browse/STORM-1731


Diffs
-

  doc/contributions.txt f9a1f62ac997 
  indra/newview/llimview.cpp f9a1f62ac997 

Diff: http://codereview.secondlife.com/r/524/diff/diff


Testing
---

See test plan in jira.

Testing Not Done: regression testing to see if these code changes have broken 
muting for other circumstances.


Thanks,

Jonathan Yap

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Jonathan Yap 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/
---

(Updated Dec. 12, 2011, 6 a.m.)


Review request for Viewer.


Description
---

Ad-hoc IMs and voice call sessions are established even though you have muted 
the initiator.  The result is that others in the ad-hoc session start writing 
back to what is usually some provocative message from the initiator and you end 
up seeing these messages.  It has been reported that many IM tabs are also 
created sometimes.


This addresses bug STORM-1731.
http://jira.secondlife.com/browse/STORM-1731


Diffs
-

  doc/contributions.txt f9a1f62ac997 
  indra/newview/llimview.cpp f9a1f62ac997 

Diff: http://codereview.secondlife.com/r/524/diff/diff


Testing
---

See test plan in jira.

Testing Not Done: regression testing to see if these code changes have broken 
muting for other circumstances.


Thanks,

Jonathan Yap

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] "Standard Human Mesh Avatar"???

2011-12-12 Thread Robert Martin 
On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble  wrote:
> The MakeHuman mesh is probably far too complex (vertex count) to allow
> reasonable real-time  performance for many users with less than the best
> graphics cards. There's probably other meshes available on other 3d content
> sites which are better designed for real-time animation.

the trick with MakeHuman is it can be used to generate multiple meshes
it would be understood that it would need to be downsampled (to below
XK vertexes) before it could be used on the grid. The big question
would be What is the recommended Maximum Vertex count?? (define X
please)



-- 
Robert L Martin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Oz Linden 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/#review1122
---



indra/newview/llimview.cpp


Warning level should be used for potential code or protocol problems.  This 
would be better at Info level.



indra/newview/llimview.cpp


Doesn't it make more sense to put the isMuted check in an outer test, and 
then the more specific additional checks for voice in the inner check?

Also, why is isLinden a special case for voice but not for other sessions?




indra/newview/llimview.cpp


Info level


- Oz Linden


On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/524/
> ---
> 
> (Updated Dec. 12, 2011, 6 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Ad-hoc IMs and voice call sessions are established even though you have muted 
> the initiator.  The result is that others in the ad-hoc session start writing 
> back to what is usually some provocative message from the initiator and you 
> end up seeing these messages.  It has been reported that many IM tabs are 
> also created sometimes.
> 
> 
> This addresses bug STORM-1731.
> http://jira.secondlife.com/browse/STORM-1731
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt f9a1f62ac997 
>   indra/newview/llimview.cpp f9a1f62ac997 
> 
> Diff: http://codereview.secondlife.com/r/524/diff/diff
> 
> 
> Testing
> ---
> 
> See test plan in jira.
> 
> Testing Not Done: regression testing to see if these code changes have broken 
> muting for other circumstances.
> 
> 
> Thanks,
> 
> Jonathan Yap
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] "Standard Human Mesh Avatar"???

2011-12-12 Thread Mike Chase 
On Mon, 2011-12-12 at 09:40 -0500, Robert Martin wrote:
> On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble  
> wrote:
> > The MakeHuman mesh is probably far too complex (vertex count) to allow
> > reasonable real-time  performance for many users with less than the best
> > graphics cards. There's probably other meshes available on other 3d content
> > sites which are better designed for real-time animation.
> 
> the trick with MakeHuman is it can be used to generate multiple meshes
> it would be understood that it would need to be downsampled (to below
> XK vertexes) before it could be used on the grid. The big question
> would be What is the recommended Maximum Vertex count?? (define X
> please)
> 

You could always dump the avatar mesh from the viewer (in the develop
menu I believe) and pull it into blender to get an idea of what your
dealing with.

Mike

> 
> 


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Jonathan Yap 


> On Dec. 12, 2011, 6:42 a.m., Oz Linden wrote:
> > indra/newview/llimview.cpp, lines 2730-2744
> > 
> >
> > Doesn't it make more sense to put the isMuted check in an outer test, 
> > and then the more specific additional checks for voice in the inner check?
> > 
> > Also, why is isLinden a special case for voice but not for other 
> > sessions?
> >

Having the tests in this order is what is needed.  There are two cases here: 
dealing with a muted session initiator has to take precendence over a muted 
non-initiator avatar in an existing session.

Not having the test for a linden was someone's oversight which I have 
corrected.  There are a few other instances of this check not being performed 
properly.  If you think fixing these now is within the scope of this jira 
please let me know.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/#review1122
---


On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/524/
> ---
> 
> (Updated Dec. 12, 2011, 6 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Ad-hoc IMs and voice call sessions are established even though you have muted 
> the initiator.  The result is that others in the ad-hoc session start writing 
> back to what is usually some provocative message from the initiator and you 
> end up seeing these messages.  It has been reported that many IM tabs are 
> also created sometimes.
> 
> 
> This addresses bug STORM-1731.
> http://jira.secondlife.com/browse/STORM-1731
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt f9a1f62ac997 
>   indra/newview/llimview.cpp f9a1f62ac997 
> 
> Diff: http://codereview.secondlife.com/r/524/diff/diff
> 
> 
> Testing
> ---
> 
> See test plan in jira.
> 
> Testing Not Done: regression testing to see if these code changes have broken 
> muting for other circumstances.
> 
> 
> Thanks,
> 
> Jonathan Yap
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Standard Human Mesh Avatar

2011-12-12 Thread Daniel 
There is no single number you can define for all cases.  During the mesh 
beta one Linden
staffer noted the mesh cost formulae were made assuming 300K triangles 
for the entire scene being
rendered would allow low end PCs to run at adequate frame rates.  Note I 
said "triangles", which
is what graphics cards process, not vertexes.  High end machines can 
handle a lot more.  Crytek
(designer of the Crysis games) recommends level designers keep to under 
3 million triangles per
frame, versus whatever PC hardware they recommend for those games.  How 
much work the
SL viewer does with each triangle depends on graphics settings, but 
generally a given hardware
will process X triangles per second, and so frame rate will tend to go 
inversely with scene complexity.

The existing default SL avatar is about 8000 triangles, each sculpt map 
can add 2000, and each prim
can add 100 to 2000 or so depending on type.  So an avatar wearing a lot 
of detailed attachments
can add up to a lot of theoretical triangles.  I say theoretical because 
the SL viewer applies "Levels of
Detail" (LOD) on the theory that objects at longer distance would end up 
with geometry which is
less than one pixel on the monitor.  This is unnecessary processing, so 
the viewer applies simplification
of what it renders at various distances.  For prims and the standard 
avatar the LOD levels are built in.
For sculpts it discards alternate rows and columns of the map texture, 
and for mesh you explicitly
define the LOD geometry at the time of upload.  LOD levels kick in at 
specified multiples of the object
size vs camera distance.  So if you design a mesh avatar as a single 
object, the levels will switch at
multiples of the full body size.  If you design it as separate body 
parts, the switches will happen per
part, so generally at closer distance.

The final consideration is what environment will the avatar be used in.  
One made for fashion photography,
where only one will be in view, and frame rate does not matter, can be a 
very detailed.  One made
for SL role playing games, where speed matters, or for visiting popular 
clubs, where lots of other attachment-
heavy avatars will be in view, should stick to lower detail.  For the 
latter cases I would suggest staying under
double the default avatar (ie to < 16K triangles), on the assumption 
that the default avatar when hidden
by an alpha texture subtracts 8K from the rendering task, and an extra 
8K total is not a large impact given
whatever else the avatar has in attachments.  Levels of detail by 
default go down by a factor of 4 per level
in the upload window.  You are free to upload whatever geometry you want 
for each level to maintain
decent looks for your avatar, but that is a reasonable guideline for how 
aggressively to simplify each LOD.

Message: 3 Date: Mon, 12 Dec 2011 09:40:26 -0500 From: Robert Martin 

> the trick with MakeHuman is it can be used to generate multiple meshes
> it would be understood that it would need to be downsampled (to below
> XK vertexes) before it could be used on the grid. The big question
> would be What is the recommended Maximum Vertex count?? (define X
> please)
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] "Standard Human Mesh Avatar"???

2011-12-12 Thread Moriz Gupte 
Or to save some time, get the blender files from the link I provided
earlier ... and examine the mesh files in blender
R


On Mon, Dec 12, 2011 at 8:53 AM, Mike Chase <
mike.ch...@alternatemetaverse.com> wrote:

> On Mon, 2011-12-12 at 09:40 -0500, Robert Martin wrote:
> > On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble 
> wrote:
> > > The MakeHuman mesh is probably far too complex (vertex count) to allow
> > > reasonable real-time  performance for many users with less than the
> best
> > > graphics cards. There's probably other meshes available on other 3d
> content
> > > sites which are better designed for real-time animation.
> >
> > the trick with MakeHuman is it can be used to generate multiple meshes
> > it would be understood that it would need to be downsampled (to below
> > XK vertexes) before it could be used on the grid. The big question
> > would be What is the recommended Maximum Vertex count?? (define X
> > please)
> >
>
> You could always dump the avatar mesh from the viewer (in the develop
> menu I believe) and pull it into blender to get an idea of what your
> dealing with.
>
> Mike
>
> >
> >
>
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>



-- 
'Consider how the lilies grow. They do not labor or spin.'
*Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research
Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel:
208-240-0040
Blog ,
LinkedIn
, DeepSemaphore LLC , Google+
profile
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] "Standard Human Mesh Avatar"???

2011-12-12 Thread Mike Chase 
On Mon, 2011-12-12 at 10:25 -0700, Moriz Gupte wrote:
> Or to save some time, get the blender files from the link I provided
> earlier ... and examine the mesh files in blender
> R

Yep, Gaia's project is very relevant. It include 2 meshes, the SL one
and a Makehuman mesh as well as an SL compatible rig.

Mike
> 
> On Mon, Dec 12, 2011 at 8:53 AM, Mike Chase
>  wrote:
> On Mon, 2011-12-12 at 09:40 -0500, Robert Martin wrote:
> > On Sat, Dec 10, 2011 at 2:56 PM, Dahlia Trimble
>  wrote:
> > > The MakeHuman mesh is probably far too complex (vertex
> count) to allow
> > > reasonable real-time  performance for many users with less
> than the best
> > > graphics cards. There's probably other meshes available on
> other 3d content
> > > sites which are better designed for real-time animation.
> >
> > the trick with MakeHuman is it can be used to generate
> multiple meshes
> > it would be understood that it would need to be downsampled
> (to below
> > XK vertexes) before it could be used on the grid. The big
> question
> > would be What is the recommended Maximum Vertex count??
> (define X
> > please)
> >
> 
> 
> You could always dump the avatar mesh from the viewer (in the
> develop
> menu I believe) and pull it into blender to get an idea of
> what your
> dealing with.
> 
> Mike
> 
> >
> >
> 
> 
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated
> posting privileges
> 
> 
> 
> 
> 
> -- 
> 'Consider how the lilies grow. They do not labor or spin.'
> Rameshsharma Ramloll PhD, CEO CTO DeepSemaphore LLC,
> Affiliate Research Associate Professor, Idaho State University,
> Pocatello, ID 83209 Tel: 208-240-0040
> Blog, LinkedIn, DeepSemaphore LLC, Google+ profile
> 
> 


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Oz Linden 


> On Dec. 12, 2011, 6:42 a.m., Oz Linden wrote:
> > indra/newview/llimview.cpp, lines 2730-2744
> > 
> >
> > Doesn't it make more sense to put the isMuted check in an outer test, 
> > and then the more specific additional checks for voice in the inner check?
> > 
> > Also, why is isLinden a special case for voice but not for other 
> > sessions?
> >
> 
> Jonathan Yap wrote:
> Having the tests in this order is what is needed.  There are two cases 
> here: dealing with a muted session initiator has to take precendence over a 
> muted non-initiator avatar in an existing session.
> 
> Not having the test for a linden was someone's oversight which I have 
> corrected.  There are a few other instances of this check not being performed 
> properly.  If you think fixing these now is within the scope of this jira 
> please let me know.

I'm prepared to believe there's a difference here I don't see, but why isn't 
this:

//ignore invites from muted residents
if (LLMuteList::getInstance()->isMuted(caller_id) && !is_linden)
{
if (voice_invite && "VoiceInviteQuestionDefault" == question_type)
{
llinfos << "Rejecting voice call from initiating muted resident 
" << caller_name << llendl;
LLIncomingCallDialog::processCallResponse(1, payload);
}
return;
}


- Oz


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/#review1122
---


On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/524/
> ---
> 
> (Updated Dec. 12, 2011, 6 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Ad-hoc IMs and voice call sessions are established even though you have muted 
> the initiator.  The result is that others in the ad-hoc session start writing 
> back to what is usually some provocative message from the initiator and you 
> end up seeing these messages.  It has been reported that many IM tabs are 
> also created sometimes.
> 
> 
> This addresses bug STORM-1731.
> http://jira.secondlife.com/browse/STORM-1731
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt f9a1f62ac997 
>   indra/newview/llimview.cpp f9a1f62ac997 
> 
> Diff: http://codereview.secondlife.com/r/524/diff/diff
> 
> 
> Testing
> ---
> 
> See test plan in jira.
> 
> Testing Not Done: regression testing to see if these code changes have broken 
> muting for other circumstances.
> 
> 
> Thanks,
> 
> Jonathan Yap
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Jonathan Yap 


> On Dec. 12, 2011, 6:42 a.m., Oz Linden wrote:
> > indra/newview/llimview.cpp, lines 2730-2744
> > 
> >
> > Doesn't it make more sense to put the isMuted check in an outer test, 
> > and then the more specific additional checks for voice in the inner check?
> > 
> > Also, why is isLinden a special case for voice but not for other 
> > sessions?
> >
> 
> Jonathan Yap wrote:
> Having the tests in this order is what is needed.  There are two cases 
> here: dealing with a muted session initiator has to take precendence over a 
> muted non-initiator avatar in an existing session.
> 
> Not having the test for a linden was someone's oversight which I have 
> corrected.  There are a few other instances of this check not being performed 
> properly.  If you think fixing these now is within the scope of this jira 
> please let me know.
> 
> Oz Linden wrote:
> I'm prepared to believe there's a difference here I don't see, but why 
> isn't this:
> 
>   //ignore invites from muted residents
>   if (LLMuteList::getInstance()->isMuted(caller_id) && !is_linden)
>   {
> if (voice_invite && "VoiceInviteQuestionDefault" == 
> question_type)
> {
>   llinfos << "Rejecting voice call from initiating muted 
> resident " << caller_name << llendl;
>   LLIncomingCallDialog::processCallResponse(1, payload);
> }
>   return;
>   }
>

I'm sorry, you are totally correct.  I was rushing trying to get these changes 
done quickly so you could have them for your test build and was still thinking 
of the logic changes I made elsewhere for the non-voice part of this fix.  I've 
adjusted the code per what you have above.


- Jonathan


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/#review1122
---


On Dec. 12, 2011, 6 a.m., Jonathan Yap wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/524/
> ---
> 
> (Updated Dec. 12, 2011, 6 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> ---
> 
> Ad-hoc IMs and voice call sessions are established even though you have muted 
> the initiator.  The result is that others in the ad-hoc session start writing 
> back to what is usually some provocative message from the initiator and you 
> end up seeing these messages.  It has been reported that many IM tabs are 
> also created sometimes.
> 
> 
> This addresses bug STORM-1731.
> http://jira.secondlife.com/browse/STORM-1731
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt f9a1f62ac997 
>   indra/newview/llimview.cpp f9a1f62ac997 
> 
> Diff: http://codereview.secondlife.com/r/524/diff/diff
> 
> 
> Testing
> ---
> 
> See test plan in jira.
> 
> Testing Not Done: regression testing to see if these code changes have broken 
> muting for other circumstances.
> 
> 
> Thanks,
> 
> Jonathan Yap
> 
>

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] "Standard Human Mesh Avatar"???

2011-12-12 Thread Robert Martin 
On Mon, Dec 12, 2011 at 2:07 PM, Mike Chase
 wrote:
> On Mon, 2011-12-12 at 10:25 -0700, Moriz Gupte wrote:
>> Or to save some time, get the blender files from the link I provided
>> earlier ... and examine the mesh files in blender
>> R
>
> Yep, Gaia's project is very relevant. It include 2 meshes, the SL one
> and a Makehuman mesh as well as an SL compatible rig.
>
okay which would help if I COULD ACCESS THE SITE.
Does anybody have a copy on another server??

-- 
Robert L Martin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Review Request: STORM-1731 Ad-hoc confererence block failing. Residents using it to start massive multi-sim conferences, used as a griefing tool.

2011-12-12 Thread Jonathan Yap 

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/524/
---

(Updated Dec. 12, 2011, 11:54 a.m.)


Review request for Viewer.


Changes
---

Updated diff with revised if-muted logic per RB requst.


Description
---

Ad-hoc IMs and voice call sessions are established even though you have muted 
the initiator.  The result is that others in the ad-hoc session start writing 
back to what is usually some provocative message from the initiator and you end 
up seeing these messages.  It has been reported that many IM tabs are also 
created sometimes.


This addresses bug STORM-1731.
http://jira.secondlife.com/browse/STORM-1731


Diffs (updated)
-

  doc/contributions.txt f9a1f62ac997 
  indra/newview/llimview.cpp f9a1f62ac997 

Diff: http://codereview.secondlife.com/r/524/diff/diff


Testing
---

See test plan in jira.

Testing Not Done: regression testing to see if these code changes have broken 
muting for other circumstances.


Thanks,

Jonathan Yap

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges