https://wiki.secondlife.com/w/api.php?action=feedcontributions&feedformat=atom&user=Kerunix+Flan 2026-05-30T00:11:45Z User contributions MediaWiki 1.42.1 https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=82534 2008-08-03T15:55:41Z

<p>Kerunix Flan: /* French */</p> <hr /> <div>{{Multi-lang}}<br /> <br /> == Recommended Locations ==<br /> An in-world Landmark giver is located in the {{SLurl/simple|SLVEC|172|64|22|Buddy Bungalow}} at [[SLVEC]]. You can drop notecards/landmarks, or touch it to receive copies.<br /> <br /> == InfoHubs ==<br /> * {{SLurl/Infohub|Ahern|28|28|40|Ahern (Ahern Welcome Area)}}<br /> * {{SLurl/Infohub|Ambat|97|212|59}}<br /> * {{SLurl/Infohub|Anzere|80|50|59}}<br /> * {{SLurl/Infohub|Bear|26|181|110|Bear Infohub (Bear Dream Lodge)}}<br /> * {{SLurl/Infohub|Bonifacio|228|228|40|Bonifacio (Ahern Welcome Area)}}<br /> * {{SLurl/Infohub|Braunworth|92|155|179}}<br /> * {{SLurl/Infohub|Calleta|128|206|26|Calleta Infohub (Calleta Hobo Railroad)}}<br /> * {{SLurl/Infohub|Clementina|184|123|61|Clementina Infohub (Governor Lindens Mansion)}}<br /> * {{SLurl/Infohub|Dore|228|28|40|Dore (Ahern Welcome Area)}}<br /> * {{SLurl/Infohub|Gukyeol|228|28|108|Gukyeol (Hanja Welcome Area)}}<br /> * {{SLurl/Infohub|Hangeul|28|28|108|Hangeul (Hanja Welcome Area)}}<br /> * {{SLurl/Infohub|Hanja|228|228|108|Hanja (Hanja Welcome Area)}}<br /> * {{SLurl/Infohub|Hyles|38|30|22|Hyles Infohub (Hyles Swamp)}}<br /> * {{SLurl/Infohub|Idu|28|228|108|Idu (Hanja Welcome Area)}}<br /> * {{SLurl/Infohub|Iris|202|125|29|Iris Infohub (Temple of Iris)}}<br /> * {{SLurl/Infohub|Isabel|44|107|57}}<br /> * {{SLurl/Infohub|Mahulu|58|193|85}}<br /> * {{SLurl/Infohub|Mauve|222|184|42}}<br /> * {{SLurl/Infohub|Miramare|3|24|25}}<br /> * {{SLurl/Infohub|Morris|28|228|40|Morris (Ahern Welcome Area)}}<br /> * {{SLurl/Infohub|Periwinkle|44|115|36|Periwinkle Infohub (Railroad Station)}}<br /> * {{SLurl/Infohub|Ross|34|224|57}}<br /> * {{SLurl/Infohub|Violet|162|100|26}}<br /> * {{SLurl/Infohub|Warmouth|42|143|95}}<br /> * {{SLurl/Infohub|Wengen|22|208|85}}<br /> <br /> == Welcome Areas ==<br /> * Ahern Welcome Area<br /> *# {{SLurl/simple|Ahern|28|28|40|Ahern}}<br /> *# {{SLurl/simple|Bonifacio|228|228|40|Bonifacio}}<br /> *# {{SLurl/simple|Dore|228|28|40|Dore}}<br /> *# {{SLurl/simple|Morris|28|228|40|Morris}}<br /> * Hanja Welcome Area:<br /> *# {{SLurl/simple|Gukyeol|228|28|108|Gukyeol}}<br /> *# {{SLurl/simple|Hangeul|28|28|108|Hangeul}}<br /> *# {{SLurl/simple|Hanja|228|228|108|Hanja}}<br /> *# {{SLurl/simple|Idu|28|228|108|Idu}}<br /> * {{SLurl/WA|Violet|162|100|27}}<br /> * {{SLurl/WA|Waterhead|36|76|25}}<br /> <br /> == Linden Meeting Spaces ==<br /> * {{SLurl/simple|Pooley|247|5|39|Pooley Stage}}<br /> <br /> == Volunteer Resources ==<br /> * {{SLurl/simple|SL Volunteer Island|1|1|35|SL Volunteer Island}} <br /> * {{SLurl/simple|Tenera|208|83|70|Volunteer HQ}}<br /> * {{SLurl/simple|Portage|24|178|85|Second Life Helper's Lyceum}}<br /> * {{SLurl/simple|Pro Racer|144|127|36|The Mental House}}: ''Access restricted to SL Volunteers. Just a peacefull full sim for (spam) stressed volunteers :D. Feel free to build anything cool, if you can find some free space (Sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> ==Orientation Islands ==<br /> ''(see [[Orientation Island]])''<br /> <br /> * {{SLurl/simple|Orientation Island Public|128|128|32|Orientation Island Public}}<br /> <br /> == Help Islands ==<br /> ''(See [[Help Island for Volunteers]])''<br /> <br /> Please note that only Volunteers can access [[Help Island]]s. However, &quot;Help Island Public&quot; and &quot;Help Island Public2&quot; are accessible by anyone. Please also note that &quot;Help Island Public2&quot; is an overflow for the busy &quot;Help Island Public,&quot; not a load-balanced location. As such, it is sparsely populated. While &quot;Help Island Public&quot; is restarting after a crash, there will be no traffic diverted to &quot;Help Island Public2.&quot;<br /> * {{SLurl/HI|Public}}<br /> * {{SLurl/HI|Public2}}<br /> * {{SLurl/HI}}<br /> * {{SLurl/HI|2}}<br /> * {{SLurl/HI|3}}<br /> * {{SLurl/HI|4}}<br /> * {{SLurl/HI|5}}<br /> * {{SLurl/HI|6}}<br /> * {{SLurl/HI|7}}<br /> * {{SLurl/HI|8}}<br /> * {{SLurl/HI|9}}<br /> <br /> == International Areas ==<br /> <br /> === French ===<br /> <br /> '''Resident owned'''<br /> <br /> * {{SLurl/simple|Gaia|147|124|28|Gaia France - French school}}: a full sim with dedicated French mentor, classes, and translated notecards. '' ([[User:kerunix Flan|kerunix Flan]])''<br /> * {{SLurl/simple|area 51|138|125|27|Area 51}}: The oldest French sim. Usually full and laggy, but with useful resources, classes and sandbox. (it's just next to the French School)<br /> * {{SLurl/simple|Terminus|128|128|27|Terminus - bac a sable / sandbox}}: The french sandbox (next to gaia)<br /> <br /> '''French speaking groups'''<br /> <br /> * [http://world.secondlife.com/group/88350540-e019-bc1e-c5c2-bb4d7f7e24bf Cooperation francaise]<br /> <br /> '''See Also'''<br /> <br /> These sims are not dedicated to SL Education, but you'll usually find French mentor.<br /> <br /> * {{SLurl/simple|Europe|217|155|75|Europe}}<br /> * {{SLurl/simple|ile de france|128|104|75|Ile de France}}<br /> * {{SLurl/simple|Solaria|123|115|75|Loisir Area}}<br /> * {{SLurl/simple|Trantor|184|24|75|La Playa Del Noob}}<br /> * {{SLurl/simple|Wild Vertigo|50|42|75|Wild Vertigo}}<br /> <br /> === German ===<br /> <br /> '''Resident owned'''<br /> <br /> * {{SLurl/simple|Pixelpark|179|227|28|Deutsches Tutorium}}<br /> * {{SLurl/simple|Samoa|109|158|557|German Tutorial}}<br /> * {{SLurl/simple|Berlin%20newBerlin%203|172|111|31|German Newbie Center}}<br /> <br /> === Korean ===<br /> <br /> '''Linden Lab owned'''<br /> <br /> * {{SLurl/Infohub|Korea1|226|23|25}}<br /> * {{SLurl/Infohub|Korea2|1|24|25}}<br /> * {{SLurl/Infohub|Korea3|239|228|25}}<br /> * {{SLurl/Infohub|Korea4|13|228|25}}<br /> <br /> === Spanish ===<br /> <br /> '''Resident owned'''<br /> <br /> * {{SLurl/simple|Quantum Fields|84|167|56|Centro de Ayuda en Castellano (Quantum Fields)}}: Center of welcome and orientation for all who speak Spanish. A place where newbies can find help, notecards, gifts, friends, and clear doubts. <br /> * {{SLurl/simple|Quest II|158|80|22|SecondLifeSpain.com (Quest II)}}: Headquarters of the community of Spanish-speaking residents [http://secondlifespain.com secondlifespain.com]. Newbies can find help, classes, and translated notecards.<br /> * {{SLurl/simple|Spanish Orientation|125|125|125|Spanish Orientation}}: The first Spanish Orientation Island with regapi and listed in secondlife.com [http://spanishorientation.com spanishorientation.com]. SL News, forum, community...<br /> <br /> '''Spanish speaking groups'''<br /> <br /> There are many groups where Spanish speaking residents can find help and make friends. Some of the more significant groups are (in no special order):<br /> <br /> * [http://world.secondlife.com/group/af64c5cf-4195-9bf9-74d6-5dbb64232a58 Segunda Vida] (founded by long term Resident, Greeter and Mentor [[User:Blueman Steele|Blueman Steele]]).<br /> * [http://world.secondlife.com/group/72698a03-bed6-447c-60b3-215e717c9674 Spanish From Spain=SpaniardS in SL]<br /> * [http://world.secondlife.com/group/b0cbccc1-f8dd-8428-5f08-d6c158da71f6 Secondlifespain.com]<br /> * [http://world.secondlife.com/group/fd6677e1-a3b4-54a9-02c0-f829657997d1 Aventura y Viajes] (founded by Mentor [[User:Irene Muni|Irene Muni]])<br /> <br /> '''See Also'''<br /> <br /> * {{SLurl/simple|La Isla|122|129|28|La Isla}}: Great place to take Spanish speakers. Active community and Spanish speaking DJ's.<br /> * {{SLurl/simple|Cycnia|168|175|30|Mirando al Mar (Cycnia)}}: A place to make new friends, speak in Spanish and have fun. Free help, Spanish notecards, etc.<br /> * {{SLurl/simple|Ibiza The Island|195|46|21|Ibiza The Island (Spain)}}<br /> <br /> === Portuguese ===<br /> <br /> There are no &quot;permanent&quot; help structures for either Brazilian or Portuguese users, but you can join their respective major groups for more help: [http://world.secondlife.com/group/576d3db9-a386-cc8e-2e6a-6acf32bb36e1 Brasileiros no SL] (for Brazil) and [http://world.secondlife.com/group/e7ef6c27-708f-5464-312b-7837f36b70fe Tugas no SL] (for Portugal). People there will usually point new users to the most recently built areas with Portuguese content.<br /> <br /> There is an island for Brazilian users run by residents called, very appropriately, {{SLurl/simple|Brasil|128|128|0|Brasil}}. Another place is listed as having information for Brazilian users: {{SLurl/simple|Delphi|37|84|26|PSDB - Diretorio SL}}.<br /> <br /> === Multi Language ===<br /> <br /> {{SLurl/simple|Dream City|186|81|26|NCI INTERNATIONAL}}. An International Learning Area and Tutorial Area<br /> <br /> == Sandboxes ==<br /> <br /> These locations are for the technically advanced - those who are familiar with building and scripting. There are very experienced people in the sandboxes as well, but are often too preoccupied to help the Newbies who arrive interested in finding out what they can do.<br /> <br /> '''Unmanaged sandboxes''' have no one in particular overseeing the operations of the area. They often rely on auto-returns and may have scripts disabled to prevent griefer attacks.<br /> <br /> '''Managed Sandboxes''' have administrators or sandbox guardians who oversee the activities on the sandboxes. They are often reachable by a paging system or group chat, if they are not physically present.<br /> <br /> <br /> === Unmanaged Sandboxes ===<br /> * {{SLurl/HI|Public}}<br /> * {{SLurl/HI|Public2}}<br /> * {{SLurl/simple|Pi|117|88|38|Pi Park &amp; Sandbox}}<br /> * {{SLurl/simple|Plum|73|250|47|Plum}}<br /> * {{SLurl/simple|Sandbox Cordova|62|198|20|Sandbox Cordova}}<br /> * {{SLurl/simple|Sandbox Goguen|208|178|20|Sandbox Goguen}}<br /> * {{SLurl/simple|Sandbox Island|69|153|24|Sandbox Island}}<br /> * {{SLurl/simple|Sandbox Newcomb|190|202|20|Sandbox Newcomb}}<br /> * {{SLurl/simple|Sandbox Wanderton|128|128|20|Sandbox Wanderton}}<br /> * {{SLurl/simple|Sandbox - Weapons testing (no damag|129|129|21|Linden Weapons Testing Sandbox}}<br /> * {{SLurl/simple|Theta|163|140|24|Theta Sandbox &amp; Park}}<br /> * {{SLurl/simple|Myungsimbogam|11|212|63|Newbie Convenience Center and Rest Station}}<br /> * {{SLurl/simple|Mauve|88|87|33|Mauve Public Sandbox (PG) near Infohub Mauve}}<br /> * {{SLurl/simple|Columbia|143|147|33|Columbia Public Sandbox (Mature) with Weapon Testing Sandbox, Dressing Room, Mature Content Skybox}}<br /> * {{SLurl/simple|Hyboria|96|212|25|Hyboria Public Sandbox (Mature)}}<br /> * {{SLurl/simple|Bethel|26|72|30|Special Vehicle Sandbox}}<br /> * {{SLurl/simple|FurNation Vista|88|80|23|Public Furry Sandbox (Mature)}}<br /> <br /> === Managed Sandboxes ===<br /> * {{SLurl/simple|Fermi|152|128|23|Fermi Sandbox}}<br /> * {{SLurl/simple|SkyBeam|77|76|37|SkyBeam Sandbox}}<br /> * {{SLurl/simple|Littleblue|138|213|22| Little Blue}}<br /> [[Category:Second Life Volunteers| ]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SLDev_Resident_Names&diff=30629 2007-09-07T02:02:50Z

<p>Kerunix Flan: laurent laborde</p> <hr /> <div>[[SLDev]] &gt; '''SLDev Resident Names'''<br /> <br /> This page is (or will hopefully be) a decoder ring for people to figure out who's who on the [[SLDev]] mailing list.<br /> <br /> If you post messages to the SLDev mailing list under a different name than your Second Life Resident name, please note it here. (Tip: putting three tildes, e.g. &quot;&lt;nowiki&gt;~~~&lt;/nowiki&gt;&quot;, will automatically convert to your name and a link to your username on this wiki) :<br /> <br /> {|border=&quot;1&quot; cellpadding=&quot;2&quot; class=sortable<br /> |-<br /> !| SLDev Posting Name <br /> !| Second Life Resident Name<br /> |-<br /> | Rob Lanphier || [[User:Rob Linden|Rob Linden]] <br /> |-<br /> | Harold &quot;LabRat&quot; Brown || [[User:Thraxis Epsilon|Thraxis Epsilon]] <br /> |-<br /> | Laurent Laborde || [[User:Kerunix Flan|Kerunix Flan]]<br /> |}</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SL_Volunteer_Island&diff=27949 2007-08-11T23:11:33Z

<p>Kerunix Flan: /* Here Are Some Attractions Going On Right Now! */</p> <hr /> <div>Second Life Volunteer Island is composed of islands that host attractions made useful for events, volunteer orientation, and training. The islands are volunteer-only, making them fantastic sandbox getaways!<br /> <br /> Volunteers are welcome to design attractions, host events, and have guests on these islands. Please review the Second Life Volunteer Island Events/Attractions Policies link below for information on how YOU can utilize SL Volunteer Islands for your own attractions and events.<br /> <br /> [[SLVI Events/Attractions Policies]]<br /> <br /> <br /> == Here Are Some Attractions Going On Right Now! ==<br /> <br /> Waterslides, Tiki Huts, Stone Faces, Hot Tubs, Coves, Flora, Fish, and Beyond - all around the SL Volunteer Islands you'll find these scattered about for your enjoyment. Some are fine details, some are easter eggs, but all are for fun and relaxation!<br /> <br /> *SL Volunteer Island (SLVI)<br /> **'''Sandcastle Maze''' - Find its entrance at (205, 60, 22) ... the exit is a bit harder to find!<br /> **'''Ruins By The Wrestling Pit''' - Catchy eh? Stop by here for some scenic ruins by a wrestling pit!<br /> **'''Surf's Up''' - Check out the beaches at this side of the island--they rock for surfing and hanging out beside!<br /> **'''The Big Ship!''' Famed location of SLVDay's dancing and pie exploits!<br /> <br /> <br /> *SL Volunteer Island S (SLVIS)<br /> **'''The ThinkDome''' - A quiet, badly-cracked gardendome with little of note except access to a prim-rezzer and a knowledge fruit tree... What's a knowledge fruit tree anyway?<br /> **'''Mental Artist's Beach Pad''' - Open to all artistic mental mentors, volunteers, and others of kindred spirit. Use the office amenities, play the piano (bring your own sheet music or use what is there), lounge in comfort upstairs, sit and chat, or gaze out over the water. Don't forget to bring your swimsuit! Relax, re-create, and go create!<br /> **'''Shorgin's Public Rest and Play Station''' - A nice place to hang and relax, with room to build and create inside and out! Posing stands inside for easy aligments. Free items as I find them for ALL Mentors and Volenters! Come on down and Enjoy!<br /> <br /> <br /> *SL Volunteer Island SW (SLVISW)<br /> **'''The Spam Museum''' - A collection of pictures and items sent out in the [[Mental Mentors]] group.<br /> **'''The Road and Garden''' - An early infrastructure built around the spam museum to organise the planned growth on this island and garden to leave some free green space for (random (shit))chatting. [[User:Kerunix Flan|Kerunix Flan]] 16:11, 11 August 2007 (PDT)<br /> **'''Borrowdale Pier Stage''' - Beautiful stage by the water, found at the edge of the central island.<br /> **'''Island of Relaxation''' - Little Island in the middle of everything to relax from all the stresses of Volunteering with Shamooo the Resident Whale! More to Come! All are welcome! (SL Volunteer Island SW 238,40,22)<br /> **'''Office Building''' - Expanding office building Katie Kellner and Stewart Saru own. If you want to have an office in it just ask one of us. We will expand it more and you can put your office down. (Note: Mentor offices will be used for hanging out basically or get away from the public.) The green windows design however may change seeing as how I walked right into one.(SL Volunteer Island SW 88,166,21)<br /> **'''Don Misfit's Volunteer Hangout''' - A nice spot to sit and chat... and to try out the Amazing Vacuum Tube! (warning: it *will* send you up and flying across the region). Also, be sure to pick up a copy of my Wearable Slide Show for Mentors ([[User:Don Misfit/Wearable Slide show|details]]) and a Free-for-Volunteers copy of my See Me HUD! (SL Volunteer Island SW 215,93,21)<br /> <br /> <br /> *SL Volunteer Island W (SLVIW)<br /> **Two versatile '''holodeck systems''', capable of rezzing multiple scenes<br /> ***Demo Holodeck http://slurl.com/secondlife/SL%20Volunteer%20Island%20W/71/130/29<br /> ***Horzions Advanced Virtual Reality System, Basic Edition http://slurl.com/secondlife/SL%20Volunteer%20Island%20W/71/130/68<br /> **Calling all Mentors come on out to '''Doc G's Mentor Clinic'''. Specially prescribed relaxation for the Mental Lag of Mentoring.<br /> ***Come Dance, Bounce in the Moon Walk, Use the Hot tub, relax by the beach. Feel free to enjoy this space at any time.<br /> **'''Mentor's Skygarden''' another place to escape the stress omnipresent in the rest of the grid. Just use the teleporter on the pier at http://slurl.com/secondlife/SL%20Volunteer%20Island%20W/175/92/22 to find a peaceful sanctuary in the clouds. Also features an alternative meeting place for up to 30 people.<br /> <br /> <br /> *SL Volunteer Island OI (SLVOI)<br /> **Grab an Orientation Guide attachment from the center and feel free to walk through '''Orientation Island''' on your own! <br /> <br /> <br /> *SL Volunteer Island HI (SLVHI)<br /> **Feel free to explore the most current '''Help Island''' in Second Life. This Help Island uses its sandbox area as the main stage for Second Life Volunteer Orientation!</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Registration_API_Third_Party_Support&diff=24906 2007-07-05T20:20:13Z

<p>Kerunix Flan: /* eMagine */</p> <hr /> <div>&lt;b&gt;This page contains self-listed providers of support for use of the Registration API.&lt;/b&gt;<br /> <br /> Note to listers: by listing here, you are offering to provide support for users of the RegAPI<br /> and by so doing, are indicating that you have appropriate knowledge of both the RegAPI<br /> and the appropriate scripting languages and host installation to do so.<br /> <br /> Note to users: Linden Lab makes no representation of the performance of companies or individuals listed here. <br /> Use at your own risk! As you would with any other service, ask for references, have clear agreement on performance,<br /> timeline and fees, and be reasonable in your expectations.<br /> <br /> ==Listings==<br /> === Centric ===<br /> * Contact information:&lt;br&gt; SL IM: Adam Rakosi (English, Spanish), Neko Longduk (Japanese, Mandarin) &lt;br&gt; Email: adam.rakunas@centric.com (English, Spanish), ken.brady@centric.com (Japanese, Mandarin) &lt;br&gt; Phone: (800) 9-CENTRIC or (818) 985-8855<br /> <br /> * Services provided: &lt;br&gt; RegAPI implementation: on our gateways or on your website. &lt;br&gt; Full-service metaverse development: from partial regions to world-spanning strategies. &lt;br&gt; Technology development: LSL to back-end database integration and media support. <br /> <br /> Languages: English, Spanish, Japanese, Mandarin<br /> <br /> ----<br /> <br /> === eMagine ===<br /> * Contact information:<br /> In-world IM Kinzo Nurmi, or contact David Graham by email at graham@emgaine.jp. Or call us at +81 78-881-0151, Skype: dgraham.kobe.<br /> <br /> * Services provided:<br /> We are a full service SL content development company, delivering a full line of services from Web Portal development to in-world experiences. We provide end-to-end solutions, including gathering project metrics, in addition to ad-hoc project work.<br /> <br /> We can provide support and/or development of your Second Life registration pages, welcome centers tailored to your brand, and metric collection systems.<br /> <br /> Languages Spoken: English, Japanese, Mandarin<br /> <br /> '''We have available a generic registration page''' that has all of the required scripting for a registration portal, including dynamic error catching. You do not need to be an expert in PHP; that work is already done for you. Just add your capability URLs, HTML and web graphics to customize the look, and you're ready to go. <br /> <br /> A sample of the generic portal can be found at [http://www.emagine.jp/regapi/secondlife.php www.emagine.jp/regapi/secondlife.php].<br /> <br /> The generic registration portal is compatible with php4.0 and php5.0.<br /> <br /> Feedback : &quot;''Quick and clean service. It just work.''&quot; [[User:Kerunix Flan|Kerunix Flan]] 13:20, 5 July 2007 (PDT)<br /> <br /> ----<br /> <br /> === FireSabre Consulting LLC ===<br /> <br /> * Contact information:&lt;br&gt; IM Gus Plisskin in SL, or email us at: bulkaccounts /AT/ FireSabre /DOT/ com.<br /> <br /> * Services provided:&lt;br&gt;FireSabre offers two kinds of RegAPI service.&lt;br&gt;1) We create a batch of bulk accounts for your project.&lt;br&gt;2) We can also provide a website with which you can register your own accounts as needed.&lt;br&gt;<br /> <br /> We've been providing RegAPI services since 2006. We're experienced, and have provided bulk accounts for quite a few clients.<br /> <br /> Please contact us about your SL account creation needs. Our services are fast, inexpensive, and flexible.<br /> <br /> For more information see: [http://firesabre.com/Services.php www.firesabre.com]<br /> <br /> ----<br /> <br /> === MageTech LLC ===<br /> * Contact information:&lt;br&gt; IM Alexander Regent in SL, or email us at: info@magetech.com or call directly at 617-256-8030<br /> <br /> * Services provided: &lt;BR&gt; Any needed including:<br /> <br /> 1) Full API support of both bulk and individual registrations, either through your own website or our existing gateways. <br /> <br /> References available upon request.<br /> <br /> 2) Full service scripting and backend server/database development to track usage of your new clients.<br /> <br /> 3) &quot;in-world&quot; sim and parcel development on a per project basis.<br /> <br /> Language: English, et aussi Francais!</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Sculpted_Prims:_Technical_Explanation&diff=19474 2007-05-02T15:19:46Z

<p>Kerunix Flan: </p> <hr /> <div>Eddy - SWEEEET. SWEEET SWEEET SWEET. thank you. --[[User:Qarl Linden|Qarl Linden]] 10:15, 30 April 2007 (PDT)<br /> <br /> <br /> PS: regarding that apple texture - by my estimate that texture has been jpeg encoded at LEAST 4 times - which probably explains why your wireframe is so jaggy. let me get you an uncompressed version later today. --[[User:Qarl Linden|Qarl Linden]] 10:15, 30 April 2007 (PDT)<br /> <br /> I think I died and went to heaven. Thanks for the explanation about the uvspace and mesh, makes it easier to approximate offline. Seems like all my 3d skills will be finally used in SL, once this feature enters the grid :D --[[User:Hypatia Callisto|Hypatia Callisto]] 16:08, 30 April 2007 (PDT)<br /> <br /> <br /> Mmmmm... where can i download this software ? :D [[User:Kerunix Flan|Kerunix Flan]] 08:19, 2 May 2007 (PDT)</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SLDev-Traffic_5_(FR)&diff=16658 2007-04-03T04:23:52Z

<p>Kerunix Flan: Translation done !!</p> <hr /> <div>{{SLDevTraffic}}<br /> <br /> French translation of [[SLDev-Traffic_5]]<br /> <br /> Traduction francaise de [[SLDev-Traffic_5]] par [[User:Kerunix Flan|Kerunix Flan]] 21:23, 2 April 2007 (PDT)<br /> <br /> Discussions sur sldev depuis le 30 Mars 2007<br /> <br /> == Plante Linden Customisée ==<br /> Argent Stonecutter a remarqué que très peu de données définissent les arbres et les plantes utilisées dans Second Life. L'objet entier pourrait être spécifié dans une liste et déployés de la même manière que sont déployés les particules. Cela offre la possibilité d'avoir plus de controle, via les scripts, sur les plantes et de réduire le nombre de prims utilisés.<br /> Vous pouvez trouver les détails sur le wiki (en anglais) [[Custom Linden Plants]] et sur JIRA a {{JIRA|VWR-303}}. <br /> <br /> <br /> == Modérer les logs du client==<br /> Tom &quot;Spot&quot; Callaway a exprimé son intérêt à réduire la quantité de log généré par le client. Il a trouvé une référence à logcontrol.xml et logcontrol-dev.xml mais il n'a pas pu trouver d'exemple de leurs utilisations. Ryan Williams (Linden) a écrit une page sur [[Error Logging System]]. Phoenix Linden fait remarquer que la librairie openJPEG est la plus verbeuse car elle écrit directement sur stderr, ce qui outrepasse le système de gestion de log. Phoenix indique aussi qu'un correctif devrait être apporté sous peu. &quot;Guido&quot; indique que {{JIRA|VWR-100}} montre comment désactiver les logs d'openJPEG en attendant.<br /> <br /> <br /> == Calmer les discussions ==<br /> La discussion continue sur le meilleur moyen de gérer les sujet générant un fort trafic. Pour l'instant, Rob Lanphier (Linden) a demandé aux utilisateurs de créer une entrée JIRA ou d'utiliser les pages de discussion wiki (talk page). Une discussion a cependant continuée à propos de l'intérêt des talk page sur [[Talk:SLDev|SLDev Talk page]]. Rob a expliqué certains bénéfices à utiliser le wiki pour cela, incluant le fait que certains sujets seront encore discutés pour les mois et années a venir. Il donne l'exemple de [[Talk:Texture_cache|texture cache discussion]] qui refera certainement surface dans le futur.<br /> <br /> Rob a aussi parlé du problème des discussion qui semblent êtres plus le sujet d'un amusement que d'un travail constructif. Cela arrive souvent quand quelqu'un parle d'un sujet ou une idée sans avoir l'intention d'écrire du code et que d'autres, sans intention de programmer, prennent position sur un long débat sans pourtant produire quoi que ce soit.<br /> <br /> A propos de la séparation des sujet vers le JIRA et le wiki, certains membres ont protesté contre cette idée et ont proposés de tout garder sur la liste, d'utiliser des forums, ou plusieurs mailling lists. La discussion a aussi continuée in-world, l'idée d'une liste limitée aux contributeurs qui ont signés un agrément avec LL a refait surface, ainsi que l'idée de poster des sommaires de certaines discussions in-worl sur la liste.<br /> <br /> Aucune consensus n'a été trouvé. Mais Rob a demandé aux participants d'essayer tout de même sa proposition pendant quelques semaines. Pendant son office du lundi, rob a rapporté qu'il n'a pas encore eu de retour de la part des développeurs Linden à propos des guides d'utilisation de la liste.<br /> <br /> Un point unanime est que le système de notification par mail du wiki doit être réparé. Pendant les heures de bureaux in-world, Soft a fait remarquer que si il était possible de recevoir chaque changement du wiki par mail, cela serait fonctionnellement identique à une mailling list pour ceux qui préfèrent le système de liste.<br /> <br /> <br /> == Contrôler les modes de construction ==<br /> Ettore Pasquini a exprimé sont intérêt à apprendre comment la souris et le clavier contrôlent le mode de construction. Spécifiquement, Ettore cherche &quot;quelle classe ou fonction s'occupe des mouvements.&quot; Ettore est intéressé dans l'utilisation d'un contrôleur 3D pour pour commander le mode de construction avec une plus grande précision.<br /> <br /> Il y a eu quelques discussion à propos des périphériques disponibles et même un lien vers un driver pour utiliser une Wiimote comme contrôleur, à ce jour Ettore n'a pas eu de réponse.<br /> <br /> == Cross-compilation avec mingw ==<br /> Dzonatos Sol a posté un autre patch pour compiler le client Windows avec mingw. Le [https://lists.secondlife.com/pipermail/sldev/2007-March/001324.html nouveau patch] ne semble pas être attaché à une entrée JIRA, cependant Dzonatas mentionne que le patch fait référence à {{JIRA|VWR-186}}, {{JIRA|VWR-187}} et {{JIRA|VWR-198}}. Ce patch a été fait partir de First Look 58390.<br /> <br /> == Déconnexion sans avertissement ==<br /> Laurent Laborde (kerunix Flan) a remarqué que les utilisateurs ne sont pas explicitement avertis quand le simulateur courant ne repond plus et déconnecte. Callum Lerwick fait aussi remarquer que sa femme à perdu des heures de travail en continuant a faire des changements sur des objets sans avoir réalisé que la carte était rouge. Callum suggère qu'un message explicite avertissant de la déconnexion pourrait fonctionner s'il y avait la possibilités de sauvegarder son travail ou de se reconnecter immédiatement, à noter que certains systèmes peuvent prendre plusieurs minutes pour se reconnecter.<br /> <br /> == Sortie de la GPL v3 ==<br /> Dzonata Sol a remarqué que le 3ème Draft de la GPL est sortie. Particulièrement, ce 3eme draft supprime une partie qui obligeait le détenteur du copyright à protéger les licenciés des infractions de brevets. &quot;There is now an overall clarification of how a covered work is conveyed and when one conveys such a work that one must abide by the terms of the license to disclaim patent infringement or likewise.&quot; Dzonata indique que le wiki devra être mis à jour quand on en sera plus à propos de ces changements.<br /> <br /> == OpenJPEG - Bigger, Better, Stronger, Faster ==<br /> Callum Lerwick a trouvé une boucle où un array était mis a zero dans l'ordre des lignes au lieu des colonnes. James Cook (Linden) note qu'un memset serait encore mieux que de corriger l'ordre, puisqu'un memset est garantis pour être optimisé pour chaque plateforme. Stefen Westerfeld note qu'un travail de nettoyage à deja été effectué et fait aussi remarquer l'existence d'une mailling list pour l'optimisation d'openJPEG. Francois-Olivier Devaux, membre du groupe openJPEG, fait remarquer qu'une nouvelle version d'openJPEG devrait sortir bientot, et indique que ces corrections peuvent être incluses si quelqu'un écrit un patch. Callum Lerwick a répondu par un patch encore non-finalisé.<br /> <br /> == Lire la friendlist des autres ==<br /> Marco Milanesion a demandé s'il était possible de lire les friend list des autres. Il n'y a pas eu de réponses pour l'aider. Bien que la question reste sans solution, Dale Glass espère que cela ne sera jamais possible. <br /> <br /> == Signature de clé GPG ==<br /> Dale Glass a indiqué qu'il y aurait un intérêt à ce que LL signe les clés GPG. Il suggère que LL devrait créer une clé maitre utilisée pour pour signer tous les employés, ainsi que de créer un mécanisme de signature automatique du nom de compte ou d'avatar et qui tournerai sur le site web de SL. Dale a proposé plusieurs applications possible telles que la signature de patch et d'eventuels plugins. Dale a aussi suggéré que le niveau de confiance de clé pourrait être utilisé pour différencier les utilisateurs avec &quot;payement info on file&quot;, &quot;payement info used&quot;, &quot;Linden Lab employee&quot;, etc ...<br /> <br /> Phoenix indique que sa clé est valable sur le wiki et via subkeys.php.net. Phoenix à déjà signé beaucoup de developpeurs LL et indique:&lt;br /&gt;<br /> I will sign keys of people that I meet and that I prove to<br /> myself match their proposed email address.<br /> <br /> A secure and automated method of proving identity and key mappings<br /> would take a while, so no one is spending much time thinking about<br /> it. I will think about how to do this, and talk to Zero to see if<br /> there is a good way to roll that into our current Agent Domain<br /> scalability work.<br /> <br /> Until that time, I am the best gateway (aka bottleneck) for signing<br /> contributor keys.<br /> <br /> == Soumission de patch réclamant un travail de traduction ==<br /> Jason Giglio à demandé quoi faire a propos des patches qui incluent des nouveaux textes UI.<br /> <br /> Leyla Farazha (Linden) indique que les contributeurs ont uniquement besoin de faire les changement sur la version US. Il y a un processus qui détecte ce qui a besoin d'être traduit avant d'être publié :&lt;br /&gt;<br /> <br /> Help with the translation process is always welcome, and once we have<br /> set up the pipeline for that work we'll let you all know. :-)<br /> <br /> Jean Miller (Linden) demande que les utilisateurs ne fassent pas de traductions automatiques et indiquent que Linden Lab travaille à mettre en place les outils nécessaires pour permettre les traduction des textes manquants via le wiki. Jean a invité les membres de la liste a contribuer à un format pour une telle page.<br /> <br /> Alissa Sabre, un japonais, indique que la traduction japonaise est très mauvaise. Jean Miller a répondu que le service de traduction responsable n'est plus utilisé, et que LL est au courant qu'il y a un travail de nettoyage a faire. Laurent Laborde était beaucoup plus content avec la traduction francaise : &quot;Not super-perfect, but good enough to be 100% useable.&quot;<br /> <br /> == Identifier les JIRAs prioritaires ==<br /> Rob Lanphier (Linden) a précédemment indiqué que les membres de la liste pourrait énormément aider en votant sur les tickets qui réclament l'attention de LL. Quelques tickets sont encore perdus sous le volume du JIRA publique. Pendant les heures de bureaux de Rob, Gigs Taggart a montré quelques tickets. Il a aussi fait remarquer qu'il était possible de chercher des tickets JIRA qui ont des patchs attachés et qu'ils sont des bon candidants à des traitements prioritaires.<br /> <br /> Rob indique que LL cherche à embaucher quelqu'un qui peut aider a gérer les JIRAs et patchs offerts par le public.<br /> <br /> == Physique ==<br /> Pendant les heures de bureau de Rob Lanphier (Linden), Soft Noel a demandé pourquoi LL utilise encore une ancienne version de Havok dans Second Life. Rob a expliqué que beaucoup de contenu utilisateur repose sur un comportement precis de l'ancien moteur. Rob espère que les prochains changements apportés à secondlife permettront des étapes incrémentales pour permettre de migrer vers un moteur plus rapide.<br /> <br /> Drewan Keats a demandé s'il y avait eu des discussions a propos de moteurs physiques opensource. Il n'y a pas eu de réponses pour l'instant.<br /> <br /> == Adroit's Unit Testing Patches ==<br /> Soft Noel a demandé si quelqu'un a utilisé ou testé les patches de test unitaire d'Adroit. Personne dans le bureau de Rob n'a eu de réponses positives. Rob a indiqué que le framework de test unitaire utilisé est le [http://tut-framework.sourceforge.net tut-framework]. <br /> <br /> == Rob Linden Needs a Bear ==<br /> You can't have this many in-world meetings and not have a prize at the end, just in case a meeting actually turns out to be boring and all. &quot;Oh hey, and look - FREE BEAR!&quot; is a perfect save. Does SLDev have any qualified bear makers?</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SLDev-Traffic_5_(FR)&diff=16657 2007-04-03T03:52:22Z

<p>Kerunix Flan: </p> <hr /> <div>{{SLDevTraffic}}<br /> <br /> == DO NOT EDIT ! TRANSLATION CURRENTLY IN PROGRESS == <br /> <br /> (i'm just saving from time to time :p ) [[User:Kerunix Flan|Kerunix Flan]] 20:17, 2 April 2007 (PDT)<br /> <br /> sldev-traffic (FR) no 5<br /> <br /> Discussions sur sldev depuis le 30 Mars 2007<br /> <br /> <br /> == Plante Linden Customisé ==<br /> Argent Stonecutter a remarqué que très peu de données definissent les arbres et les plantes utilisées dans Second Life. L'object entier pourrait etre specifié dans une liste et deployés de la même manière que sont deployés les particules. Cela offre la possibilité d'avoir plus de controle, via les scripts, sur les plantes et de reduire le nombre de prims utilisés.<br /> Vous pouvez trouver les détails sur le wiki (en anglais) [[Custom Linden Plants]] et sur JIRA a {{JIRA|VWR-303}}. <br /> <br /> <br /> == Modérer les logs du client==<br /> Tom &quot;Spot&quot; Callaway à exprimé son intérêt à réduire la quantité de log généré par le client. Il a trouvé une référence à logcontrol.xml et logcontrol-dev.xml mais il n'a pas pu trouver d'exemple de leurs utilisations. Ryan Williams (Linden) a écrit une page sur [[Error Logging System]]. Phoenix Linden fait remarquer que la librairie openJPEG est la plus verbeuse car elle écrit directement sur stderr, ce qui outrepasse le systeme de gesion de log. Phoenix indique aussi qu'un correctif devrait être apporté sous peu. &quot;Guido&quot; indique que {{JIRA|VWR-100}} montre comment désactiver les logs d'openJPEG en attendant.<br /> <br /> <br /> == Calmer les discussions ==<br /> La discussion continue sur le meilleur moyen de gerer les sujet generant un fort traffic. Pour l'instant, Rob Lanphier (Linden) a demandé aux utilisateurs de créer une entrée JIRA ou d'utiliser les pages de discussion wiki (talk page). Une discussion a cependant continué a propos de l'intérêt des talk page sur [[Talk:SLDev|SLDev Talk page]]. Rob a expliqué certains bénéfices à utiliser le wiki pour cela, incluant le fait que certains sujets seront encore discutés pour les mois et années a venir. Il donne l'exemple de [[Talk:Texture_cache|texture cache discussion]] qui refera certainement surface dans le futur.<br /> <br /> Rob a aussi parlé du problème des discussion qui semblent êtres plus le sujet d'un amusement que d'un travail constructif. Cela arrive souvent quand quelqu'un parle d'un sujet ou une idée sans avoir l'intention d'écrire du code et que d'autres, sans intention de programmer, prennent position sur un long débat sans pourtant produire quoi que ce soit.<br /> <br /> A propos de la séparation des sujet vers le JIRA et le wiki, certains membres ont protestés contre cette idée et ont proposés de tout garder sur la liste, d'utiliser des forums, ou plusieurs mailling lists. La discussion a aussi continuée in-world, l'idée d'une liste limitée aux contributeurs qui ont signés un agrément avec LL a refait surface, ainsi que l'idée de poster des sommaires de certaines discussions in-worl sur la liste.<br /> <br /> Aucune consensus n'a été trouvé. Mais Rob a demandé aux participants d'essayer tout de même sa proposition pendant quelques semaines. Pendant son office du lundi, rob a rapporté qu'il n'a pas encore eu de retour de la part des développeurs Linden a propos des guides d'utilisation de la list.<br /> <br /> Un point unanime est que le système de notification par mail du wiki doit être réparé. Pendant les heures de bureaux in-world, Soft a fait remarquer que si il était possible de recevoir chaques changements du wiki par mail, cela serait fonctionnellement identique à une mailling list pour ceux qui préfèrent le système de liste.<br /> <br /> <br /> == Contrôler les modes de construction ==<br /> Ettore Pasquini a exprimé sont intérêt à apprendre comment la souris et le clavier contrôlent le mode de construction. Spécifiquement, Ettore cherche &quot;quelle classe ou fonction s'occupe des mouvements.&quot; Ettore est intéressé dans l'utilisation d'un contrôleur 3D pour pour commander le mode de construction avec une plus grande précision.<br /> <br /> Il y a eu quelques discussion à propos des périphériques disponibles et même un lien vers un driver pour utiliser une Wiimote comme controleur, à ce jour Ettore n'a pas eu de réponse.<br /> <br /> == Cross-compilation avec mingw ==<br /> Dzonatos Sol a posté un autre patch pour compiler le client Windows avec mingw. Le [https://lists.secondlife.com/pipermail/sldev/2007-March/001324.html nouveau patch] ne semble pas être attaché à une entrée JIRA, cependant Dzonatas mentionne que le patch fait référence à {{JIRA|VWR-186}}, {{JIRA|VWR-187}} et {{JIRA|VWR-198}}. Ce patch a été fait partir de First Look 58390.<br /> <br /> == Déconnexion sans avertissement ==<br /> Laurent Laborde (kerunix Flan) a remarqué que les utilisateurs ne sont pas explicitement avertis quand le simulateur courant timeout et déconnecte. Callum Lerwick fait aussi remarqué que sa femme a perdu des heures de traivail en continuant a fraire des changements sur des objets sans avoir réalisé que la carte etait rouge. Callum suggère qu'un message explicite avertissant de la déconnexion pourrait fonctionner s'il y avait la possibilités de sauvegarder son travail ou de se reconnecter immédiatement, a noter que certains systèmes peuvent prendre plusieurs minutes pour se reconnecter.<br /> <br /> == Sortie de la GPL v3 ==<br /> Dzonata Sol a remarqué que le 3ème Draft de la GPL est sortie. Particulièrement, ce 3eme draft supprime une partie qui obligeait le détenteur du copyright à protéger les licenciés des infractions de brevets. &quot;There is now an overall clarification of how a covered work is conveyed and when one conveys such a work that one must abide by the terms of the license to disclaim patent infringement or likewise.&quot; Dzonata indique que le wiki devra être mis à jour quand on en sera plus à propos de ces changements.<br /> <br /> == OpenJPEG - Bigger, Better, Stronger, Faster ==<br /> Callum Lerwick a trouvé une boucle ou un array était mis a zero dans l'ordre des lignes au lieu des collones. James Cook (Linden) note qu'un memset serait encore mieux que de corriger l'ordre, puisqu'un memset est garantis pour être optimisé pour chaque plateforme. Stefen Westerfeld note qu'un travail de nettoyage à deja été effectué et fait aussi remarquer l'existance d'une mailling list sur l'optimisation openJPEG. Francois-Olivier Devaux, membre du groupe openJPEG, fait remarquer qu'une nouvelle version d'openJPEG devrait sortir bientot, et indique que ces corrections peuvent être incluses si quelqu'un ecrit un patch. Callum Lerwick a répondu par un patch en cours de travail.<br /> <br /> == Lire la friendlist des autres ==<br /> Marco Milanesion a demandé s'il etait possible de lire les friend list des autres. Il n'y a pas eu de reponses pour l'aider. Bien que la question reste sans reponse, Dale Glass espère que cela ne sera jamais possible. <br /> <br /> == Signature de clé GPG ==<br /> Dale Glass a indiqué qu'il y aurait un interet a ce que LL signe les clés GPG. Il suggère que LL devrait créer une clé maitre utilisée pour pour signer tous les employés, ainsi que de creer un mecanisme de signature automatique du nom de compte ou d'avatar et qui tournerai sur le site web de SL. Dale a proposé plusieurs applications possible telles que la signature de patch et d'envetuels plugins. Dale a aussi suggeré que le niveau de confiance de clé pourait être utilisé pour differencer les utilisateurs avec &quot;payement info on file&quot;, &quot;payement info used&quot;, &quot;Linden Lab employee&quot;, etc ...<br /> <br /> Phoenix indique que sa clé est valable sur le wiki et via subkeys.php.net. Phoenix à déjà signé beaucoup de developpeurs LL et indique:&lt;br /&gt;<br /> I will sign keys of people that I meet and that I prove to<br /> myself match their proposed email address.<br /> <br /> A secure and automated method of proving identity and key mappings<br /> would take a while, so no one is spending much time thinking about<br /> it. I will think about how to do this, and talk to Zero to see if<br /> there is a good way to roll that into our current Agent Domain<br /> scalability work.<br /> <br /> Until that time, I am the best gateway (aka bottleneck) for signing<br /> contributor keys.<br /> <br /> == Soumission de patch réclamant un travail de traduction ==<br /> Jason Giglio à demandé quoi faire a propos des patches qui incluent des nouveaux textes UI.<br /> <br /> Leyla Farazha (Linden) indique que les contributeurs ont uniquement besoin de faire les changement sur la version US. Il y a un processus qui detecte ce qui a besoin d'être traduit avant d'être publié :&lt;br /&gt;<br /> <br /> Help with the translation process is always welcome, and once we have<br /> set up the pipeline for that work we'll let you all know. :-)<br /> <br /> Jean Miller (Linden) demande que les utilisateurs ne fassent pas de traductions automatiques et indiquent que Linden Lab travaille à mettre en place les outils necessaires pour permettre les traduction des textes manquants via le wiki. Jean a invité les membres de la liste a contribuer à un format pour une telle page.<br /> <br /> Alissa Sabre, un japonais, indique que la traduction japonaise est très mauvaise. Jean Miller a repondu que le service de traduction reponsable n'est plus utilisé, et que LL est au courant qu'il y a un travail de nettoyage a faire. Laurent Laborde était beaucoup plus content avec la traduction francaise : &quot;Not super-perfect, but good enough to be 100% useable.&quot;<br /> <br /> <br /> <br /> == Identifying JIRAs Needing Action ==<br /> Rob Lanphier (Linden) previously indicated that list members could help tremendously by voting on issues needing attention. Some issues are still getting lost in the volume of the public JIRA however. During Rob's office hours, Gigs Taggart pointed to a few hot issues. It was also noted that it was possible to search for JIRAs with patches attached, and that these would be good high-priority candidates.<br /> <br /> Rob indicated that LL are looking to hire someone who can help handle JIRAs and patches offered by the public.<br /> <br /> == Physics ==<br /> During Rob Lanphier's (Linden) office hours, Soft Noel inquired about why LL was using an old version of Havok for physics in Second Life. Rob explained that much user content relied on quirks and precise behaviors of the older engine. Rob hoped that coming changes in SL that make it possible to do incremental rollouts might offer a step toward phasing in a faster engine.<br /> <br /> Drewan Keats wondered if there had been any discussion about open source physics engines. There was no follow-up discussion on the point.<br /> <br /> == Adroit's Unit Testing Patches ==<br /> Soft Noel asked if anyone had been using or testing Adroit's unit testing patches. Nobody in Rob Lanphier's office hours had any positive response, though Rob pointed to the unit testing framework in use as the [http://tut-framework.sourceforge.net tut-framework]. <br /> <br /> == Rob Linden Needs a Bear ==<br /> You can't have this many in-world meetings and not have a prize at the end, just in case a meeting actually turns out to be boring and all. &quot;Oh hey, and look - FREE BEAR!&quot; is a perfect save. Does SLDev have any qualified bear makers?</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SLDev-Traffic_5_(FR)&diff=16655 2007-04-03T03:17:35Z

<p>Kerunix Flan: </p> <hr /> <div>{{SLDevTraffic}}<br /> <br /> == DO NOT EDIT ! TRANSLATION CURRENTLY IN PROGRESS == <br /> <br /> (i'm just saving from time to time :p ) [[User:Kerunix Flan|Kerunix Flan]] 20:17, 2 April 2007 (PDT)<br /> <br /> sldev-traffic (FR) no 5<br /> <br /> Discussions sur sldev depuis le 30 Mars 2007<br /> <br /> <br /> == Plante Linden Customisé ==<br /> Argent Stonecutter a remarqué que très peu de données definissent les arbres et les plantes utilisées dans Second Life. L'object entier pourrait etre specifié dans une liste et deployés de la même manière que sont deployés les particules. Cela offre la possibilité d'avoir plus de controle, via les scripts, sur les plantes et de reduire le nombre de prims utilisés.<br /> Vous pouvez trouver les détails sur le wiki (en anglais) [[Custom Linden Plants]] et sur JIRA a {{JIRA|VWR-303}}. <br /> <br /> <br /> == Modérer les logs du client==<br /> Tom &quot;Spot&quot; Callaway à exprimé son intérêt à réduire la quantité de log généré par le client. Il a trouvé une référence à logcontrol.xml et logcontrol-dev.xml mais il n'a pas pu trouver d'exemple de leurs utilisations. Ryan Williams (Linden) a écrit une page sur [[Error Logging System]]. Phoenix Linden fait remarquer que la librairie openJPEG est la plus verbeuse car elle écrit directement sur stderr, ce qui outrepasse le systeme de gesion de log. Phoenix indique aussi qu'un correctif devrait être apporté sous peu. &quot;Guido&quot; indique que {{JIRA|VWR-100}} montre comment désactiver les logs d'openJPEG en attendant.<br /> <br /> <br /> == Calmer les discussions ==<br /> La discussion continue sur le meilleur moyen de gerer les sujet generant un fort traffic. Pour l'instant, Rob Lanphier (Linden) a demandé aux utilisateurs de créer une entrée JIRA ou d'utiliser les pages de discussion wiki (talk page). Une discussion a cependant continué a propos de l'intérêt des talk page sur [[Talk:SLDev|SLDev Talk page]]. Rob a expliqué certains bénéfices à utiliser le wiki pour cela, incluant le fait que certains sujets seront encore discutés pour les mois et années a venir. Il donne l'exemple de [[Talk:Texture_cache|texture cache discussion]] qui refera certainement surface dans le futur.<br /> <br /> Rob a aussi parlé du problème des discussion qui semblent êtres plus le sujet d'un amusement que d'un travail constructif. Cela arrive souvent quand quelqu'un parle d'un sujet ou une idée sans avoir l'intention d'écrire du code et que d'autres, sans intention de programmer, prennent position sur un long débat sans pourtant produire quoi que ce soit.<br /> <br /> A propos de la séparation des sujet vers le JIRA et le wiki, certains membres ont protestés contre cette idée et ont proposés de tout garder sur la liste, d'utiliser des forums, ou plusieurs mailling lists. La discussion a aussi continuée in-world, l'idée d'une liste limitée aux contributeurs qui ont signés un agrément avec LL a refait surface, ainsi que l'idée de poster des sommaires de certaines discussions in-worl sur la liste.<br /> <br /> Aucune concensus n'a été trouvé. Mais Rob a demandé aux participants d'essayer tout de même sa proposition pendant quelques semaines. Pendant son office du lundi, rob a rapporté qu'il n'a pas encore eu de retour de la part des developpeurs Linden a propos des guides d'utilisation de la list.<br /> <br /> Un point unanime est que le systeme de notification par mail du wiki doit être reparé. Pendant les heures de bureaux in-worlf, Soft a fait remarquer que si il était possible de recevoir chaque changement du wiki par mail, cela serait fonctionnellement identique a une mailling list pour ceux qui préfèrent le système de liste.<br /> <br /> <br /> == Controller les modes de construction ==<br /> Ettore Pasquini à exprimé sont interet à apprendre comment la souris et le clavier controle le mode de construction. Specifiquement, Ettore cherche &quot;quelle classe ou fonction s'occupe des mouvements.&quot; Ettore est interessé dans l'utilisation d'un controlleur 3D pour pour commander le mode de construction avec une plus grnade precision.<br /> <br /> Il y a eu quelques discussion à propos des peripheriques disponibles et même un lien vers un driver pour utiliser une Wiimote comme controleur, a ce jour Ettore n'a pas eu de réponse.<br /> <br /> == Cross-compilation avec mingw ==<br /> Dzonatos Sol a posté un autre patch pour compiler le client Windows avec mingw. Le <br /> <br /> Dzonatas Sol posted another patch for building the Windows viewer using mingw. The [https://lists.secondlife.com/pipermail/sldev/2007-March/001324.html nouveua patch] ne semble pas être attaché a une entrée JIRA, cependant Dzonatas mentionne que le patch fait référence à {{JIRA|VWR-186}}, {{JIRA|VWR-187}} et {{JIRA|VWR-198}}. Ce patch a été fait partir de First Look 58390.<br /> <br /> == Deconnection sans avertissement ==<br /> Laurent Laborde (kerunix Flan) a remarqué que les utilisateurs ne sont pas explicitement avertis quand le simulateur courant timeout et deconnecte. Callum Lerwick fait aussi remarqué que sa femme a perdu des heures de traiavail en continuant a fraire des changements sur des objets sans avoir réalisé que la carte etait rouge. Callum suggère qu'un message explicite avertissant de la déconnexion pourrait fonctionner s'il y avait la possibilitée de sauvegarder son travail ou de se reconnecter immediatement, a noter que certains systèmes peuvent prendre plusieurs minutes pour se reconnecter.<br /> <br /> == Sortie de la GPL v3 ==<br /> Dzonata Sol a remarqué que le 3ème Draft de la GPL est sortie. Particulierement, ce 3eme draft supprime une partie qui obligait le detenteur du copyright de proteger les liciencés des infractions de brevets. &quot;There is now an overall clarification of how a covered work is conveyed and when one conveys such a work that one must abide by the terms of the license to disclaim patent infringement or likewise.&quot; Dzonata indique que le wiki devra être mis à jour quand on en sera plus a propos de ces changements.<br /> <br /> <br /> ----<br /> <br /> <br /> == OpenJPEG - Bigger, Better, Stronger, Faster ==<br /> Callum Lerwick found a loop where an array was being zeroed in row order instead of column order. James Cook (Linden) noted that a memset would work even better than correcting the order here, as memset was guaranteed to be optimized for each platform. Stefan Westerfeld noted some work being done on cleaning up this code already and also noted the existence of an OpenJPEG optimization mailing list. Francois-Olivier Devaux, part of the OpenJPEG project, noted that a new version of OpenJPEG was imminent, and suggested that this fix could be included if someone offers a patch. Callum Lerwick followed up with a patch of work in progress.<br /> <br /> == Reading Others' Friendlists ==<br /> Marco Milanesio inquired as to whether it was possible to read other users' friendlists. There were no helpful replies for Marco Milanesio. Whether this is possible remains unanswered, though Dale Glass expressed that he hoped it would never be possible.<br /> <br /> == GPG Keysigning ==<br /> Dale Glass inquired as to whether there would be interest in LL GPG keysigning. He suggested that LL should create a master key used to sign all employees, as well as creating an automated signing mechanism running on the SL website which allowed signing against a player name or the registered account name. Dale went on to discuss various applications for the keys such as SLDev patch signing and eventual plugin signing. Dale also suggested that key trust levels could be used to differentiate between users with payment info on file, payment info used, Linden Lab employees, and so on.<br /> <br /> Phoenix Linden noted that his key is available on his wiki page and via subkeys.pgp.net. Phoenix has signed many of the LL developer keys already and notes:&lt;br /&gt;<br /> I will sign keys of people that I meet and that I prove to<br /> myself match their proposed email address.<br /> <br /> A secure and automated method of proving identity and key mappings<br /> would take a while, so no one is spending much time thinking about<br /> it. I will think about how to do this, and talk to Zero to see if<br /> there is a good way to roll that into our current Agent Domain<br /> scalability work.<br /> <br /> Until that time, I am the best gateway (aka bottleneck) for signing<br /> contributor keys.<br /> <br /> == Submitting Patches Requiring Translation Work ==<br /> Jason Giglio asked what to do about patches that included new UI text.<br /> <br /> Leyla Farazha (Linden) noted that contributors needed only make changes to the US English text. There is a process in place to detect what needs translation before release. Further:&lt;br /&gt;<br /> <br /> Help with the translation process is always welcome, and once we have<br /> set up the pipeline for that work we'll let you all know. :-)<br /> <br /> Jean Miller (Linden) requests that users please not include machine translations and noted that Linden Lab are putting together tools which would allow contributing translations for missing strings via the Wiki. Jean invited list members to contribute a snazzy format for such a wiki page.<br /> <br /> Alissa Sabre, a native Japanese speaker, noted that the Japanese translation is very poor. Jean Miller indicated that the responsible translation service was no longer in use, and that LL were aware of cleanup work to be done here. Laurent Laborde was happier with the French version, &quot;Not super-perfect, but good enough to be 100% useable.&quot;<br /> <br /> == Identifying JIRAs Needing Action ==<br /> Rob Lanphier (Linden) previously indicated that list members could help tremendously by voting on issues needing attention. Some issues are still getting lost in the volume of the public JIRA however. During Rob's office hours, Gigs Taggart pointed to a few hot issues. It was also noted that it was possible to search for JIRAs with patches attached, and that these would be good high-priority candidates.<br /> <br /> Rob indicated that LL are looking to hire someone who can help handle JIRAs and patches offered by the public.<br /> <br /> == Physics ==<br /> During Rob Lanphier's (Linden) office hours, Soft Noel inquired about why LL was using an old version of Havok for physics in Second Life. Rob explained that much user content relied on quirks and precise behaviors of the older engine. Rob hoped that coming changes in SL that make it possible to do incremental rollouts might offer a step toward phasing in a faster engine.<br /> <br /> Drewan Keats wondered if there had been any discussion about open source physics engines. There was no follow-up discussion on the point.<br /> <br /> == Adroit's Unit Testing Patches ==<br /> Soft Noel asked if anyone had been using or testing Adroit's unit testing patches. Nobody in Rob Lanphier's office hours had any positive response, though Rob pointed to the unit testing framework in use as the [http://tut-framework.sourceforge.net tut-framework]. <br /> <br /> == Rob Linden Needs a Bear ==<br /> You can't have this many in-world meetings and not have a prize at the end, just in case a meeting actually turns out to be boring and all. &quot;Oh hey, and look - FREE BEAR!&quot; is a perfect save. Does SLDev have any qualified bear makers?</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SLDev-Traffic_5_(FR)&diff=16653 2007-04-03T02:56:59Z

<p>Kerunix Flan: </p> <hr /> <div>{{SLDevTraffic}}<br /> <br /> == DO NOT EDIT ! TRANSLATION CURRENTLY IN PROGRESS == (i'm just saving from time to time :p ) [[User:Kerunix Flan|Kerunix Flan]] 19:56, 2 April 2007 (PDT)<br /> <br /> sldev-traffic (FR) no 5<br /> <br /> Discussions sur sldev depuis le 30 Mars 2007<br /> <br /> == Plante Linden Customisé ==<br /> Argent Stonecutter a remarqué que très peu de données definissent les arbres et les plantes utilisées dans Second Life. L'object entier pourrait etre specifié dans une liste et deployés de la même manière que sont deployés les particules. Cela offre la possibilité d'avoir plus de controle, via les scripts, sur les plantes et de reduire le nombre de prims utilisés.<br /> Vous pouvez trouver les détails sur le wiki (en anglais) [[Custom Linden Plants]] et sur JIRA a {{JIRA|VWR-303}}. <br /> <br /> <br /> == Modérer les logs du client==<br /> Tom &quot;Spot&quot; Callaway à exprimé son intérêt à réduire la quantité de log généré par le client. Il a trouvé une référence à logcontrol.xml et logcontrol-dev.xml mais il n'a pas pu trouver d'exemple de leurs utilisations. Ryan Williams (Linden) a écrit une page sur [[Error Logging System]]. Phoenix Linden fait remarquer que la librairie openJPEG est la plus verbeuse car elle écrit directement sur stderr, ce qui outrepasse le systeme de gesion de log. Phoenix indique aussi qu'un correctif devrait être apporté sous peu. &quot;Guido&quot; indique que {{JIRA|VWR-100}} montre comment désactiver les logs d'openJPEG en attendant.<br /> <br /> <br /> == Calmer les discussions ==<br /> La discussion continue sur le meilleur moyen de gerer les sujet generant un fort traffic. Pour l'instant, Rob Lanphier (Linden) a demandé aux utilisateurs de creer une entrée JIRA ou d'utiliser les pages de discussion wiki (talk page). Une discussion a cependant continué a propos de l'interet des talk page sur [[Talk:SLDev|SLDev Talk page]]. Rob a expliqué certains benefices a utiliser le wiki pour cela, incluant le fait que certains sujets seront encore discutés pour les mois et années a venir. Il donne l'exemple de [[Talk:Texture_cache|texture cache discussion]] qui refera certainement surface dans le futur.<br /> <br /> Rob a aussi parlé du problème des discussion qui semblent êtres plus le sujet d'un amusement que d'un travail constructif. Cela arrive souvent quand quelqu'un parle d'un sujet ou une idée sans avoir l'intention d'écrire du code et que d'autres, sans intention de programmer, prennent position sur un long débat sans pourtant produire quoi que ce soit.<br /> <br /> A propos de la séparation des sujet vers le JIRA et le wiki, certains membres ont protestés contre cette idée et ont proposés de tout garder sur la liste, d'utiliser des forums, ou plusieurs mailling lists. La discussion a aussi continuée in-world, l'idée d'une list limitée aux contributeurs qui ont signés un agrement avec LL a refait surface, ainsi que l'idée de poster des sommaires de certaines discussions in-worl sur la liste.<br /> <br /> Aucune concensus n'a été trouvé. Mais Rob a demandé aux participants d'essayer tout de même sa proposition pendant quelques semaines. Pendant son office du lundi, rob a rapporté qu'il n'a pas encore eu de retour de la part des developpeurs Linden a propos des guides d'utilisation de la list.<br /> <br /> Un point unanime est que le systeme de notification par mail du wiki doit être reparé. <br /> <br /> <br /> ----<br /> <br /> <br /> One point with unanimous agreement is that the Wiki's email notification signup system needs to be fixed. During Rob's office hours, Soft noted that if it were possible to receive an email about every change on a subscribed item, it would be functionally identical to the mailing list for those who favor the list's push format.<br /> <br /> (One note - if these discussions continue in the Wiki, people need to be better about signing comments. SLDev's Talk page was very hard to read. -- Soft)<br /> <br /> == Controlling the Build Mode ==<br /> Ettore Pasquini expressed interest in learning how the mouse and keyboard control the build mode. Specifically, Ettore is looking for &quot;which classes or functions take care of movements.&quot; Ettore is interested in hooking up a 3D controller for use in controlling build mode with high precision.<br /> <br /> There was some discussion about available controllers and even a link to a driver for using a Wiimote as an input device but to date, Ettore has no answer.<br /> <br /> == More mingw Cross-Build Work ==<br /> Dzonatas Sol posted another patch for building the Windows viewer using mingw. The [https://lists.secondlife.com/pipermail/sldev/2007-March/001324.html new patch] does not appear to be attached to an existing JIRA entry, although Dzonatas mentions that it addresses {{JIRA|VWR-186}}, {{JIRA|VWR-187}} and {{JIRA|VWR-198}}. This patch was made against First Look 58390.<br /> <br /> == Disconnected Without Warning ==<br /> Laurent Laborde noted that the user is not explicitly warned when the current simulator times out and disconnects. Callum Lerwick notes that his wife has lost hours worth of work in continuing to make changes to objects without realizing that the map has gone red. Callum suggested that an explicit dialog warning about the disconnection would work if somehow saving the data for later upload or immediately reconnecting were infeasible. Erik Anderson advocates an immediate reconnection, noting that less capable systems can take minutes to relog.<br /> <br /> == GPL v3 Released ==<br /> Dzonatas Sol noted that third draft GPL has been released. Of particular interest, the third draft removes language that required copyright holders to protect downstream licensees from patent infringements. &quot;There is now an overall clarification of how a covered work is conveyed and when one conveys such a work that one must abide by the terms of the license to disclaim patent infringement or likewise.&quot; Dzonatas indicated the wiki would be updated when more was known about these changes.<br /> <br /> == OpenJPEG - Bigger, Better, Stronger, Faster ==<br /> Callum Lerwick found a loop where an array was being zeroed in row order instead of column order. James Cook (Linden) noted that a memset would work even better than correcting the order here, as memset was guaranteed to be optimized for each platform. Stefan Westerfeld noted some work being done on cleaning up this code already and also noted the existence of an OpenJPEG optimization mailing list. Francois-Olivier Devaux, part of the OpenJPEG project, noted that a new version of OpenJPEG was imminent, and suggested that this fix could be included if someone offers a patch. Callum Lerwick followed up with a patch of work in progress.<br /> <br /> == Reading Others' Friendlists ==<br /> Marco Milanesio inquired as to whether it was possible to read other users' friendlists. There were no helpful replies for Marco Milanesio. Whether this is possible remains unanswered, though Dale Glass expressed that he hoped it would never be possible.<br /> <br /> == GPG Keysigning ==<br /> Dale Glass inquired as to whether there would be interest in LL GPG keysigning. He suggested that LL should create a master key used to sign all employees, as well as creating an automated signing mechanism running on the SL website which allowed signing against a player name or the registered account name. Dale went on to discuss various applications for the keys such as SLDev patch signing and eventual plugin signing. Dale also suggested that key trust levels could be used to differentiate between users with payment info on file, payment info used, Linden Lab employees, and so on.<br /> <br /> Phoenix Linden noted that his key is available on his wiki page and via subkeys.pgp.net. Phoenix has signed many of the LL developer keys already and notes:&lt;br /&gt;<br /> I will sign keys of people that I meet and that I prove to<br /> myself match their proposed email address.<br /> <br /> A secure and automated method of proving identity and key mappings<br /> would take a while, so no one is spending much time thinking about<br /> it. I will think about how to do this, and talk to Zero to see if<br /> there is a good way to roll that into our current Agent Domain<br /> scalability work.<br /> <br /> Until that time, I am the best gateway (aka bottleneck) for signing<br /> contributor keys.<br /> <br /> == Submitting Patches Requiring Translation Work ==<br /> Jason Giglio asked what to do about patches that included new UI text.<br /> <br /> Leyla Farazha (Linden) noted that contributors needed only make changes to the US English text. There is a process in place to detect what needs translation before release. Further:&lt;br /&gt;<br /> <br /> Help with the translation process is always welcome, and once we have<br /> set up the pipeline for that work we'll let you all know. :-)<br /> <br /> Jean Miller (Linden) requests that users please not include machine translations and noted that Linden Lab are putting together tools which would allow contributing translations for missing strings via the Wiki. Jean invited list members to contribute a snazzy format for such a wiki page.<br /> <br /> Alissa Sabre, a native Japanese speaker, noted that the Japanese translation is very poor. Jean Miller indicated that the responsible translation service was no longer in use, and that LL were aware of cleanup work to be done here. Laurent Laborde was happier with the French version, &quot;Not super-perfect, but good enough to be 100% useable.&quot;<br /> <br /> == Identifying JIRAs Needing Action ==<br /> Rob Lanphier (Linden) previously indicated that list members could help tremendously by voting on issues needing attention. Some issues are still getting lost in the volume of the public JIRA however. During Rob's office hours, Gigs Taggart pointed to a few hot issues. It was also noted that it was possible to search for JIRAs with patches attached, and that these would be good high-priority candidates.<br /> <br /> Rob indicated that LL are looking to hire someone who can help handle JIRAs and patches offered by the public.<br /> <br /> == Physics ==<br /> During Rob Lanphier's (Linden) office hours, Soft Noel inquired about why LL was using an old version of Havok for physics in Second Life. Rob explained that much user content relied on quirks and precise behaviors of the older engine. Rob hoped that coming changes in SL that make it possible to do incremental rollouts might offer a step toward phasing in a faster engine.<br /> <br /> Drewan Keats wondered if there had been any discussion about open source physics engines. There was no follow-up discussion on the point.<br /> <br /> == Adroit's Unit Testing Patches ==<br /> Soft Noel asked if anyone had been using or testing Adroit's unit testing patches. Nobody in Rob Lanphier's office hours had any positive response, though Rob pointed to the unit testing framework in use as the [http://tut-framework.sourceforge.net tut-framework]. <br /> <br /> == Rob Linden Needs a Bear ==<br /> You can't have this many in-world meetings and not have a prize at the end, just in case a meeting actually turns out to be boring and all. &quot;Oh hey, and look - FREE BEAR!&quot; is a perfect save. Does SLDev have any qualified bear makers?</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=SLDev-Traffic_4&diff=16161 2007-03-26T03:41:22Z

<p>Kerunix Flan: /* Performance part 1: Profiling */</p> <hr /> <div>{{SLDevTraffic}}<br /> <br /> sldev-traffic no 4<br /> <br /> sldev discussions through March 23, 2007<br /> <br /> == Intro ==<br /> The big discussions revolved around performance this week. I've tried to break what mostly happened in two hugely intertwined threads into component parts. Feel free to be extra picky and edit the page if you think I've obfuscated anything by breaking apart the topics.<br /> <br /> I'm also pulling more from the IRC and Rob Lanphier's (Linden) in-world office hours than in the past. Look for more of this in the future. And please don't say anything in #opensl or at Rob's office that you don't want repeated without noting it in advance. :) --[[User:Soft Noel|Soft Noel]] 14:33, 25 March 2007 (PDT)<br /> <br /> == Build Errata on Source Download Page ==<br /> There's an additional column on the [https://wiki.secondlife.com/wiki/Source_downloads source download page] for bugs that prevent building or running the viewer. If you run into a build issue, please get it into JIRA and add the bug in the new field. If you're stuck, check back to see if a bug has been added.<br /> <br /> == Unofficial SVN ==<br /> Dzonatas Sol announced a subversion repository for the viewer, including all existing public source drops. She added an intro to [[get source and compile]] and the repository is located here:&lt;br /&gt;<br /> http://oslcc.svn.sourceforge.net/svnroot/oslcc/ll/release/<br /> <br /> Rob Lanphier (Linden) noted that the official LL repository was in the works, and that at least initially it would follow a method much like the one Dzonatas was using, relying on the same source drops seen in the zips and tarballs. During his Monday office hours, Rob indicated that he knew the internal and external repository system was unusual, but hoped the hybrid approach would work until LL can sort out a better approach.<br /> <br /> The LL repository will initially be hosted with wush.net, a professional svn hosting service. Rob indicated that he wanted to see if it's something capable enough that LL's devs would feel comfortable using it for day-to-day work.<br /> <br /> == Help Prioritize JIRAs ==<br /> There are too many JIRAs for them all to be fully evaluated by LL with current resources. Please remember to vote on issues of importance. Who votes is every bit as important as the number of votes. If you're a productive voice on the mailing list, you can be a an especially productive voter as well.<br /> <br /> == Forking Big Discussions ==<br /> Rob Lanphier (Linden) requested that discussions generating more than 5 replies in a day be redirected to the JIRA to make the list easier to follow. If a topic dies down after a couple days, it's okay to bring the discussion back to the list, starting with a summary of the JIRA discussion.<br /> <br /> Topics not specifically related to Second Life development should be moved to the JIRA immediately.<br /> <br /> There was a small amount of follow-up discussion on the [https://wiki.secondlife.com/wiki/Talk:SLDev SLDev Talk page]. Dzonatas Sol seconded the suggestion while Iron Perth suggested that the wiki and JIRA were better used for documentation and bugs, but would be obstacles to discussion. Rob Linden suggested that forums could be used as an alternative target if appropriate.<br /> <br /> Of note, there was an slight drop-off in list subscriptions in the past week as the texture discussion traffic increased, mentioned during Rob's Friday office hours.<br /> <br /> == Performance part 1: Profiling ==<br /> Laurent Laborde (kerunix Flan) posted a hierarchical profile of the viewer running on his MacBook Pro and asked for some help in interpreting the output. Tielades offered a few notes. In summary: Unsurprisingly, a large amount of time is spent in OpenGL, and Tleiades noted that nVidia has a profiling tool that may shed extra light on where that time is going. There is a lot of dynamic memory freeing (presumably allocation too -- Soft) going on, and creating resource pools could help performance. LLOctreeTraveler::traverse may be a candidate for optimization -- it would be helpful to investigate how frequently render states change, and how many render batches are dispatched.<br /> <br /> Laurent performed a subsequent profile, noting that it looked like QuickTime's MCIdle was being run more often than needed and quoted some material from the Apple developer documentation detailing ways of reducing the load here. Of particular interest may be the QTGetTimeUntilNextTask, which returns the number of milliseconds until an MCIdle call is actually needed again. There was no followup discussion on this point.<br /> <br /> Laurent did another profile showing some curious STL behavior, but Dave Parks (Linden) noted that the behavior in question did not exist in release builds, only in debug.<br /> :I confirmed my mistake. The behaviour do not exist in release builds. [[User:Kerunix Flan|Kerunix Flan]] 20:41, 25 March 2007 (PDT)<br /> <br /> == Performance part 2: Multithreading ==<br /> Skal Tura asked whether any work was happening on multithreading and asked why it was difficult to do. Tleiades gave a brief primer about the types of work that could and couldn't be parallelized, the difficulties in adding parallelization to an existing object without fine-grained resource locking, and noted cases where threading could hurt performance instead of helping. Tleidas also speculated that the CPU may not be the true bottleneck for the viewer, but the amount of GPU setup if render state is too-often changed, or tiny work packets are being submitted. Tleidas emphasized the importance of measuring and isolating bottlenecks before trying to optimize.<br /> <br /> Zack Geers noted that the render pipeline is all in one thread, and other threads include disk IO and jpeg2000 decoding. (Note: You can see where all of the threads are kicked off at the top of main() in viewer.cpp; it's a little bit finer-grained than this -- Soft) Zack said he believed some thread-safety work was being done in advance of adding threading to the render pipeline.<br /> <br /> Dave Parks (Linden) stepped in with an [https://lists.secondlife.com/pipermail/sldev/2007-March/001116.html extensive post] about the performance work being done. From the end:&lt;br /&gt;<br /> <br /> In summary, the candidates for optimization are (in no particular order):<br /> - Put LLPipeline::renderGeom on its own thread<br /> - LLVertexBuffer::clientCopy - make it optimal and find the optimal <br /> location from which to call it<br /> - LLVolumeGeometryManager::rebuildGeom - build better batches, build <br /> them faster<br /> - LLOctreeTraveler::traverse - the faster the tree is, the better<br /> <br /> Honorable mention but slightly out of my domain for discussion:<br /> - Particle simulation (can't touch particle rendering, sorry). I ported <br /> the particle rendering to point sprites, but it turns out 90% of the <br /> particle systems out there won't port, so it was a wasted effort.<br /> - Avatar animation - I'm sure there's some low hanging fruit in the <br /> avatar animation system. In fact, one dev here claims it used to be a <br /> ton faster than it is, so there might be a one line bug in there slowing <br /> things down.<br /> - Flexible object updates - Ugh.<br /> <br /> With all that said, Dave implored people to make stability issues a priority. Previously, Lindens have urged the importance of researching crashes in list members' own builds. Some crashes may have never yet been seen by a Linden with a debugger active. This is one area where list members can really help.<br /> <br /> == Performance part 3: Decoded Image Cache Reset on Teleport ==<br /> In the multithreading thread, Skal Tura asked why all textures were apparently loaded again when teleporting to a new location and suggested that the slow rate at which the images were reloaded pointed to bad caching. Tateru Nino confirmed the observation by pointing to a point in code where the cache was effectively invalidated after teleporting. Steve (Linden) [https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html stepped in] with clarification and details about the in-memory cache policy, and reminded list members to look at the First Look branch when doing their own research. He suggested that a good problem to tackle would be that of teleporting to a new location, waiting ~30s, then teleporting back. The system has dropped the in-memory decoded image cache by this point. He also noted that the focus cannot be only on memory, but also the cost of tracking many many in-memory textures.<br /> <br /> == Performance part 4: JPEG2000 Decoding and Image Caching ==<br /> <br /> Laurent Laborde noted that the jpeg2000 decoding cost a lot of CPU time, and other list members confirmed the observation. There was discussion about whether the viewer used a service thread for jpeg2000 decoding, and several list members confirmed that it was, with Callum Lerwick and Dave Parks (Linden) noting that the improvement was new to the First Look branch. Dzonatas Sol noted that jpeg2000 was designed to incorporate threading though it didn't exist in the current implementation. She pointed to [[Openjpeg improvements]] for some work already begun on speeding up jpeg2000 decoding.<br /> <br /> Callum Lerwick noted that the KDU jpeg2000 decoder had functionality enabling it to decode for a number of milliseconds and then return, functionality openjpeg lacks. Douglas Soo (Linden) noted that he had added this himself as the threading quantum was large on some OSes, and on systems with more active threads than cores, there would be marked choppiness without voluntarily relinquishing a time slice. Adding this functionality to openjpeg could help considerably on low-end systems if openjpeg is decoding images to completion and enjoying preferential scheduling owing to its irregular load.<br /> <br /> From here, the thread bloomed into a very extensive discussion about how already-decoded images could be cached and whether they should be. It was noted that the textures are all of similar fixed sizes which could specify a specialized fragmentation-resistant cache layout, and that they all had unique IDs already, which made one proposed relational database or any kind of hashing unnecessary for their tracking.<br /> <br /> As an alternative to decoded image caching, list members also explored the idea of caching images in an alternative file format, either as a permanent local replacement for jpeg2000, or as an interim format for lower resolution images while the full resolution images were still being decoded.<br /> <br /> Discussion continued on the [https://wiki.secondlife.com/wiki/Talk:Texture_cache texture cache talk page].<br /> <br /> == Performance part 5: Performance Degrading Over Time ==<br /> In the multithreading thread, Skal Tura noted that SL takes more and more memory over time, and runs perceptibly slower. No measurements were given. SLDev listmembers came down on both sides of whether this performance degradation existed. Skal Tura noted that he runs for ten hours or more at a time, and by this point there were visible pauses on a very high end machine.<br /> <br /> == Performance part 6: How Low Do You Go? ==<br /> There was discussion about SL targeting very low end machines, and about whether it would be advantageous to raise the bar a bit. Laptops, low-end macs still on the market today, international (third-world) users and those on fixed budgets were all mentioned. Some list members also noted that they were sticking with earlier versions of Windows and wanted to avoid anything that might force them to upgrade.<br /> <br /> == gcc4 Fix ==<br /> Ismail Dönmez followed the First Look 1.13.3.59315 release with a minor patch for gcc4 support, quipping that someone at Linden Lab must hate gcc4. Jesse Nesbitt noted that getting these into the JIRA would help. Ismail obliged and Tofu Linden accepted and applied it:&lt;br /&gt;<br /> https://jira.secondlife.com/browse/VWR-255 (no internal JIRA)<br /> <br /> == XUL Editor ==<br /> Vincent Capuano inquired about whether there was an approach to editing the XUL (user interface markup) XML files other than hand-hacking XML. John Hurliman said LL developers had previously stated that they edited by hand. Tinker LaFollette and Synthalor Mandelbrot suggested XML editors that might be a step above straight editing:&lt;br /&gt;<br /> http://www.activestate.com/products/komodo_edit/ (all platforms)&lt;br /&gt;<br /> http://symbolclick.com/index.htm (Windows)<br /> <br /> == GPL'd Submissions ==<br /> This thread began in the week prior, but was still continuing when SLDev-Traffic 3 was written. It has since tapered off.<br /> <br /> There was extensive about whether and how Linden Lab could accept patches with a GPL license attached. A prior message from Rob Linden was quoted wherein he thanked Alynna for a submission but noted that the viewer has GPL-incompatible components, and so the patch could not be incorporated. Further confusion seemed to stem from contributors not understanding dual licensing, wherein Linden Lab providing the viewer source to the public under the GPL doesn't necessarily mean LL will use the GPL license for their own builds, which include non-free libraries.<br /> <br /> Discussion continued in-world during Rob Lanphier's (Linden) Wednesday office hours. Dzonatas Sol wanted guidance on whether she could contribute some GPLd code. Rob said the code could be used by Dzonatas, but not submitted to Linden Lab under GPL. Discussion continued about whether the code, owned by Dzonatas Sol, could be relicensed in a way compatible with LL's needs and Dzonatas' needs alike. Rob asked Dzonatas to lay out the issue in the JIRA and then forward the request to LL licensing.<br /> <br /> On-list again, Jason Giglio listed the non-free libraries that would currently prevent distributing an all-free version of the client. These included:&lt;br/&gt;<br /> APR<br /> *Cg<br /> FMOD<br /> Kakadu<br /> OpenSSL<br /> SmartHeap<br /> SpeedTree<br /> <br /> Callum Lerwick detailed substitutions and work-arounds for most of the above, pointing to APR and OpenSSL as the most substantial blockers.<br /> <br /> Argent Stonecutter noted that QuickTime was not on the list, but probably should be. While GPL allows linking to libraries distributed with the OS, QT is only distributed with OS X, not with Windows.<br /> <br /> == Unit Test Harness: Patch 4 ==<br /> Gaurav Sharma posted the fourth Adroit unit test harness. This week it properly appears in the list archives:&lt;br /&gt;<br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001254.html<br /> <br /> == QuickTime Replacement ==<br /> Linden Lab are investigating a replacement for QuickTime under Linux -- currently gstreamer, as mentioned during Rob Lanphier's (Linden) Friday office hours. One obstacle is that many .mov files are actually Sorenson video CODEC files, not mpeg4 H.264 CODEC files as many users believed they were. Current .mov is mostly H.264, but there may be other catches.</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=16096 2007-03-25T10:48:00Z

<p>Kerunix Flan: /* Databases */</p> <hr /> <div>{{Talk}}<br /> <br /> == GIF ==<br /> <br /> We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies] -- {{User|kerunix Flan}}<br /> <br /> : The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. [[User:Seg Baphomet|Seg Baphomet]] 22:45, 23 March 2007 (PDT)<br /> <br /> : The GIF format is not suitable. It only supports 256 colors per frame. It does not support semi-transparent pixels. PNG is a superior format. Has anyone considered the time required to re-encode images in the target format? [[User:Strife Onizuka|Strife Onizuka]] 09:42, 24 March 2007 (PDT)<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> : APR = [http://apr.apache.org/ Apache Portable Runtime] ? If yes, i can't find any interface to common databases in the APR documentation. [[User:Kerunix Flan|Kerunix Flan]] 03:48, 25 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie. [[User:Iron Perth|Iron Perth]] 03:00, 23 March 2007 (PDT)<br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.{{unsigned|kerunix Flan}}<br /> <br /> :Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. [[User:Strife Onizuka|Strife Onizuka]] 02:22, 24 March 2007 (PDT)<br /> <br /> <br /> == Faster Formats ==<br /> Contribution from Tofu Linden from the email discussion<br /> <br /> RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.<br /> [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT)<br /> <br /> :And as said on the mailling, the destructive effect of JPEG2000 probably killed any chance to have a good compression rate using RLE. RLE is fast and the only compression supported by the Targavision specification. If we don't use it (probably because it's useless) then don't use compression at all. One of the advantage of using RLE like said in the specification is that we don't have to decompress anything to read the header, developer area, and footer. [[User:Kerunix Flan|Kerunix Flan]] 08:02, 24 March 2007 (PDT)<br /> <br /> ::I think I missed the bit about &quot;the destructive effect of JPEG2000&quot; on the list. Currently lossy compression is only used when the source is a JPEG and lossless for BMP and TGA. The point of using a format like JPEG2000 is that it achieves high compression ratios superior to other formats for the same image quality. For modern codecs to achieves high compression ratios they sacrifice CPU time. The reason for the push for higher ratios is to reduce the amount of storage and bandwidth required for transmission. If SL moves away from using JPEG2000 and towards a less CPU intensive, lower compression ratio codec, the asset servers will be serving more data per asset request. This seems like a step backwards and not forwards. As an intermediate format to save CPU time to avert the costly re-decoding of an image, it makes sense to pick a faster format though it will be costly in diskspace; and as long as the disk is not horibly fragmented it has the potential to be faster then decoding. A format needs to fit these criteria to be considered for this task:<br /> ::#Lossless<br /> ::#Support a variable number of channels.<br /> ::#Fast to encode, fast to decode<br /> ::#Preferably GPL compatible.<br /> ::This excludes: GIF &amp; JPEG. This may also exclude PNG because most implementations treat anything that is fully transparent as rgba(0,0,0,0); white images develop black outlines at low resolutions (not lossless). [[User:Strife Onizuka|Strife Onizuka]] 21:08, 24 March 2007 (PDT)<br /> <br /> :::We talked about at least 2 kind of local cache :<br /> :::#Compressed texture cache : Obviously, it should be just a storage for the jpeg2000 sent by the sim. Why recoding ? (and lose quality ?)<br /> :::#Uncompressed texture cache : storing some texture already decoded, so the client don't have to lose time decoding it when needed. For me, the best format is TGA. [[User:Kerunix Flan|Kerunix Flan]] 03:31, 25 March 2007 (PDT)<br /> <br /> == Current Caching ==<br /> <br /> Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..<br /> <br /> Contribution from Steve Linden from email discussion:<br /> <br /> 2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:<br /> <br /> a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)<br /> <br /> b. Once a frame, reduce the current pixel coverage of all textures by 10%.<br /> <br /> This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code &quot;assume that all textures are no longer visible&quot; and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.<br /> <br /> 3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.<br /> <br /> :do that mean that, even if we have a lot of VRAM available, the texture will be removed from cache if we don't see the texture for 30s ? and then, moving our avatar in the sim will make the client redecoding the texture from cache to load it in VRAM again ? Why not discarding the texture only when we're out of memory ? (''please delete/replace this comment by the answer'') [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> 4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client &gt; Rendering &gt; Run Multiple Threads, the decoding will be done on the second CPU and go much faster.<br /> <br /> :I can't believe loading a texture from a remote cache isn't much slower than loading a texture from a local cache. And if you add the usual packet loss and high ping (for non-us user) it's *certainly* much slower. [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:<br /> <br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT)<br /> <br /> <br /> == Home Cache ==<br /> <br /> If a resident has a home, why not have a separate texture cache for it, a ''Home Cache''. This cache would only be explicitly cleared down and would be accessed first by the client when the resident logs on or teleports home.<br /> <br /> Once populated with textures, each logon/teleport to home would not involve network traffic, as they would be available locally, on the client.<br /> <br /> [[User:Benja Kepler|Benja Kepler]] 02:52, 24 March 2007 (PDT)<br /> <br /> :A similar idea would be to have a hit count on textures. The hit count can be kept around much longer than the texture data. The hit count would be used to indicate what textures to keep in the cache longer. [[User:Dzonatas Sol|Dzonatas Sol]] 12:53, 24 March 2007 (PDT)<br /> <br /> ::We probably don't want to invent our own caching system, since this type of thing gets studied a lot. Looking around, at what other projects are doing (e.g. PostgreSQL, Linux), I found this replacement for the LRU scheme used today: [http://www.vldb.org/dblp/db/conf/vldb/vldb94-439.html 2Q cache system]. This balances hit frequency and hit recency to determine whether to eject something from the cache. -- [[User:Rob Linden|Rob Linden]] 23:34, 24 March 2007 (PDT)<br /> <br /> == Textures in Inventory ==<br /> <br /> A search through the avatar's inventory is a good indication of what textures to keep around longer in the cache than others. [[User:Dzonatas Sol|Dzonatas Sol]] 12:50, 24 March 2007 (PDT)<br /> <br /> :I can't agree with this. I have many textures that I rarely see in-world. I don't think it merits extra attention. [[User:Strife Onizuka|Strife Onizuka]] 22:59, 24 March 2007 (PDT)<br /> <br /> == Plan: Normalization of Texture Usage ==<br /> <br /> A method to keep the statistics of pixel coverage and hit rates: We use a collection of hit counters such that each represents an individual entry for an associated texture. When any hit counter hits a threshold, the collection is normalized and the results are stored in each associated hit-rate fields of the entry. The hit-rate fields may store percentages for short term and long term storage. The short term and long term storage indicators present a value for determination in how textures are archived or disposed. Pixel-coverage rates are optional fields in each entry for determination of an optimal storage medium for texture data such that the medium is represented in uncompressed or compressed methods and if the stored texture is downsampled and to what degree it is downsampled. [[User:Dzonatas Sol|Dzonatas Sol]] 17:05, 24 March 2007 (PDT)<br /> <br /> :I think this would result in decreased performance as a lot of time would be spent incrementing hit counters. [[User:Strife Onizuka|Strife Onizuka]] 22:57, 24 March 2007 (PDT)<br /> ::How hit counters are incremented have not been analyzed for implementation. This is just a general plan independent of any specific implementation. [[User:Dzonatas Sol|Dzonatas Sol]] 23:03, 24 March 2007 (PDT)<br /> <br /> == Idea: Keep a cache index ==<br /> <br /> Keep an on-disk index of cache files. This could be made compact and small enough to fully into RAM. The index would allow to know whether a file is in the cache, thus avoiding trying to open a file if the current way of storing a texture in its own file is kept.<br /> <br /> Additionally, store some metadata with: filesize, md5sum, and a very rough texture approximation (perhaps even limited to a solid color) to have something better than the current grey.<br /> <br /> Filesize and md5sum would allow to check the on-disk files' integrity, which should avoid any need to clear the cache, as correctness could be automatically verified.<br /> <br /> My suggested format for the index is Berkeley DB, which is simple and compact, and is ACID compliant, which should ensure the integrity of the index. [[User:Dale Glass|Dale Glass]] 15:39, 24 March 2007 (PDT)<br /> <br /> :The old VFS used an index, while it didn't keep a hash of the asset it did track access date. If you are going to be using a DB on top of the cache, you might as well put the entire cache in a single file and save on file system IO. Why? After all a VFS is just a database of sorts and regardless you have to search the DB or the FS for the file. There were two problems with the old VFS: slow to find data in the index and slow to decode images (this isn't the fault of the VFS). A well designed VFS should be able to out perform any FS (because it doesn't have to perform locks). [[User:Strife Onizuka|Strife Onizuka]] 19:12, 24 March 2007 (PDT)<br /> ::The filesystem is already an entirely suitable way of keeping data like textures. It does have a few problems for example, such as that searching for a file in a directory may be relatively expensive. This can be easily compensated for with a small DB used only to compensate for those shortcomings. A full VFS-like thing is a lot more complex, you basically have to write your own mini-filesystem, and as we've seen, that's hard to do well. Berkeley DB is especially nice in that it's ACID - you have a guarantee of that data in it is consistent, unlike with the VFS (unless you go and code that in, but that takes time). Also, by keeping a collection of small items of data of a fixed size you avoid internal fragmentation, which is something you'd have to deal with a VFS-like approach. If you store textures as files, just use the system defragmenter. [[User:Dale Glass|Dale Glass]] 19:43, 24 March 2007 (PDT)<br /> :::*How would having a Berkeley DB solve the problem of searches being slow? Would it be faster then a std::map.find()? How well does it's search alg scale?<br /> :::The old VFS did have a bit of a problem with free space fragmentation. Writing a quick and dirty defragmentation utility for it is not a difficult task (at one point i wrote a utility for converting the cache into a tar archive, the output couldn't have fragmented free space). Remember, we already have a VFS, we don't have an integrated Berkeley DB. [[User:Strife Onizuka|Strife Onizuka]] 22:20, 24 March 2007 (PDT)<br /> <br /> == Idea: Keep a texture map for every sim ==<br /> <br /> Currently, dual core CPUs have a large amount of spare time on the second core while they're not actively fetching textures. I propose a way of using this spare time.<br /> <br /> The viewer would create a database per visited sim with a list of textures found in each location. This database would allow the viewer to know what textures can be found in nearby areas, even before the grid has transmitted the data about them. Then, when idle, the viewer could use the spare time to start loading textures from the surrounding areas, so that they are instantly available when the avatar moves.<br /> <br /> My suggested way of doing that is using a Berkeley DB database to store the data. A simple way of storing the data would be making the key the position inside the sim, rounded to for example multiples of 16 meters. The data stored for that key would be a list of textures used in that area.<br /> <br /> For example, the position (120,90,56) when rounded to multiples to 16m translates to (112, 80, 48). Under key &quot;112,80,48&quot; the viewer would store a list of textures used inside that 16x16x16 area.<br /> <br /> This should make several optimizations possible:<br /> * When teleporting to a new area, decoding of textures can be started before the grid had time to transmit the required information. It should be possible to start loading textures immediately after the user starts the teleport, while the progress bar is still being shown.<br /> <br /> * When the avatar moves around, the viewer could start decoding textures likely to be present in locations about which there's no data available yet. This might make flying less painful.<br /> <br /> * If a storage method like the VFS, which stores multiple textures in a file is chosen, then having this data available could make it possible to optimize the placement of the texture data on disk, for optimal loading. [[User:Dale Glass|Dale Glass]] 15:39, 24 March 2007 (PDT)<br /> <br /> :&lt;br/&gt;Stupid question: Why not just have the sim send the object definitions too? You can glean UUIDs for the images from the objects. Then you don't have to ask the sim for the objects too. Wait but isn't that just the same as looking in all directions at the same time (but only rendering what is infront of the camera). The great part about just asking for the object definitions is that there already is code inplace for caching those definitions. No need to hack in an entirely new DB. Silly question: Is this an efficient way to spend sim CPU time: Serving assets not in view and in directions other then that the user is pointing? Downloading textures while the client is in TP is a bad idea; what if the user doesn't have access to the sim (it takes some time for TP's to fail)? It would be a bad thing for say SAP to try to TP into Oracle's private sim (knowing full well that the TP would fail) in an attempt to glean insider information via texture pre-caching ([http://www.betanews.com/article/Oracle_Accuses_SAP_of_Massive_Corporate_Theft/1174664992 linky]). [[User:Strife Onizuka|Strife Onizuka]] 19:34, 24 March 2007 (PDT)<br /> ::Sorry, I don't think I succeeded at getting the idea across. It wouldn't involve requesting anything extra from the sim. The idea is that the viewer would compile a database of texture usage inside sims you visited, so when you started teleporting to a sim, it could look in its database and start preloading images from its '''cache''' that are likely to be found in the place you're teleporting to. Basically, instead of waiting for the sim to tell you what's there and then loading the images, it would load from the cache things that are likely to be there (as sims don't change all that often), and when the sim does finally give you the data, you'd already have a part of the images decoded and ready to show. If you visited a place in the past, I think there should be a very good chance of mostly correctly guessing the textures needed to render it.<br /> <br /> ::SAP problem wouldn't happen because the mechanism would work based on information you previously got, so you'd have to have been to the place before for it to work. [[User:Dale Glass|Dale Glass]] 19:56, 24 March 2007 (PDT)<br /> <br /> :::Ahhh its' a passive solution. What you want could be archived without a special DB; the client already collects this information in the sim-object cache. For TPing, it could be done quite easily. The viewer just needs to load the data from the object cache and render it. This would cause the appropriate functions to be called to decode and request missing assets. It doesn't need to render it to the screen, just an extra buffer.&lt;br/&gt;Doing a fake render is probably the easiest, most efficient and most accurate way of doing this. A major issue with building a separate DB is you have to build the dynamic octrees for it. By using the rendering pipeline with the object cache you don't have to write new code to do this. [[User:Strife Onizuka|Strife Onizuka]] 22:51, 24 March 2007 (PDT)<br /> <br /> [[Category:Future Roundtables]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=16095 2007-03-25T10:47:24Z

<p>Kerunix Flan: link to &quot;APR&quot; needed.</p> <hr /> <div>{{Talk}}<br /> <br /> == GIF ==<br /> <br /> We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies] -- {{User|kerunix Flan}}<br /> <br /> : The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. [[User:Seg Baphomet|Seg Baphomet]] 22:45, 23 March 2007 (PDT)<br /> <br /> : The GIF format is not suitable. It only supports 256 colors per frame. It does not support semi-transparent pixels. PNG is a superior format. Has anyone considered the time required to re-encode images in the target format? [[User:Strife Onizuka|Strife Onizuka]] 09:42, 24 March 2007 (PDT)<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> : APR = [http://apr.apache.org/ Apache Portable Runtime] ? If yes, i can't find any interface to common databases in the APR documentation.<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie. [[User:Iron Perth|Iron Perth]] 03:00, 23 March 2007 (PDT)<br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.{{unsigned|kerunix Flan}}<br /> <br /> :Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. [[User:Strife Onizuka|Strife Onizuka]] 02:22, 24 March 2007 (PDT)<br /> <br /> <br /> == Faster Formats ==<br /> Contribution from Tofu Linden from the email discussion<br /> <br /> RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.<br /> [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT)<br /> <br /> :And as said on the mailling, the destructive effect of JPEG2000 probably killed any chance to have a good compression rate using RLE. RLE is fast and the only compression supported by the Targavision specification. If we don't use it (probably because it's useless) then don't use compression at all. One of the advantage of using RLE like said in the specification is that we don't have to decompress anything to read the header, developer area, and footer. [[User:Kerunix Flan|Kerunix Flan]] 08:02, 24 March 2007 (PDT)<br /> <br /> ::I think I missed the bit about &quot;the destructive effect of JPEG2000&quot; on the list. Currently lossy compression is only used when the source is a JPEG and lossless for BMP and TGA. The point of using a format like JPEG2000 is that it achieves high compression ratios superior to other formats for the same image quality. For modern codecs to achieves high compression ratios they sacrifice CPU time. The reason for the push for higher ratios is to reduce the amount of storage and bandwidth required for transmission. If SL moves away from using JPEG2000 and towards a less CPU intensive, lower compression ratio codec, the asset servers will be serving more data per asset request. This seems like a step backwards and not forwards. As an intermediate format to save CPU time to avert the costly re-decoding of an image, it makes sense to pick a faster format though it will be costly in diskspace; and as long as the disk is not horibly fragmented it has the potential to be faster then decoding. A format needs to fit these criteria to be considered for this task:<br /> ::#Lossless<br /> ::#Support a variable number of channels.<br /> ::#Fast to encode, fast to decode<br /> ::#Preferably GPL compatible.<br /> ::This excludes: GIF &amp; JPEG. This may also exclude PNG because most implementations treat anything that is fully transparent as rgba(0,0,0,0); white images develop black outlines at low resolutions (not lossless). [[User:Strife Onizuka|Strife Onizuka]] 21:08, 24 March 2007 (PDT)<br /> <br /> :::We talked about at least 2 kind of local cache :<br /> :::#Compressed texture cache : Obviously, it should be just a storage for the jpeg2000 sent by the sim. Why recoding ? (and lose quality ?)<br /> :::#Uncompressed texture cache : storing some texture already decoded, so the client don't have to lose time decoding it when needed. For me, the best format is TGA. [[User:Kerunix Flan|Kerunix Flan]] 03:31, 25 March 2007 (PDT)<br /> <br /> == Current Caching ==<br /> <br /> Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..<br /> <br /> Contribution from Steve Linden from email discussion:<br /> <br /> 2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:<br /> <br /> a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)<br /> <br /> b. Once a frame, reduce the current pixel coverage of all textures by 10%.<br /> <br /> This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code &quot;assume that all textures are no longer visible&quot; and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.<br /> <br /> 3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.<br /> <br /> :do that mean that, even if we have a lot of VRAM available, the texture will be removed from cache if we don't see the texture for 30s ? and then, moving our avatar in the sim will make the client redecoding the texture from cache to load it in VRAM again ? Why not discarding the texture only when we're out of memory ? (''please delete/replace this comment by the answer'') [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> 4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client &gt; Rendering &gt; Run Multiple Threads, the decoding will be done on the second CPU and go much faster.<br /> <br /> :I can't believe loading a texture from a remote cache isn't much slower than loading a texture from a local cache. And if you add the usual packet loss and high ping (for non-us user) it's *certainly* much slower. [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:<br /> <br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT)<br /> <br /> <br /> == Home Cache ==<br /> <br /> If a resident has a home, why not have a separate texture cache for it, a ''Home Cache''. This cache would only be explicitly cleared down and would be accessed first by the client when the resident logs on or teleports home.<br /> <br /> Once populated with textures, each logon/teleport to home would not involve network traffic, as they would be available locally, on the client.<br /> <br /> [[User:Benja Kepler|Benja Kepler]] 02:52, 24 March 2007 (PDT)<br /> <br /> :A similar idea would be to have a hit count on textures. The hit count can be kept around much longer than the texture data. The hit count would be used to indicate what textures to keep in the cache longer. [[User:Dzonatas Sol|Dzonatas Sol]] 12:53, 24 March 2007 (PDT)<br /> <br /> ::We probably don't want to invent our own caching system, since this type of thing gets studied a lot. Looking around, at what other projects are doing (e.g. PostgreSQL, Linux), I found this replacement for the LRU scheme used today: [http://www.vldb.org/dblp/db/conf/vldb/vldb94-439.html 2Q cache system]. This balances hit frequency and hit recency to determine whether to eject something from the cache. -- [[User:Rob Linden|Rob Linden]] 23:34, 24 March 2007 (PDT)<br /> <br /> == Textures in Inventory ==<br /> <br /> A search through the avatar's inventory is a good indication of what textures to keep around longer in the cache than others. [[User:Dzonatas Sol|Dzonatas Sol]] 12:50, 24 March 2007 (PDT)<br /> <br /> :I can't agree with this. I have many textures that I rarely see in-world. I don't think it merits extra attention. [[User:Strife Onizuka|Strife Onizuka]] 22:59, 24 March 2007 (PDT)<br /> <br /> == Plan: Normalization of Texture Usage ==<br /> <br /> A method to keep the statistics of pixel coverage and hit rates: We use a collection of hit counters such that each represents an individual entry for an associated texture. When any hit counter hits a threshold, the collection is normalized and the results are stored in each associated hit-rate fields of the entry. The hit-rate fields may store percentages for short term and long term storage. The short term and long term storage indicators present a value for determination in how textures are archived or disposed. Pixel-coverage rates are optional fields in each entry for determination of an optimal storage medium for texture data such that the medium is represented in uncompressed or compressed methods and if the stored texture is downsampled and to what degree it is downsampled. [[User:Dzonatas Sol|Dzonatas Sol]] 17:05, 24 March 2007 (PDT)<br /> <br /> :I think this would result in decreased performance as a lot of time would be spent incrementing hit counters. [[User:Strife Onizuka|Strife Onizuka]] 22:57, 24 March 2007 (PDT)<br /> ::How hit counters are incremented have not been analyzed for implementation. This is just a general plan independent of any specific implementation. [[User:Dzonatas Sol|Dzonatas Sol]] 23:03, 24 March 2007 (PDT)<br /> <br /> == Idea: Keep a cache index ==<br /> <br /> Keep an on-disk index of cache files. This could be made compact and small enough to fully into RAM. The index would allow to know whether a file is in the cache, thus avoiding trying to open a file if the current way of storing a texture in its own file is kept.<br /> <br /> Additionally, store some metadata with: filesize, md5sum, and a very rough texture approximation (perhaps even limited to a solid color) to have something better than the current grey.<br /> <br /> Filesize and md5sum would allow to check the on-disk files' integrity, which should avoid any need to clear the cache, as correctness could be automatically verified.<br /> <br /> My suggested format for the index is Berkeley DB, which is simple and compact, and is ACID compliant, which should ensure the integrity of the index. [[User:Dale Glass|Dale Glass]] 15:39, 24 March 2007 (PDT)<br /> <br /> :The old VFS used an index, while it didn't keep a hash of the asset it did track access date. If you are going to be using a DB on top of the cache, you might as well put the entire cache in a single file and save on file system IO. Why? After all a VFS is just a database of sorts and regardless you have to search the DB or the FS for the file. There were two problems with the old VFS: slow to find data in the index and slow to decode images (this isn't the fault of the VFS). A well designed VFS should be able to out perform any FS (because it doesn't have to perform locks). [[User:Strife Onizuka|Strife Onizuka]] 19:12, 24 March 2007 (PDT)<br /> ::The filesystem is already an entirely suitable way of keeping data like textures. It does have a few problems for example, such as that searching for a file in a directory may be relatively expensive. This can be easily compensated for with a small DB used only to compensate for those shortcomings. A full VFS-like thing is a lot more complex, you basically have to write your own mini-filesystem, and as we've seen, that's hard to do well. Berkeley DB is especially nice in that it's ACID - you have a guarantee of that data in it is consistent, unlike with the VFS (unless you go and code that in, but that takes time). Also, by keeping a collection of small items of data of a fixed size you avoid internal fragmentation, which is something you'd have to deal with a VFS-like approach. If you store textures as files, just use the system defragmenter. [[User:Dale Glass|Dale Glass]] 19:43, 24 March 2007 (PDT)<br /> :::*How would having a Berkeley DB solve the problem of searches being slow? Would it be faster then a std::map.find()? How well does it's search alg scale?<br /> :::The old VFS did have a bit of a problem with free space fragmentation. Writing a quick and dirty defragmentation utility for it is not a difficult task (at one point i wrote a utility for converting the cache into a tar archive, the output couldn't have fragmented free space). Remember, we already have a VFS, we don't have an integrated Berkeley DB. [[User:Strife Onizuka|Strife Onizuka]] 22:20, 24 March 2007 (PDT)<br /> <br /> == Idea: Keep a texture map for every sim ==<br /> <br /> Currently, dual core CPUs have a large amount of spare time on the second core while they're not actively fetching textures. I propose a way of using this spare time.<br /> <br /> The viewer would create a database per visited sim with a list of textures found in each location. This database would allow the viewer to know what textures can be found in nearby areas, even before the grid has transmitted the data about them. Then, when idle, the viewer could use the spare time to start loading textures from the surrounding areas, so that they are instantly available when the avatar moves.<br /> <br /> My suggested way of doing that is using a Berkeley DB database to store the data. A simple way of storing the data would be making the key the position inside the sim, rounded to for example multiples of 16 meters. The data stored for that key would be a list of textures used in that area.<br /> <br /> For example, the position (120,90,56) when rounded to multiples to 16m translates to (112, 80, 48). Under key &quot;112,80,48&quot; the viewer would store a list of textures used inside that 16x16x16 area.<br /> <br /> This should make several optimizations possible:<br /> * When teleporting to a new area, decoding of textures can be started before the grid had time to transmit the required information. It should be possible to start loading textures immediately after the user starts the teleport, while the progress bar is still being shown.<br /> <br /> * When the avatar moves around, the viewer could start decoding textures likely to be present in locations about which there's no data available yet. This might make flying less painful.<br /> <br /> * If a storage method like the VFS, which stores multiple textures in a file is chosen, then having this data available could make it possible to optimize the placement of the texture data on disk, for optimal loading. [[User:Dale Glass|Dale Glass]] 15:39, 24 March 2007 (PDT)<br /> <br /> :&lt;br/&gt;Stupid question: Why not just have the sim send the object definitions too? You can glean UUIDs for the images from the objects. Then you don't have to ask the sim for the objects too. Wait but isn't that just the same as looking in all directions at the same time (but only rendering what is infront of the camera). The great part about just asking for the object definitions is that there already is code inplace for caching those definitions. No need to hack in an entirely new DB. Silly question: Is this an efficient way to spend sim CPU time: Serving assets not in view and in directions other then that the user is pointing? Downloading textures while the client is in TP is a bad idea; what if the user doesn't have access to the sim (it takes some time for TP's to fail)? It would be a bad thing for say SAP to try to TP into Oracle's private sim (knowing full well that the TP would fail) in an attempt to glean insider information via texture pre-caching ([http://www.betanews.com/article/Oracle_Accuses_SAP_of_Massive_Corporate_Theft/1174664992 linky]). [[User:Strife Onizuka|Strife Onizuka]] 19:34, 24 March 2007 (PDT)<br /> ::Sorry, I don't think I succeeded at getting the idea across. It wouldn't involve requesting anything extra from the sim. The idea is that the viewer would compile a database of texture usage inside sims you visited, so when you started teleporting to a sim, it could look in its database and start preloading images from its '''cache''' that are likely to be found in the place you're teleporting to. Basically, instead of waiting for the sim to tell you what's there and then loading the images, it would load from the cache things that are likely to be there (as sims don't change all that often), and when the sim does finally give you the data, you'd already have a part of the images decoded and ready to show. If you visited a place in the past, I think there should be a very good chance of mostly correctly guessing the textures needed to render it.<br /> <br /> ::SAP problem wouldn't happen because the mechanism would work based on information you previously got, so you'd have to have been to the place before for it to work. [[User:Dale Glass|Dale Glass]] 19:56, 24 March 2007 (PDT)<br /> <br /> :::Ahhh its' a passive solution. What you want could be archived without a special DB; the client already collects this information in the sim-object cache. For TPing, it could be done quite easily. The viewer just needs to load the data from the object cache and render it. This would cause the appropriate functions to be called to decode and request missing assets. It doesn't need to render it to the screen, just an extra buffer.&lt;br/&gt;Doing a fake render is probably the easiest, most efficient and most accurate way of doing this. A major issue with building a separate DB is you have to build the dynamic octrees for it. By using the rendering pipeline with the object cache you don't have to write new code to do this. [[User:Strife Onizuka|Strife Onizuka]] 22:51, 24 March 2007 (PDT)<br /> <br /> [[Category:Future Roundtables]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=16094 2007-03-25T10:31:06Z

<p>Kerunix Flan: /* Faster Formats */</p> <hr /> <div>{{Talk}}<br /> <br /> == GIF ==<br /> <br /> We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies] -- {{User|kerunix Flan}}<br /> <br /> : The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. [[User:Seg Baphomet|Seg Baphomet]] 22:45, 23 March 2007 (PDT)<br /> <br /> : The GIF format is not suitable. It only supports 256 colors per frame. It does not support semi-transparent pixels. PNG is a superior format. Has anyone considered the time required to re-encode images in the target format? [[User:Strife Onizuka|Strife Onizuka]] 09:42, 24 March 2007 (PDT)<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie. [[User:Iron Perth|Iron Perth]] 03:00, 23 March 2007 (PDT)<br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.{{unsigned|kerunix Flan}}<br /> <br /> :Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. [[User:Strife Onizuka|Strife Onizuka]] 02:22, 24 March 2007 (PDT)<br /> <br /> <br /> == Faster Formats ==<br /> Contribution from Tofu Linden from the email discussion<br /> <br /> RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.<br /> [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT)<br /> <br /> :And as said on the mailling, the destructive effect of JPEG2000 probably killed any chance to have a good compression rate using RLE. RLE is fast and the only compression supported by the Targavision specification. If we don't use it (probably because it's useless) then don't use compression at all. One of the advantage of using RLE like said in the specification is that we don't have to decompress anything to read the header, developer area, and footer. [[User:Kerunix Flan|Kerunix Flan]] 08:02, 24 March 2007 (PDT)<br /> <br /> ::I think I missed the bit about &quot;the destructive effect of JPEG2000&quot; on the list. Currently lossy compression is only used when the source is a JPEG and lossless for BMP and TGA. The point of using a format like JPEG2000 is that it achieves high compression ratios superior to other formats for the same image quality. For modern codecs to achieves high compression ratios they sacrifice CPU time. The reason for the push for higher ratios is to reduce the amount of storage and bandwidth required for transmission. If SL moves away from using JPEG2000 and towards a less CPU intensive, lower compression ratio codec, the asset servers will be serving more data per asset request. This seems like a step backwards and not forwards. As an intermediate format to save CPU time to avert the costly re-decoding of an image, it makes sense to pick a faster format though it will be costly in diskspace; and as long as the disk is not horibly fragmented it has the potential to be faster then decoding. A format needs to fit these criteria to be considered for this task:<br /> ::#Lossless<br /> ::#Support a variable number of channels.<br /> ::#Fast to encode, fast to decode<br /> ::#Preferably GPL compatible.<br /> ::This excludes: GIF &amp; JPEG. This may also exclude PNG because most implementations treat anything that is fully transparent as rgba(0,0,0,0); white images develop black outlines at low resolutions (not lossless). [[User:Strife Onizuka|Strife Onizuka]] 21:08, 24 March 2007 (PDT)<br /> <br /> :::We talked about at least 2 kind of local cache :<br /> :::#Compressed texture cache : Obviously, it should be just a storage for the jpeg2000 sent by the sim. Why recoding ? (and lose quality ?)<br /> :::#Uncompressed texture cache : storing some texture already decoded, so the client don't have to lose time decoding it when needed. For me, the best format is TGA. [[User:Kerunix Flan|Kerunix Flan]] 03:31, 25 March 2007 (PDT)<br /> <br /> == Current Caching ==<br /> <br /> Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..<br /> <br /> Contribution from Steve Linden from email discussion:<br /> <br /> 2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:<br /> <br /> a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)<br /> <br /> b. Once a frame, reduce the current pixel coverage of all textures by 10%.<br /> <br /> This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code &quot;assume that all textures are no longer visible&quot; and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.<br /> <br /> 3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.<br /> <br /> :do that mean that, even if we have a lot of VRAM available, the texture will be removed from cache if we don't see the texture for 30s ? and then, moving our avatar in the sim will make the client redecoding the texture from cache to load it in VRAM again ? Why not discarding the texture only when we're out of memory ? (''please delete/replace this comment by the answer'') [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> 4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client &gt; Rendering &gt; Run Multiple Threads, the decoding will be done on the second CPU and go much faster.<br /> <br /> :I can't believe loading a texture from a remote cache isn't much slower than loading a texture from a local cache. And if you add the usual packet loss and high ping (for non-us user) it's *certainly* much slower. [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:<br /> <br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT)<br /> <br /> <br /> == Home Cache ==<br /> <br /> If a resident has a home, why not have a separate texture cache for it, a ''Home Cache''. This cache would only be explicitly cleared down and would be accessed first by the client when the resident logs on or teleports home.<br /> <br /> Once populated with textures, each logon/teleport to home would not involve network traffic, as they would be available locally, on the client.<br /> <br /> [[User:Benja Kepler|Benja Kepler]] 02:52, 24 March 2007 (PDT)<br /> <br /> :A similar idea would be to have a hit count on textures. The hit count can be kept around much longer than the texture data. The hit count would be used to indicate what textures to keep in the cache longer. [[User:Dzonatas Sol|Dzonatas Sol]] 12:53, 24 March 2007 (PDT)<br /> <br /> ::We probably don't want to invent our own caching system, since this type of thing gets studied a lot. Looking around, at what other projects are doing (e.g. PostgreSQL, Linux), I found this replacement for the LRU scheme used today: [http://www.vldb.org/dblp/db/conf/vldb/vldb94-439.html 2Q cache system]. This balances hit frequency and hit recency to determine whether to eject something from the cache. -- [[User:Rob Linden|Rob Linden]] 23:34, 24 March 2007 (PDT)<br /> <br /> == Textures in Inventory ==<br /> <br /> A search through the avatar's inventory is a good indication of what textures to keep around longer in the cache than others. [[User:Dzonatas Sol|Dzonatas Sol]] 12:50, 24 March 2007 (PDT)<br /> <br /> :I can't agree with this. I have many textures that I rarely see in-world. I don't think it merits extra attention. [[User:Strife Onizuka|Strife Onizuka]] 22:59, 24 March 2007 (PDT)<br /> <br /> == Plan: Normalization of Texture Usage ==<br /> <br /> A method to keep the statistics of pixel coverage and hit rates: We use a collection of hit counters such that each represents an individual entry for an associated texture. When any hit counter hits a threshold, the collection is normalized and the results are stored in each associated hit-rate fields of the entry. The hit-rate fields may store percentages for short term and long term storage. The short term and long term storage indicators present a value for determination in how textures are archived or disposed. Pixel-coverage rates are optional fields in each entry for determination of an optimal storage medium for texture data such that the medium is represented in uncompressed or compressed methods and if the stored texture is downsampled and to what degree it is downsampled. [[User:Dzonatas Sol|Dzonatas Sol]] 17:05, 24 March 2007 (PDT)<br /> <br /> :I think this would result in decreased performance as a lot of time would be spent incrementing hit counters. [[User:Strife Onizuka|Strife Onizuka]] 22:57, 24 March 2007 (PDT)<br /> ::How hit counters are incremented have not been analyzed for implementation. This is just a general plan independent of any specific implementation. [[User:Dzonatas Sol|Dzonatas Sol]] 23:03, 24 March 2007 (PDT)<br /> <br /> == Idea: Keep a cache index ==<br /> <br /> Keep an on-disk index of cache files. This could be made compact and small enough to fully into RAM. The index would allow to know whether a file is in the cache, thus avoiding trying to open a file if the current way of storing a texture in its own file is kept.<br /> <br /> Additionally, store some metadata with: filesize, md5sum, and a very rough texture approximation (perhaps even limited to a solid color) to have something better than the current grey.<br /> <br /> Filesize and md5sum would allow to check the on-disk files' integrity, which should avoid any need to clear the cache, as correctness could be automatically verified.<br /> <br /> My suggested format for the index is Berkeley DB, which is simple and compact, and is ACID compliant, which should ensure the integrity of the index. [[User:Dale Glass|Dale Glass]] 15:39, 24 March 2007 (PDT)<br /> <br /> :The old VFS used an index, while it didn't keep a hash of the asset it did track access date. If you are going to be using a DB on top of the cache, you might as well put the entire cache in a single file and save on file system IO. Why? After all a VFS is just a database of sorts and regardless you have to search the DB or the FS for the file. There were two problems with the old VFS: slow to find data in the index and slow to decode images (this isn't the fault of the VFS). A well designed VFS should be able to out perform any FS (because it doesn't have to perform locks). [[User:Strife Onizuka|Strife Onizuka]] 19:12, 24 March 2007 (PDT)<br /> ::The filesystem is already an entirely suitable way of keeping data like textures. It does have a few problems for example, such as that searching for a file in a directory may be relatively expensive. This can be easily compensated for with a small DB used only to compensate for those shortcomings. A full VFS-like thing is a lot more complex, you basically have to write your own mini-filesystem, and as we've seen, that's hard to do well. Berkeley DB is especially nice in that it's ACID - you have a guarantee of that data in it is consistent, unlike with the VFS (unless you go and code that in, but that takes time). Also, by keeping a collection of small items of data of a fixed size you avoid internal fragmentation, which is something you'd have to deal with a VFS-like approach. If you store textures as files, just use the system defragmenter. [[User:Dale Glass|Dale Glass]] 19:43, 24 March 2007 (PDT)<br /> :::*How would having a Berkeley DB solve the problem of searches being slow? Would it be faster then a std::map.find()? How well does it's search alg scale?<br /> :::The old VFS did have a bit of a problem with free space fragmentation. Writing a quick and dirty defragmentation utility for it is not a difficult task (at one point i wrote a utility for converting the cache into a tar archive, the output couldn't have fragmented free space). Remember, we already have a VFS, we don't have an integrated Berkeley DB. [[User:Strife Onizuka|Strife Onizuka]] 22:20, 24 March 2007 (PDT)<br /> <br /> == Idea: Keep a texture map for every sim ==<br /> <br /> Currently, dual core CPUs have a large amount of spare time on the second core while they're not actively fetching textures. I propose a way of using this spare time.<br /> <br /> The viewer would create a database per visited sim with a list of textures found in each location. This database would allow the viewer to know what textures can be found in nearby areas, even before the grid has transmitted the data about them. Then, when idle, the viewer could use the spare time to start loading textures from the surrounding areas, so that they are instantly available when the avatar moves.<br /> <br /> My suggested way of doing that is using a Berkeley DB database to store the data. A simple way of storing the data would be making the key the position inside the sim, rounded to for example multiples of 16 meters. The data stored for that key would be a list of textures used in that area.<br /> <br /> For example, the position (120,90,56) when rounded to multiples to 16m translates to (112, 80, 48). Under key &quot;112,80,48&quot; the viewer would store a list of textures used inside that 16x16x16 area.<br /> <br /> This should make several optimizations possible:<br /> * When teleporting to a new area, decoding of textures can be started before the grid had time to transmit the required information. It should be possible to start loading textures immediately after the user starts the teleport, while the progress bar is still being shown.<br /> <br /> * When the avatar moves around, the viewer could start decoding textures likely to be present in locations about which there's no data available yet. This might make flying less painful.<br /> <br /> * If a storage method like the VFS, which stores multiple textures in a file is chosen, then having this data available could make it possible to optimize the placement of the texture data on disk, for optimal loading. [[User:Dale Glass|Dale Glass]] 15:39, 24 March 2007 (PDT)<br /> <br /> :&lt;br/&gt;Stupid question: Why not just have the sim send the object definitions too? You can glean UUIDs for the images from the objects. Then you don't have to ask the sim for the objects too. Wait but isn't that just the same as looking in all directions at the same time (but only rendering what is infront of the camera). The great part about just asking for the object definitions is that there already is code inplace for caching those definitions. No need to hack in an entirely new DB. Silly question: Is this an efficient way to spend sim CPU time: Serving assets not in view and in directions other then that the user is pointing? Downloading textures while the client is in TP is a bad idea; what if the user doesn't have access to the sim (it takes some time for TP's to fail)? It would be a bad thing for say SAP to try to TP into Oracle's private sim (knowing full well that the TP would fail) in an attempt to glean insider information via texture pre-caching ([http://www.betanews.com/article/Oracle_Accuses_SAP_of_Massive_Corporate_Theft/1174664992 linky]). [[User:Strife Onizuka|Strife Onizuka]] 19:34, 24 March 2007 (PDT)<br /> ::Sorry, I don't think I succeeded at getting the idea across. It wouldn't involve requesting anything extra from the sim. The idea is that the viewer would compile a database of texture usage inside sims you visited, so when you started teleporting to a sim, it could look in its database and start preloading images from its '''cache''' that are likely to be found in the place you're teleporting to. Basically, instead of waiting for the sim to tell you what's there and then loading the images, it would load from the cache things that are likely to be there (as sims don't change all that often), and when the sim does finally give you the data, you'd already have a part of the images decoded and ready to show. If you visited a place in the past, I think there should be a very good chance of mostly correctly guessing the textures needed to render it.<br /> <br /> ::SAP problem wouldn't happen because the mechanism would work based on information you previously got, so you'd have to have been to the place before for it to work. [[User:Dale Glass|Dale Glass]] 19:56, 24 March 2007 (PDT)<br /> <br /> :::Ahhh its' a passive solution. What you want could be archived without a special DB; the client already collects this information in the sim-object cache. For TPing, it could be done quite easily. The viewer just needs to load the data from the object cache and render it. This would cause the appropriate functions to be called to decode and request missing assets. It doesn't need to render it to the screen, just an extra buffer.&lt;br/&gt;Doing a fake render is probably the easiest, most efficient and most accurate way of doing this. A major issue with building a separate DB is you have to build the dynamic octrees for it. By using the rendering pipeline with the object cache you don't have to write new code to do this. [[User:Strife Onizuka|Strife Onizuka]] 22:51, 24 March 2007 (PDT)<br /> <br /> [[Category:Future Roundtables]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=16014 2007-03-24T15:21:25Z

<p>Kerunix Flan: reformating and typo</p> <hr /> <div>{{Talk}}<br /> <br /> We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies] -- {{User|kerunix Flan}}<br /> <br /> : The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. [[User:Seg Baphomet|Seg Baphomet]] 22:45, 23 March 2007 (PDT)<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie. [[User:Iron Perth|Iron Perth]] 03:00, 23 March 2007 (PDT)<br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.{{unsigned|kerunix Flan}}<br /> <br /> :Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. [[User:Strife Onizuka|Strife Onizuka]] 02:22, 24 March 2007 (PDT)<br /> <br /> <br /> == Faster Formats ==<br /> Contribution from Tofu Linden from the email discussion<br /> <br /> <br /> RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT)<br /> <br /> <br /> :And as said on the mailling, the destructive effect of JPEG2000 probably killed any chance to have a good compression rate using RLE. RLE is fast and the only compression supported by the Targavision specification. If we don't use it (probably because it's useless) then don't use compression at all. One of the advantage of using RLE like said in the specification is that we don't have to decompress anything to read the header, developper area, and footer. [[User:Kerunix Flan|Kerunix Flan]] 08:02, 24 March 2007 (PDT)<br /> <br /> <br /> == Current Caching ==<br /> <br /> Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..<br /> <br /> Contribution from Steve Linden from email discussion:<br /> <br /> 2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:<br /> <br /> a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)<br /> <br /> b. Once a frame, reduce the current pixel coverage of all textures by 10%.<br /> <br /> This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code &quot;assume that all textures are no longer visible&quot; and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.<br /> <br /> 3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.<br /> <br /> :do that mean that, even if we have a lot of VRAM available, the texture will be removed from cache if we don't see the texture for 30s ? and then, moving our avatar in the sim will make the client redecoding the texture from cache to load it in VRAM again ? Why not discarding the texture only when we're out of memory ? (''please delete/replace this comment by the answer'') [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> 4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client &gt; Rendering &gt; Run Multiple Threads, the decoding will be done on the second CPU and go much faster.<br /> <br /> :I can't believe loading a texture from a remote cache isn't much slower than loading a texture from a local cache. And if you add the usual packet loss and high ping (for non-us user) it's *certainly* much slower. [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:<br /> <br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT)<br /> <br /> <br /> == Home Cache ==<br /> <br /> If a resident has a home, why not have a separate texture cache for it, a ''Home Cache''. This cache would only be explicitly cleared down and would be accessed first by the client when the resident logs on or teleports home.<br /> <br /> Once populated with textures, each logon/teleport to home would not involve network traffic, as they would be available locally, on the client.<br /> <br /> [[User:Benja Kepler|Benja Kepler]] 02:52, 24 March 2007 (PDT)</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=16013 2007-03-24T15:18:52Z

<p>Kerunix Flan: /* Current Caching */</p> <hr /> <div>{{Talk}}<br /> <br /> We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies] -- {{User|kerunix Flan}}<br /> <br /> : The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. [[User:Seg Baphomet|Seg Baphomet]] 22:45, 23 March 2007 (PDT)<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie. [[User:Iron Perth|Iron Perth]] 03:00, 23 March 2007 (PDT)<br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.{{unsigned|kerunix Flan}}<br /> <br /> :Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. [[User:Strife Onizuka|Strife Onizuka]] 02:22, 24 March 2007 (PDT)<br /> <br /> <br /> == Faster Formats ==<br /> Contribution from Tofu Linden from the email discussion<br /> <br /> <br /> RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT)<br /> <br /> <br /> :And as said on the mailling, the destructive effect of JPEG2000 probably killed any chance to have a good compression rate using RLE. RLE is fast and the only compression supported by the Targavision specification. If we don't use it (probably because it's useless) then don't use compression at all. One of the advantage of using RLE like said in the specification is that we don't have to decompress anything to read the header, developper area, and footer. [[User:Kerunix Flan|Kerunix Flan]] 08:02, 24 March 2007 (PDT)<br /> <br /> == Current Caching ==<br /> <br /> Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..<br /> <br /> Contribution from Steve Linden from email discussion:<br /> <br /> 2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:<br /> <br /> a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)<br /> <br /> b. Once a frame, reduce the current pixel coverage of all textures by 10%.<br /> <br /> This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code &quot;assume that all textures are no longer visible&quot; and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.<br /> <br /> 3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.<br /> <br /> :do that mean that, even if we have a lot of VRAM available, the texture will be removed from cache if we don't see the texture for 30s ? and then, moving our avatar in the sim will make the client redecoding the texture from cache to load it in VRAM again ? Why not discarding the texture only when we're out of memory ? (''please delete/replace this comment by the answer'') [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> 4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client &gt; Rendering &gt; Run Multiple Threads, the decoding will be done on the second CPU and go much faster.<br /> <br /> :I can't believe loading a texture from a remote cache isn't much slower than loading a texture from a local cache. And if you add the usual packet loss and high ping (for non-us user) it's *certainly* a lot slower. [[User:Kerunix Flan|Kerunix Flan]] 08:18, 24 March 2007 (PDT)<br /> <br /> He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:<br /> <br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT)<br /> <br /> == Home Cache ==<br /> <br /> If a resident has a home, why not have a separate texture cache for it, a ''Home Cache''. This cache would only be explicitly cleared down and would be accessed first by the client when the resident logs on or teleports home.<br /> <br /> Once populated with textures, each logon/teleport to home would not involve network traffic, as they would be available locally, on the client.<br /> <br /> [[User:Benja Kepler|Benja Kepler]] 02:52, 24 March 2007 (PDT)</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=16012 2007-03-24T15:02:30Z

<p>Kerunix Flan: /* Faster Formats */</p> <hr /> <div>{{Talk}}<br /> <br /> We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies] -- {{User|kerunix Flan}}<br /> <br /> : The last of the patents expired in October 2006. GIF is no longer patent encumbered. But PNG is still better. Keep in mind by recompressing the image to cache it you're trading CPU usage for disk space. Compression is usually a lot slower than decompression. Just storing uncompressed might be overall faster. In the end, we need to assume nothing and benchmark, benchmark, benchmark. [[User:Seg Baphomet|Seg Baphomet]] 22:45, 23 March 2007 (PDT)<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie. [[User:Iron Perth|Iron Perth]] 03:00, 23 March 2007 (PDT)<br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.{{unsigned|kerunix Flan}}<br /> <br /> :Converting images into the TGA format for cache storage has the advantage that the client already supports rendering TGA images. It would be one of the easiest solutions. Images with the same dimensions would all be the same but otherwise would be different in size. [[User:Strife Onizuka|Strife Onizuka]] 02:22, 24 March 2007 (PDT)<br /> <br /> <br /> == Faster Formats ==<br /> Contribution from Tofu Linden from the email discussion<br /> <br /> <br /> RLE is cheap but also not very effective at all for many, many textures; wherever I might have used RLE in ye olden days I'd now use trusty old zlib or blingy liblzf, the latter of which is more or less on the same order of speed as RLE but a LOT more effective on data (images) with redundancy not necessarily manifesting as runs of pixels.<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:30, 24 March 2007 (PDT)<br /> <br /> <br /> :And as said on the mailling, the destructive effect of JPEG2000 probably killed any chance to have a good compression rate using RLE. RLE is fast and the only compression supported by the Targavision specification. If we don't use it (probably because it's useless) then don't use compression at all. One of the advantage of using RLE like said in the specification is that we don't have to decompress anything to read the header, developper area, and footer. [[User:Kerunix Flan|Kerunix Flan]] 08:02, 24 March 2007 (PDT)<br /> <br /> == Current Caching ==<br /> <br /> Both Tofu and Steve have made the point they feel cache hit rate issues are a priority..<br /> <br /> Contribution from Steve Linden from email discussion:<br /> <br /> 2. The way we calculate texture pixel coverage (and therefore desired discard level) is as follows:<br /> <br /> a. When anything using a texture is rendered. set its pixel coverage to MAX(current pixel coverage, rendered pixel coverage)<br /> <br /> b. Once a frame, reduce the current pixel coverage of all textures by 10%.<br /> <br /> This way, everything rendered recently has an accurate pixel coverage, and everything not rendered degrades over time. gImageList.mForceResetTextureStats merely tells the code &quot;assume that all textures are no longer visible&quot; and resets the pixel area of all texture to 0. As soon as they are rendered their pixel coverage is updated.<br /> <br /> 3. Even if a textures pixel coverage gets set to 0, we do not immediately discard the texture data. We only discard the data if we need room for more textures (in which case we discard the textures with the lowest priority), or if no object in view is using the texture *and* 30 seconds have elapsed.<br /> <br /> 4. Tateru is absolutely correct in that caching textures to disk mostly just saves on network bandwidth. Unless you have a slow network connection, it can be almost as fast to load textures across the network as from a disk, especially if that disk is not especially fast or is fragmented. Decoding the textures takes quite a bit longer. However, if you have multiple CPUs and enable Client &gt; Rendering &gt; Run Multiple Threads, the decoding will be done on the second CPU and go much faster.<br /> <br /> <br /> He also makes some interesting comments about teleporting around and filling up the texture cache. Check out his original email here:<br /> <br /> https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html<br /> <br /> [[User:Iron Perth|Iron Perth]] 02:44, 24 March 2007 (PDT)<br /> <br /> == Home Cache ==<br /> <br /> If a resident has a home, why not have a separate texture cache for it, a ''Home Cache''. This cache would only be explicitly cleared down and would be accessed first by the client when the resident logs on or teleports home.<br /> <br /> Once populated with textures, each logon/teleport to home would not involve network traffic, as they would be available locally, on the client.<br /> <br /> [[User:Benja Kepler|Benja Kepler]] 02:52, 24 March 2007 (PDT)</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=15981 2007-03-24T04:25:20Z

<p>Kerunix Flan: </p> <hr /> <div>from kerunix Flan : We can safely avoid the GIF format. It's 256 colors only. it use unisys patent LZW (the good old patent used in the good old GIF expired, but unisys repatent'd it because of some &quot;improvments&quot; in the algorithm.). Unisys suddenly claimed they wanted royalties to encode GIF file, and just for that we shouldn't use it. source : [http://www.unisys.com/about__unisys/lzw License Information on GIF and Other LZW-based Technologies]<br /> <br /> == Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie.<br /> <br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=15980 2007-03-24T04:12:00Z

<p>Kerunix Flan: </p> <hr /> <div>== Databases ==<br /> <br /> There appears to be support with APR for a portable interface to common databases, namely Berkely-DB and SQL. [[User:Dzonatas Sol|Dzonatas Sol]] 18:23, 23 March 2007 (PDT)<br /> <br /> == Stats ==<br /> It would be useful to get stats on current and new hardware profiles from LL to get a sense of what people are using and where the focus should lie.<br /> <br /> <br /> == [http://en.wikipedia.org/wiki/TGA TGA] ==<br /> <br /> I can't find it in the spec, but i think this format give the warranty that images of a given size will always have the same file size. (without RLE of course). This may help for some optimization.<br /> <br /> Additionaly, the &quot;developper area&quot; of the TGA file format could be used to store some usefull information.</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Talk:Texture_Cache&diff=15973 2007-03-24T00:24:15Z

<p>Kerunix Flan: </p> <hr /> <div>from kerunix Flan : &quot;[http://en.wikipedia.org/wiki/Run-length_encoding rle]&quot; is a compression standard, not a file format. Should be something like &quot;[http://en.wikipedia.org/wiki/TGA TGA] (with or without RLE)&quot;.</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5973 2007-01-21T22:53:39Z

<p>Kerunix Flan: /* International Areas */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> * [http://slurl.com/secondlife/Gaia/147/124/28 French school - Accueil francophone] : a full sim with dedicated french helper, classes, and translated notecard. ''(yet another non-profit sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> * [http://slurl.com/secondlife/area%2051/138/125/27 Area 51] : The main french sim. Usually full and laggy, but with usefull ressources, classes and sandbox. (it's just next to the French School)<br /> * See also (still french) : [http://slurl.com/secondlife/ile%20de%20france/128/104/75 Ile de France] , [http://slurl.com/secondlife/Wild%20Vertigo/50/42/75 Wild Vertigo] , [http://slurl.com/secondlife/Europe/217/155/75 Europe] , [http://slurl.com/secondlife/Trantor/184/24/75 La Playa Del Noob](with a linden gallery) , [http://slurl.com/secondlife/Solaria/123/115/75 Loisir Area], [http://slurl.com/secondlife/Terminus/149/139/75 SL Ecosystem Working Group] (international ALife project hosted in french sim) , and Tohama, Nebuleuse, Croix du sud, Aurore. Those sim are not dedicated to SL Education, but you'll usually find french helper. Usefull groups dedicated to French support : &quot;cooperation francaise&quot; (over 1000 members).<br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub]<br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House] : ''Access restricted to mentor, greeter and live helper. Just a peacefull full sim for (spammmmm) stressed volunteers :D. Feel free to build anything cool, if you can find some free space (Sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]<br /> <br /> <br /> [[Category:Second Life Volunteers]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Category:Text_from_In-world_Notecards_(French)&diff=5936 2007-01-21T07:22:58Z

<p>Kerunix Flan: </p> <hr /> <div>Coming soon :)</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5930 2007-01-21T03:17:12Z

<p>Kerunix Flan: /* International Areas */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> * [http://slurl.com/secondlife/Gaia/147/124/28 French school - Accueil francophone] : a full sim with dedicated french helper, classes, and translated notecard. ''(yet another non-profit sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> * [http://slurl.com/secondlife/area%2051/138/125/27 Area 51] : The main french sim. Usually full and laggy, but with usefull ressources, classes and sandbox. (it's just next to the French School)<br /> * See also (still french) : [http://slurl.com/secondlife/ile%20de%20france/128/104/75 Ile de France] , [http://slurl.com/secondlife/Wild%20Vertigo/50/42/75 Wild Vertigo] , [http://slurl.com/secondlife/Europe/217/155/75 Europe] , [http://slurl.com/secondlife/Trantor/184/24/75 The Noob Beach](with a linden gallery) , [http://slurl.com/secondlife/Solaria/123/115/75 Loisir Area], [http://slurl.com/secondlife/Terminus/149/139/75 SL Ecosystem Working Group] (international ALife project hosted in french sim) , and Tohama, Nebuleuse, Croix du sud, Aurore. Those sim are not dedicated to SL Education, but you'll usually find french helper. Usefull groups dedicated to French support : &quot;cooperation francaise&quot; (over 1000 members).<br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub]<br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House] : ''Access restricted to mentor, greeter and live helper. Just a peacefull full sim for (spammmmm) stressed volunteers :D. Feel free to build anything cool, if you can find some free space (Sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]<br /> <br /> <br /> [[Category:Second Life Volunteers]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5928 2007-01-21T03:03:52Z

<p>Kerunix Flan: /* Volunteer Support */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> * [http://slurl.com/secondlife/Gaia/147/124/28 French school - Accueil francophone] : a full sim with dedicated french helper, classes, and translated notecard. ''(yet another non-profit sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub]<br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House] : ''Access restricted to mentor, greeter and live helper. Just a peacefull full sim for (spammmmm) stressed volunteers :D. Feel free to build anything cool, if you can find some free space (Sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]<br /> <br /> <br /> [[Category:Second Life Volunteers]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5927 2007-01-21T03:02:12Z

<p>Kerunix Flan: /* Volunteer Support */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> * [http://slurl.com/secondlife/Gaia/147/124/28 French school - Accueil francophone] : a full sim with dedicated french helper, classes, and translated notecard. ''(yet another non-profit sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub]<br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House] : ''Access restricted to mentor, greeter and live helper. Just a fun place for (spammmmm) stressed volunteers :D (Sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]<br /> <br /> <br /> [[Category:Second Life Volunteers]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5926 2007-01-21T03:00:39Z

<p>Kerunix Flan: /* International Areas */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> * [http://slurl.com/secondlife/Gaia/147/124/28 French school - Accueil francophone] : a full sim with dedicated french helper, classes, and translated notecard. ''(yet another non-profit sim hosted and paid by &quot;kerunix Flan&quot;)''<br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub]<br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House] : Access restricted to mentor, greeter and live helper. Just a fun place for (spammmmm) stressed volunteers :D (Sim offered and paid by &quot;kerunix Flan&quot;)<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]<br /> <br /> <br /> [[Category:Second Life Volunteers]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5924 2007-01-20T22:30:03Z

<p>Kerunix Flan: /* Volunteer Support */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> <br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub] <br /> <br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House] : Access restricted to mentor, greeter and live helper. Just a fun place for (spammmmm) stressed volunteers :D (Sim offered and paid by &quot;kerunix Flan&quot;)<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]<br /> <br /> <br /> [[Category:Second Life Volunteers]]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=Inworld_Locations_for_Volunteers&diff=5922 2007-01-20T22:25:04Z

<p>Kerunix Flan: /* Volunteer Support */</p> <hr /> <div>== InfoHubs ==<br /> * [http://slurl.com/secondlife/Ambat/97/212/59/?msg=Ambat%20Infohub Ambat Infohub]<br /> * [http://slurl.com/secondlife/Anzere/82/56/124/?msg=Anzere%20Infohub Anzere Infohub] <br /> * [http://slurl.com/secondlife/Bear/26/181/110/?msg=Bear%20Dream%20Lodge%20Infohub Bear Infohub]<br /> * [http://slurl.com/secondlife/Braunworth/92/155/179/?msg=Braunworth%20Infohub Braunworth Infohub] <br /> * [http://slurl.com/secondlife/Calleta/128/206/26/?msg=Calleta%27s%20Hobo%20Railroad%20Infohub Calleta Infohub]<br /> * [http://slurl.com/secondlife/Clementina/184/123/61/?msg=Governor%20Lindens%20Mansion Clementina Infohub] <br /> * [http://slurl.com/secondlife/Hyles/38/30/22/?msg=Hyles%20Swamp%20Infohub Hyles Infohub]<br /> * [http://slurl.com/secondlife/Iris/202/125/29/?title=Iris_Infohub-Temple_of_Iris Iris Infohub ]<br /> * [http://slurl.com/secondlife/Isabel/44/107/57/?msg=Isabel%20Infohub Isabel Infohub] <br /> * [http://slurl.com/secondlife/Mahulu/58/193/85/?msg=Mahulu%20Infohub Mahulu Infohub] <br /> * [http://slurl.com/secondlife/Mauve/233/184/42/?msg=Mauve%20Infohub Mauve Infohub]<br /> * [http://slurl.com/secondlife/Miramare/3/24/25/?msg=Miramare%20Infohub Miramare Infohub] <br /> * [http://slurl.com/secondlife/Ross/34/224/57/?msg=Ross%20Infohub Ross Infohub]<br /> * [http://slurl.com/secondlife/Violet/175/95/26/?msg=Violet%20Infohub Violet Infohub]<br /> * [http://slurl.com/secondlife/Wengen/8/231/85/?msg=Chalet%20Linden Wengen Infohub]<br /> <br /> <br /> == International Areas ==<br /> <br /> '''French'''<br /> <br /> <br /> '''Korean'''<br /> * [http://slurl.com/secondlife/Korea1/226/23/25/?msg=Korea1%20Infohub Korea1 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/1/24/25/?msg=Korea2%20Infohub Korea2 Infohub] <br /> * [http://slurl.com/secondlife/Korea2/239/228/25/?msg=Korea3%20Infohub Korea3 Infohub] <br /> * [http://slurl.com/secondlife/Korea4/13/228/25/?msg=Korea4%20Infohub Korea4 Infohub] <br /> <br /> <br /> == Welcome Areas ==<br /> * [http://slurl.com/secondlife/Waterhead/6/6/40/?msg=Ahern%20Welcome%20Area Ahern Welcome Area]<br /> * [http://slurl.com/secondlife/Waterhead/41/78/25/?msg=Waterhead%20Welcome%20Area Waterhead Welcome Area]<br /> <br /> <br /> == Linden Meeting Spaces ==<br /> * [http://slurl.com/secondlife/Pooley/247/5/39/?msg=Pooley%20Stage Pooley Stage]<br /> * [http://slurl.com/secondlife/Orientation%20Island%20Public/127/129/23/?msg=Orientation%20Island%20Public Orientation Island Public]<br /> <br /> <br /> == Volunteer Support ==<br /> * [http://slurl.com/secondlife/Tenera/208/83/70/?title=Second%20Life%20Volunteer%20HQ Volunteer HQ]<br /> * [http://slurl.com/secondlife/Portage/24/178/85/?msg=Live%20Help%20Lyceum Live Help Lyceum]<br /> * [http://slurl.com/secondlife/Pro%20Racer/144/127/36/?title=Teh%20Mental%20House Teh Mental House]<br /> <br /> == Help Islands ==<br /> Please note that only Volunteers can access Help Islands. However, &quot;Help Island Public&quot; is accessible by anyone.<br /> * [http://slurl.com/secondlife/Help%20Island%20Public/124/124/26/ Help Island Public]<br /> * [http://slurl.com/secondlife/Help%20Island/124/124/26/ Help Island]<br /> * [http://slurl.com/secondlife/Help%20Island%202/124/124/26/ Help Island 2]<br /> * [http://slurl.com/secondlife/Help%20Island%203/124/124/26/ Help Island 3]<br /> * [http://slurl.com/secondlife/Help%20Island%204/124/124/26/ Help Island 4]<br /> * [http://slurl.com/secondlife/Help%20Island%205/124/124/26/ Help Island 5]<br /> * [http://slurl.com/secondlife/Help%20Island%206/124/124/26/ Help Island 6]<br /> * [http://slurl.com/secondlife/Help%20Island%207/124/124/26/ Help Island 7]<br /> * [http://slurl.com/secondlife/Help%20Island%208/124/124/26/ Help Island 8]<br /> * [http://slurl.com/secondlife/Help%20Island%209/124/124/26/ Help Island 9]</div>

Kerunix Flan https://wiki.secondlife.com/w/index.php?title=User:Kerunix_Flan&diff=5280 2007-01-13T12:30:19Z

<p>Kerunix Flan: </p> <hr /> <div>Hi !<br /> <br /> French mentor and liver helper !<br /> <br /> (to be continued ...)</div>

Kerunix Flan