Second Life Wiki - User contributions [en]

Talk:Wiki3DBuilder

2010-05-03T19:02:13Z

Vision Raymaker: /* IP Theft? */

==Needs Reference==
Including this statement:
"...written by Jonny Bee Cioc and Vision Raymaker which was under a CC by,nc,sa license itself"
...without any support leaves the matter unsupported. This statement should link to that earlier work, particularly highlighting the release under CC Att-NonComm-Share license since that is the point being made. 
 
Question: Where any NODE can possibly have inserted a "URL that can be given"...how is this URL submitted by the user, by chat, notecard, entered into object description?
[[User:Azwaldo Villota|azwaldo]] 13:07, 21 July 2009 (UTC)

===> answer: you click on content and then click on SET URL and so you should be able (bugs permitting) to chat in public chat the "http://www.google.com" url you want to add.. I will specify it in next modification tour

[[User:Salahzar Stenvaag|Salahzar Stenvaag]] 19:42, 25 July 2009 (UTC) I provided the reference uploading a copy full permissions of the object to xstreetsl https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1647618

== Answers [[User:Salahzar Stenvaag|Salahzar Stenvaag]] 09:21, 22 July 2009 (UTC) ==
* Thanks Azwaldo, I will detail furtherly what was the other tool and exactly the differences from it
* I reincorporated the modifications in key2int from Strife, thanks Strife for this alternative way I must study it to understand how it is working.
* Strife is telling that he doesn't like the key2int... Not sure if it is the entire concept in itself or just using key2int to name the channels. Maybe he has a better idea on how to deal with channels... Looking forward to hearing his solution. I know that was just a draft, but it is really simple and relatively good working solution, unless, obviously there are some nasty nasty hidden anomalies. I'm always learning and what I'm doing IS normally perfectible in infinite ways ;)
* If there is already a wiki page on lsl teaching how objects can easily negotiate a channel, I'd love to follow a more standard and easy way.

== IP Theft? ==

{{Quote|1=[https://wiki.secondlife.com/wiki/User:Salahzar_Stenvaag Salahzar_Stenvaag] didn't and do not have rights to sell that object on [https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1647618 xstreet] because it's a violation of [http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode CreativeCommons by-nc-sa license] and [https://wiki.secondlife.com/wiki/Intellectual_Property Linden Lab Official KB: Intellectual Property] [[User:Vision Raymaker|Vision Raymaker]] 21:15, 26 April 2010 (UTC)}}

I've pulled the above comment from the article, placed it here and left a message for it's author [[User_talk:Vision_Raymaker#Wiki3DBuilder_Drama|here]]. I'm nonplussed. Just because you think your rights have been infringed does not give you the right to deface an article (it does however give you the right to have the content yanked if you can prove it). It is not the right way of seeking restitution. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:37, 27 April 2010 (UTC)

: You are right I made a strong claim and there were few evidence '''there''' to prove it. You all will notice that [https://wiki.secondlife.com/w/index.php?title=Wiki3DBuilder&curid=79573&diff=881973&oldid=452812 Wiki3DBuilder] doesn't exist any more probably trying to put cover over his infringement of Creative Commons license. As you can see in this snapshot

:[[Image:Snapshot_violazione_CC_by-NC-sa_by_Salahzar_Stenvaag.png]] [[User:Salahzar_Stenvaag|Salahzar Stenvaag]] was selling on XstreetSL marketplace an item called ''SpatialMap.org (MindMap 3D) v1.0.18 (MONO)'' for L$ 50. (He was selling also on [http://meta-life.net/second-life/item/89393-SpatialMaporg-MindMap-3D-v1018-MONO]).

: As you can see he was selling getting profit and this was not allowed under the [http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode Creative Commons license Attribution-NonCommercial-ShareAlike 2.5].

: The SpatialMap LSL source code was freely downloadable from [http://code.google.com/p/spatialmap/downloads/list http://code.google.com/p/spatialmap/downloads/list]. The license have been CC by-nc-sa 2.5 since version 0. If you have time you can see that '''every''' file has Creative Commons by-nc-sa references into the header. If you have doubts that people listed in [http://code.google.com/p/spatialmap/people] called owner, ''marco.vanadia'' and ''davide.caroli85'', are respectively [[User:Vision_Raymaker|Vision Raymaker]] and [[User:JonnyBee_Cioc|JonnyBee Cioc]] you can browse into Tish Shute UgoTrade blog article that cite our works [http://www.ugotrade.com/2008/01/28/the-archeology-and-future-of-software-design-meeting-grady-booch/].

: He, and everybody else, had and has rights to derive works from SpatialMap code, '''do not get profit from it''', and share what come out under the same license.

: Law doesn't admit ignorance and he also use same license in his works. So he must know what NotCommercial means. This means that he consciously infringe the law.

: So this is not 'Drama'. This is '''Theft'''. Penal prosecutable by law.

: I do not need to have a lawyer to say that and it is obvious that he can't had so much profit from this theft. But this is all about unethical after than illegal. He tells to embrace opensource ethic. Nice way to do it. People must be known from what they do after what they tell to do.
:[[User:Vision Raymaker|Vision Raymaker]] 18:25, 3 May 2010 (UTC)

User talk:Vision Raymaker

2010-05-03T18:25:51Z

Vision Raymaker: /* Wiki3DBuilder Drama */

== Wiki3DBuilder Drama ==

You are making quite a strong claim in [https://wiki.secondlife.com/w/index.php?title=Wiki3DBuilder&curid=79573&diff=881973&oldid=452812 Wiki3DBuilder] but you provide no details let alone supporting evidence. I'm here sitting on the sidelines and I'm a bit confused. I'm not a lawyer but if you think your rights have been infringed you really should speak to one. Your product is mentioned in the source code of his product and he admits to using your product as a source of ideas, but if this is the truth I fail to see the problem. Thus far there has been no mention of patents, I bring it up because, while mooching ideas may be unethical, unless you have patented the design of your scripts, he hasn't done anything illegal or actionable. He states he hasn't infringed upon the copyrights (he claims not to have copied the code), but without a patent you're ideas are fair game. Copyright protects the content, not the ideas. Patents protect ideas but not content. If anything he has gone beyond what is required by citing your product as his source of ideas. While he hasn't said it in so many words, he's saying his product is not a derivative work.

Without proper documentation or at least more information, this clearly is Drama. Which is to say, social meta-data.

Which brings me to why I'm posting, normally we keep Drama out of the articles and only allow it on the discussion pages. So unless you can provide some details to support your claim, I'm moving your comment to the discussion page. Upon receipt of proper documentation, further action can be taken against the article. -- '''[[User:Strife_Onizuka|Strife]]''' ([[User talk:Strife_Onizuka|talk]]|[[Special:Contributions/Strife_Onizuka|contribs]]) 00:28, 27 April 2010 (UTC)

: You are right I made a strong claim and there were few evidence '''there''' to prove it. You all will notice that [https://wiki.secondlife.com/w/index.php?title=Wiki3DBuilder&curid=79573&diff=881973&oldid=452812 Wiki3DBuilder] doesn't exist any more probably trying to put cover over his infringement of Creative Commons license. As you can see in this snapshot

:[[Image:Snapshot_violazione_CC_by-NC-sa_by_Salahzar_Stenvaag.png]] [[User:Salahzar_Stenvaag|Salahzar Stenvaag]] was selling on XstreetSL marketplace an item called ''SpatialMap.org (MindMap 3D) v1.0.18 (MONO)'' for L$ 50. (He was selling also on [http://meta-life.net/second-life/item/89393-SpatialMaporg-MindMap-3D-v1018-MONO]).

: As you can see he was selling getting profit and this was not allowed under the [http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode Creative Commons license Attribution-NonCommercial-ShareAlike 2.5].

: The SpatialMap LSL source code was freely downloadable from [http://code.google.com/p/spatialmap/downloads/list http://code.google.com/p/spatialmap/downloads/list]. The license have been CC by-nc-sa 2.5 since version 0. If you have time you can see that '''every''' file has Creative Commons by-nc-sa references into the header. If you have doubts that people listed in [http://code.google.com/p/spatialmap/people] called owner, ''marco.vanadia'' and ''davide.caroli85'', are respectively [[User:Vision_Raymaker|Vision Raymaker]] and [[User:JonnyBee_Cioc|JonnyBee Cioc]] you can browse into Tish Shute UgoTrade blog article that cite our works [http://www.ugotrade.com/2008/01/28/the-archeology-and-future-of-software-design-meeting-grady-booch/].

: He, and everybody else, had and has rights to derive works from SpatialMap code, '''do not get profit from it''', and share what come out under the same license.

: Law doesn't admit ignorance and he also use same license in his works. So he must know what NotCommercial means. This means that he consciously infringe the law.

: So this is not 'Drama'. This is '''Theft'''. Penal prosecutable by law.

: I do not need to have a lawyer to say that and it is obvious that he can't had so much profit from this theft. But this is all about unethical after than illegal. He tells to embrace opensource ethic. Nice way to do it. People must be known from what they do after what they tell to do.
:[[User:Vision Raymaker|Vision Raymaker]] 18:25, 3 May 2010 (UTC)

File:Snapshot violazione CC by-NC-sa by Salahzar Stenvaag.png

2010-05-03T17:22:22Z

Vision Raymaker: Snapshot Salahzar Stenvaag violates Creative Commons license sellings items containing script released under CreativeCommons Attribution-NonCommercial-ShareAlike license

Snapshot Salahzar Stenvaag violates Creative Commons license sellings items containing script released under CreativeCommons Attribution-NonCommercial-ShareAlike license

User talk:Salahzar Stenvaag

2010-04-26T21:27:12Z

Vision Raymaker:

Hi, please contact me about an important issue regarding your use of litesim's code. IM me inworld (Gareth Ellison) or email me at gareth@litesim.com

[https://wiki.secondlife.com/wiki/User:Salahzar_Stenvaag Salahzar_Stenvaag] didn't and do not have rights to sell "SpatialMap.org (MindMap 3D) v1.0.18 (MONO)" object on [https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1647618] and [http://meta-life.net/second-life/item/89393-SpatialMaporg-MindMap-3D-v1018-MONO] because it's a violation of [http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode CreativeCommons by-nc-sa license] and [https://wiki.secondlife.com/wiki/Intellectual_Property Linden Lab Official KB: Intellectual Property] [[User:Vision Raymaker|Vision Raymaker]] 21:15, 26 April 2010 (UTC)

Wiki3DBuilder

2010-04-26T21:15:44Z

Vision Raymaker: Vision Raymaker annotated violation of CreativeCommons license by Salahzar Stenvaag

{{LSL Header}}

== Introduction ==
Here a sample of using this tool (v0.1) by a Sloodle fan (Giancarla Loon) for teaching sloodle basics for Teachers:

(See also the enhanced version v1 [[Wiki3DBuilder1.0]] with significative enhancements. I'm leaving this version on this wiki since somebody did like this version even with its limitations)

[[Image:Sloodle-mindmap.jpg]]

This had been built following the ideas (but not the code) of similar object "SpatialMap.org (MindMap 3D) v1.0.18" written by Jonny Bee Cioc and Vision Raymaker which was under a CC by,nc,sa license itself. You can find it here on xstreetsl: [https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1647618 Get it from xstreet].

[https://wiki.secondlife.com/wiki/User:Salahzar_Stenvaag Salahzar_Stenvaag] didn't and do not have rights to sell that object on [https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1647618 xstreet] because it's a violation of [http://creativecommons.org/licenses/by-nc-sa/2.5/legalcode CreativeCommons by-nc-sa license] and [https://wiki.secondlife.com/wiki/Intellectual_Property Linden Lab Official KB: Intellectual Property] [[User:Vision Raymaker|Vision Raymaker]] 21:15, 26 April 2010 (UTC)

=== Disclaimer ===

This is just a POC (Proof of Concept) and it is meant as a very alpha stage prototype I developed during last week.
It is not meant to satisfy security and high level coding standards.

In particular the following things are possibly dangerous and might be rethought and made it professionally:
* Using llSetPin using key2int is not good (final solution might have another copy of main script) which BTW will make the rezzing much rapid
* Using key2int to communicate with the rezzed cubes is to say the least quite "optimistic" and might lead to notworking and malfunctioning objects
* Need more sophisticated ways to Lock the object, to Link it in a unique linkset to simplify inventory operations and to avoid that everybody can hack or destroy the mindmap thing

=== QuickStart ===

* Build a cube, name it "nodo" and put inside the llSetPin script
* Build another cube, name it Wiki3D_Builder and put inside its content the "nodo" and the main script
* It should work just clicking on this starting cube (try to rez other cubes, to change the type, form etc).

=== What it is ===
A tool that helps a user to build rich 3D wiki architectures made up of NODES connected with particles BEAMS 
Each NODE can be customized by changing its NAME, COLOR, SIZE, and FORM 
Each NODE can contain:
# 1 Notecard
# 1 Landmark
# 1 Object
# 1 Script
# 1 Texture
# URL that can be given
The network is completely open to the participation of a group of people who can change the network, the position of each node, and freely add or remove portions of the graph.

Being a Wiki there is no limitation on who can do what. If you don't want that the work can be changed further, please set to NOT RUNNING the scripts. To save the mindmap you need to select all the nodes and manually link them together or take into inventory as an aggregate (a coalesced object).

=== How it works ===
Initially you have a NODE (i.e., a cube) which must be touched to start the process
* Touch object to see a menu with these options: color, name, size, content, move, rez
* Select "color" to enter a color on the local chat
* Select "name" to enter a name on the local chat
* Select "size" to enter a size on the local chat
* Select "rez" to rez a new node; when choosing this option, you must touch one of the faces of the cube and a new node will be rezzed 50cm on that direction.
* Select "move" and then touch a face to pull the node towards in direction
* Any user can move objects, textures and so from their inventory to a node (CTRL-Dragging them).
*'''Contents:''' Only one type of inventory item can be in the node at one time, and that content can be given to whom is asking for content
*Changing the texture will also change the texture of the node

=== Internal architecture ===
This is done in ONLY one script named "Main Script" and an internal object named "nodo" containing a llSetPin script.
The llSetPin is just a way for setting the pin to a number depending on the Owner of the object so it is NOT easy to
hack.
The "Main Script" is implementing a quite interesting mechanism for dealing with "multi-threading", i.e. multiple
avatars touching the object at the same time. This is accomplished using an Array of RECORDs representing
the waiting avatars and what they were waiting for. So listen(), touch(), and other events can query this QUEUE
and understand what is to be made next.
This also allows for an interesting handling of MULTI MENU
A part from this the rest is relatively simple, except for the communication between the various nodes.
* A node communicates with its children for example to propagate the DELETE message
* A node communicates with its parent to emit the particles connector
* A node receives messages from its parent to llDie and with alert when other related objects are changing UUID the latter happens when objects are re-rezzed from inventory
To accomplish this object listens to a
channelPublic (taken from Owner key) for transmitting and receiving changes of UUIDs,
or to channelPrivate (taken from the object key) for receiving commands from parent

== llSetPin to put in "nodo" object ==

This is NOT really needed you can instead put a copy of main script in inner object.
I used this technique to avoid changing every time the internal script whenever I update it.

<lsl>// This will convert an id to an integer same id => same key
// used to easily set up a not easy way to deposit scripts with a PIN
integer key2int(key id)
{
string idstring = (string)id;
integer ret = 0;
integer i = 0;
for(; i < llStringLength(idstring); ++i)
{
ret = ret * 10 + (((integer)("0x8"+llGetSubString(idstring, i, i)) - 2) % 17);
}
return ret;
}

default
{
state_entry()
{
llSetRemoteScriptAccessPin(key2int(llGetOwner()));
}
changed(integer change)
{
llSetRemoteScriptAccessPin(key2int(llGetOwner()));
}
}</lsl>

== The Main Script ==

<lsl>

// This source is "OpenSource"
// It can be freely used under the following CC license
// by: you need to state it was originally written by Salahzar Stenvaag
// nc: you cannot use for commercial products
// sa: you can extend it but you must redistribute it under the same license
// This software is specifically written to be used by GPLv3 licenced software

// Wiki3DBuilder (MindMap)
// This had been built following the ideas (but not the code) of similar
// object "SpatialMap.org (MindMap 3D) v1.0.18" written by Jonny Bee Cioc and Vision Raymaker
// which was under a CC by,nc,sa license itself

// What it is
// ==========
// You can build rich 3D wiki architectures made up of NODES, connected with particles BEANS
// Each NODE can be customized changing its NAME, COLOR, SIZE, FORM and possibly inserting in it
// 1 Notecard, 1 Landmark, 1 Object, 1 Script, 1 Texture, URL that can be given
// The network is completely open to the participation of a group of people who can change the
// newtwork, the position of each node, and freely add or remove portions of the graph

// Being a Wiki there is no limitation on who can do what. If you don't want that the work can be furtherly
// changed please set to NOT RUNNING the scripts. To save the mindmap you need to select all the nodes
// and manually link them together or take in the inventory as aggregate

// How it works
// Initially you have a NODE, i.e. a cube which must be touched to start the process
// Touching it you have a menu specifying color, name, size, content, move, rez, ...
// * clicking on name you can type the name on the local chat and other menu for resizing, recoloring...
// * clicking rez you rez a new node when choosing this option you must touch one of the faces of the cube:
// new node will be rezzed 50cm on that direction.
// * similarly applies to move clicking on a face will pull the node towards that direction
// * content. Everybody can move objects, textures and so from their inventory to a node (CTRL-Dragging them).
// at each moment only one type of object can be in the node and it can be given to whom is asking for content
// changing the texture will also change the texture of the node

// Internal architecture
// This is done in ONLY one script named "Salahzar Map" and an internal object named "nodo" containing a llSetPin script.
// The llSetPin is just a way for setting the pin to a number depending on the Owner of the object so it is NOT easy to
// hack.
// The "Salahzar Map" is implementing a quite interesting mechanism for dealing with "multi-threading", i.e. multiple
// avatars touching the object at the same time. This is accomplished using an Array of RECORDs representing
// the waiting avatars and what they were waiting for. So listen(), touch(), and other events can query this QUEUE
// and understand what is to be made next.
// This also allows for an interesting handling of MULTI MENU
// A part from this the rest is relatively simple, except for the communication between the various nodes.
// A node communicates with its children for example to propagate the DELETE message
// A node communicates with its parent to emit the particles connector
// A node receives messages from its parent to llDie and with alert when other related objects are changing UUID
// the latter happens when objects are re-rezzed from inventory
// To accomplish this object listens to a
// channelPublic (taken from Owner key) for transmitting and receiving changes of UUIDs,
// or to channelPrivate (taken from the object key) for receiving commands from parent

// TODOLIST:

// implement LINKSET all this can be very tricky
// implement UNLINK (remove particles)

// CUSTOMIZABLE PARAMETERS
integer TIMEOUT=30; // menu will be obsolesced after this period of time
integer CLEANTIMERSEC=10; // timer will run once every this period of time for cleaning timers
integer DEBUG=0; // 2 maximum level
// END OF CUSTOMIZABLE PARAMETERS

string url=""; // url associated with this node

// 0) General utility functions

// debug this string only if DEBUG is at least 1
debug(string str)
{
if(DEBUG>=1)llOwnerSay(str);
}

// trace the string only if DEBUG is 2
trace(string str)
{
if(DEBUG>=2)llOwnerSay(str);
}
// will put on the hover string
notify(string str)
{
llSetText(str,<1,1,1>,1);
}

// 1) RECORD STACK
// handling. We keep a "queue" or RECORDS for understanding
// multi-avatar touching and remember prompts and menu and let them expire
//

integer STRIDE=6; // we hold 6 field in the waiting list
list waiting=[]; // this is where we actually keep the queue

// this will be the RECORD with the 6 fields
string theType; // it is something like MENUxxxx or PROMPTyyyy
key theAv; // which avatar is waiting
integer theTime; // when the RECORD has been stacked
integer theMenu; // the menu handle so we can clean up it
integer theChannel; // which channel
string theRest; // some further information on this RECORD (prompt string?)

// count how many RECORDS are being stacked waiting to be served
integer howManyRecords()
{
integer ret= llGetListLength(waiting)/STRIDE;
trace("howManyRecords returning: "+(string)ret);
return ret;
}
// load the record in theXXX variables to ease handling of it
integer loadTheRecord(integer index)
{
if(index>=0)
{
theType=llList2String(waiting,index);
theAv=llList2Key(waiting,index+1);
theTime=llList2Integer(waiting,index+2);
theMenu=llList2Integer(waiting,index+3);
theChannel=llList2Integer(waiting,index+4);
theRest=llList2String(waiting,index+5);
debug("Loading the record: \n type: "+theType+"\n Av: "+(string)theAv
+"\n time: "+(string)theTime+"\n menu: "+(string)theMenu+"\n channel:"
+(string)theChannel+"\n rest:"+theRest);
return index;
}
else
{
theType="";
theAv=NULL_KEY;
theTime=-1;
theMenu=-1;
theChannel=-1;
theRest="";
trace("No record returned");
return -1;
}
}

// look in our stack for this avatar return the index AND loading in theXXX variables

integer findWaitingAvatar(key av)
{
debug("Looking for avatar: "+(string)av);
integer pos=llListFindList(waiting,[av]);
integer index;
if(~pos) index=pos-1; else index=-1;
return loadTheRecord(index);
}
// change the time of the event at position index
updateTimer(integer index)
{
if(index<0 || index>=howManyRecords()) return;
trace("Updating timer for index: "+(string)index);
integer posTime=index*STRIDE+2;
waiting=llListReplaceList(waiting,[ llGetUnixTime() ], posTime, posTime);
}

// remove a record
integer deleteRecord(integer index)
{
if(index>=0 && index<howManyRecords())
{
integer i=index*STRIDE;
waiting=llDeleteSubList(waiting,i,i+STRIDE-1);
trace("deleteRecord "+(string)index+" array: "+llList2CSV(waiting));
}
return TRUE;
}

// PSEUDO record containing the avatar for detecting key and message
key detected_key=NULL_KEY;
string detected_type="";

// add a MENU stack in the queue
addMenu(string type, key av, string title, list options)
{
trace("Adding menu "+type+" for "+(string)av);
integer channel=-1000000-(integer)llFrand(1000000);
integer menuid=llListen(channel,"",av,"");
waiting+=[ type, av, llGetUnixTime(), menuid, channel,"" ];
//debug("List in touch: "+llList2CSV(waiting));
llDialog(av,title,options,channel);

}
// add a PROMPT stack in the queue
addPrompt(string type, key av, string title)
{
trace("Adding prompt "+type+" for "+(string)av);
integer menuid=llListen(0,"",av,"");
waiting+=[ type, av, llGetUnixTime(), menuid, 0, title];

llInstantMessage(av,"Please chat: "+title);

}
// add in queue detect option to be able square is TRUE if we only allow boxed movement
addDetected(string type, key av, string title)
{
trace("Adding detected "+type+" for "+(string)av);
detected_key=av;
detected_type=type;

}
remove_detected()
{
trace("remove detected");
detected_key=NULL_KEY;
detected_type="";
}

// 2) INVENTORY HANDLING

list currentInventory=[]; // will keep note of current inventory
// return a list of strings in ls1 NOT in ls2
// actually implementing set difference : [ a,b,c ] - [a, b] => [c]
// useful to understan which elements have been added deleted in the inventory
list diffList(list ls1, list ls2)
{
//llSay(0,"ls1: "+llList2CSV(ls1)+" ls2:"+llList2CSV(ls2));
list ret=[];
integer i=0;
for(i=0;i<llGetListLength(ls1);i++)
{
list el=llList2List(ls1,i,i);
// if not found in ls2 add to residual
if(llListFindList(ls2, el)<0)
{
ret+=el;
}
}
return ret;
}

// find out the first inventory object of the specified type
string getFromListOfType(list lst,integer type)
{
integer i;
for(i=0;i<llGetListLength(lst);i++)
{
string name=llList2String(lst,i);
if(name != "nodo" && name != llGetScriptName() && name != "llSetPin")
{
if(llGetInventoryType(name)==type) return name;
}
}
return "";
}

// will check if inventory changed and make sure that we have JUST one elemento
// for each type
inventoryUpdate()
{
//llSay(0,"inventory update");
integer i=0; integer j=0; string ret="";
integer num=llGetInventoryNumber(INVENTORY_ALL);
//if(num==llGetListLength(currentInventory)) return;

list newInventory=[];
for(i=0;i<num;i++)
{
string name=llGetInventoryName(INVENTORY_ALL,i); integer found=0;
newInventory+=[name];
}
// now find added inventory
list added=diffList(newInventory,currentInventory);
list removed=diffList(currentInventory,newInventory);

//llSay(0,"==>Added "+llList2CSV(added));
//llSay(0,"==>Removed "+llList2CSV(removed));

// now check for each added if there was a duplicate in currentInventory
for(i=0;i<llGetListLength(added);i++)
{
string name=llList2String(added,i);
string already=getFromListOfType(currentInventory,llGetInventoryType(name));
if(already!="")
{
llRemoveInventory(already);
llSay(0,name+" replaced "+already);
}
else
llSay(0,name+" inserted in content");

if(llGetInventoryType(name)==INVENTORY_TEXTURE)
llSetTexture(name,ALL_SIDES);
}

currentInventory=newInventory;
return;
}

// 3) handles particles
key target=NULL_KEY;
particles()
{

trace("making particles to "+(string)target);
integer pattern = PSYS_SRC_PATTERN_ANGLE;
integer flags= PSYS_PART_EMISSIVE_MASK
| PSYS_PART_INTERP_COLOR_MASK
//| PSYS_PART_FOLLOW_SRC_MASK
| PSYS_PART_FOLLOW_VELOCITY_MASK
| PSYS_PART_INTERP_SCALE_MASK
| PSYS_PART_TARGET_LINEAR_MASK
| PSYS_PART_TARGET_POS_MASK;
// set particles
llParticleSystem([ PSYS_PART_MAX_AGE,5.0,
PSYS_PART_FLAGS, flags,
PSYS_PART_START_COLOR, <1,0.25,0.25>,
PSYS_PART_END_COLOR, <0.75,0,0>,
PSYS_PART_START_SCALE,<0.051,.2,FALSE>,
PSYS_PART_END_SCALE,<0.2,.1,FALSE>,
PSYS_SRC_PATTERN, pattern,
PSYS_SRC_BURST_RATE,.1,
//PSYS_SRC_ACCEL, <0,0,0>,
PSYS_SRC_BURST_PART_COUNT,8,
//PSYS_SRC_BURST_RADIUS,0.0,
PSYS_SRC_BURST_SPEED_MIN,0.0,
PSYS_SRC_BURST_SPEED_MAX,5.0,
PSYS_SRC_TARGET_KEY,target,
PSYS_SRC_ANGLE_BEGIN,0.0,
PSYS_SRC_ANGLE_END,0.0,
PSYS_SRC_OMEGA, <0,0,0>,
PSYS_SRC_MAX_AGE, 0.0,
//PSYS_SRC_TEXTURE, TEXTURE_BLANK,
PSYS_PART_START_ALPHA, 1.0,
PSYS_PART_END_ALPHA, 0.5
]);

}
// 4) This will convert an id to an integer same id => same key
// used to easily set up a not easy way to deposit scripts with a PIN
integer key2int(key id)
{
string idstring = (string)id;
integer ret = 0;
integer i = 0;
for(; i < llStringLength(idstring); ++i)
{
ret = ret * 10 + (((integer)("0x8"+llGetSubString(idstring, i, i)) - 2) % 17);
}
return ret;
}

integer isroot=TRUE; // are we the MAIN object? Useful to avoid being deleted
list children=[]; // will keep the keys of ALL depending children

// 5) propagate message to all children
propagate(string message)
{
debug("Received message propagating to children: "+llList2CSV(children));
// received a message from my parent
// propagate message to my children
integer i;
for(i=0;i<llGetListLength(children);i++)
{
integer channel=key2int(llList2Key(children,i));
debug("Saying on channel "+(string)channel+" "+message);
llSay(channel,message);
}
if(message=="DELETE")
{
// we must die IF we are not ROOT

if(isroot==0) llDie();
else debug("Cannot delete master cube");
}

}

// ============================== MAIN =========================

integer lstPrivate;
integer lstPublic;
integer channelPublic;
integer channelPrivate;

key parent=NULL_KEY;
default
{
state_entry()
{
// setting the communication channel identity private can change when re-rezzing
channelPrivate=key2int(llGetKey());
channelPublic=key2int(llGetOwner());
debug("My local channel: "+(string)channelPrivate);
debug("My public channel: "+(string)channelPublic);

// if we are the main node go directly to ready
// we know that because we don't have the llSetPin on main Ball
inventoryUpdate(); // setup inventory
if(llGetInventoryType("llSetPin")==INVENTORY_NONE)
{
isroot=TRUE;
//llRequestPermissions(llGetOwner(), PERMISSION_CHANGE_LINKS);
state ready;
}

isroot=FALSE;
// we are in a child node,
notify("Node bootstrapping...");
// else rezzed by parent wait to listen who is the parent
// parent will send a message on a special channel computed starting from
// the child key

// waiting for knowing who is my parent
lstPrivate=llListen(channelPrivate,"",NULL_KEY,"");
}

// this listen only waits until my parent talks to me
// this happens when rezzing avatar stops the menu
listen(integer channel,string name, key id, string str)
{
debug("received "+str+" on channel "+(string)channel);

// set my parent to whom is talking to me first
parent=id;
// llListenRemove(lstparent);

// emits the beam towards my parent
target=id;
particles();

// remove listener before leaving this state
llListenRemove(lstPrivate);

state ready;
}

}

// =========================== READY =========================

state ready
{
state_entry()
{
// reset waiting list
waiting=[]; children=[]; notify(llGetObjectName());
llSetTimerEvent(CLEANTIMERSEC); // garbage collector

// listen on private channel (for messages from parent -- delete)
lstPrivate=llListen(channelPrivate,"",NULL_KEY,"");

// listen on public channel (for UUID changing)
lstPublic=llListen(channelPublic,"",NULL_KEY,"");

// allow inventory dropping (for content dropping)
llAllowInventoryDrop(TRUE);

// If here it means I'm being creating from scratch... Mark my UUID on the description
llSetObjectDesc((string)llGetKey());
}

on_rez(integer rez)
{
trace("Object rezzed with new taskUUID");
// this happens ONLY if I come back from the inventory my UUID has changed
// then will broadcast my old UUID
string what="OUID:"+llGetObjectDesc();
debug("Saying "+what+" in public channel "+(string)channelPublic);
llSay(channelPublic,what);

// private channel has to be reset!
llListenRemove(lstPrivate);
channelPrivate=key2int(llGetKey());
trace("Listening to new privateChannel "+(string)channelPrivate);
lstPrivate=llListen(channelPrivate,"",NULL_KEY,"");

// reset the description
llSetObjectDesc((string)llGetKey());

}
// If we changed owner or inventory
changed(integer change)
{
//llSay(0,"change: "+(string)change);
if(change & CHANGED_OWNER)
{
debug("Changed owner, resetting");
llResetScript();
}
// handle changing of the inventory or somebody dropped
if(change & CHANGED_INVENTORY || change & CHANGED_ALLOWED_DROP)
{
inventoryUpdate();
}
}

// timer is trying to get all the menu listener clean
// if they are exhausted then proceed to cancel them
timer()
{
integer i;
for(i=0;i<howManyRecords();i++)
{
loadTheRecord(i); // into theXXXX fields

// check if timeout (60 seconds
if( (llGetUnixTime() - theTime ) > TIMEOUT )
{
debug("Removing listener for "+llKey2Name(theAv));
// if we were on particular menu should also delete the
llListenRemove(theMenu);
deleteRecord(i);

// if timeout something related to the detected avatar need to remove from list
if(detected_key==theAv) remove_detected();

}
}
//debug("List in timer exit: "+llList2CSV(waiting));
}

// main menu listening for waiting avatars
// we answer only to
touch_start(integer total_number)
{
integer i;
for(i=0;i<total_number;i++)
{
key av=llDetectedKey(i);
debug("touched by "+llKey2Name(av));

// check if we already have this avatar waiting. Don't allow touches if in a menu or a prompt!!!!
integer index=findWaitingAvatar(av);
if(index>=0)
{
debug("Has already a menu waiting");
// we have a menu for this avatar.. Check if we have it in detected_key
// in such case we allow touching for detecting
if(av==detected_key)
{
trace("We have a detected_key for this avatar type:"+detected_type);
// handle this event
if(detected_type=="DETECTMOVE")
{
debug("Moving the prim");
llSetPos(llGetPos()+llDetectedTouchNormal(i)*0.2);
}

if(detected_type=="DETECTPOSREZ")
{
debug("rezzing a new cube");
vector posrez=llDetectedTouchNormal(i);
llRezAtRoot("nodo",llGetPos()+posrez,ZERO_VECTOR,ZERO_ROTATION,1);
// execution is going on at rez_object

}
//upgrade time for this event extend it so that timer won't remove it for next 60 secs
updateTimer(index);

// do NOT consume this event will be ended by ctimeout
return;
}

// touch this when avatar has already a queue, will remove the queue
deleteRecord(index);

// informing the avatar the menu has been reset
llInstantMessage(av,"Removing pending menu/promt");
return;
}

// avatar hasn't any pending menu so start with main menu
// start the initial menu
addMenu("MENUMAIN",av,"Main menu:
DELETE: delete this and children,
NAME: you can type the new name,
COLOR: change the color,
SIZE: change the scale,
REZ: rez another node (click next on face for where to rez)
MOVE: pull the object in a direction (click next on face for where to rez),
TYPE: changes the object type,
HELP: go to online help,
UNLINK: remove the connecting beam",
["DELETE","NAME","COLOR",
"SIZE","REZ","MOVE",
"TYPE","HELP","UNLINK",
"CONTENT" ]);
trace("List in touch exit: "+llList2CSV(waiting));
return;
}
}

// listen must understand if this avatar already has pending menu
// and correctly sort out of them
listen(integer channel,string name, key id, string message)
{
debug("receiving a message in channel "+(string)channel+" message "+message);

// PRIVATE CHANNEL
if(channel==channelPrivate)
{
debug("Received a message for me from my parent "+message);
propagate(message);
return;
}

// PUBLIC CHANNEL
if(channel==channelPublic)
{
// on channel public we ONLY receive OLD UUID in the format
// UUID:
if(llGetSubString(message,0,4)=="OUID:")
{
key olduuid=(key)llGetSubString(message,5,-1);
debug("Received from "+(string)id+" UUID change from old "+(string)olduuid);

// need to understand if it was MY target
if(target==olduuid){
target=id;
particles(); // change the beam to this new target
}
// check my children
integer pos=llListFindList(children,[olduuid]);
if(pos>=0)
{
debug("Replacing in children olduuid: "+(string)olduuid+" with "+(string)id);
children=llListReplaceList(children,[id],pos,pos);
}

}
return;
}

// if not channel public or private then it shoudl be on stack
integer index=findWaitingAvatar(id);
debug("listen index found on waiting list: "+(string)index);
if(index<0) return;

// only here if we found on the stack
integer elapsed=llGetUnixTime()-theTime;

// remove handle AND the record from waiting list
llListenRemove(theMenu);
deleteRecord(index);
debug("Found listen menu type: "+theType+" mesg "+message);

// stopping menus
if(theType=="MENUSTOPMOVE")
{
remove_detected();
llInstantMessage(id,"Stop moving");
return;
}
if(theType=="MENUSTOPREZ")
{
remove_detected();
llInstantMessage(id,"Stop rezzing");
return;
}

// handling menu content allow for setting content
if(theType=="MENUCONTENT")
{
// allows for specifying a URL
if(message=="SETURL")
{
addPrompt("PROMPTURL",id,"Say in chat the url where to go");
return;
}
// just send help on how ctrl-dragging objects
if(message=="SETCONTENT")
{
// send help
llInstantMessage(id,"Please ctrl-drag something from your inventory on me. You can change the texture dragging a texture");
return;
}

// going to stored URL
if(message=="GIVE URL")
{
if(url!="")
{
llLoadURL(id,"Go to webpage",url);
}
return;
}
// handle all GETXXX buttons
string name; string desc;
if(message=="GIVE NOTE")
{
name=getFromListOfType(currentInventory,INVENTORY_NOTECARD);
desc="notecard";
}
if(message=="GIVE LMARK")
{
name=getFromListOfType(currentInventory,INVENTORY_LANDMARK);
desc="landmark";
}
if(message=="GIVE OBJECT")
{
name=getFromListOfType(currentInventory,INVENTORY_OBJECT);
desc="object";
}
if(message=="GIVE TEXTURE")
{
name=getFromListOfType(currentInventory,INVENTORY_TEXTURE);
desc="texture";
}

if(name=="")
{
llInstantMessage(id,"No "+desc+" to give you");
return;
}
// giving actually the object
llGiveInventory(id,name);
llInstantMessage(id,"You have been given a "+desc+" named "+name);
return;

}

// Handling of the options in MAIN MENU
if(theType=="MENUMAIN")
{
if(message=="HELP")
{
llLoadURL(id,"Load this page for help","http://opensimita.org/lsl/mindmap/README.html");
return;
}
if(message=="CONTENT")
{
integer i;
string texture=getFromListOfType(currentInventory,INVENTORY_TEXTURE);
string object=getFromListOfType(currentInventory,INVENTORY_OBJECT);
string note=getFromListOfType(currentInventory,INVENTORY_NOTECARD);
string landmark=getFromListOfType(currentInventory,INVENTORY_LANDMARK);
string prompt = "Choose an action:
SETCONTENT: explains how to insert an object
SETURL: allows for specifying a url";
list buttons=["SETCONTENT","SETURL" ];
if(url!="")
{
prompt+="\nGIVE URL: go to the url "+url;
buttons+=["GIVE URL"];
}
if(note!="")
{
prompt+="\nGIVE NOTE: get the note "+note;
buttons+=["GIVE NOTE"];
}

if(object!="")
{
prompt+="\nGIVE OBJECT: get the object "+object;
buttons+=["GIVE OBJECT"];
}

if(landmark!="")
{
prompt+="\nGIVE LMARK: get the landmark "+landmark;
buttons+=["GIVE LMARK"];
}
if(texture!="")
{
prompt+="\nGETTEXTURE: get the texture "+texture;
buttons+=["GIVE TEXTURE"];
}

addMenu("MENUCONTENT",id,prompt,buttons);
return;
}
if(message=="NAME")
{
addPrompt("PROMPTNAME",id,"Say in chat name of this concept");
return;
}
if(message=="DELETE")
{
addPrompt("PROMPTDELETE",id,"Say DELETE in chat to be absolutely sure to delete from here");
return;
}
if(message=="COLOR")
{
addMenu("MENUCOLOR",id,"Enter color",["RED","GREEN","BLUE","WHITE","BLACK","VIOLET","TURQUESE","YELLOW"]);
return;
}
if(message=="SIZE")
{
addMenu("MENUSIZE",id,"Enter size",["HALF", "DOUBLE", "+0.2","-0.2","DEFAULT"]);
return;
}

if(message=="UNLINK")
{
llParticleSystem([]); target=NULL_KEY;
llInstantMessage(id,"Removed particles");
return;
}
// detected category
if(message=="REZ")
{
addDetected("DETECTPOSREZ",id,"Enter position where rez");
addMenu("MENUSTOPREZ",id,"Click on a face of the concept to rez a new cube in that direction.\nClick 'stop' after chosing",["STOP"]);
return;
}
if(message=="MOVE")
{
addDetected("DETECTMOVE",id,"Click on a face of the concept and the cube will move 20cm in that direction.");
addMenu("MENUSTOPMOVE",id,"Click to stop moving",["STOP"]);
return;
}
if(message=="TYPE")
{
addMenu("MENUTYPE",id,"Select type of this concept",["SPHERE","CUBE","FLAT","CYLINDER","PYRAMID","POINT","STAR","ENDTYPE"]);
return;
}
}

// change the type of this prim
if(theType=="MENUTYPE")
{
if(message=="ENDTYPE")
{
llInstantMessage(id,"Finished with typing");
return;
}
list typ=[];
if(message=="FLAT")
{
vector scale=llGetScale();
llSetScale(<0.01,scale.y,scale.z>);
return;
}

if(message=="POINT")
{
llSetScale(<0.01,0.01,0.01>);
return;
}
if(message=="STAR")
{
llInstantMessage(id,"STAR not yet implemented");
return;
}

if(message=="SPHERE") typ=[ PRIM_TYPE, PRIM_TYPE_SPHERE, 0, <0,1,0>, 0.0, <0,0,0>,<0,1,0> ];
if(message=="CUBE") typ=[ PRIM_TYPE, PRIM_TYPE_BOX,0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>];
if(message=="CYLINDER") typ=[ PRIM_TYPE, PRIM_TYPE_CYLINDER, 0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>];
if(message=="PYRAMID") typ=[ PRIM_TYPE, PRIM_TYPE_BOX,0, <0.0, 1.0, 0.0>, 0.0, <0.0, 0.0, 0.0>, <0.0, 0.0, 0.0>, <0.0, 0.0, 0.0>];

llSetPrimitiveParams(typ);

addMenu("MENUTYPE",id,"Select type of this concept",["SPHERE","CUBE","FLATBOX","CYLINDER","PYRAMID","POINT","STAR","ENDTYPE"]);
return;

}

// change the size of this prim
if(theType=="MENUSIZE")
{
vector current=llGetScale();
if(message=="HALF") current=current/2;
if(message=="DOUBLE") current=current*2;
if(message=="+0.2") current=current+<0.2,0.2,0.2>;
if(message=="-0.2") current=current-<0.2,0.2,0.2>;
if(message=="DEFAULT") current=<0.5,0.5,0.5>;
llSetScale(current);
llInstantMessage(id,"Size changed to '"+(string)current+"'");
return;

}

// change the color of this prim
if(theType=="MENUCOLOR")
{
if(message=="RED") llSetColor(<1,0,0>,ALL_SIDES);
if(message=="GREEN") llSetColor(<0,1,0>,ALL_SIDES);
if(message=="BLUE") llSetColor(<0,0,1>,ALL_SIDES);
if(message=="WHITE") llSetColor(<1,1,1>,ALL_SIDES);
if(message=="BLACK") llSetColor(<0,0,0>,ALL_SIDES);
if(message=="VIOLET") llSetColor(<1,0,1>,ALL_SIDES);
if(message=="TURQUESE") llSetColor(<0,1,1>,ALL_SIDES);
if(message=="YELLOW") llSetColor(<1,1,0>,ALL_SIDES);
llInstantMessage(id,"Color changed to '"+message+"'");
return;
}

// change the name
if(theType=="PROMPTNAME")
{
notify(message);
llSetObjectName(message);
llInstantMessage(id,"Name changed to '"+message+"'");
return;
}
if(theType=="PROMPTDELETE")
{
if(message=="DELETE")
{
// handle delete message
propagate(message);
return;
}
}

// change the url
if(theType=="PROMPTURL")
{
url=message;
llInstantMessage(id,"URL accepted: "+url);
return;
}

}
// when new node is rezzed then we give this script running and tell it
// my id so that it can emit particles
object_rez(key id)
{

// understand the remotepin which is publicchannel
integer remotePin=key2int(llGetOwner());
integer childchannel=key2int(id);

llRemoteLoadScriptPin(id, llGetScriptName(), remotePin, TRUE, key2int(llGetKey()));
debug("Obtaining my key: "+(string)childchannel+(string)llGetKey());

// memorize this channel so to be able to speak to all my children in case of die
children+=[id];

llGiveInventory(id,"nodo");

debug("Chatting "+(string)llGetKey()+" on channel "+(string)key2int(id)+ "children: "+llList2CSV(children));
llSay(childchannel,(string)llGetKey());

//llInstantMessage("Node created");
}
}
</lsl>

== Having a copy from XStreetsl ==
If you have any difficulties in having these scripts running, please get a copy from XStreetSL: https://www.xstreetsl.com/modules.php?name=Marketplace&file=item&ItemID=1632590

Havok4

2008-02-15T10:19:26Z

Vision Raymaker: added multilink template

{{Multi-lang}}
==Havok4 (New Physics Engine) Beta Test Information Hub==
===Introduction===
The beta testing for the Havok4 implementation in Second Life is now in process. This page provides information on the project, as well as useful information that will help us all to make sure that Havok4 is tested well before it is rolled throughout the main Second Life grid.

Please read the [[Havok4 Beta1 Release Notes]]

===What Is Havok?===
The Second Life virtual world has a lot of moving parts that keep it going. One of these is the Physics Engine. A physics engine is a specialized piece of software that does the "real world" calculations to figure out what do when:
* Something or someone is pushed
* Something or someone collides with something or someone else
* Something or someone is in motion and has momentum
* Friction or damping slows the motion of something or someone

Havok is a commercially produced physics engine, and Second Life was built using Havok1. on which it operated for several years.

===How Can I Participate In Havok4 Physics Engine Testing?===
You can participate in the Beta Test of Havok4 with a few easy steps:
# Read "[[What's Changed With Havok4]]" to understand what should be different, and what should not be different, on the Havok4 Beta Test grid
# Read "[[Linkability_Rules|New Prim Linkability Rules]]" to understand how prim linkage works with Havok4 (it's better and should be much more reliable!)
# Login to the Public Issue Tracker at "[https://jira.secondlife.com/ Issue Tracker]" to see how easily you can tell us about problems you find during the beta test
# [http://secondlife.com/community/preview.php Download the install the Havok4 Beta Viewer here]

===What To Test?===
Make sure that all of the your content works on the Havok4 grid, and try as many physics-related things as you can think of as well... Here is a short list, and a link to a page with a more exhaustive list of ideas:
* Building, linking, unlinking
* Vehicles
* Weapons
* "Spells"
* Shields
* Building Tools
* Rezzing large linked sets of prims
* Try building simple and complex items, taking them into inventory and rezzing them in different orientations and in different places
* Does walking, sitting, flying, swimming, running and other avatar motions work the way you expect it to?
* Do scripts work as expected?
* Try creating scripts and modifying them
* Are permissions working correctly?
* Can you get the sim to crash using "physics crashes"? (those of you who know what this means... "go for it" and let us know if you can... ;)

There are [[Havok4_Beta_Test_Ideas|Many Things You Can Test In Havok4]] (a list of lots of things that would be helpful for you to test. Feel free to pick and choose from this list and make up your own things to try as well!

===How Do I Stay "In The Loop" With Havok4 Testing?===
# Attend "[[Regular Havok4 Office Hours In-World]]"
# TELL US about everything you find using the Public Issue Tracker at "[https://jira.secondlife.com/ Issue Tracker]" 
Please enter bugs using PROJECT "Second Life Service - SVC" and when entering the bug choose AFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" to be sure we see them right away!

===How Will Havok4 Be Tested And Rolled Out?===
This project replaces a core component of Second Life, and being sure that "anything that pushes, collides or has inertia" works right is a pretty extensive task. We have already done a lot of internal testing, and plowed through hundreds of internal bug fixes. We will be taking a phased approach to both catch as many problems as early as possible, and reduce risk of issues as Havok4 is rolled out.

Phase 1 - Internal Testing On Non-Public Test Grid (DONE!) 
We already completed this phase, and had a variety of internal staff work on Havok4 enabled simulators. Basic functions were checked, as well as checking to see that the known physics-related simulator crashes were resolved.

Phase 2 - Public Beta Test On Beta Grid (DONE!) 
We expect the public beta test for Havok4 to be very active, with many participants. We have prepared a test grid that allows for many types of physics-related tests. The test regions will include:
* [[Orientation Islands]]
* [[Welcome Areas]]
* [[Lusk]]
* Several [[sandboxes]]
* [[Combat sandboxes]]
* [[Vehicle testing simulators]]

NOTE: The Public Beta viewer will be configured to use the beta grid, which will be a snapshot copy of portions of the main grid and a copy of your user account. You can do "anything you want" on this grid without risking damage to your "real account" on the main grid.

Phase 3 - Havok4 On A Select Few Main Grid Regions (DONE!) 
In this phase we will use the new HetGrid functionality to deploy Havok4 simulators on a small number of regions of the main grid. This will still be a testing phase, and for this phase any participants will need to remember that you will be on the main grid, working with your real inventory (caveat emptor - don't rez "no copy/transfer" items on these early test Havok4 sims without understanding the potential risks)

Phase 4 - Partial Main Grid Rollout (400-500 regions) ("YOU ARE HERE!" :) 
At this point, we will have resolved outstanding issues found during beta testing and the Phase 3 "small deployment in a corner of the main grid" and will deploy Havok4 to a subset of the main grid.

After collecting feedback, if all looks good, we will continue to...

Phase 5 - Full Havok4 Rollout On Main Grid (deploy to rest of grid) 
If all is clean at this point, we will then roll out the Havok4 engine to the rest of the main grid, and we'll be "live" with Havok4 everywhere.

===A Historical Note: Why Did "Doing Havok" Take So Long?===
Some of you who have been around for a long time will know that we talked about replacing Havok1 a long time ago, and did not seem to get this project done, and finally went silent about it. After several false starts, we decided that it would be best to stop talking about the work, or making public commitments, until we were far closer to the goal, and we believe that we are finally at this point.

For "quite some time" we worked to replace Havok1 with Havok2. After working on that project, we realized that we really should rework the interfaces for how Havok is integrated with Second Life. We realized that we needed to define an abstraction layer - a layer of code that would make it easier to do future physics engine migrations so that they don't take as much effort as this migration took, and to allow for more flexibility down the road. At this point Havok4 became a much more reasonable target than implementing based on a then-older release... and thus we set Havok4 as the target. This project has been significantly larger than any of us anticipated, however the good news is that we are now here, ready for beta testing, and ready to fix the last minute issues before we bring Havok4-based sims to the main grid!

== New experiences that are normal ==

=== Ejection and separation of interpenetrating objects ===
One of the largest improvements over the previous Havok I engine is that Havok 4 supports separation of interpenetrating objects. That is, a cube that is embedded into the ground and turned physical will attempt to work its way out and up, until it has separated from from the ground and then rests on the ground.

The previous engine did not handle interpenetrating objects very well. It would go into a deeply recursive processing loop known as the "Deep Think" condition, trying to determine where the overlapping objects should move, causing the simulator to run very slowly.

The new engine quickly and easily separates overlapping objects. The objects are treated like compressed springs, so that a deeper interpenetration imparts a greater ejection force onto the object. The interpenetration resolver attempts to obey movement constraints and will not explode out through enclosing walls, but will expand out through whatever openings or spaces are available.

Here is a Google Video showing an extreme example of how the interpenetration resolver works. A stack of about 200 very large disks about 0.5 meter thick overlap in a short stack about 10 meters tall, and enclosed inside a large hollow tube. When rezzed on the ground and turned physical, the disks explode upward and out of the top of the tube, with some disks shooting over 300 meters high from the repulsive force of the overlap resolution. No scripted movements or pushes are being applied to the disks. The motion is purely from the interpenetration resolver.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Simulator lag from huge piles of stacked objects ===
Even though this is a new and improved physics engine that should not crash as frequently as the original Havok-1 engine, there are times when the new simulator will still experience very bad lag due to a large number of touching physical objects.

This lag is not a bug, and is not like the old Havok-1 Deep Think condition, but is due to a limitation in how physics engines work in general. This same problem affected Havok-1, but it wasn't as obvious, since large stacks often crashed the simulator before this condition could become apparant.

Normally when physical objects slow down to below a critical speed for a period of time, the engine quiets the physics processing for that object, in order to save CPU time for the more active objects.

In order for the physics processing to settle, the object needs to be in contact with a nonmoving reference object. A single physical bar coming to a stop touching the ground is therefore quieted.

But for multiple stacked physical objects, it is difficult for them all to settle down, because one or more of the other touching objects may still be slightly moving when the other objects settle. This slight movement of the one then reawakens the objects that previously were settled, resulting in small movements rippling through the stack. The feedback of reawakening constantly circulates through the pile so that none of them are ever really able to settle completely. This constant moving and twitching of the spheres is similar to the physical concept of Brownian Motion with atoms.

Google Video example of simulator lag generated from 565 physical spheres held inside a container:

http://video.google.com/videoplay?docid=7316931483709158462

This engine lag is not based on the size of the objects involved. A collection of 500 very small stacked objects can cause as much lag as 500 large stacked objects.

=== Thousands of objects that don't touch do not lag ===

The Havok-4 simulator will run at full speed, if there is enough space between physical objects so that the reawakening collisions are kept to a mininum.

There can be thousands of physical objects in a simulator without any lag, just so long as the objects minimally touch each other.

Google Video of 2000-3400 physical cubes in a sandbox, with no lag:

http://video.google.com/videoplay?docid=-2779779276874540721

=== Pseudocode for llPushObject (the Havok4 implementation of this function) ===
[http://wiki.secondlife.com/wiki/LlPushObject/Havok4Implementation Pseudocode for llPushObject]

Linkability Rules/it

2008-01-29T12:51:04Z

Vision Raymaker: correct multi-lang template param

{{Multi-lang}}
=== Quando le prim sono linkabili ===

Considerate due primitive, A e B. Per determinare se queste possono essere collegate o meno si calcola lo ''spazio'' dal bordo della sfera che racchiude l'oggetto al bordo opposto dall'altra sfera e confrontandolo con il valore di ''massima distanza di linkabilità'', che è una funzione dei raggi delle due sfere:

(1) massima_distanza_link = minimo( 3 * (raggio_di_A + raggio_di_B) + distanza_minima, distanza_massima)

Dove:

(2) distanza_minima = 1,0 metri
(3) distanza_massima = 54,0 metri
(4) raggio_X = raggio della sfera contenente la primitiva X (Figura A)
(5) minimo (C, D) = al minimo tra C e D

Se la distanza misurata tra le due sfere è inferiore o uguale al ''massima_distanza_link'' allora le corrispondenti primitive possono essere linkate tra loro. In termini matematici:

(6) A_può_linkare_B = lunghezza (centro_di_A - centro_di_B) + raggio_di_A + raggio_di_B <= massima_distanza_link)

{|align = "right"
|[[Image:Primitive_diameter.png]]
|}

La '''bounding sphere''' è la più piccola sfera che racchiude tutto il ''bounding box'' locale di una primitiva.

Il '''local bounding box''' è il cubo centrato nella primitiva nel suo centro geometrico con il sistema di riferimento locale e di dimensioni uguali alla dimensione della primitiva.

Il centro geometrico della primitiva è il suo centro di simmetria locale calcolato prima delle operazioni di ''cut'', ''shear'', ''twist'', ''taper'', e di ''hollow''.

'''Nota''' che una bounding sphere di una primitiva non è necessariamente la sfera più stretta
possibile per la sua forma, a meno che la primitiva non sia una semplice box. La sfera di bounding
dipende esclusivamente dalla posizione della primitiva e dalle sue dimensioni, per cui qualsiasi
cut o hollow della primitiva la renderà notevolmente più piccola della sua bounding sphere, e non necessariamente vicina al suo centro. Inoltre, una primitiva twistata o shearata può avere gli spigoli che si estendono al di fuori della sua sfera di bounding. Poiché le regole di
Linkability dipendono solo dalla bounding sphere, che è in ultima analisi dipende solo dalla posizione della primitiva e dalle sue dimensioni, la linkabilità di due prims è indipendente dai cambiamenti della forma e di rotazione.

TODO - abbiamo bisogno di un nuovo figura_A che mostri ''Area'', invece''di diametro''.
Anche bisogno di nuove figure e _B _C per due correlabili prims e due correlabili multi-cfr oggetti.

=== Algoritmo per la linkabilità ===

Le norme che disciplinano il '''linkability di oggetti multi-prim''' è molto simile al caso di due sole primitive. Si applica la stessa formula (1) e (6), ma la bounding sphere di un oggetto multi-prim sono le più piccole sfere che contengono completamente tutte le sfere di bounding delle corrispondenti primitive che si vogliono linkare.

Quando si collegano '''tre o più oggetti''' l'algoritmo itera tra gli oggetti candidati fino a quando tutte le prim linkabili sono state trovate. La prim principale dell'oggetto viene testata con ogni candidato e la sfera di bounding diventa più grande ad ogni collegamento calcolato andato a buon fine. Quindi qualsiasi prim scollegata viene testata e fusa man mano ottenendo collezioni più grandi secondo le formule. L'oggetto principale è quindi ri-testato contro la modifica e il processo continua fino a quando tutti gli oggetti sono collegati, o non vengono trovati nuovi collegamenti validi.

=== Casi di fallimento ===

Se un '''insieme non linkabile''' è testato dall'algoritmo di linkabilità il sottoinsieme finale delle parti linkabili è determinato dall'ordine in cui i candidati sono stati elaborati.
La banale prova di questo si ha considerano primitiva root tra una griglia di tantissime altre primitive. L'algoritmo non riesce a linkare tutte queste primitive, ma se sono state testate prima tutte quelle a ovest alla fine il sottoinsieme delle prim linkate durante l'operazione di link potrebbe non
poter collegare parte delle primitive a est che non superano il vincolo della ''distanza_massima'' (3). Il risultato finale potrebbe essere diverso se le primitive a est vengono testate prima delle altre.

Se un '''insieme linkabile''' è testato dall'algoritmo di linkabilità il sottoinsieme finale delle parti linkabili '''non''' è determinato dall'ordine in cui i candidati sono stati sottoposti. Ciò significa che, se i sottoinsiemi linkabili del caso precedente vengono testati per la linkabilità qualunque permutaziona dei suoi elementi sarà sempre linkabile a prescindere dall'ordine in cui vengono linkati. La prova di ciò è lasciata come un esercizio per il lettore.

=== Esempi ===
==== Due prim molto piccole ====
raggio_di_A = ~ 0,01

raggio_di_B = ~ 0,01

distanza_minima = 1,0 metri

distanza_massima = 54,0 metri

massima_distanza_link = 1.06m

==== Uno prim grande con un piccolo prim ====
raggio_di_A = 5m

raggio_di_B = ~ 0,01

distanza_minima = 1,0 metri

distanza_massima = 54,0 metri

3 * (raggio_di_A + raggio_di_B) + distanza_massima = 15,03 metri

15.03m è inferiore a 54.0m

Così la massima_distanza_link = 15.03m

==== Due prim molto grandi ====
Il diametro di una sfera bounding è la radice quadrata di x ^ 2 + y ^ 2 + z ^ 2

Quindi, il diametro della sfera che contiene il cubo di dimensioni 10m x 10m x 10m è la radice quadrata di (100 + 100 + 100) = ~ 17.3m

E il diametro di un 10m x 1m x 1m è radice quadrata (100 + 1 + 1) = ~ 10.1m

(Il tipo di prim non importa per questo calcolo. Sono importanti soltanto le dimensioni.)

Prendiamo il caso di due prim di dimensione 10m x 10m x 10m.

raggio_di_A = 8.66m

raggio_di_B = 8.66m

distanza_minima = 1,0 metri

distanza_massima = 54,0 metri

3 * (raggio_di_A + raggio_di_B) + distanza_minima = 52.96m

52.96m è inferiore a 54m

Così la massima_distanza_link = 52.96m

Linkability Rules/it

2008-01-29T12:49:01Z

Vision Raymaker: translation of the Linkability Rules page

{{Multi-lang|Regole di Linkabilità}}
=== Quando le prim sono linkabili ===

Considerate due primitive, A e B. Per determinare se queste possono essere collegate o meno si calcola lo ''spazio'' dal bordo della sfera che racchiude l'oggetto al bordo opposto dall'altra sfera e confrontandolo con il valore di ''massima distanza di linkabilità'', che è una funzione dei raggi delle due sfere:

(1) massima_distanza_link = minimo( 3 * (raggio_di_A + raggio_di_B) + distanza_minima, distanza_massima)

Dove:

(2) distanza_minima = 1,0 metri
(3) distanza_massima = 54,0 metri
(4) raggio_X = raggio della sfera contenente la primitiva X (Figura A)
(5) minimo (C, D) = al minimo tra C e D

Se la distanza misurata tra le due sfere è inferiore o uguale al ''massima_distanza_link'' allora le corrispondenti primitive possono essere linkate tra loro. In termini matematici:

(6) A_può_linkare_B = lunghezza (centro_di_A - centro_di_B) + raggio_di_A + raggio_di_B <= massima_distanza_link)

{|align = "right"
|[[Image:Primitive_diameter.png]]
|}

La '''bounding sphere''' è la più piccola sfera che racchiude tutto il ''bounding box'' locale di una primitiva.

Il '''local bounding box''' è il cubo centrato nella primitiva nel suo centro geometrico con il sistema di riferimento locale e di dimensioni uguali alla dimensione della primitiva.

Il centro geometrico della primitiva è il suo centro di simmetria locale calcolato prima delle operazioni di ''cut'', ''shear'', ''twist'', ''taper'', e di ''hollow''.

'''Nota''' che una bounding sphere di una primitiva non è necessariamente la sfera più stretta
possibile per la sua forma, a meno che la primitiva non sia una semplice box. La sfera di bounding
dipende esclusivamente dalla posizione della primitiva e dalle sue dimensioni, per cui qualsiasi
cut o hollow della primitiva la renderà notevolmente più piccola della sua bounding sphere, e non necessariamente vicina al suo centro. Inoltre, una primitiva twistata o shearata può avere gli spigoli che si estendono al di fuori della sua sfera di bounding. Poiché le regole di
Linkability dipendono solo dalla bounding sphere, che è in ultima analisi dipende solo dalla posizione della primitiva e dalle sue dimensioni, la linkabilità di due prims è indipendente dai cambiamenti della forma e di rotazione.

TODO - abbiamo bisogno di un nuovo figura_A che mostri ''Area'', invece''di diametro''.
Anche bisogno di nuove figure e _B _C per due correlabili prims e due correlabili multi-cfr oggetti.

=== Algoritmo per la linkabilità ===

Le norme che disciplinano il '''linkability di oggetti multi-prim''' è molto simile al caso di due sole primitive. Si applica la stessa formula (1) e (6), ma la bounding sphere di un oggetto multi-prim sono le più piccole sfere che contengono completamente tutte le sfere di bounding delle corrispondenti primitive che si vogliono linkare.

Quando si collegano '''tre o più oggetti''' l'algoritmo itera tra gli oggetti candidati fino a quando tutte le prim linkabili sono state trovate. La prim principale dell'oggetto viene testata con ogni candidato e la sfera di bounding diventa più grande ad ogni collegamento calcolato andato a buon fine. Quindi qualsiasi prim scollegata viene testata e fusa man mano ottenendo collezioni più grandi secondo le formule. L'oggetto principale è quindi ri-testato contro la modifica e il processo continua fino a quando tutti gli oggetti sono collegati, o non vengono trovati nuovi collegamenti validi.

=== Casi di fallimento ===

Se un '''insieme non linkabile''' è testato dall'algoritmo di linkabilità il sottoinsieme finale delle parti linkabili è determinato dall'ordine in cui i candidati sono stati elaborati.
La banale prova di questo si ha considerano primitiva root tra una griglia di tantissime altre primitive. L'algoritmo non riesce a linkare tutte queste primitive, ma se sono state testate prima tutte quelle a ovest alla fine il sottoinsieme delle prim linkate durante l'operazione di link potrebbe non
poter collegare parte delle primitive a est che non superano il vincolo della ''distanza_massima'' (3). Il risultato finale potrebbe essere diverso se le primitive a est vengono testate prima delle altre.

Se un '''insieme linkabile''' è testato dall'algoritmo di linkabilità il sottoinsieme finale delle parti linkabili '''non''' è determinato dall'ordine in cui i candidati sono stati sottoposti. Ciò significa che, se i sottoinsiemi linkabili del caso precedente vengono testati per la linkabilità qualunque permutaziona dei suoi elementi sarà sempre linkabile a prescindere dall'ordine in cui vengono linkati. La prova di ciò è lasciata come un esercizio per il lettore.

=== Esempi ===
==== Due prim molto piccole ====
raggio_di_A = ~ 0,01

raggio_di_B = ~ 0,01

distanza_minima = 1,0 metri

distanza_massima = 54,0 metri

massima_distanza_link = 1.06m

==== Uno prim grande con un piccolo prim ====
raggio_di_A = 5m

raggio_di_B = ~ 0,01

distanza_minima = 1,0 metri

distanza_massima = 54,0 metri

3 * (raggio_di_A + raggio_di_B) + distanza_massima = 15,03 metri

15.03m è inferiore a 54.0m

Così la massima_distanza_link = 15.03m

==== Due prim molto grandi ====
Il diametro di una sfera bounding è la radice quadrata di x ^ 2 + y ^ 2 + z ^ 2

Quindi, il diametro della sfera che contiene il cubo di dimensioni 10m x 10m x 10m è la radice quadrata di (100 + 100 + 100) = ~ 17.3m

E il diametro di un 10m x 1m x 1m è radice quadrata (100 + 1 + 1) = ~ 10.1m

(Il tipo di prim non importa per questo calcolo. Sono importanti soltanto le dimensioni.)

Prendiamo il caso di due prim di dimensione 10m x 10m x 10m.

raggio_di_A = 8.66m

raggio_di_B = 8.66m

distanza_minima = 1,0 metri

distanza_massima = 54,0 metri

3 * (raggio_di_A + raggio_di_B) + distanza_minima = 52.96m

52.96m è inferiore a 54m

Così la massima_distanza_link = 52.96m

Havok4/it

2008-01-28T23:18:41Z

Vision Raymaker: format

{{Multi-lang}}
== Centro Informazioni sul nuovo motore fisico Havok4 in fase Beta Test ==
=== Introduzione ===
È in corso in Second Life la fase di beta test di Havok4. Questa pagina fornisce informazioni sul progetto, aiuteranno tutti ad assicurarsi che Havok4 sia stato testato per bene prima che sia attivato su tutta la rete Second Life.

Si prega di leggere la [[Havok4 Beta1 Release Notes/it|Havok4 Beta1 Release Notes]]

=== Cos'è Havok? ===
Il mondo virtuale Second Life è composto di molte parti che contribuiscono a tenerla in funzione. Uno di queste è il motore che simula la Fisica. Un motore fisico è un componente software specializzato che fa tutti i calcoli del "mondo reale" per capire cosa fare quando:
* Qualcosa o qualcuno viene spinto
* Qualcosa o qualcuno si scontra con qualcos'altro o qualcuno
* Qualcosa o qualcuno è in movimento e sta ruotando
* L'attrito rallenta il movimento di qualcosa o qualcuno

Havok è un motore fisico commerciale, e Second Life è stato costruito utilizzando Havok1. Con il quale ha funzionato per diversi anni.

=== Come faccio a partecipare alla fase di test per il motore fisico Havok4? ===
Puoi partecipare al Beta Test di Havok4 con pochi, semplici passaggi:
# Leggi "[[What's Changed With Havok4]]" per capire quali differenza dovrebbero esserci nel nuovo motore fisico, e quali sarebbe meglio non avere, testandole sulla griglia Havok4 Beta Test grid.
# Leggi "[[Linkability_Rules|New Cfr Linkability Regole]]" per capire come funziona il linking tra prim in Havok4 (è molto migliorato e dovrebbe essere molto più affidabile!)
# Fa un login nella Public Issue Tracker su "[https://jira.secondlife.com/Issue Tracker]" per vedere come è facile esporre i problemi riscontrati durante il beta test
# [http://secondlife.com/community/preview.php Scaricare il file per installare la Beta Havok4 Viewer qui]

=== Cosa testare? ===
Assicurarsi che tutti i tuoi oggetti funzionino nella grid Havok4, e prova tutto quello che pensi possa avere a che fare con la fisica... Ecco una breve lista, e un link a una pagina con un elenco più esauriente di idee relative alla fisica degli oggetti:
* Building, linking, unlinking
* i veicoli
* le armi
* gli "incantesimi"
* gli shields
* gli strumenti di costruzione
* il rezzing di grandi insiemi di prim
* prova a costruire oggetti semplici e complessi, prendendoli poi in inventario per rezzarli in posti diversi e orientandoti diversamente
* camminare, sedersi, volare, nuotare, e correre e tutti gli altri movimenti degli avatar funzionano come previsto?
* gli script funzionano come previsto?
* prova a creare nuovi script e modificarli
* i permessi funzionano correttamente?
* è possibile mandare in crash la sim facendo crashare il motore fisico? (Quelli di voi che sanno cosa significa ... "fatelo" e fate sapere come ...;)

Ci sono [[Havok4_Beta_Test_Ideas|molte cose che puoi fare per testare Havok4]] (una lista lunghissima di cose utili da provare. Sei libero di sceglierne una ma ancora meglio se provi cose nuove tue!

=== Come posso partecipare al test Havok4 ===
# Partecipa agli incontri "[[Regular Havok4 Office Hours In-World]]"
# Comunicaci tutto quello che scopri usando il Public Issue Tracker su "[https://jira.secondlife.com/ Issue Tracker]" 
Segnala i bug trovati usando PROJECT "Second Life Service - SVC" e quando inserisci il bug scegliere aFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" in questo modo troveremo subito le tue segnalazioni!

=== Come sarà testato e rilasciato Havok4 ===
Questo progetto sostituisce un componente fondamentale di Second Life, ed essere certi che "tutto ciò che spinge, si scontra o ha inerzia" funzioni a dovere è un compito arduo. abbiamo già fatto un sacco di test interno, e corretto centinaia di bug. Ci saranno impegnati in un approccio graduale sia per accorgerci di molti problemi il prima possibile, sia per ridurre il rischio di problemi causati da Havok4 quando verrà rilasciato.

 Fase 1 - Test interno sulla griglia non pubblica (FATTO!) 
Abbiamo già completato questa fase, e il personale interno ha svolto tutta una serie di lavori sui simulatori abilitati con Havok4. Le funzioni di base sono state controllate, come pure sono state controllati e risolti i noti crash dati dal motore fisico nel simulatore.

 Fase 2 - Public Beta Test su Beta Grid 
Ci aspettiamo che la fase del beta test pubblico di Havok4 sia molto attiva, con molti partecipanti. abbiamo preparato una test grid, per permettere vari test relativi alla fisica. Il regioni di test comprendono:
* le [[Orientation Islands|Orientation Island]]
* le [[Welcome areas|Welcome area]]
* [[Lusk]]
* Diverse [[sandboxes]]
* le [[Combat sandboxes]]
* i [[Vehicle testing simulators|simulatori per il test di veicoli]]

NOTA: Il Public Beta viewer sarà configurato per accedere alla beta grid, che sarà una copia di una porzione della main rete e del vostro account utente. Si può fare "tutto ciò che si desidera" su questa rete senza rischiare di danneggiare il tuo "vero account" sulla griglia principale.

 Fase 3 - Havok4 su un piccolo gruppo di regioni selezionate ( "SIAMO QUI!":) 
In questa fase verranno utilizzati le nuove funzionalità di HetGrid per la distribuzione dei simulatori Havok4 su un piccolo numero di regioni della griglia principale. Questa continua ad essere una fase di test, e, per questa fase, i partecipanti devono ricordare che sono sulla griglia principale, lavorando con il tuo vero inventario (quindi attenzione, non rezzate oggetti non copiabili / non trasferibili per provare le sim Havok4 se non si è al corrente dei potenziali rischi)

 Fase 4 - Rollout parziale sulla Main Grid (50-100 regioni) 
A questo punto, avremo risolto le questioni in sospeso riscontrate durante il beta testing e durante la Fase 3 "la piccola distribuzione, in un angolo della griglia principale", per distribuire Havok4 a un sottoinsieme della griglia principale.

Dopo la raccolta di commenti e feedback, se tutto sembra andare bene, ma noi andremo avanti...

 Fase 5 - Rollout totale di Havok4 sulla Main Grid (distribuzione alle resto della rete) 
Se tutto va a dovere a questo punto, distruibuiremo il motore Havok4 su tutto il resto della griglia principale, e avremo il nuovo motore Havok4 in funzione dappertutto in Second Life.

=== Una nota storica: Perché per far funzionare Havok c'è voluto tanto tempo? ===
Alcuni di voi che girano da lungo tempo si sa che abbiamo cominciato a parlare della sostituzione di Havok1 molto tempo fa, che sembrava di aver abbandonato questo progetto e, infine, che tutto fosse finito nel silenzio. Dopo diverse false partenze, abbiamo deciso che sarebbe stato meglio smettere di parlare di questo lavoro, o di rendere pubblici gli impegni, fino a quando non fossimo molto più vicini alla meta, e noi crediamo che finalmente siamo giunti a questo punto.

Per un po' di tempo abbiamo lavorato per sostituire Havok1 con Havok2. Dopo aver lavorato su questo progetto, ci siamo resi conto che era davvero necessario rielaborare le interfacce che integrano Havok in Second Life. Ci siamo resi conto che avevamo bisogno di definire un livello di astrazione - uno strato di codice che rendesse più facile poter modificare e migrare il motore fisico, ridurre lo sforzo e per consentire una maggiore flessibilità in futuro. a questo punto Havok4 è risultato la scelta più ragionevole piuttosto che basarsi sulla precedente release ... e per questo motivo abbiamo fissato come obiettivo l'adozione di Havok4. Questo progetto è stato significativamente più grande di quanto noi potessimo prevedere, ma la buona notizia è che ora siamo qui, pronti per il beta testing, e pronti a risolvere gli ultimi problemi prima di portare Havok4 sulle sim della griglia principale!

== Nuova esperienze che sono normali ==

=== Eiezione e separazione degli oggetti che si compenetrano ===
Uno dei maggiori miglioramenti rispetto al precedente motore Havok è che Havok4 supporta la separazione degli oggetti che si compenetrano. Per esempio un cubo, che è conficcato nel terreno e viene trasformato in oggetto fisico cercherà di uscirne, fino a quando non si sarà separato dalla terra e da quel momento si poggerà sul terreno.

Il motore precedente non gestiva gli oggetti compenetranti molto bene. andava in un loop per una elaborazione ricorsiva conosciuta come "Deep Think", una condizione in cui il motore cercava di stabilire dove spostare gli oggetti per evitare la sovrapposizione, causando un gran uso di risorse da parte del simulatore che appariva reagire lentamente per altre richieste.

Il nuovo motore separa gli oggetti che si sovrappongono in modo rapido e semplice. Gli oggetti sono trattati come molle compresse, in modo che maggiore è la interpenetrazione maggiore è la forza di espulsione sull'oggetto. Il risolutore dell'interpenetrazione tenta di obbedire ai vincoli di movimento per evitare di essere espulsi per esempio attraverso delle mura che racchiudono un oggetto, ma cercherà qualunque apertura o spazio disponibile dove dirigere l'oggetto.

Ecco un video di Google che mostra un esempio estremo di come il resolver della compenetrazione opera. Una pila di circa 200 dischi di grandi dimensioni spessi circa mezzo metro si sovrappongono in un pila di circa 10 metri di altezza, il tutto racchiuso all'interno di un grande tubo cavo. Quando questo oggetto viene rezzato sul terreno e trasformato in fisico, i dischi vengono espulsi verso l'alto e fuori verso la parte superiore del tubo, con alcuni dischi che raggiungono più di 300 metri di altezza per la forza repulsiva impressa dal risoluzione. Nessuna spinta viene applicata sui dischi via script o per push. Il movimento è dato esclusivamente dalla compenetrazione e dai dai calcoli del risolutore.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Lag del simulatore per enormi mucchi di oggetti impilati ===
Anche se si tratta di una nuovo e migliore motore fisico che non dovrebbe bloccarsi così frequentemente come il motore originale Havok-1, ci sono volte in cui anche il nuovo simulatore causa un grande lag quando sono presenti un gran numero oggetti fisici che si toccano fra loro.

Questo ritardo non è un bug, e non è come la vecchia condizione chiamata "Deep Think" di Havok-1, ma è dovuto ad una limitazione intrinseca nel modo in cui i motori fisici lavorano. Questo problema colpiva anche Havok-1, ma non era così evidente, dal momento che spesso grandi cataste crashavano il simulatore prima che questa condizione potesse diventare evidente.

Normalmente, quando oggetti fisici rallentano il simulatore oltre una certa soglia critica, per un periodo di tempo il motore mette in pausa le elaborazioni per la fisica dell'oggetto, in modo da risparmiare tempo CPU per altri oggetti attivi.

Per poter risolvere l'elaborazione degli oggetti fisici, l'oggetto deve essere in contatto con un oggetto di riferimento non in movimento. Una barra fisica si ferma dopo aver toccato il suolo.

Ma per più oggetti fisici impilati l'uno sull'altro, è difficile che raggiungano la stabilità, perché uno o più oggetti in movimento possono toccare quelli che si stanno stabilizzando. Questo leggero movimento rimette in moto anche quegli oggetti che si erano fermati, creando come un onda che attraversa la pila di oggetti. Quest'onda si trasmette costantemente attraverso la pila con il risultato che nessuno oggetto si assesti mai del tutto. Questa costante movimento e vibrazioni è simile al concetto fisico del moto browniano delle molecole di un gas.

L'esempio su Google Video del lag generato in un simulatore da 565 sfere fisiche poste in un contenitore:

http://video.google.com/videoplay?docid=7316931483709158462

Questo lag del motore non dipende dalle dimensioni degli oggetti coinvolti. Una raccolta di 500 oggetti molto piccoli impilati può causare lo stesso ritardo di 500 oggetti grandi accatastati.

=== Migliaia di oggetti che non si toccano non causano lag ===

Il simulatore di Havok-4 funziona a pieno ritmo, se non vi è abbastanza spazio tra oggetti fisici fa in modo da ridurre il più possibile le collisioni ravvicinate tra loro.

Ci possono essere migliaia di oggetti fisici in un simulatore creare alcun ritardo, a patto che gli oggetti si tocchino il meno possibile l'uno con l'altro.

Il seguente video su google presenta 2000-3400 cubetti fisici in una sandbox, senza ritardo:

http://video.google.com/videoplay?docid=-2779779276874540721

Havok4/it

2008-01-28T23:14:56Z

Vision Raymaker: format

{{Multi-lang}}
== Centro Informazioni sul nuovo motore fisico Havok4 in fase Beta Test ==
=== Introduzione ===
È in corso in Second Life la fase di beta test di Havok4. Questa pagina fornisce informazioni sul progetto, aiuteranno tutti ad assicurarsi che Havok4 sia stato testato per bene prima che sia attivato su tutta la rete Second Life.

Si prega di leggere la [[Havok4 Beta1 Release Notes/it|Havok4 Beta1 Release Notes]]

=== Cos'è Havok? ===
Il mondo virtuale Second Life è composto di molte parti che contribuiscono a tenerla in funzione. Uno di queste è il motore che simula la Fisica. Un motore fisico è un componente software specializzato che fa tutti i calcoli del "mondo reale" per capire cosa fare quando:
* Qualcosa o qualcuno viene spinto
* Qualcosa o qualcuno si scontra con qualcos'altro o qualcuno
* Qualcosa o qualcuno è in movimento e sta ruotando
* L'attrito rallenta il movimento di qualcosa o qualcuno

Havok è un motore fisico commerciale, e Second Life è stato costruito utilizzando Havok1. Con il quale ha funzionato per diversi anni.

=== Come faccio a partecipare alla fase di test per il motore fisico Havok4? ===
Puoi partecipare al Beta Test di Havok4 con pochi, semplici passaggi:
# Leggi "[[What's Changed With Havok4]]" per capire quali differenza dovrebbero esserci nel nuovo motore fisico, e quali sarebbe meglio non avere, testandole sulla griglia Havok4 Beta Test grid.
# Leggi "[[Linkability_Rules|New Cfr Linkability Regole]]" per capire come funziona il linking tra prim in Havok4 (è molto migliorato e dovrebbe essere molto più affidabile!)
# Fa un login nella Public Issue Tracker su "[https://jira.secondlife.com/Issue Tracker]" per vedere come è facile esporre i problemi riscontrati durante il beta test
# [http://secondlife.com/community/preview.php Scaricare il file per installare la Beta Havok4 Viewer qui]

=== Cosa testare? ===
assicurarsi che tutti i tuoi oggetti funzionino nella grid Havok4, e prova tutto quello che pensi possa avere a che fare con la fisica... Ecco una breve lista, e un link a una pagina con un elenco più esauriente di idee relative alla fisica degli oggetti:
* Building, linking, unlinking
* i veicoli
* le armi
* gli "incantesimi"
* gli shields
* gli strumenti di costruzione
* il rezzing di grandi insiemi di prim
* prova a costruire oggetti semplici e complessi, prendendoli poi in inventario per rezzarli in posti diversi e orientandoti diversamente
* camminare, sedersi, volare, nuotare, e correre e tutti gli altri movimenti degli avatar funzionano come previsto?
* gli script funzionano come previsto?
* prova a creare nuovi script e modificarli
* i permessi funzionano correttamente?
* è possibile mandare in crash la sim facendo crashare il motore fisico? (Quelli di voi che sanno cosa significa ... "fatelo" e fate sapere come ...;)

Ci sono [[Havok4_Beta_Test_Ideas|molte cose che puoi fare per testare Havok4]] (una lista lunghissima di cose utili da provare. Sei libero di sceglierne una ma ancora meglio se provi cose nuove tue!

=== Come posso partecipare al test Havok4 ===
# Partecipa agli incontri "[[Regular Havok4 Office Hours In-World]]"
# Comunicaci tutto quello che scopri usando il Public Issue Tracker su "[https://jira.secondlife.com/ Issue Tracker]" 
Segnala i bug trovati usando PROJECT "Second Life Service - SVC" e quando inserisci il bug scegliere aFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" in questo modo troveremo subito le tue segnalazioni!

=== Come sarà testato e rilasciato Havok4 ===
Questo progetto sostituisce un componente fondamentale di Second Life, ed essere certi che "tutto ciò che spinge, si scontra o ha inerzia" funzioni a dovere è un compito arduo. abbiamo già fatto un sacco di test interno, e corretto centinaia di bug. Ci saranno impegnati in un approccio graduale sia per accorgerci di molti problemi il prima possibile, sia per ridurre il rischio di problemi causati da Havok4 quando verrà rilasciato.

 Fase 1 - Test interno sulla griglia non pubblica (FaTTO!) 
abbiamo già completato questa fase, e il personale interno ha svolto tutta una serie di lavori sui simulatori abilitati con Havok4. Le funzioni di base sono state controllate, come pure sono state controllati e risolti i noti crash dati dal motore fisico nel simulatore.

 Fase 2 - Public Beta Test su Beta Grid 
Ci aspettiamo che la fase del beta test pubblico di Havok4 sia molto attiva, con molti partecipanti. abbiamo preparato una test grid, per permettere vari test relativi alla fisica. Il regioni di test comprendono:
* le [[Orientation Islands|Orientation Island]]
* le [[Welcome areas|Welcome area]]
* [[Lusk]]
* Diverse [[sandboxes]]
* le [[Combat sandboxes]]
* i [[Vehicle testing simulators|simulatori per il test di veicoli]]

NOTA: Il Public Beta viewer sarà configurato per accedere alla beta grid, che sarà una copia di una porzione della main rete e del vostro account utente. Si può fare "tutto ciò che si desidera" su questa rete senza rischiare di danneggiare il tuo "vero account" sulla griglia principale.

 Fase 3 - Havok4 su un piccolo gruppo di regioni selezionate ( "SIaMO QUI!":) 
In questa fase verranno utilizzati le nuove funzionalità di HetGrid per la distribuzione dei simulatori Havok4 su un piccolo numero di regioni della griglia principale. Questa continua ad essere una fase di test, e, per questa fase, i partecipanti devono ricordare che sono sulla griglia principale, lavorando con il tuo vero inventario (quindi attenzione, non rezzate oggetti non copiabili / non trasferibili per provare le sim Havok4 se non si è al corrente dei potenziali rischi)

 Fase 4 - Rollout parziale sulla Main Grid (50-100 regioni) 
a questo punto, avremo risolto le questioni in sospeso riscontrate durante il beta testing e durante la Fase 3 "la piccola distribuzione, in un angolo della griglia principale", per distribuire Havok4 a un sottoinsieme della griglia principale.

Dopo la raccolta di commenti e feedback, se tutto sembra andare bene, ma noi andremo avanti...

 Fase 5 - Rollout totale di Havok4 sulla Main Grid (distribuzione alle resto della rete) 
Se tutto va a dovere a questo punto, distruibuiremo il motore Havok4 su tutto il resto della griglia principale, e avremo il nuovo motore Havok4 in funzione dappertutto in Second Life.

=== Una nota storica: Perché per far funzionare Havok ci vuole tanto tempo? ===
alcuni di voi che girano da lungo tempo si sa che abbiamo cominciato a parlare della sostituzione di Havok1 molto tempo fa, che sembrava di aver abbandonato questo progetto e, infine, che tutto fosse finito nel silenzio. Dopo diverse false partenze, abbiamo deciso che sarebbe stato meglio smettere di parlare di questo lavoro, o di rendere pubblici gli impegni, fino a quando non fossimo molto più vicini alla meta, e noi crediamo che finalmente siamo giunti a questo punto.

Per un po' di tempo abbiamo lavorato per sostituire Havok1 con Havok2. Dopo aver lavorato su questo progetto, ci siamo resi conto che era davvero necessario rielaborare le interfacce che integrano Havok in Second Life. Ci siamo resi conto che avevamo bisogno di definire un livello di astrazione - uno strato di codice che rendesse più facile poter modificare e migrare il motore fisico, ridurre lo sforzo e per consentire una maggiore flessibilità in futuro. a questo punto Havok4 è risultato la scelta più ragionevole piuttosto che basarsi sulla precedente release ... e per questo motivo abbiamo fissato come obiettivo l'adozione di Havok4. Questo progetto è stato significativamente più grande di quanto noi potessimo prevedere, ma la buona notizia è che ora siamo qui, pronti per il beta testing, e pronti a risolvere gli ultimi problemi prima di portare Havok4 sulle sim della griglia principale!

== Nuova esperienze che sono normali ==

=== Eiezione e separazione degli oggetti che si compenetrano ===
Uno dei maggiori miglioramenti rispetto al precedente motore Havok è che Havok4 supporta la separazione degli oggetti che si compenetrano. Per esempio un cubo, che è conficcato nel terreno e viene trasformato in oggetto fisico cercherà di uscirne, fino a quando non si sarà separato dalla terra e da quel momento si poggerà sul terreno.

Il motore precedente non gestiva gli oggetti compenetranti molto bene. andava in un loop per una elaborazione ricorsiva conosciuta come "Deep Think", una condizione in cui il motore cercava di stabilire dove spostare gli oggetti per evitare la sovrapposizione, causando un gran uso di risorse da parte del simulatore che appariva reagire lentamente per altre richieste.

Il nuovo motore separa gli oggetti che si sovrappongono in modo rapido e semplice. Gli oggetti sono trattati come molle compresse, in modo che maggiore è la interpenetrazione maggiore è la forza di espulsione sull'oggetto. Il risolutore dell'interpenetrazione tenta di obbedire ai vincoli di movimento per evitare di essere espulsi per esempio attraverso delle mura che racchiudono un oggetto, ma cercherà qualunque apertura o spazio disponibile dove dirigere l'oggetto.

Ecco un video di Google che mostra un esempio estremo di come il resolver della compenetrazione opera. Una pila di circa 200 dischi di grandi dimensioni spessi circa mezzo metro si sovrappongono in un pila di circa 10 metri di altezza, il tutto racchiuso all'interno di un grande tubo cavo. Quando questo oggetto viene rezzato sul terreno e trasformato in fisico, i dischi vengono espulsi verso l'alto e fuori verso la parte superiore del tubo, con alcuni dischi che raggiungono più di 300 metri di altezza per la forza repulsiva impressa dal risoluzione. Nessuna spinta viene applicata sui dischi via script o per push. Il movimento è dato esclusivamente dalla compenetrazione e dai dai calcoli del risolutore.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Lag del simulatore per enormi mucchi di oggetti impilati ===
anche se si tratta di una nuovo e migliore motore fisico che non dovrebbe bloccarsi così frequentemente come il motore originale Havok-1, ci sono volte in cui anche il nuovo simulatore causa un grande lag quando sono presenti un gran numero oggetti fisici che si toccano fra loro.

Questo ritardo non è un bug, e non è come la vecchia condizione chiamata "Deep Think" di Havok-1, ma è dovuto ad una limitazione intrinseca nel modo in cui i motori fisici lavorano. Questo problema colpiva anche Havok-1, ma non era così evidente, dal momento che spesso grandi cataste crashavano il simulatore prima che questa condizione potesse diventare evidente.

Normalmente, quando oggetti fisici rallentano il simulatore oltre una certa soglia critica, per un periodo di tempo il motore mette in pausa le elaborazioni per la fisica dell'oggetto, in modo da risparmiare tempo CPU per altri oggetti attivi.

Per poter risolvere l'elaborazione degli oggetti fisici, l'oggetto deve essere in contatto con un oggetto di riferimento non in movimento. Una barra fisica si ferma dopo aver toccato il suolo.

Ma per più oggetti fisici impilati l'uno sull'altro, è difficile che raggiungano la stabilità, perché uno o più oggetti in movimento possono toccare quelli che si stanno stabilizzando. Questo leggero movimento rimette in moto anche quegli oggetti che si erano fermati, creando come un onda che attraversa la pila di oggetti. Quest'onda si trasmette costantemente attraverso la pila con il risultato che nessuno oggetto si assesti mai del tutto. Questa costante movimento e vibrazioni è simile al concetto fisico del moto browniano delle molecole di un gas.

L'esempio su Google Video del lag generato in un simulatore da 565 sfere fisiche poste in un contenitore:

http://video.google.com/videoplay?docid=7316931483709158462

Questo lag del motore non dipende dalle dimensioni degli oggetti coinvolti. Una raccolta di 500 oggetti molto piccoli impilati può causare lo stesso ritardo di 500 oggetti grandi accatastati.

=== Migliaia di oggetti che non si toccano non causano lag ===

Il simulatore di Havok-4 funziona a pieno ritmo, se non vi è abbastanza spazio tra oggetti fisici fa in modo da ridurre il più possibile le collisioni ravvicinate tra loro.

Ci possono essere migliaia di oggetti fisici in un simulatore creare alcun ritardo, a patto che gli oggetti si tocchino il meno possibile l'uno con l'altro.

Il seguente video su google presenta 2000-3400 cubetti fisici in una sandbox, senza ritardo:

http://video.google.com/videoplay?docid=-2779779276874540721

Havok4/it

2008-01-28T23:13:10Z

Vision Raymaker: multi lang template

{{Multi-lang}}
== Centro Informazioni sul nuovo motore fisico Havok4 in fase Beta Test ==
=== Introduzione ===
È in corso in Second Life la fase di beta test di Havok4. Questa pagina fornisce informazioni sul progetto, aiuteranno tutti ad assicurarsi che Havok4 sia stato testato per bene prima che sia attivato su tutta la rete Second Life.

Si prega di leggere la [[Havok4 Beta1 Release Notes/it|Havok4 Beta1 Release Notes]]

=== Cos'è Havok? ===
Il mondo virtuale Second Life è composto di molte parti che contribuiscono a tenerla in funzione. Uno di queste è il motore che simula la Fisica. Un motore fisico è un componente software specializzato che fa tutti i calcoli del "mondo reale" per capire cosa fare quando:
* Qualcosa o qualcuno viene spinto
* Qualcosa o qualcuno si scontra con qualcos'altro o qualcuno
* Qualcosa o qualcuno è in movimento e sta ruotando
* L'attrito rallenta il movimento di qualcosa o qualcuno

Havok è un motore fisico commerciale, e Second Life è stato costruito utilizzando Havok1. Con il quale ha funzionato per diversi anni.

=== Come faccio a partecipare alla fase di test per il motore fisico Havok4? ===
Puoi partecipare al Beta Test di Havok4 con pochi, semplici passaggi:
# Leggi "[[What's Changed Con Havok4]]" per capire quali differenza dovrebbero esserci nel nuovo motore fisico, e quali sarebbe meglio non avere, testandole sulla griglia Havok4 Beta Test grid.
# Leggi "[[Linkability_Rules | New Cfr Linkability Regole]]" per capire come funziona il linking tra prim in Havok4 (è molto migliorato e dovrebbe essere molto più affidabile!)
# Fa un login nella Public Issue Tracker su "[https://jira.secondlife.com/Issue Tracker]" per vedere come è facile esporre i problemi riscontrati durante il beta test
# [http://secondlife.com/community/preview.php Scaricare il file per installare la Beta Havok4 Viewer qui]

=== Cosa testare? ===
assicurarsi che tutti i tuoi oggetti funzionino nella grid Havok4, e prova tutto quello che pensi possa avere a che fare con la fisica... Ecco una breve lista, e un link a una pagina con un elenco più esauriente di idee relative alla fisica degli oggetti:
* Building, linking, unlinking
* i veicoli
* le armi
* gli "incantesimi"
* gli shields
* gli strumenti di costruzione
* il rezzing di grandi insiemi di prim
* prova a costruire oggetti semplici e complessi, prendendoli poi in inventario per rezzarli in posti diversi e orientandoti diversamente
* camminare, sedersi, volare, nuotare, e correre e tutti gli altri movimenti degli avatar funzionano come previsto?
* gli script funzionano come previsto?
* prova a creare nuovi script e modificarli
* i permessi funzionano correttamente?
* è possibile mandare in crash la sim facendo crashare il motore fisico? (Quelli di voi che sanno cosa significa ... "fatelo" e fate sapere come ...;)

Ci sono [[Havok4_Beta_Test_Ideas|molte cose che puoi fare per testare Havok4]] (una lista lunghissima di cose utili da provare. Sei libero di sceglierne una ma ancora meglio se provi cose nuove tue!

=== Come posso partecipare al test Havok4 ===
# Partecipa agli incontri "[[Regular Havok4 Office Hours In-World]]"
# Comunicaci tutto quello che scopri usando il Public Issue Tracker su "[https://jira.secondlife.com/ Issue Tracker]" 
Segnala i bug trovati usando PROJECT "Second Life Service - SVC" e quando inserisci il bug scegliere aFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" in questo modo troveremo subito le tue segnalazioni!

=== Come sarà testato e rilasciato Havok4 ===
Questo progetto sostituisce un componente fondamentale di Second Life, ed essere certi che "tutto ciò che spinge, si scontra o ha inerzia" funzioni a dovere è un compito arduo. abbiamo già fatto un sacco di test interno, e corretto centinaia di bug. Ci saranno impegnati in un approccio graduale sia per accorgerci di molti problemi il prima possibile, sia per ridurre il rischio di problemi causati da Havok4 quando verrà rilasciato.

 Fase 1 - Test interno sulla griglia non pubblica (FaTTO!) 
abbiamo già completato questa fase, e il personale interno ha svolto tutta una serie di lavori sui simulatori abilitati con Havok4. Le funzioni di base sono state controllate, come pure sono state controllati e risolti i noti crash dati dal motore fisico nel simulatore.

 Fase 2 - Public Beta Test su Beta Grid 
Ci aspettiamo che la fase del beta test pubblico di Havok4 sia molto attiva, con molti partecipanti. abbiamo preparato una test grid, per permettere vari test relativi alla fisica. Il regioni di test comprendono:
* le [[Orientation Islands|Orientation Island]]
* le [[Welcome areas|Welcome area]]
* [[Lusk]]
* Diverse [[sandboxes]]
* le [[Combat sandboxes]]
* i [[Vehicle testing simulators|simulatori per il test di veicoli]]

NOTa: Il Public Beta viewer sarà configurato per accedere alla beta grid, che sarà una copia di una porzione della main rete e del vostro account utente. Si può fare "tutto ciò che si desidera" su questa rete senza rischiare di danneggiare il tuo "vero account" sulla griglia principale.

 Fase 3 - Havok4 su un piccolo gruppo di regioni selezionate ( "SIaMO QUI!":) 
In questa fase verranno utilizzati le nuove funzionalità di HetGrid per la distribuzione dei simulatori Havok4 su un piccolo numero di regioni della griglia principale. Questa continua ad essere una fase di test, e, per questa fase, i partecipanti devono ricordare che sono sulla griglia principale, lavorando con il tuo vero inventario (quindi attenzione, non rezzate oggetti non copiabili / non trasferibili per provare le sim Havok4 se non si è al corrente dei potenziali rischi)

 Fase 4 - Rollout parziale sulla Main Grid (50-100 regioni) 
a questo punto, avremo risolto le questioni in sospeso riscontrate durante il beta testing e durante la Fase 3 "la piccola distribuzione, in un angolo della griglia principale", per distribuire Havok4 a un sottoinsieme della griglia principale.

Dopo la raccolta di commenti e feedback, se tutto sembra andare bene, ma noi andremo avanti...

 Fase 5 - Rollout totale di Havok4 sulla Main Grid (distribuzione alle resto della rete) 
Se tutto va a dovere a questo punto, distruibuiremo il motore Havok4 su tutto il resto della griglia principale, e avremo il nuovo motore Havok4 in funzione dappertutto in Second Life.

=== Una nota storica: Perché per far funzionare Havok ci vuole tanto tempo? ===
alcuni di voi che girano da lungo tempo si sa che abbiamo cominciato a parlare della sostituzione di Havok1 molto tempo fa, che sembrava di aver abbandonato questo progetto e, infine, che tutto fosse finito nel silenzio. Dopo diverse false partenze, abbiamo deciso che sarebbe stato meglio smettere di parlare di questo lavoro, o di rendere pubblici gli impegni, fino a quando non fossimo molto più vicini alla meta, e noi crediamo che finalmente siamo giunti a questo punto.

Per un po' di tempo abbiamo lavorato per sostituire Havok1 con Havok2. Dopo aver lavorato su questo progetto, ci siamo resi conto che era davvero necessario rielaborare le interfacce che integrano Havok in Second Life. Ci siamo resi conto che avevamo bisogno di definire un livello di astrazione - uno strato di codice che rendesse più facile poter modificare e migrare il motore fisico, ridurre lo sforzo e per consentire una maggiore flessibilità in futuro. a questo punto Havok4 è risultato la scelta più ragionevole piuttosto che basarsi sulla precedente release ... e per questo motivo abbiamo fissato come obiettivo l'adozione di Havok4. Questo progetto è stato significativamente più grande di quanto noi potessimo prevedere, ma la buona notizia è che ora siamo qui, pronti per il beta testing, e pronti a risolvere gli ultimi problemi prima di portare Havok4 sulle sim della griglia principale!

== Nuova esperienze che sono normali ==

=== Eiezione e separazione degli oggetti che si compenetrano ===
Uno dei maggiori miglioramenti rispetto al precedente motore Havok è che Havok4 supporta la separazione degli oggetti che si compenetrano. Per esempio un cubo, che è conficcato nel terreno e viene trasformato in oggetto fisico cercherà di uscirne, fino a quando non si sarà separato dalla terra e da quel momento si poggerà sul terreno.

Il motore precedente non gestiva gli oggetti compenetranti molto bene. andava in un loop per una elaborazione ricorsiva conosciuta come "Deep Think", una condizione in cui il motore cercava di stabilire dove spostare gli oggetti per evitare la sovrapposizione, causando un gran uso di risorse da parte del simulatore che appariva reagire lentamente per altre richieste.

Il nuovo motore separa gli oggetti che si sovrappongono in modo rapido e semplice. Gli oggetti sono trattati come molle compresse, in modo che maggiore è la interpenetrazione maggiore è la forza di espulsione sull'oggetto. Il risolutore dell'interpenetrazione tenta di obbedire ai vincoli di movimento per evitare di essere espulsi per esempio attraverso delle mura che racchiudono un oggetto, ma cercherà qualunque apertura o spazio disponibile dove dirigere l'oggetto.

Ecco un video di Google che mostra un esempio estremo di come il resolver della compenetrazione opera. Una pila di circa 200 dischi di grandi dimensioni spessi circa mezzo metro si sovrappongono in un pila di circa 10 metri di altezza, il tutto racchiuso all'interno di un grande tubo cavo. Quando questo oggetto viene rezzato sul terreno e trasformato in fisico, i dischi vengono espulsi verso l'alto e fuori verso la parte superiore del tubo, con alcuni dischi che raggiungono più di 300 metri di altezza per la forza repulsiva impressa dal risoluzione. Nessuna spinta viene applicata sui dischi via script o per push. Il movimento è dato esclusivamente dalla compenetrazione e dai dai calcoli del risolutore.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Lag del simulatore per enormi mucchi di oggetti impilati ===
anche se si tratta di una nuovo e migliore motore fisico che non dovrebbe bloccarsi così frequentemente come il motore originale Havok-1, ci sono volte in cui anche il nuovo simulatore causa un grande lag quando sono presenti un gran numero oggetti fisici che si toccano fra loro.

Questo ritardo non è un bug, e non è come la vecchia condizione chiamata "Deep Think" di Havok-1, ma è dovuto ad una limitazione intrinseca nel modo in cui i motori fisici lavorano. Questo problema colpiva anche Havok-1, ma non era così evidente, dal momento che spesso grandi cataste crashavano il simulatore prima che questa condizione potesse diventare evidente.

Normalmente, quando oggetti fisici rallentano il simulatore oltre una certa soglia critica, per un periodo di tempo il motore mette in pausa le elaborazioni per la fisica dell'oggetto, in modo da risparmiare tempo CPU per altri oggetti attivi.

Per poter risolvere l'elaborazione degli oggetti fisici, l'oggetto deve essere in contatto con un oggetto di riferimento non in movimento. Una barra fisica si ferma dopo aver toccato il suolo.

Ma per più oggetti fisici impilati l'uno sull'altro, è difficile che raggiungano la stabilità, perché uno o più oggetti in movimento possono toccare quelli che si stanno stabilizzando. Questo leggero movimento rimette in moto anche quegli oggetti che si erano fermati, creando come un onda che attraversa la pila di oggetti. Quest'onda si trasmette costantemente attraverso la pila con il risultato che nessuno oggetto si assesti mai del tutto. Questa costante movimento e vibrazioni è simile al concetto fisico del moto browniano delle molecole di un gas.

L'esempio su Google Video del lag generato in un simulatore da 565 sfere fisiche poste in un contenitore:

http://video.google.com/videoplay?docid=7316931483709158462

Questo lag del motore non dipende dalle dimensioni degli oggetti coinvolti. Una raccolta di 500 oggetti molto piccoli impilati può causare lo stesso ritardo di 500 oggetti grandi accatastati.

=== Migliaia di oggetti che non si toccano non causano lag ===

Il simulatore di Havok-4 funziona a pieno ritmo, se non vi è abbastanza spazio tra oggetti fisici fa in modo da ridurre il più possibile le collisioni ravvicinate tra loro.

Ci possono essere migliaia di oggetti fisici in un simulatore creare alcun ritardo, a patto che gli oggetti si tocchino il meno possibile l'uno con l'altro.

Il seguente video su google presenta 2000-3400 cubetti fisici in una sandbox, senza ritardo:

http://video.google.com/videoplay?docid=-2779779276874540721

Havok4/it

2008-01-28T23:12:25Z

Vision Raymaker: multi lang template

{{{Multi-lang}}}
== Centro Informazioni sul nuovo motore fisico Havok4 in fase Beta Test ==
=== Introduzione ===
È in corso in Second Life la fase di beta test di Havok4. Questa pagina fornisce informazioni sul progetto, aiuteranno tutti ad assicurarsi che Havok4 sia stato testato per bene prima che sia attivato su tutta la rete Second Life.

Si prega di leggere la [[Havok4 Beta1 Release Notes/it|Havok4 Beta1 Release Notes]]

=== Cos'è Havok? ===
Il mondo virtuale Second Life è composto di molte parti che contribuiscono a tenerla in funzione. Uno di queste è il motore che simula la Fisica. Un motore fisico è un componente software specializzato che fa tutti i calcoli del "mondo reale" per capire cosa fare quando:
* Qualcosa o qualcuno viene spinto
* Qualcosa o qualcuno si scontra con qualcos'altro o qualcuno
* Qualcosa o qualcuno è in movimento e sta ruotando
* L'attrito rallenta il movimento di qualcosa o qualcuno

Havok è un motore fisico commerciale, e Second Life è stato costruito utilizzando Havok1. Con il quale ha funzionato per diversi anni.

=== Come faccio a partecipare alla fase di test per il motore fisico Havok4? ===
Puoi partecipare al Beta Test di Havok4 con pochi, semplici passaggi:
# Leggi "[[What's Changed Con Havok4]]" per capire quali differenza dovrebbero esserci nel nuovo motore fisico, e quali sarebbe meglio non avere, testandole sulla griglia Havok4 Beta Test grid.
# Leggi "[[Linkability_Rules | New Cfr Linkability Regole]]" per capire come funziona il linking tra prim in Havok4 (è molto migliorato e dovrebbe essere molto più affidabile!)
# Fa un login nella Public Issue Tracker su "[https://jira.secondlife.com/Issue Tracker]" per vedere come è facile esporre i problemi riscontrati durante il beta test
# [http://secondlife.com/community/preview.php Scaricare il file per installare la Beta Havok4 Viewer qui]

=== Cosa testare? ===
assicurarsi che tutti i tuoi oggetti funzionino nella grid Havok4, e prova tutto quello che pensi possa avere a che fare con la fisica... Ecco una breve lista, e un link a una pagina con un elenco più esauriente di idee relative alla fisica degli oggetti:
* Building, linking, unlinking
* i veicoli
* le armi
* gli "incantesimi"
* gli shields
* gli strumenti di costruzione
* il rezzing di grandi insiemi di prim
* prova a costruire oggetti semplici e complessi, prendendoli poi in inventario per rezzarli in posti diversi e orientandoti diversamente
* camminare, sedersi, volare, nuotare, e correre e tutti gli altri movimenti degli avatar funzionano come previsto?
* gli script funzionano come previsto?
* prova a creare nuovi script e modificarli
* i permessi funzionano correttamente?
* è possibile mandare in crash la sim facendo crashare il motore fisico? (Quelli di voi che sanno cosa significa ... "fatelo" e fate sapere come ...;)

Ci sono [[Havok4_Beta_Test_Ideas|molte cose che puoi fare per testare Havok4]] (una lista lunghissima di cose utili da provare. Sei libero di sceglierne una ma ancora meglio se provi cose nuove tue!

=== Come posso partecipare al test Havok4 ===
# Partecipa agli incontri "[[Regular Havok4 Office Hours In-World]]"
# Comunicaci tutto quello che scopri usando il Public Issue Tracker su "[https://jira.secondlife.com/ Issue Tracker]" 
Segnala i bug trovati usando PROJECT "Second Life Service - SVC" e quando inserisci il bug scegliere aFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" in questo modo troveremo subito le tue segnalazioni!

=== Come sarà testato e rilasciato Havok4 ===
Questo progetto sostituisce un componente fondamentale di Second Life, ed essere certi che "tutto ciò che spinge, si scontra o ha inerzia" funzioni a dovere è un compito arduo. abbiamo già fatto un sacco di test interno, e corretto centinaia di bug. Ci saranno impegnati in un approccio graduale sia per accorgerci di molti problemi il prima possibile, sia per ridurre il rischio di problemi causati da Havok4 quando verrà rilasciato.

 Fase 1 - Test interno sulla griglia non pubblica (FaTTO!) 
abbiamo già completato questa fase, e il personale interno ha svolto tutta una serie di lavori sui simulatori abilitati con Havok4. Le funzioni di base sono state controllate, come pure sono state controllati e risolti i noti crash dati dal motore fisico nel simulatore.

 Fase 2 - Public Beta Test su Beta Grid 
Ci aspettiamo che la fase del beta test pubblico di Havok4 sia molto attiva, con molti partecipanti. abbiamo preparato una test grid, per permettere vari test relativi alla fisica. Il regioni di test comprendono:
* le [[Orientation Islands|Orientation Island]]
* le [[Welcome areas|Welcome area]]
* [[Lusk]]
* Diverse [[sandboxes]]
* le [[Combat sandboxes]]
* i [[Vehicle testing simulators|simulatori per il test di veicoli]]

NOTa: Il Public Beta viewer sarà configurato per accedere alla beta grid, che sarà una copia di una porzione della main rete e del vostro account utente. Si può fare "tutto ciò che si desidera" su questa rete senza rischiare di danneggiare il tuo "vero account" sulla griglia principale.

 Fase 3 - Havok4 su un piccolo gruppo di regioni selezionate ( "SIaMO QUI!":) 
In questa fase verranno utilizzati le nuove funzionalità di HetGrid per la distribuzione dei simulatori Havok4 su un piccolo numero di regioni della griglia principale. Questa continua ad essere una fase di test, e, per questa fase, i partecipanti devono ricordare che sono sulla griglia principale, lavorando con il tuo vero inventario (quindi attenzione, non rezzate oggetti non copiabili / non trasferibili per provare le sim Havok4 se non si è al corrente dei potenziali rischi)

 Fase 4 - Rollout parziale sulla Main Grid (50-100 regioni) 
a questo punto, avremo risolto le questioni in sospeso riscontrate durante il beta testing e durante la Fase 3 "la piccola distribuzione, in un angolo della griglia principale", per distribuire Havok4 a un sottoinsieme della griglia principale.

Dopo la raccolta di commenti e feedback, se tutto sembra andare bene, ma noi andremo avanti...

 Fase 5 - Rollout totale di Havok4 sulla Main Grid (distribuzione alle resto della rete) 
Se tutto va a dovere a questo punto, distruibuiremo il motore Havok4 su tutto il resto della griglia principale, e avremo il nuovo motore Havok4 in funzione dappertutto in Second Life.

=== Una nota storica: Perché per far funzionare Havok ci vuole tanto tempo? ===
alcuni di voi che girano da lungo tempo si sa che abbiamo cominciato a parlare della sostituzione di Havok1 molto tempo fa, che sembrava di aver abbandonato questo progetto e, infine, che tutto fosse finito nel silenzio. Dopo diverse false partenze, abbiamo deciso che sarebbe stato meglio smettere di parlare di questo lavoro, o di rendere pubblici gli impegni, fino a quando non fossimo molto più vicini alla meta, e noi crediamo che finalmente siamo giunti a questo punto.

Per un po' di tempo abbiamo lavorato per sostituire Havok1 con Havok2. Dopo aver lavorato su questo progetto, ci siamo resi conto che era davvero necessario rielaborare le interfacce che integrano Havok in Second Life. Ci siamo resi conto che avevamo bisogno di definire un livello di astrazione - uno strato di codice che rendesse più facile poter modificare e migrare il motore fisico, ridurre lo sforzo e per consentire una maggiore flessibilità in futuro. a questo punto Havok4 è risultato la scelta più ragionevole piuttosto che basarsi sulla precedente release ... e per questo motivo abbiamo fissato come obiettivo l'adozione di Havok4. Questo progetto è stato significativamente più grande di quanto noi potessimo prevedere, ma la buona notizia è che ora siamo qui, pronti per il beta testing, e pronti a risolvere gli ultimi problemi prima di portare Havok4 sulle sim della griglia principale!

== Nuova esperienze che sono normali ==

=== Eiezione e separazione degli oggetti che si compenetrano ===
Uno dei maggiori miglioramenti rispetto al precedente motore Havok è che Havok4 supporta la separazione degli oggetti che si compenetrano. Per esempio un cubo, che è conficcato nel terreno e viene trasformato in oggetto fisico cercherà di uscirne, fino a quando non si sarà separato dalla terra e da quel momento si poggerà sul terreno.

Il motore precedente non gestiva gli oggetti compenetranti molto bene. andava in un loop per una elaborazione ricorsiva conosciuta come "Deep Think", una condizione in cui il motore cercava di stabilire dove spostare gli oggetti per evitare la sovrapposizione, causando un gran uso di risorse da parte del simulatore che appariva reagire lentamente per altre richieste.

Il nuovo motore separa gli oggetti che si sovrappongono in modo rapido e semplice. Gli oggetti sono trattati come molle compresse, in modo che maggiore è la interpenetrazione maggiore è la forza di espulsione sull'oggetto. Il risolutore dell'interpenetrazione tenta di obbedire ai vincoli di movimento per evitare di essere espulsi per esempio attraverso delle mura che racchiudono un oggetto, ma cercherà qualunque apertura o spazio disponibile dove dirigere l'oggetto.

Ecco un video di Google che mostra un esempio estremo di come il resolver della compenetrazione opera. Una pila di circa 200 dischi di grandi dimensioni spessi circa mezzo metro si sovrappongono in un pila di circa 10 metri di altezza, il tutto racchiuso all'interno di un grande tubo cavo. Quando questo oggetto viene rezzato sul terreno e trasformato in fisico, i dischi vengono espulsi verso l'alto e fuori verso la parte superiore del tubo, con alcuni dischi che raggiungono più di 300 metri di altezza per la forza repulsiva impressa dal risoluzione. Nessuna spinta viene applicata sui dischi via script o per push. Il movimento è dato esclusivamente dalla compenetrazione e dai dai calcoli del risolutore.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Lag del simulatore per enormi mucchi di oggetti impilati ===
anche se si tratta di una nuovo e migliore motore fisico che non dovrebbe bloccarsi così frequentemente come il motore originale Havok-1, ci sono volte in cui anche il nuovo simulatore causa un grande lag quando sono presenti un gran numero oggetti fisici che si toccano fra loro.

Questo ritardo non è un bug, e non è come la vecchia condizione chiamata "Deep Think" di Havok-1, ma è dovuto ad una limitazione intrinseca nel modo in cui i motori fisici lavorano. Questo problema colpiva anche Havok-1, ma non era così evidente, dal momento che spesso grandi cataste crashavano il simulatore prima che questa condizione potesse diventare evidente.

Normalmente, quando oggetti fisici rallentano il simulatore oltre una certa soglia critica, per un periodo di tempo il motore mette in pausa le elaborazioni per la fisica dell'oggetto, in modo da risparmiare tempo CPU per altri oggetti attivi.

Per poter risolvere l'elaborazione degli oggetti fisici, l'oggetto deve essere in contatto con un oggetto di riferimento non in movimento. Una barra fisica si ferma dopo aver toccato il suolo.

Ma per più oggetti fisici impilati l'uno sull'altro, è difficile che raggiungano la stabilità, perché uno o più oggetti in movimento possono toccare quelli che si stanno stabilizzando. Questo leggero movimento rimette in moto anche quegli oggetti che si erano fermati, creando come un onda che attraversa la pila di oggetti. Quest'onda si trasmette costantemente attraverso la pila con il risultato che nessuno oggetto si assesti mai del tutto. Questa costante movimento e vibrazioni è simile al concetto fisico del moto browniano delle molecole di un gas.

L'esempio su Google Video del lag generato in un simulatore da 565 sfere fisiche poste in un contenitore:

http://video.google.com/videoplay?docid=7316931483709158462

Questo lag del motore non dipende dalle dimensioni degli oggetti coinvolti. Una raccolta di 500 oggetti molto piccoli impilati può causare lo stesso ritardo di 500 oggetti grandi accatastati.

=== Migliaia di oggetti che non si toccano non causano lag ===

Il simulatore di Havok-4 funziona a pieno ritmo, se non vi è abbastanza spazio tra oggetti fisici fa in modo da ridurre il più possibile le collisioni ravvicinate tra loro.

Ci possono essere migliaia di oggetti fisici in un simulatore creare alcun ritardo, a patto che gli oggetti si tocchino il meno possibile l'uno con l'altro.

Il seguente video su google presenta 2000-3400 cubetti fisici in una sandbox, senza ritardo:

http://video.google.com/videoplay?docid=-2779779276874540721

Havok4/it

2008-01-28T23:07:00Z

Vision Raymaker: italian translation of Havok 4 Beta Test Home page

== Centro Informazioni sul nuovo motore fisico Havok4 in fase Beta Test ==
=== Introduzione ===
È in corso in Second Life la fase di beta test di Havok4. Questa pagina fornisce informazioni sul progetto, aiuteranno tutti ad assicurarsi che Havok4 sia stato testato per bene prima che sia attivato su tutta la rete Second Life.

Si prega di leggere la [[Havok4 Beta1 Release Notes/it|Havok4 Beta1 Release Notes]]

=== Cos'è Havok? ===
Il mondo virtuale Second Life è composto di molte parti che contribuiscono a tenerla in funzione. Uno di queste è il motore che simula la Fisica. Un motore fisico è un componente software specializzato che fa tutti i calcoli del "mondo reale" per capire cosa fare quando:
* Qualcosa o qualcuno viene spinto
* Qualcosa o qualcuno si scontra con qualcos'altro o qualcuno
* Qualcosa o qualcuno è in movimento e sta ruotando
* L'attrito rallenta il movimento di qualcosa o qualcuno

Havok è un motore fisico commerciale, e Second Life è stato costruito utilizzando Havok1. Con il quale ha funzionato per diversi anni.

=== Come faccio a partecipare alla fase di test per il motore fisico Havok4? ===
Puoi partecipare al Beta Test di Havok4 con pochi, semplici passaggi:
# Leggi "[[What's Changed Con Havok4]]" per capire quali differenza dovrebbero esserci nel nuovo motore fisico, e quali sarebbe meglio non avere, testandole sulla griglia Havok4 Beta Test grid.
# Leggi "[[Linkability_Rules | New Cfr Linkability Regole]]" per capire come funziona il linking tra prim in Havok4 (è molto migliorato e dovrebbe essere molto più affidabile!)
# Fa un login nella Public Issue Tracker su "[https://jira.secondlife.com/Issue Tracker]" per vedere come è facile esporre i problemi riscontrati durante il beta test
# [http://secondlife.com/community/preview.php Scaricare il file per installare la Beta Havok4 Viewer qui]

=== Cosa testare? ===
assicurarsi che tutti i tuoi oggetti funzionino nella grid Havok4, e prova tutto quello che pensi possa avere a che fare con la fisica... Ecco una breve lista, e un link a una pagina con un elenco più esauriente di idee relative alla fisica degli oggetti:
* Building, linking, unlinking
* i veicoli
* le armi
* gli "incantesimi"
* gli shields
* gli strumenti di costruzione
* il rezzing di grandi insiemi di prim
* prova a costruire oggetti semplici e complessi, prendendoli poi in inventario per rezzarli in posti diversi e orientandoti diversamente
* camminare, sedersi, volare, nuotare, e correre e tutti gli altri movimenti degli avatar funzionano come previsto?
* gli script funzionano come previsto?
* prova a creare nuovi script e modificarli
* i permessi funzionano correttamente?
* è possibile mandare in crash la sim facendo crashare il motore fisico? (Quelli di voi che sanno cosa significa ... "fatelo" e fate sapere come ...;)

Ci sono [[Havok4_Beta_Test_Ideas|molte cose che puoi fare per testare Havok4]] (una lista lunghissima di cose utili da provare. Sei libero di sceglierne una ma ancora meglio se provi cose nuove tue!

=== Come posso partecipare al test Havok4 ===
# Partecipa agli incontri "[[Regular Havok4 Office Hours In-World]]"
# Comunicaci tutto quello che scopri usando il Public Issue Tracker su "[https://jira.secondlife.com/ Issue Tracker]" 
Segnala i bug trovati usando PROJECT "Second Life Service - SVC" e quando inserisci il bug scegliere aFFECTS VERSIONS "Havok4 Beta" and COMPONENTS "Physics" in questo modo troveremo subito le tue segnalazioni!

=== Come sarà testato e rilasciato Havok4 ===
Questo progetto sostituisce un componente fondamentale di Second Life, ed essere certi che "tutto ciò che spinge, si scontra o ha inerzia" funzioni a dovere è un compito arduo. abbiamo già fatto un sacco di test interno, e corretto centinaia di bug. Ci saranno impegnati in un approccio graduale sia per accorgerci di molti problemi il prima possibile, sia per ridurre il rischio di problemi causati da Havok4 quando verrà rilasciato.

 Fase 1 - Test interno sulla griglia non pubblica (FaTTO!) 
abbiamo già completato questa fase, e il personale interno ha svolto tutta una serie di lavori sui simulatori abilitati con Havok4. Le funzioni di base sono state controllate, come pure sono state controllati e risolti i noti crash dati dal motore fisico nel simulatore.

 Fase 2 - Public Beta Test su Beta Grid 
Ci aspettiamo che la fase del beta test pubblico di Havok4 sia molto attiva, con molti partecipanti. abbiamo preparato una test grid, per permettere vari test relativi alla fisica. Il regioni di test comprendono:
* le [[Orientation Islands|Orientation Island]]
* le [[Welcome areas|Welcome area]]
* [[Lusk]]
* Diverse [[sandboxes]]
* le [[Combat sandboxes]]
* i [[Vehicle testing simulators|simulatori per il test di veicoli]]

NOTa: Il Public Beta viewer sarà configurato per accedere alla beta grid, che sarà una copia di una porzione della main rete e del vostro account utente. Si può fare "tutto ciò che si desidera" su questa rete senza rischiare di danneggiare il tuo "vero account" sulla griglia principale.

 Fase 3 - Havok4 su un piccolo gruppo di regioni selezionate ( "SIaMO QUI!":) 
In questa fase verranno utilizzati le nuove funzionalità di HetGrid per la distribuzione dei simulatori Havok4 su un piccolo numero di regioni della griglia principale. Questa continua ad essere una fase di test, e, per questa fase, i partecipanti devono ricordare che sono sulla griglia principale, lavorando con il tuo vero inventario (quindi attenzione, non rezzate oggetti non copiabili / non trasferibili per provare le sim Havok4 se non si è al corrente dei potenziali rischi)

 Fase 4 - Rollout parziale sulla Main Grid (50-100 regioni) 
a questo punto, avremo risolto le questioni in sospeso riscontrate durante il beta testing e durante la Fase 3 "la piccola distribuzione, in un angolo della griglia principale", per distribuire Havok4 a un sottoinsieme della griglia principale.

Dopo la raccolta di commenti e feedback, se tutto sembra andare bene, ma noi andremo avanti...

 Fase 5 - Rollout totale di Havok4 sulla Main Grid (distribuzione alle resto della rete) 
Se tutto va a dovere a questo punto, distruibuiremo il motore Havok4 su tutto il resto della griglia principale, e avremo il nuovo motore Havok4 in funzione dappertutto in Second Life.

=== Una nota storica: Perché per far funzionare Havok ci vuole tanto tempo? ===
alcuni di voi che girano da lungo tempo si sa che abbiamo cominciato a parlare della sostituzione di Havok1 molto tempo fa, che sembrava di aver abbandonato questo progetto e, infine, che tutto fosse finito nel silenzio. Dopo diverse false partenze, abbiamo deciso che sarebbe stato meglio smettere di parlare di questo lavoro, o di rendere pubblici gli impegni, fino a quando non fossimo molto più vicini alla meta, e noi crediamo che finalmente siamo giunti a questo punto.

Per un po' di tempo abbiamo lavorato per sostituire Havok1 con Havok2. Dopo aver lavorato su questo progetto, ci siamo resi conto che era davvero necessario rielaborare le interfacce che integrano Havok in Second Life. Ci siamo resi conto che avevamo bisogno di definire un livello di astrazione - uno strato di codice che rendesse più facile poter modificare e migrare il motore fisico, ridurre lo sforzo e per consentire una maggiore flessibilità in futuro. a questo punto Havok4 è risultato la scelta più ragionevole piuttosto che basarsi sulla precedente release ... e per questo motivo abbiamo fissato come obiettivo l'adozione di Havok4. Questo progetto è stato significativamente più grande di quanto noi potessimo prevedere, ma la buona notizia è che ora siamo qui, pronti per il beta testing, e pronti a risolvere gli ultimi problemi prima di portare Havok4 sulle sim della griglia principale!

== Nuova esperienze che sono normali ==

=== Eiezione e separazione degli oggetti che si compenetrano ===
Uno dei maggiori miglioramenti rispetto al precedente motore Havok è che Havok4 supporta la separazione degli oggetti che si compenetrano. Per esempio un cubo, che è conficcato nel terreno e viene trasformato in oggetto fisico cercherà di uscirne, fino a quando non si sarà separato dalla terra e da quel momento si poggerà sul terreno.

Il motore precedente non gestiva gli oggetti compenetranti molto bene. andava in un loop per una elaborazione ricorsiva conosciuta come "Deep Think", una condizione in cui il motore cercava di stabilire dove spostare gli oggetti per evitare la sovrapposizione, causando un gran uso di risorse da parte del simulatore che appariva reagire lentamente per altre richieste.

Il nuovo motore separa gli oggetti che si sovrappongono in modo rapido e semplice. Gli oggetti sono trattati come molle compresse, in modo che maggiore è la interpenetrazione maggiore è la forza di espulsione sull'oggetto. Il risolutore dell'interpenetrazione tenta di obbedire ai vincoli di movimento per evitare di essere espulsi per esempio attraverso delle mura che racchiudono un oggetto, ma cercherà qualunque apertura o spazio disponibile dove dirigere l'oggetto.

Ecco un video di Google che mostra un esempio estremo di come il resolver della compenetrazione opera. Una pila di circa 200 dischi di grandi dimensioni spessi circa mezzo metro si sovrappongono in un pila di circa 10 metri di altezza, il tutto racchiuso all'interno di un grande tubo cavo. Quando questo oggetto viene rezzato sul terreno e trasformato in fisico, i dischi vengono espulsi verso l'alto e fuori verso la parte superiore del tubo, con alcuni dischi che raggiungono più di 300 metri di altezza per la forza repulsiva impressa dal risoluzione. Nessuna spinta viene applicata sui dischi via script o per push. Il movimento è dato esclusivamente dalla compenetrazione e dai dai calcoli del risolutore.

Google Video: '''Second Life Havok 4 - Exploding Can of Disks'''

http://video.google.com/videoplay?docid=-2623683631644524154

=== Lag del simulatore per enormi mucchi di oggetti impilati ===
anche se si tratta di una nuovo e migliore motore fisico che non dovrebbe bloccarsi così frequentemente come il motore originale Havok-1, ci sono volte in cui anche il nuovo simulatore causa un grande lag quando sono presenti un gran numero oggetti fisici che si toccano fra loro.

Questo ritardo non è un bug, e non è come la vecchia condizione chiamata "Deep Think" di Havok-1, ma è dovuto ad una limitazione intrinseca nel modo in cui i motori fisici lavorano. Questo problema colpiva anche Havok-1, ma non era così evidente, dal momento che spesso grandi cataste crashavano il simulatore prima che questa condizione potesse diventare evidente.

Normalmente, quando oggetti fisici rallentano il simulatore oltre una certa soglia critica, per un periodo di tempo il motore mette in pausa le elaborazioni per la fisica dell'oggetto, in modo da risparmiare tempo CPU per altri oggetti attivi.

Per poter risolvere l'elaborazione degli oggetti fisici, l'oggetto deve essere in contatto con un oggetto di riferimento non in movimento. Una barra fisica si ferma dopo aver toccato il suolo.

Ma per più oggetti fisici impilati l'uno sull'altro, è difficile che raggiungano la stabilità, perché uno o più oggetti in movimento possono toccare quelli che si stanno stabilizzando. Questo leggero movimento rimette in moto anche quegli oggetti che si erano fermati, creando come un onda che attraversa la pila di oggetti. Quest'onda si trasmette costantemente attraverso la pila con il risultato che nessuno oggetto si assesti mai del tutto. Questa costante movimento e vibrazioni è simile al concetto fisico del moto browniano delle molecole di un gas.

L'esempio su Google Video del lag generato in un simulatore da 565 sfere fisiche poste in un contenutore:

http://video.google.com/videoplay?docid=7316931483709158462

Questo lag del motore non dipende dalle dimensioni degli oggetti coinvolti. Una raccolta di 500 oggetti molto piccoli impilati può causare lo stesso ritardo di 500 oggetti grandi accatastati.

=== Migliaia di oggetti che non si toccano non causano lag ===

Il simulatore di Havok-4 funziona a pieno ritmo, se non vi è abbastanza spazio tra oggetti fisici fa in modo da ridurre il piu' possibile le collisioni ravvicinate tra loro.

Ci possono essere migliaia di oggetti fisici in un simulatore creare alcun ritardo, a patto che gli oggetti si tocchino il meno possibile l'uno con l'altro.

Il seguente video su google presenta 2000-3400 cubetti fisici in una sandbox, senza ritardo:

http://video.google.com/videoplay?docid=-2779779276874540721

Template:LSLC/it

2008-01-04T22:39:50Z

Vision Raymaker: creato template category italiano

<includeonly>{{#if:{{{2|}}}|[[Category:LSL{{#if:{{{1|}}}|_{{{1}}}}}{{{3|/it}}}|{{{2|}}}]]|[[Category:LSL{{#if:{{{1|}}}|_{{{1}}}}}{{{3|/it}}}]]}}</includeonly><noinclude>
<nowiki>[[:Category:LSL {{{1}}}{{{3|/it}}}|{{PAGENAME}}]]</nowiki></noinclude>

Template:LSL Header/it

2008-01-04T22:33:54Z

Vision Raymaker:

<div id=box>
{{{!}} style="border-width: 1px 1px 1px 1px;border-spacing: 3px;"
{{!}}-
{{!!}} [[LSL Portal/it|Portale LSL]]
{{!!}} | {{!!}} {{LSLGC|Functions/it|Funzioni}}
{{!!}} | {{!!}} {{LSLGC|Events/it|Eventi}}
{{!!}} | {{!!}} {{LSLGC|Types/it|Tipi}}
{{!!}} | {{!!}} {{LSLGC|Constants/it|Costanti}}
{{!!}} | {{!!}} {{LSLGC|Flow Control/it|Flusso d'esecuzione}}
{{!!}} | {{!!}} [[LSL Library|Libreria degli Script]]
{{!!}} | {{!!}} {{LSLGC|Tutorials|Tutorial}}
{{#if: {{{1|}}}|{{!!}} | {{!!}} {{{1|1}}}
}}{{#if:{{{2|}}}|{{!!}} | {{!!}} {{{2|2}}}
}}{{#if:{{{3|}}}|{{!!}} | {{!!}} {{{3|3}}}
}}{{#if:{{{4|}}}|{{!!}} | {{!!}} {{{4|4}}}
}}{{#if:{{{5|}}}|{{!!}} | {{!!}} {{{5|5}}}
}}{{#if:{{{6|}}}|{{!!}} | {{!!}} {{{6|6}}}
}}{{#if:{{{7|}}}|{{!!}} | {{!!}} {{{7|7}}}
}}{{#if:{{{8|}}}|{{!!}} | {{!!}} {{{8|8}}}
}}{{#if:{{{9|}}}|{{!!}} | {{!!}} {{{9|9}}}}}
{{!}}}
</div>

Template:LSL Header/it

2008-01-04T22:32:14Z

Vision Raymaker: creato template header italiano

<div id=box>
{{{!}} style="border-width: 1px 1px 1px 1px;border-spacing: 3px;"
{{!}}-
{{!!}} [[LSL Portal/it|Portale LSL]]
{{!!}} | {{!!}} {{LSLGC|Functions/it|Funzioni}}
{{!!}} | {{!!}} {{LSLGC|Events/it|Eventi}}
{{!!}} | {{!!}} {{LSLGC|Types/it|Tipi}}
{{!!}} | {{!!}} {{LSLGC|Constants/it|}}
{{!!}} | {{!!}} {{LSLGC|Flow Control/it|Flusso d'esecuzione}}
{{!!}} | {{!!}} [[LSL Library|Libreria degli Script]]
{{!!}} | {{!!}} {{LSLGC|Tutorials|Tutorial}}
{{#if: {{{1|}}}|{{!!}} | {{!!}} {{{1|1}}}
}}{{#if:{{{2|}}}|{{!!}} | {{!!}} {{{2|2}}}
}}{{#if:{{{3|}}}|{{!!}} | {{!!}} {{{3|3}}}
}}{{#if:{{{4|}}}|{{!!}} | {{!!}} {{{4|4}}}
}}{{#if:{{{5|}}}|{{!!}} | {{!!}} {{{5|5}}}
}}{{#if:{{{6|}}}|{{!!}} | {{!!}} {{{6|6}}}
}}{{#if:{{{7|}}}|{{!!}} | {{!!}} {{{7|7}}}
}}{{#if:{{{8|}}}|{{!!}} | {{!!}} {{{8|8}}}
}}{{#if:{{{9|}}}|{{!!}} | {{!!}} {{{9|9}}}}}
{{!}}}
</div>

Category:LSL Functions/it

2008-01-04T22:16:04Z

Vision Raymaker:

{{Multi-lang}}
{{LSL Header/it}}

Questa categoria contiene le funzioni integrate nel LSL.

{{LSLC|Keywords/it}}{{LSLC|Flow Control/it}}{{LSLC/it|}}

Category:LSL Functions/it

2008-01-04T22:12:04Z

Vision Raymaker: traduzione indice categoria

{{Multi-lang}}
{{LSL Header}}

Questa categoria contiene le funzioni integrate nel LSL.
{{LSLC|Keywords}}{{LSLC|Flow Control}}{{LSLC|}}