Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
LL Snowstorm/Opensource-Dev, To stimulate SL growth and accessibility to the mainstream, one or the collective SL Viewer developers and/or decision makers ought to think design universally. If mesh becomes a standard in SL, a basic mesh editor ought to be included by default. The ability to plugin with existing professional tools such as Photoshop, Gimp, Blender, Max, etc. is essential for high-end content production and advanced SL users. However, to deny a new users who are discovering either 3D Second Life or the 3D Web for the first time a complete basic set of content creation tools for the 3D world they are introduced to (of which would include a mesh editor), may seriously discourage them; along with potential opportunity for regular influx of new emerging content creators within our community from Low, Medium, and High End. SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' and 'basic' to encourage new content creators to create and feel that they begin to learn and participate without significant barriers. We must try and avoid any situation where a New User in SL feels disadvantaged or unable to create before they start. Regards, DMC Zsigmond-Jurassic Science Fiction. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Stickman Sent: Tuesday, October 05, 2010 2:48 PM To: Frans Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? On Mon, Oct 4, 2010 at 1:38 PM, Frans mrfr...@gmail.com wrote: I really hope LL is not going to add a Mesh Editor in the client. That's just going to be so bloated. I think it's a terrible idea for LL to try to recreate tools that teams of professionals have already been working on for years. Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out there, many of them free, that already do a much, much better job than LL ever could, simply because that is their only job and they have years of a head start. What I would like to see is a better connection with existing tools. Being able to have SL work with other programs easier, better conversion and import support, to cut steps out of the design workflow. For example, texture work often involves modifying a texture, test it out, modifying it again, and repeat forever. Having SL watch a texture, model, or other file for a change and automatically update it in SL so you can see exactly what it will look like would cut out a lot of steps. Even if it was only a local view. Heck, even if I had to pay for every single time I hit the save button in Photoshop or Blender. Though I'd prefer it be integrated in a way that all people could see what I was working on, then I hit finalize and it does the final upload. Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and planned that they will never evolve beyond a basic level. A simple whiteboard-style application for textures, being able to push vertices around on a model or sculpty. Nothing fancy, but enough to create something simple or touch something up without starting up an external program. That's my opinion. I know it's not universal, but it's my view based on my limited experience as a content creator. Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
I don't see why mesh editing needs to be considered basic? I would consider building through prims to be the most basic, to learn how objects/prims/links work and what features are available and what texturing is and the such. New users also have all the free tools and those existing tutorials available to start working with meshes, so new users should hopefully still feel like they have an advancement path. Even if prim objects became totally non-competitive on the market, people probably still start out just experimenting for their own use, so prims should still be a good stepping stone while learning for their quick results and feedback. What would a mesh editor in the viewer add? (Well, one likely feature of an in-world tool would be to enable people to work concurrently with others and see others' changes as they are made, but I doubt you're referring to that aspect.) Ironically, what I would think of as the most basic conceptual transitions going from prims to meshes are probably the most difficult to program. To ease the transition to meshes when the time comes for a new content creator, what I could imagine is the introduction of some tools and concepts from a mesh's content creation process - hierarchical links to allow stacking transformations? a way to palletize the textures applied to an object? - but while still working with prims in-world. Maybe it can even go as far as a full conversion tool if someone were ambitious enough to code such a thing (to convert and tinker). But I wouldn't go as far as controlling subdivisions or twiddling edge normals or nudging vertices -- a list that is in increasing order of usability difficulty, but decreasing order of programming complexity, and thus the irony of a basic mesh editor. Celi On Tue, Oct 5, 2010 at 2:21 AM, Science Fiction Computer - SCi-Fi PC partn...@scifipc.com wrote: LL Snowstorm/Opensource-Dev, To stimulate SL growth and accessibility to the mainstream, one or the collective SL Viewer developers and/or decision makers ought to think design universally. If mesh becomes a standard in SL, a basic mesh editor ought to be included by default. The ability to plugin with existing professional tools such as Photoshop, Gimp, Blender, Max, etc. is essential for high-end content production and advanced SL users. However, to deny a new users who are discovering either 3D Second Life or the 3D Web for the first time a complete basic set of content creation tools for the 3D world they are introduced to (of which would include a mesh editor), may seriously discourage them; along with potential opportunity for regular influx of new emerging content creators within our community from Low, Medium, and High End. SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' and 'basic' to encourage new content creators to create and feel that they begin to learn and participate without significant barriers. We must try and avoid any situation where a New User in SL feels disadvantaged or unable to create before they start. Regards, DMC Zsigmond-Jurassic Science Fiction. -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Stickman Sent: Tuesday, October 05, 2010 2:48 PM To: Frans Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? On Mon, Oct 4, 2010 at 1:38 PM, Frans mrfr...@gmail.com wrote: I really hope LL is not going to add a Mesh Editor in the client. That's just going to be so bloated. I think it's a terrible idea for LL to try to recreate tools that teams of professionals have already been working on for years. Photoshop, Gimp, Blender, Max, Maya -- there are specialty tools out there, many of them free, that already do a much, much better job than LL ever could, simply because that is their only job and they have years of a head start. What I would like to see is a better connection with existing tools. Being able to have SL work with other programs easier, better conversion and import support, to cut steps out of the design workflow. For example, texture work often involves modifying a texture, test it out, modifying it again, and repeat forever. Having SL watch a texture, model, or other file for a change and automatically update it in SL so you can see exactly what it will look like would cut out a lot of steps. Even if it was only a local view. Heck, even if I had to pay for every single time I hit the save button in Photoshop or Blender. Though I'd prefer it be integrated in a way that all people could see what I was working on, then I hit finalize and it does the final upload. Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and
Re: [opensource-dev] WebP, a new image format for the Web
Hi, I was puzzled by this yet another image format from Google and did some quick research tonight. Not much turned up in the data provided by Google and, as always, the best starting point is Wikipedia: http://en.wikipedia.org/wiki/WebP . Short but to the point. The critical part is the Math: WebP is based on block prediction and encoding, something that works well for compressing frame to frame videos but one has to wonder about still images. Why would blocks be predictable spatially? Similar textures? May be but loss of precision would be horrendous, something that I don't thing the JPEG (a group of Pro Photographers) would swallow. Besides, it reminds me a lot about fractal compression of the mid 90's and we all know how this ended... Then, if prediction fails, WebP falls back to DCT so no better than classical JPEG and the blocking artifacts are as good as what JPEG gives us... a problem that, precisely, wavelet compression (used in jpeg2000) solved. It seems to me that, as far as encoding differences from levels to levels, wavelets do that uniformly on the whole image much better already and its mathematical underpinning is much stronger (see Stéphane Mallat papers' on Optimal Image Compression). Not to mention that wavelet gives us LOD (Level of Details == discard level == subres access) that we *do* use in SL and random spatial access that, unfortunately, we do not use in SL (though we ought to). Anyway, WebP gives us neither one not the other. As for the 39% better compression touted by Google, I fail to see that as a big selling point, especially when taking the huge compression time they apparently experience into account. You also get much better compression rate with jpeg2000 than with jpeg any day. But, even with good old jpeg, if you take the time to compute adapted quantization tables for each image, you would get much better compression rates. Now, no one does this because it takes too long at compress time (which is typically done on cameras...) so everyone uses the same set of standard (read ought to work for all run of the mill picture taking situations) quantization tables. So, if you were to really compare apple to apple, I'm not even sure that WebP is that much better than standard jpeg. More: 8 bits per channel only? That must be a typo... I won't even go down the raw and high dynamic range debate familiar to folks with an interest in photography. Well, I don't see why the method can't be extended to 16 bits though. Then this: comparing visually differences between JPEG images pulled from the web and reencoded with WebP to judge quality? No seriously, I almost cried... I thought Google had better standards for quality of engineering. What a disappointment. My take: keep on the radar (because it's Google...) but I don't see the urgency to jettison JPEG2000 for static images yet. Cheers, - Merov On Fri, Oct 1, 2010 at 10:45 AM, Tateru Nino tat...@taterunino.net wrote: Hmm. Only supports a single image data chunk and no alpha channels in this release. True, you could break compatibility and extend it, but I'm not sure that's really the way to go. Not close to a drop-in replacement yet, even after banging it on some rocks. On 2/10/2010 3:15 AM, SuezanneC Baskerville wrote: Google is putting out a new open source image format, said to offer higher compression rates than JPEG2000. I just thought someone with the appropriate technical knowledge ought to take a look at in case it might be useful for use in Second Life. http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html *To improve on the compression that JPEG provides, we used an image compressor based on the VP8 codec that Google open-sourcedhttp://blog.webmproject.org/2010/05/introducing-webm-open-web-media-project.htmlin May 2010. We applied the techniques from VP8 video intra frame coding to push the envelope in still image coding. We also adapted a very lightweight container based on RIFFhttp://en.wikipedia.org/wiki/Resource_Interchange_File_Format. While this container format contributes a minimal overhead of only 20 bytes per image, it is extensible to allow authors to save meta-data they would like to store. While the benefits of a VP8 based image format were clear in theory, we needed to test them in the real world. In order to gauge the effectiveness of our efforts, we randomly picked about 1,000,000 images from the web (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without perceptibly compromising visual quality. This resulted in an average 39% reduction in file size. We expect that developers will achieve in practice even better file size reduction with WebP when starting from an uncompressed image. * http://code.google.com/speed/webp/ -- v i r t u a l w o r l d e n t h u s i a s t -- http://www.google.com/profiles/s u e z a n n e -- ___ Policies and (un)subscribe information
[opensource-dev] Problem with displaying Arabic menu text in SL client
Hi, I have been looking to get Arabic text working on the SL client, but so far with no luck. I am only looking to display Arabic for menus and text on the client. What I have found is that the Arabic text is being displayed left-to-right, rather than right-to-left. I have added a language to SL, so I have the Arabic translations in UTF8 format in XML files, as with the other languages such as Chinese. I used Notepad++ to copy the translations to the XML files, and they are displayed right-to-left correctly. However, when loaded into the SL client, the text is being reversed so that it reads left-to-right. I have tried reversing the text, so that it displays left-to-right in the XML file, in the hope that it will then be reversed and display right-to-left in the client. I cannot read or write Arabic, but I have been told that the characters are displayed disjoint, most likely due to the wrong ordering of the characters breaking associations between them in the XML file. Has anyone looked into this problem, or have any ideas to what I could try? Does anyone have this working? Kind Regards, Izze ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Problem with displaying Arabic menu text in SL client
Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: I have been looking to get Arabic text working on the SL client, but so far with no luck. I am only looking to display Arabic for menus and text on the client. What I have found is that the Arabic text is being displayed left-to-right, rather than right-to-left. I have added a language to SL, so I have the Arabic translations in UTF8 format in XML files, as with the other languages such as Chinese. I used Notepad++ to copy the translations to the XML files, and they are displayed right-to-left correctly. However, when loaded into the SL client, the text is being reversed so that it reads left-to-right. Unicode has special control characters to switch between left-to-right and right-to-left in mixed language documents. Additionally, I think some programs switch direction automatically when they encounter characters they know belong to a right-to-left written script. So if the translations are displayed correctly, Notepad++ is capable of at least one of those, probably the former (interpreting the control characters). I have tried reversing the text, so that it displays left-to-right in the XML file, in the hope that it will then be reversed and display right-to-left in the client. I cannot read or write Arabic, but I have been told that the characters are displayed disjoint, most likely due to the wrong ordering of the characters breaking associations between them in the XML file. Arabic script relies heavily on ligatures. Ligatures are glyphs that represent multiple characters. Other than the ligatures used for latin script (fl, fi ffi, etc.) which merely make the rendered text look nicer, ligatures in scripts like Arabic, Devanagari (a script used for Sanskrit, Hindi and other Indian languages), Bengali (another Indian language and script) and probably many others look very distinct from the characters they represent http://en.wikipedia.org/wiki/Devanagari#Conjunctsand aren't optional. (Typographs and typesetters might argue that Latin ligatures aren't optional either. But omitting ligatures in these other scripts will not only look typographically wrong but, well, just wrong. (I don't know whether it'd be considered an orthographic error in the respective cultures.)) Has anyone looked into this problem, or have any ideas to what I could try? We've discussed the problem this summer, see here: http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13 The issue is that while the SL client has support for displaying Unicode characters, it lacks the ability to use Unicode's script direction markers and the feature of converting specific character sequences to the matching ligatures. For pre-set strings (e.g. your UI translation), the first problem can be worked around by writing stuff backwards, as you already tried. To work around the second problem, you'd have to directly write the ligature characters (so you have only one character per wanted glyph). I don't know Unicode well enough to tell whether characters for all possible glyphs exist. It might well be that some ligatures always have to be created on-the-fly from a sequence of single-character characters. Of course, both of these workarounds aren't feasible for chat and other run-time user input, because users will be used to write sequences of single characters in reading order rather than ligature characters in left-to-right order. Also, entering these ligature characters (if they even exist) might be complicated and time consuming, because their usual keyboard layout might not give direct access to them. Does anyone have this working? Adding these features to Linden Lab's homebrewn text rendering system would be a major effort that probably none of us is capable of. Alissa Sabre once adapted the Viewer to use Pango for text rendering. ( See http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer) Pango can handle bidirectional text and ligatures just fine, so this solved the problems. However, these changes haven't been integrated in the official viewer and her patches are now out of date. For chat, using Dzonatas' Icesphere (allows for IM and chat in separate GTK+ windows, thus also using Pango) has been recommended to some Arabic users, and that seems to work alright. Both, the sender and receiver, will have to use it to be able to chat in Arabic script. Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Problem with displaying Arabic menu text in SL client
U+200F Reverse direction Notes: - Microsoft have a bug, this char don't work sometimes (msoffice 2011 for Mac affected too) - parser work left2right put the char on left side of each entry in all XML files -- Sent by iPhone Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte slli...@boroon.dasgupta.ch ha scritto: Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: I have been looking to get Arabic text working on the SL client, but so far with no luck. I am only looking to display Arabic for menus and text on the client. What I have found is that the Arabic text is being displayed left-to-right, rather than right-to-left. I have added a language to SL, so I have the Arabic translations in UTF8 format in XML files, as with the other languages such as Chinese. I used Notepad++ to copy the translations to the XML files, and they are displayed right-to-left correctly. However, when loaded into the SL client, the text is being reversed so that it reads left-to-right. Unicode has special control characters to switch between left-to-right and right-to-left in mixed language documents. Additionally, I think some programs switch direction automatically when they encounter characters they know belong to a right-to-left written script. So if the translations are displayed correctly, Notepad++ is capable of at least one of those, probably the former (interpreting the control characters). I have tried reversing the text, so that it displays left-to-right in the XML file, in the hope that it will then be reversed and display right-to-left in the client. I cannot read or write Arabic, but I have been told that the characters are displayed disjoint, most likely due to the wrong ordering of the characters breaking associations between them in the XML file. Arabic script relies heavily on ligatures. Ligatures are glyphs that represent multiple characters. Other than the ligatures used for latin script (fl, fi ffi, etc.) which merely make the rendered text look nicer, ligatures in scripts like Arabic, Devanagari (a script used for Sanskrit, Hindi and other Indian languages), Bengali (another Indian language and script) and probably many others look very distinct from the characters they represent http://en.wikipedia.org/wiki/Devanagari#Conjunctsand aren't optional. (Typographs and typesetters might argue that Latin ligatures aren't optional either. But omitting ligatures in these other scripts will not only look typographically wrong but, well, just wrong. (I don't know whether it'd be considered an orthographic error in the respective cultures.)) Has anyone looked into this problem, or have any ideas to what I could try? We've discussed the problem this summer, see here: http://wiki.secondlife.com/wiki/Open_Source_Meeting/2010-07-13 The issue is that while the SL client has support for displaying Unicode characters, it lacks the ability to use Unicode's script direction markers and the feature of converting specific character sequences to the matching ligatures. For pre-set strings (e.g. your UI translation), the first problem can be worked around by writing stuff backwards, as you already tried. To work around the second problem, you'd have to directly write the ligature characters (so you have only one character per wanted glyph). I don't know Unicode well enough to tell whether characters for all possible glyphs exist. It might well be that some ligatures always have to be created on-the-fly from a sequence of single-character characters. Of course, both of these workarounds aren't feasible for chat and other run-time user input, because users will be used to write sequences of single characters in reading order rather than ligature characters in left-to-right order. Also, entering these ligature characters (if they even exist) might be complicated and time consuming, because their usual keyboard layout might not give direct access to them. Does anyone have this working? Adding these features to Linden Lab's homebrewn text rendering system would be a major effort that probably none of us is capable of. Alissa Sabre once adapted the Viewer to use Pango for text rendering. ( See http://wiki.secondlife.com/wiki/User:Alissa_Sabre/Pango_adaptation_in_SL_viewer) Pango can handle bidirectional text and ligatures just fine, so this solved the problems. However, these changes haven't been integrated in the official viewer and her patches are now out of date. For chat, using Dzonatas' Icesphere (allows for IM and chat in separate GTK+ windows, thus also using Pango) has been recommended to some Arabic users, and that seems to work alright. Both, the sender and receiver, will have to use it to be able to chat in Arabic script. Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Problem with displaying Arabic menu text in SL client
Are you able to give an example on how to use this character within an XML file? Izze From: syt...@gmail.com Date: Tue, 5 Oct 2010 12:38:44 +0200 Subject: Re: [opensource-dev] Problem with displaying Arabic menu text in SL client To: slli...@boroon.dasgupta.ch CC: iz...@hotmail.co.uk; opensource-dev@lists.secondlife.com U+200F Reverse direction Notes:- Microsoft have a bug, this char don't work sometimes (msoffice 2011 for Mac affected too) - parser work left2right put the char on left side of each entry in all XML files -- Sent by iPhone Il giorno 05/ott/2010, alle ore 12:19, Boroondas Gupte slli...@boroon.dasgupta.ch ha scritto: Hi Izze On 10/05/2010 10:31 AM, izze euler wrote: ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
On Tue, Oct 5, 2010 at 3:08 AM, Celierra Darling celie...@gmail.com wrote: I don't see why mesh editing needs to be considered basic? One philosophical stance is that all types of building whould include an easy path for novices to do that sort of building. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Daily Scrum Update - Monday, October 4, 2010
These emails keep getting corrupted on send (likely due to my extraneous formatting). You can also view the daily updates on the wiki, here: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive But here's a far less fancy update for those who prefer email! :) - Esbee *Daily Scrum Update - Monday, October 4* * * *General Notes* * Merge Monkey of the Day: Merov *Team Status* *Merov Linden* *PAST* * STORM-137: fmod on Windows: fixed fmod.dl not been copied over to build-vc80/newview/RelWithDebInfo. Modif in viewer_manifest.py and cmake/CMakeLists.txt. Committed to dev branch. * STORM-306: water flicker issue: identified the issue as being introduced mid-July in the viewer code. * STORM-330 : Crash in texture rendering: got that crash under the debugger on Windows and logged it immediately. * HR stuff *FUTURE* * New round of SG JIRA scrubbing to prepare sprint planning * Merge Monkeying * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. * STORM-281: integrate? * STORM-306: back burner: bissect and incremental builds till I pinpoint the culprit... *IMPEDIMENTS* * Kakadu license upgrade *Oz Linden* *PAST* * Caught up on email from my vacation * Answered questions from a couple of people on Contribution Agreements * Office Hour * Put in request for change to the download page for Development builds * Started running third party viewer crash reports *FUTURE* * Clarify wiki documentation on where to get code and download binaries * Get current on autobuild developments * Work on proposals for open code review and build systems * Help with code reviews? *IMPEDIMENTS* * none *Q Linden* *PAST* * HR stuff, administration * Planning Q4 * Documenting release process * Crashhunting in beta * Meeting on test automation * Looking into antialiasing *FUTURE* * Answer PE questions on STORM-325 and 295 * HR stuff * Q4 planning * Further meetings on test automation * Writing automation for LLDir *IMPEDIMENTS* * paperwork/planning blocking me from coding *Esbee Linden* *PAST* * VWR triage * Process discussions * Bug hunting * Backlog reviews * Set up new meeting times for Sprint Planning, Retrospective, and Review meetings * HR Stuff * Q4 planning *FUTURE* * VWR triage * Backlog grooming new feature request review * Prep for Sprint 5 * Viewer roadmap planning * Systems requirements research * HR Stuff * Q4 planning *IMPEDIMENTS* * None *Paul ProductEngine * *PAST* * STORM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Fixed, tomorrow will test and send for a review *FUTURE* * other bugs *IMPEDIMENTS* *none *Andrew ProductEngine* *PAST* * Bug STORM-264 (Resize grab areas on detached sidebar panels are tiny and unmarked) ** Reviewed. * Bug STORM-325 (i button no longer opens profiles). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-295 (Mini-inspector fades out if adjust voice volume). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). ** Started investigating. Estimate- 6 hours. *FUTURE* * STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). *IMPEDIMENT*S * STORM-295 and STORM-325 are fixed in viewer-development. What should be done with these fixes? Should changesets with them be transplanted from one repository to another, or simply fixed the same way manually, or left untouched to wait merge with development? *Vadim ProductEngine* OOO - Vacation. Will be back to office on Oct, 11th. *Seth ProductEngine (Sergey)* *PAST* * BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by Name/System Folders to Top Do not apply and settings changes do not persist after relogging. ** Investigated. Waiting for Esbee's reply in JIRA. * BUG (STORM-314) Wear button in My Appearance greyed out ** Investigated. Could not reproduce with reporter's scenario. Probably misfiled. * BUG (STORM-310) crash after setting sound preferences ** Could not reproduce. * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** WIP. *FUTURE* * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** Estimated: 4 hours. *IMPEDIMENTS* * STORM-316 needs answer from Esbee (?) *Andrey ProductEngine* *PAST* * smoke test of 210...@viewer-development * integrated tickets verification on 210...@viewer-development *FUTURE* * regression testing of 210...@viewer-development in scope of changes from previous development builds *IMPEDIMENTS* * none ___ Policies and (un)subscribe
Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable?
An in-world prim-to-mesh converter would both be incredibly powerful and yet also easy to use. Heck, it could be practically transparent to the end-user. Make prims, arrange, and link them * Prims are merged automagically into a mesh * Embedded and overlapping internal surfaces are removed * The original prims disappear from world * The mesh is now the stand-in for the prims Unlink the mesh * The mesh disappears and is discarded. * Prims are reloaded back into the world for editing as individual objects This could shed massive amounts of hidden vertexes from linked prim sculptures, prim vehicles, houses, roads, etc, and significantly improve frame-rates, all while being mostly transparent to the end user... perhaps little more than a checkbox option in the editor : Make linked prims into a mesh? Though I would hope for a way to separately link together prims to make the physics collision surface for a high-prim object. That way a beautiful vase with curved handles can have a simple cylinder collision surface to go with it, and take load off the physics engine. This could be anti-griefed by making sure that the collision surface always has fewer vertexes than the visible mesh it is joined to. - Dale Mahalko / Scalar Tardis On Tue, Oct 5, 2010 at 2:08 AM, Celierra Darling celie...@gmail.com wrote: I don't see why mesh editing needs to be considered basic? I would consider building through prims to be the most basic, to learn how objects/prims/links work and what features are available and what texturing is and the such. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Vertex Edit Capability
I submitted JIRA issue VWR-23202 to provide the simplest in-world editing capability, that of moving vertexes on a mesh. The reasons why include making a clothing item fit better, a large mesh object fit within a land parcel, or fit the other objects in a linkset. As someone learning to build it would also be more fun and interesting to edit shapes. Even for an advanced builder, while we can load the parts of a complex build into our 3D program and get them to fit each other, we cannot load all possible avatar shapes, or the surrounding land for large items, and see how the mesh will fit the surroundings until it is there. I am not proposing a full blown mesh editor, that is best left to specialized software. What I want to see is a way to adjust items so they are more useful once imported/transferred to others, and a learning path for new people. Once they have a taste of modifying a simple library mesh, if they want to do more advanced work they can get some outside software. This is similar in my mind to what we do with textures. We can adjust the color tint, tiling ratio, etc on a texture (simple mods), but if we want to make a whole new texture you get GIMP or Photoshop. For the UI, I suggest using the same XYZ movement gizmo we use now for whole prims, the same numerical input boxes, and the same selection highlight. Just add a radio button to Edit vertex like the Edit linked parts on that's already there. To simplify asset database and server overhead, it may make sense to do the editing local in the client until you leave edit mode. But I will leave technical implementation to those who know more about that side of things. Daniel Date: Mon, 4 Oct 2010 21:47:48 -0700 From: Stickmanstick...@gmail.com Having said that, very simple editors that are not designed to have fancy features but be as basic as possible would allow people to create things without going to an outside source. But it must be clear and planned that they will never evolve beyond a basic level. Stickman -- From: Science Fiction Computer - SCi-Fi PCpartn...@scifipc.com Subject: Re: [opensource-dev] Unity 3D as possible base / 2.x Codebase plugin capable? If mesh becomes a standard in SL, a basic mesh editor ought to be included by default. ... SL Viewer Mesh Editor doesn't need to be Maya, it just needs to be 'there' and 'basic' to encourage new content creators to create and feel that they begin to learn and participate without significant barriers. We must try and avoid any situation where a New User in SL feels disadvantaged or unable to create before they start. Regards, DMC Zsigmond-Jurassic Science Fiction. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Inventory Organization Feature Request
As a user, I would like to be able to have better tools to keep my inventory neater and put less load on the server when it loads. I would love a search for duplicate uuid option so I can easily remove duplicates. I would also like an option to have certain things received go in designated folders, for instance if i open a purchased item and there is a landmark in the box , the landmark automatically can go into the landmark folder. Maybe possibly a warning popup saying I already have an item with this uuid in my inventory and asking if they can discard the new one. An option when i do a search to be able to select all items returned without selecting the folder its in, for instance if i search for key phrase floating text or unpackboxscript I can highlight all the returns just deleting that one item out of every folder. I would also like a function to remove old landmarks where the parcel no longer exists, same with avatar calling cards. Every single landmark in my inventory loads up when I start my viewer to check to see if I have visited that place before, it remembers places I havent vistted since 2006, just so it can change the pushpin color, is this really needed? Thank you Miss ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Inventory Organization Feature Request
You might want to split this up into several things: - Duplicate avoidance (I believe you may be surprised at how rare true duplicates are, since every time you take something scripted back from the world into inventory, it will be a new asset with a different script state - so even this duplicate detection may involve several user stories) - Improved unpacking (How about -not- unpacking and using a delivery to folders and subfolders instead? Do you really want things to be auto-sorted by class? Many people would disagree there) - Improved selection (How about making ctrl-A select all -visible- items in the inventory window?) - Improve performance by changing the way inventory is loaded and accessed (there is work in progress on the server/web service side there). -- cg On Tue, Oct 5, 2010 at 8:29 AM, miss c miss_c...@yahoo.com wrote: As a user, I would like to be able to have better tools to keep my inventory neater and put less load on the server when it loads. I would love a search for duplicate uuid option so I can easily remove duplicates. I would also like an option to have certain things received go in designated folders, for instance if i open a purchased item and there is a landmark in the box , the landmark automatically can go into the landmark folder. Maybe possibly a warning popup saying I already have an item with this uuid in my inventory and asking if they can discard the new one. An option when i do a search to be able to select all items returned without selecting the folder its in, for instance if i search for key phrase floating text or unpackboxscript I can highlight all the returns just deleting that one item out of every folder. I would also like a function to remove old landmarks where the parcel no longer exists, same with avatar calling cards. Every single landmark in my inventory loads up when I start my viewer to check to see if I have visited that place before, it remembers places I havent vistted since 2006, just so it can change the pushpin color, is this really needed? Thank you Miss ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Access to an object's inventory without rezing (was: Inventory Organization Feature Request)
On 10/05/2010 05:47 PM, CG Linden wrote: # Improved unpacking (How about -not- unpacking and using a delivery to folders and subfolders instead? Do you really want things to be auto-sorted by class? Many people would disagree there) Well, that's something the buyer can't choose. It depends on the seller. But how about not unpacking (in case of in-object delivery) and being able to access the contained items anyway? See VWR-2427 https://jira.secondlife.com/browse/VWR-2427 (Allow objects containing other items to be expanded within the Inventory). Cheers, Boroondas ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Problem with displaying Arabic menu text in SL client
On Tue, Oct 5, 2010 at 4:32 AM, izze euler iz...@hotmail.co.uk wrote: Are you able to give an example on how to use this character within an XML file? Using that character won't have any effect. As Boroondas mentioned, Second Life's text engine is pretty basic and simply doesn't support: - Right-to-Left scripts - typically this functionality is called BiDi since the direction actually changes within text strings for numbers, foreign words, etc. - Contextual shaping (think: ligatures as a mandatory language feature) - Combining characters/diacritics* (think: characters merge into single glyphs) - Complex word breaking (for languages that don't use spaces) This is a big task, and (as Boroondas also mentioned) is probably best tackled by a thorough overhaul/replacement of SL's text rendering engine as Alissa Sabre attempted. Additionally, if we're talking about a localized version of the UI and not just rendering text content correctly, you'd also want to flip the X coordinates for some (but not all) UI layout if the app was running with a UI language that was RTL, which would require changes to the XUI engine and some of the controls. (Since, ideally you don't have to touch all of the control rects in all of the XUI files) -- Josh * I look forward to the day when someone writes a text engine that handles the character combining logic for classical Mayan. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Latest LL viewer beta has inventory count issues?
Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Vertex Edit Capability
On Tue, Oct 5, 2010 at 8:25 AM, Daniel danielravenn...@gmail.com wrote: I submitted JIRA issue VWR-23202 to provide the simplest in-world editing capability, that of moving vertexes on a mesh. One of the most likely starting points I see is the terrain editor. That is a limited mesh editor in itself. (one of the other Daniels) -- Daniel Smith - Sonoma County, California http://daniel.org/resume ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Unity 3D as possible base for future (maybe even official) SL Viewers
Agreed (a day late). Teravus' post is great -- very insightful, and it mimics our own thinking. The complexity of what we render, and the fact that it's not professionally created content, means that we get all sorts of edge cases that aren't a problem in traditional graphics engines. Many systems, including Unity, put constraints on the content they'll render to achieve speed or certain effects. We don't have the same sorts of limitations, and so our engine needs to be special. I know we've had people who've evaluated Unity as well as other engines, including Ogre, and it's by no means a simple problem to figure out how to get our content into those systems without choking them. It may be possible, and one of the things I'd like to do is abstract our renderer better so that we have the ability to try a few experiments without re-implementing all of the viewer. Anyway, I guess that graphics systems are kind of like Tolstoy's unhappy families: each one sucks in its own way. It so happens that ours is designed for our content (surprise!), and our content is weird, so other engines may not be as obviously well suited to displaying it as you might think. Q On Oct 4, 2010, at 8:32 AM, Teravus Ovares wrote: When working on IdealistViewer, I noticed that, generally, third party 'general purpose' renderers like Irrlicht and Ogre are not well suited for rendering objects at the quantity that SecondLife prims require. Rendering prims /can/ be done with them, however, not at the level that can be done with the SecondLife viewer. With Irrlicht, for example, the memory load of a typical 5000 prim scene runs up against the 2GB memory limit. With SecondLife prims, it's more about segmenting the render data so that only the unique things are kept and everything else is a reference to something that was calculated before. Out of the box, Irrlicht requires per-instance knowledge about texture, mesh buffer, face and lighting settings configurations. This and reference/const/value type semantics used in the engine causes far more data duplications then are necessary. Prims are strange for rendering. The prim's mesh result is complex in terms of vertex count however, in a given 5000 prim scene there's on average 130 'unique' prim mesh. Those 130 unique mesh are duplicated with various textures, colors, orientations and associated data to make for the entire prim count in the region. In theory, you can manage memory reasonably well by using a 'mesh factory' pattern where by the mesh factory keeps track of instance counts and generates a new mesh when required. In practice, however, the associated data makes this very difficult. In Irrlicht, the API is such that the texture configuration data is 'stuck in with' the mesh data object.So, to get the variability that the secondlife prim scene requires, you're also duplicating the mesh and making small changes to the object's visual configuration data. Irrlicht, like Ogre, is better optimized for a smaller number of more complex mesh objects then a very large number of highly 'instancable' objects with very small differences. I'd comment on the opposite of the last statement... but I don't really know about how the SecondLife viewer works under the hood to do so (OpenSimulator Developer). I don't think that this issue is going to 'go away'. In fact, introducing mesh in the viewer is going to make that memory, speed, and instancing balance even more difficult to maintain.The gap between the viewer and 3rd party 'general purpose' rendering tools will narrow in both directions.. the viewer will get better at managing arbitrary mesh and 3rd party 'general purpose' rendering tools will be able to render secondlife scenes better because there will be less 'prim' to render as a result of there being arbitrary mesh. In either case, the future is full of interesting technical challenges.I think in unity, like with Irrlicht, smaller, more specialized scenes will work OK with regards to prim rendering. And, I don't think 3rd party renderers are going to be able to come close to the capability of the SecondLife viewer when dealing with prim. They're just not designed for the same type of data. The object models and API just are not really appropriate for prim. I'm not saying that it isn't worth pursuing a render plugin architecture. I am saying, however, that given that 3rd party 'general purpose' renderers are never going to be able to meet the SecondLife viewer's capability in rendering prim, it probably shouldn't be very high on the priority of things to do. Regards Teravus On Mon, Oct 4, 2010 at 12:36 AM, Brandon Husbands xot...@gmail.com wrote: Ive used it, and fount it blehh. I think we are failing to communicate about our conception of what is possible and what is used. Are you saying that the
Re: [opensource-dev] Latest LL viewer beta has inventory count issues?
Recently reported against Second Life Server 10.9.10.210079SVC-6353https://jira.secondlife.com/browse/SVC-6353Inventory fails to load fully https://jira.secondlife.com/browse/SVC-6353 It has been ongoing for well over a year so maybe not the issue you are seeing. Reporter *was* using Second Life 2.2.0 (210127), so maybe this issue is more obvious in the 2.2 Beta. Older issue SVC-5902 https://jira.secondlife.com/browse/SVC-5902 Client gives up before finishing to load full inventory due to packet loss and request for a refresh button VWR-23074https://jira.secondlife.com/browse/VWR-23074Unloading item on my inventory, cause some useless relog. Other possibly related (to a slow/incomplete Inventory loading) issues - VWR-23308 https://jira.secondlife.com/browse/VWR-23308Can't rename a new folder https://jira.secondlife.com/browse/VWR-23308 - STORM-314 https://jira.secondlife.com/browse/STORM-314Wear button in My Appearance greyed out https://jira.secondlife.com/browse/STORM-314 On 5 October 2010 18:04, Ann Otoole missannoto...@yahoo.com wrote: Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010
Tuesday, October 5, 2010 *General Notes* * Merge Monkey of the Day: Merov *Team Status* *Merov Linden* *PAST* * JIRA triage to prepare sprint planning * Merge Monkeying: move things in beta, v-d, also pulled beta in v-d so we have those fixed in v_d as well. * More HR stuff *FUTURE* * Sprint planning! * STORM-137 : FMOD issue: fix upload issue with Brad. Hopefully, the rest will be easy. * STORM-105 : Perf decompression: put new data out, check the work done by opensource-dev community on similar tests. * STORM-306: back burner: bissect and incremental builds till I pinpoint the culprit... *IMPEDIMENTS* * Kakadu license upgrade *Oz Linden* *PAST* * Clarified wiki documentation on where to get code and download binaries ** Updated to use new auto-update direct links ** Submitted request to change main download page to match * TPVP Changes *FUTURE* * Worked on proposals for open code review and build systems * Get current on autobuild developments *IMPEDIMENTS* * none *Q Linden* *PAST* * HR stuff * Q4 planning * Further meetings on test automation * Writing automation for LLDir *FUTURE* * HR stuff * Q4 planning * Answer PE questions on STORM-325 and 295 *IMPEDIMENTS* * My brain *Esbee Linden* *PAST* * VWR triage * Sprint 5 planning * Backlog reviews * Q4 planning * Systems requirements research *FUTURE* * VWR triage * Sprint 5 Planning * Viewer roadmap planning * Systems requirements research * Q4 planning * HR Stuff *IMPEDIMENTS* * None *Paul ProductEngine * *PAST* * STORM-263 Cog button in lower-left of sidebar panel does not close popup menu on second click ** Fixed, tomorrow will test and send for a review *FUTURE* * other bugs *IMPEDIMENTS* *none *Andrew ProductEngine* *PAST* * Bug STORM-264 (Resize grab areas on detached sidebar panels are tiny and unmarked) ** Reviewed. * Bug STORM-325 (i button no longer opens profiles). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-295 (Mini-inspector fades out if adjust voice volume). ** Reproduced in viewer-beta, investigated, found changeset with fix in viewer-development and left comment in ticket. * Major bug STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). ** Started investigating. Estimate- 6 hours. *FUTURE* * STORM-315 (Changes to Environment Editor are not saved and do not persist across sessions). *IMPEDIMENTS* * STORM-295 and STORM-325 are fixed in viewer-development. What should be done with these fixes? Should changesets with them be transplanted from one repository to another, or simply fixed the same way manually, or left untouched to wait merge with development? *Vadim ProductEngine* OOO - Vacation. Will be back to office on Oct, 11th. *Seth ProductEngine (Sergey)* *PAST* * BUG (STORM-316) Debug: Inventory.Folders by Name/Sort by Date/Sort by Name/System Folders to Top Do not apply and settings changes do not persist after relogging. ** Investigated. Waiting for Esbee's reply in JIRA. * BUG (STORM-314) Wear button in My Appearance greyed out ** Investigated. Could not reproduce with reporter's scenario. Probably misfiled. * BUG (STORM-310) crash after setting sound preferences ** Could not reproduce. * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** WIP. *FUTURE* * BUG (STORM-305) Undocked minimized SP tabs are restored after re-login ** Estimated: 4 hours. *IMPEDIMENTS* * STORM-316 needs answer from Esbee (?) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Where oh where has my rendering gone?
Oh where oh where could it be! Anyone can point me in the direction of the RGB rendering system in the client? Am thinking about making a switch for bw output to the client. just have no idea where to start poking this beast. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Latest LL viewer beta has inventory count issues?
Could be related to an existing pjira which is why I asked. However it is restricted to code after the LL production release candidate. I observe this in the latest Kirstens and the beta viewer. Deleting cache and refreshing in the production viewer produces the expected inventory count. Therefore it appears to be related to the newer code base only. However I do know asset data is vanishing. I have a ticket open and never looked at in respect to a humble shoe texture I created and uploaded to SL that has vanished from the asset system. Easily replacable yes but highly annoying to know data seemingly vanishes into thin air that way. However the inventory record for that texture remains intact. When previewed or rezzed the texture just stays gray. No matter who tries to view it. That is an asset issue not an inventory issue. From: Ellla McMahon elllamcma...@googlemail.com To: Ann Otoole missannoto...@yahoo.com Cc: opensource-dev@lists.secondlife.com Sent: Tue, October 5, 2010 3:41:06 PM Subject: Re: [opensource-dev] Latest LL viewer beta has inventory count issues? Recently reported against Second Life Server 10.9.10.210079SVC-6353Inventory fails to load fully It has been ongoing for well over a year so maybe not the issue you are seeing. Reporter was using Second Life 2.2.0 (210127), so maybe this issue is more obvious in the 2.2 Beta. Older issue SVC-5902 Client gives up before finishing to load full inventory due to packet loss and request for a refresh button VWR-23074 Unloading item on my inventory, cause some useless relog. Other possibly related (to a slow/incomplete Inventory loading) issues * VWR-23308Can't rename a new folder * STORM-314Wear button in My Appearance greyed out On 5 October 2010 18:04, Ann Otoole missannoto...@yahoo.com wrote: Anyone else noticing the inventory counts in the latest LL beta client are increasingly less than the count in the production release client and that cache clear does not correct it? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010
I hope all this HR stuff is OK. It is making us nervous out here. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Daily Scrum Update - Tuesday, October 5, 2010
We've all been working on our end-of-year reviews. Nothing to worry about! :) (We'll make a point of being more clear about this in future, sorry!) - Esbee On Tue, Oct 5, 2010 at 7:49 PM, Ponzu lee.po...@gmail.com wrote: I hope all this HR stuff is OK. It is making us nervous out here. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Where oh where has my rendering gone?
Well, it's not quite like that. To pull this off, you'd have to take everywhere we set a color, and set it instead to its equivalent black and white value (there's a formula that's traditionally used, although there's no correct way to do it: Y = 0.3*R + 0.59*G + 0.11*B). You *might* be able to get away with modifying the LLColor4 constructor to do this, but it's probably going to have some surprising results when you assign a value and don't get the same value back. Next, you'd have to filter all of the textures so that all textures are first converted to BW before being used. That's also a troublesome task, and is likely to be slow. On certain graphics cards, you could try to convert all the pixel shaders to do a BW conversion for each pixel before rendering, but I don't know enough about our system to know if that would catch all the useful cases or not. I hope that helps, but I'm not particularly optimistic. :/ Q On Oct 5, 2010, at 5:36 PM, malachi wrote: Oh where oh where could it be! Anyone can point me in the direction of the RGB rendering system in the client? Am thinking about making a switch for bw output to the client. just have no idea where to start poking this beast. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
