Re: [opensource-dev] New Release Viewer 3.4.0 being partially blocked by popular antivirus-software AVAST
On Fri, Sep 14, 2012 at 3:47 AM, Martin Fürholz wrote: > The latest release viewer 3.4.0 from > http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-release/rev/264700/arch/CYGWIN/installer/Second_Life_3-4-0-264700_Setup.exe > is being partially blocked by the popular antivirus-software AVAST. > The webkit plugin fails to load. Avast puts it into a sandbox by default > because it is: 'not wide-spread enough or has bad reviews'. Avast's heuristics do that with more obscure software all the time. I've even had them randomly sandbox fairly well-known games downloaded from Steam. It might be worth you just disabling some or all of the heuristics until they manage to reduce the false positives a bit. ___ 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] Linux64 "boost 1.39" is still actually boost 1.34.1
Hi, It looks like the packaged linux64 version of boost, http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux64-20100119.tar.bz2, is still actually the mislabelled boost 1.34.1. Is there a newer build available? Thanks, Aidan ___ 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] Convexdecomposition for open source devs
On Thu, Dec 30, 2010 at 2:03 PM, WolfPup Lowenhar wrote: > Bullet Physics Library(just the convexdecomp section): > > Web site : http://code.google.com/p/bullet/ > > John Ratcliff's: > > Web Site : > http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html I seem to recall that the Bullet convex decomposition is actually based on an older version of John Ratcliff's code with their own improvements added. The two use completely different APIs, though, so there's probably no easy way to switch between them. ___ 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] Linux 64bit and gstreamer
On 12/12/10, Argent Stonecutter wrote: > You know what would really help people get over the hump of setting up for > building SL? > > A VMware appliance containing a working SL build environment, for 32 and 64 > bit Linux. It's sort of vaguely on my TODO list, possibly including a way of creating all the prebuilt library bundles needed to make an actual SL release. There are certain practical and licensing issues, though. Also, being able to actually run Second Life within the VM could be fun... ___ 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] Linux 64bit and gstreamer
On 12/12/10, Marc Adored wrote: > Awesome I will checkout the latest then and try to compile it. I > wasn't aware it was even close to working. I'm excited now. It's actually been possible for a while, but until recently you had to manually dig up patches from the Wiki in order to compile a 64-bit viewer successfully. Last time I tried, the major obstacles were: * Having compiled Google Breakpad, getting the viewer build process to find it is fiddly. It seems to require a slightly odd layout for the header files. I had to manually create some directories with the correct names and copy the headers to them. * Building a 64-bit version of llqtwebkit is a real pain. I believe the Imprudence developers have created a pre-compiled version of this recently - if it was available when I was trying, I'd have been tempted to use 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] LGPL violation
On 10/28/10, Erik Anderson wrote: > There is a static component that is linked when linking to dynamic > libraries, however that is present mostly to inform the compiler on what the > ABI is, or how your compiled code is expected to interact with the DLL. It > is very possible to write a piece of code that explicitly loads the library > by name and manually builds calls to it. In fact, it's likely possible to > compile a program intended to run with a .dll without any related files > being on the machine at the time. Yeah, but that's not what we're talking about. libmedia_plugin_webkit.so is in fact linked statically with various Qt libraries - the entirety of the code for those Qt libraries is incorporated into libmedia_plugin_webkit.so by the linker at compile time, not just a stub. The same happens with libmedia_plugin_webkit.a and libmedia_plugin_webkit.dylib. I'm not sure exactly why Linden Lab decided to do this - it's not a common thing to do and getting it to work right requires a certain amount of mucking with the build system, since static libraries normally aren't compiled with options that allow them to be included in a shared library - but do it they did. ___ 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] Mesh Source Code ETA
On 10/22/10, Zabb65 wrote: > Looks like this does not need an answer now. Code is up. > http://hg.secondlife.com/mesh-development/ > \o/ Oh, lovely: /** * @filellphysicsshapebuilder.cpp * @brief Generic system to convert LL(Physics)VolumeParams to physics shapes * @author fal...@lindenlab.com * * $LicenseInfo:firstyear=2010&license=internal$ * * Copyright (c) 2010, Linden Research, Inc. * * The following source code is PROPRIETARY AND CONFIDENTIAL. Use of * this source code is governed by the Linden Lab Source Code Disclosure * Agreement ("Agreement") previously entered between you and Linden * Lab. By accessing, using, copying, modifying or distributing this * software, you acknowledge that you have been informed of your * obligations under the Agreement and agree to abide by those obligations. * * ALL LINDEN LAB SOURCE CODE IS PROVIDED "AS IS." LINDEN LAB MAKES NO * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, * COMPLETENESS OR PERFORMANCE. * $/LicenseInfo$ */ I do wish organisations wouldn't do things like this... it's a real pain. ___ 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] Mesh Source Code ETA
On 10/22/10, Zabb65 wrote: > Looks like this does not need an answer now. Code is up. > http://hg.secondlife.com/mesh-development/ > \o/ Looks like convex decomposition support has been pulled. "LLConvexDecomposition is a proprietary library based on Havok (TM) physics libraries. In its place, Linden Lab shares the code for LLConvexDecompositionStub, a stub version of the same library with no proprietary components." I'd suggest porting the convex decomposition code from something like (for example) Bullet instead might be a good idea. ___ 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] O.O Display name code DROP!
On Fri, Oct 15, 2010 at 7:15 AM, Jamey Fletcher wrote: > Is there actually a *reason* for this change, or is it just to screw > around in the code to do provide an opportunity for new bugs, such as > the one you found already? I suspect the reason for the change is that with display names, the names of participants in IMs and group chat no longer uniquely identify them - and the usernames, which are unique, aren't available at the point where the logging of chat and IMs is done. This also has the interesting side-effect that it's incredibly difficult to figure out who actually said something just from your chat logs, because the only information in there that actually identifies them is their UUID. ___ 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] 2.0 Absolute Dealbreaker - script count feature request
On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden wrote: > Unfortunately no. LSL scripts take up 16k of memory no matter how much they > actually use. Is there any technical reason why this can't be made adjustable, though? I know that changing the amount of script memory available for LSL scripts would require a recompile, since it's fixed at compilation time, but I suspect it could be done. ___ 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] Openjpeg/KDU the cold hard metrics
On 9/21/10, Robin Cornelius wrote: > I'm still not 100% sure why the build of openjpeg supplied by imprudence > is better than my builds on 2005. Imprudence is using the openjpeg SVN trunk version from a few months ago, which is essentially a pre-release version of openjpeg 1.4 and is slightly more optimised than 1.3. You might want to try openjpeg from SVN yourself (the trunk version, not the 2.0 branch). Make sure to try it with SSE enabled too - it has some SSE-specific optimisations. ___ 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] User Story: Improved Cache
On 9/19/10, Argent Stonecutter wrote: > Perhaps Tateru was referring to the prim data changing (eg, geometry) while > the prim UUID stays the same. I don't think the viewer makes any assumptions > about prims being unchanged from session to session, so that's not something > that would need to be verified in the cache. Actually, I'm pretty sure it does, at least in viewer versions where caching hasn't accidentally been rendered totally ineffective by a Linden Labs typo. In fact, there's a fairly elaborate system for caching prim data to disk. As I recall, it detects changed prims using the CRC field, which is completely misnamed and is really a generation counter that records the number of changes to the prim. Then there's the CacheID, which invalidates the whole sim's cached data where necessary (e.g. if the sim moves or crashes, or perhaps even if it just restarts at all - would have to ask one of the Lab folks). ___ 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] The Plan for Snowglobe
On 9/8/10, Oz Linden (Scott Lawrence) wrote: > * Remove viewer-external from hg.secondlife.com Am I right in thinking there's no revision history in here that isn't available in more useful and fine-grained form in viewer-external? > * Take down the Snowglobe subversion repository That's going to be kinda obnoxious, because it means non-Linden Labs developers won't be able to look back at what was changed in Snowglobe, when and why. There will still be mainstream 1.23-based viewers by then unless Linden Labs does something incredibly brilliant or something incredibly stupid, and they'll still have a use for the Snowglobe version control history. ___ 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] Display Names open source
On Sun, Sep 5, 2010 at 8:54 AM, Henri Beauchamp wrote: > Any chance to get a single diff between the base sources of the viewer > version that was used to implement display names, and the fully display-names > implemented viewer sources ?... Or to get a hold on the sources for the viewer > on which the display-name viewer was based ?... That would be a great help > for porting this feature to TPVs... > > Henri. If Linden Labs have been using Mercurial properly, that should be fairly easy - and in fact it is relatively easy. Last merged revision from the upstream code is currently b532610841b5, so "hg diff -r b532610841b5" will produce the appropriate diff. It's huge, though! ( http://www.makomk.com/~aidan/viewer-display-names-to-ab6c7c8908a4.patch - see what I mean?). This is actually something that's slightly easier to do in git, but oh well... ___ 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] This is how Linden Lab treats it's customers...
On Sat, Aug 28, 2010 at 6:54 PM, Meadhbh Hamrick wrote: > but for reasons i never learned, linden never implemented prim > restrictions for openspace sims. so even though you were only supposed > to have some small number of prims in an openspace sim, the system let > you go over that limit. so guess what happened? yes, that's right, > people started putting a lot of prims on sims hosted on overloaded > cores. some sim owners even went so far as to rent out openspace sims > to people without mentioning the fact that their new virtual parcels > were hosted on CPUs that were a touch overtaxed. That's the interesting thing. Linden Labs did implement prim restrictions for openspace sims from the start. In fact, they had quite a small prim limit - 1875 prims, which was enough for the intended use and possibly a low-prim house somewhere for one or two users. Then Linden Labs, in an effort to make them more widely useful, *doubled* the prim limit. This was quite widely advertised at the time, and a large number of people bought them... just in time for Linden Labs to pull off a significant and unexpected price increase together with more restrictions. Of course, at that point everyone had already invested money and time in their regions that they didn't want to see wasted. ___ 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] Removal of the "MultipleAttachments" debug settings ?
On Thu, Aug 26, 2010 at 8:53 PM, Altair Sythos wrote: > On Thu, 26 Aug 2010 21:45:14 +0200 > Marine Kelley wrote: > > >> I for one would very much like to see the MultipleAttachments debug >> setting come back and stay ! > > i use multiple attachments, quite all users (but not emerald neither > imprudence) see them correctly, all kirsten viewers (on kirsten is > enabled by default on last 2 builds) rezz them fine, both SL2 users (if > they don't turn TRUE the debug options too, they say...) So in other words, exactly what Marine Kelley said - they only show up properly for users of Viewer 2 or a third-party viewer based on it. That's quite a lot of Second Life users who won't be able to see some attachments you're wearing in an unpredictable fashion. ___ 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] Encrypted chat & third-party servers
On 8/25/10, Brian McGroarty wrote: > Has anyone spent time looking at the encrypted chat feature included in some > third-party viewers? It's my understanding that this contacts third-party > servers in obtaining and validating keys. Is that correct? If so, do these > connections share any information about the user that we should require to > be disclosed per section 4.b of the TPV Policy?[1] I haven't looked too closely at the encrypted chat in Emerald and similar viewers, but my understanding is that it - and all the other third-party viewers - use OTR in a fairly standard way. OTR is deliberately designed not to use any third party server to obtain or validate keys - instead, it provides a way for pairs of OTR users to validate each other's keys directly with each other[2]. All communication happens over the underlying IM protocol, in this case Second Life IMs. Unless someone's really screwed up the implementation in one of the viewers, OTR should have no interesting privacy implications whatsoever. OTR keys are designed to be per-account (so provide no way of matching up alts) and the encryption scheme used carefully avoids non-repudiation; that is, neither party can use it to prove what the other said to a third party after the fact any more than they could with plain-text IMs. It's basically pretty benign. [1] NMF. [2] Specifically, it uses the Socialist Millionaire Protocol to verify the keys, using a piece of information that only the two people know. See http://en.wikipedia.org/wiki/Socialist_millionaire - note that neither the secret answer nor any information that could usefully help to determine it is ever shared with the other party! ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
On Sun, Aug 22, 2010 at 1:22 PM, Ann Otoole wrote: > What I think LL should consider is something in the TPV policy that > prohibits any tpv from connecting to any non LL server for any reason when a > LL grid is selected for login. This simple policy, if correctly followed, > would have prevented the incident. It would also eliminate a tpv team from > monitoring logins and usage but then where exactly did they get to do that > in the first place? It also prevents third-party viewers from notifying users that updates are available, including security updates. Whole bunch of other stuff too - for example the official Second Life login screen doesn't actually work on unofficial viewers. Besides, both incidents like this and undisclosed monitoring of usage violate the TPV policy anyway (and at least one of Emerald's privacy issues didn't involve connecting to any non-LL server at all). Have you taken a look at Imprudence's Privacy Policy, for example (http://imprudenceviewer.org/wiki/Imprudence:Privacy_policy)? This is roughly the level of disclosure the policy calls for regarding data collection associated with viewer use (the information related to the website goes beyond what the policy requires). I assume Emerald has a similar page somewhere too. ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
On 8/22/10, Phox wrote: > The website in question suffered no ill effects, and to imply that > loading a .php and a few images is an attempt at DDOS is just > ridiculous, our login page consists of a .php script a hi-res picture, > and our website doesn't go down as a result. Your website did go down because of the load, though - a whole bunch of times in fact! There's even still an entry in the Emerald FAQ about it[1]: "Due to a problem with our webhost 500 errors are increasingly common with new traffic. Please wait a few seconds and try to reload the page, it may take a few tries before you get through." The only reason it doesn't anymore is because you moved to a bunch of really chunky and expensive dedicated servers. http://blog.modularsystems.sl/2010/07/19/emerald-user-statistics/ says that you're using two of http://www.hetzner.de/en/hosting/produkte_rootserver/eq4/ - each of which is about as powerful as some of the older Class 5 Linden Labs servers that host 4 regions each - plus a third unspecified dedicated server. Hazim was using cheap shared hosting. What's more, the guy from the Emerald project who did this knows just how much load the Emerald login screen puts on Emerald's servers, because he apparently pays for and runs them! On 8/22/10, Katharine Berry wrote: > No it doesn't. If it was a PHP script then I could've made much of the code > much simpler when I made the thing. > > It was very deliberately not a PHP script, for reasons of load. Yep, looking at the headers it's definitely static HTML. We've got an Accept-Ranges header, a Content-Length header (both of which you can get from PHP scripts but wouldn't normally), and most importantly an ETag in the same format lighttpd uses for static content. Also, the login page wasn't just making one request for a PHP-generated page from Hazim's website - it was making 20 requests for the same page. [1] http://www.modularsystems.sl/wiki/wikka.php?wakka=FAQ ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
On Sat, Aug 21, 2010 at 3:04 PM, Thomas Grimshaw wrote: > Loading 1mb of content per user is hardly a denial of service attack. > Crosslinking occurs everywhere on the web, this is simply nothing but > paranoid bull. This isn't normal crosslinking. The images and content loaded weren't actually used for anything - they were all hidden in a 1-pixel DIV to make them totally invisible to the user. (The Emerald developers wouldn't want them to be displayed on the login screen since many of the images were ones showing they'd been up to no good.) You also have no idea how often the Emerald login screen is viewed, do you? I'll give you a hint - this apparently worked out at around 70-120 GB per day of data transfer[1]. At the cheaper end of excess bandwidth charges, this could easily have cost a victim £200 per day or more - most people don't have over 2 terabytes of monthly transfer allowance included in their web hosting plan, which is how much would've been needed to withstand this attack. Before the Emerald developers upgraded their webserver to something seriously beefy, just the normal requests for the login screen were bringing their website to a standstill, and the number of users has only increased since then. And the bandwidth usage isn't even the main DDoS vector. The Emerald login screen was set up to waste lots of server CPU time by making 20 worthless requests for PHP-generated content on the victim server every time someone viewed it. That did cause some real performance issues for the victim site - shared hosting really can't cope with this kind of request rate for dynamically-generated content. [1] http://www.sluniverse.com/php/vb/general-sl-discussion/47885-emerald-problem-conspiracy-theory-5.html#post999709 ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
You may recall that the Emerald viewer has been leaking potentially privacy-infringing information - specifically, the directory to which it's been installed, which in some cases includes usernames - in encrypted form in baked textures. You may also recall that the developers lied and said the issue was fixed, when really they just leaked the same data but with stronger encryption to hide it better. Well, it turns out that the Emerald developers have been using their viewer to launch a Distributed Denial of Service attack on the website of the person who discovered this[1]. The attack involved loading about 1 MB of images and a whole bunch of dynamically-generated content from the Emerald login screen displayed every time a user opened Emerald to consume both bandwidth and server CPU time.[2] This served no purpose other than to try and DoS the server - none of the loaded content was visible or used. The Emerald developers have even admitted as much, though they're trying to spin it interestingly[3]. (Their explanation is total bullshit - if they just wanted to make a point about the number of Emerald users rather than attack the server, loading a single file would do.) Now, this is of course entirely in violation of the TPV policy, which forbids certain content - including DoS attacks - within third party viewers. The question is, does the Lab care and will they even remove the viewer in question from the TPV directory? [1] http://www.sluniverse.com/php/vb/general-sl-discussion/47885-emerald-problem-conspiracy-theory-3.html#post997824 [2] See http://pastebin.ca/1921405 for a copy of the actual code. [3] http://blog.modularsystems.sl/2010/08/20/shenanigans/ ___ 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] display names = the end of 1.x viewers?
On 8/19/10, Kelly Linden wrote: > I just wanted to point out that this theoretical new user's username would > be baloo198731, it would not be baloo198731.resident. The 'Resident' isn't > really a part of a new user's identity. It is only shown to viewers that do > not support display names and legacy LSL script calls - in other words that > last name is only there when required for backwards compatibility. > Which has the interesting side-effect that you can't trivially convert from a username to a legacy full name since there are two different possible conversions and no way of telling which is correct without accessing the login database, right? ___ 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] Open Viewer Development Announcement
On 8/18/10, Oz Linden (Scott Lawrence) wrote: > While there were some good things about the v1 implementation of pie > menus, they also had some flaws - such as not opening a submenu centered > on the mouse click. I actually puzzled over this a bit when I first realised that Second Life's pie menus worked this way. Originally, the pie menus worked well when you didn't click too close to the edge of the screen but didn't actually open under the mouse cursor if you did. Since the "More..." item is sensibly always the southmost one, opening new submenus centered on the mouse would cause the pie menu to drift down the screen until it hit the bottom and caused problems. Also, opening the submenu at the same location has the nice side-effect that the mouse remains over the "More..." option for the pie menus that are nested 3 or more levels deep. What I have been contemplating is how to make it possible to open the next layer of a pie menu without moving the mouse at all. Sadly, it'd probably break too much from normal UI conventions to be worth doing. ___ 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] Open Viewer Development Announcement
On 8/16/10, Oz Linden (Scott Lawrence) wrote: > Think about it for a minute - there are an infinite number of possible > solutions for how to build a UI for a virtual world viewer - what are > the odds that the first or second attempt produced the best possible > UI? We need new and creative ideas focused on specific problem > descriptions. The trouble is - and I've said this before - that whoever designed the New, Shiny and Improved Viewer 2.0 interface clearly didn't think too much about why the Viewer 1.0 UI was designed the way it was, what advantages this has, or how it was actually used. For example, this shows up in the replacement of pie menus with standard right-click menus. The big advantage of pie menus is that they're fast to use - all the entries are large and easy to hit with the mouse. The new right-click menu, on the other hand, has really tiny entries that make you hunt with the mouse. Unlike in Second Life, in most applications the right-click menu is not intended as the main way to interact with the application - anything commonly-used can be accessed in another faster way. Then there's the sidebar and the impossibility of opening more than one person's profile at once, or of getting back to someone's profile once you've clicked on one of the groups listed therein... Oh, and Viewer 2 is still a bit hit and miss about making keyboard shortcuts for commonly-used functionality discoverable in some places. For example, I'm not sure if the shortcuts for Always Run or Fly/Stop Flying are displayed anywhere. ___ 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] Mesh rendering: What does indicesp provide?
Hi, On Thu, Jun 3, 2010 at 12:35 AM, Rob Nelson wrote: > I am working on the rendering code in the SL viewer at the moment, > having completed the server-side code and some of the client-side > packet-handling classes. However, I have zero familiarity with OpenGL, > so bear with me. > > My viewer needs to construct a terrain surface (a mesh) for display. I > have completed an LLViewerObject to this end, except for: > > ::getGeometry(LLStrider &verticesp, >LLStrider &normalsp, >LLStrider &colorsp, >LLStrider &texCoords0p, >LLStrider &texCoords1p, >LLStrider &indicesp) > > What is confusing me is indicesp. I think it has something to do with > connecting vertices, but I'm not sure how. I think you should find it's a list of indexes into the vertex, normal, etc arrays that's later passed to glDrawElements, but I'm not 100% sure. > The example code I am > working with uses a mess of lookup tables in the following loop for each > voxel: > >//Draw the triangles that were found. There can be up to five per cube >for(iTriangle = 0; iTriangle < 5; iTriangle++) >{ >if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] < 0) > break; > >for(iCorner = 0; iCorner < 3; iCorner++) >{ >iVertex = > a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner]; > >vGetColor(sColor, asEdgeVertex[iVertex], > asEdgeNorm[iVertex]); >glColor4f(sColor.fX, sColor.fY, sColor.fZ, 0.6); >glNormal3f(asEdgeNorm[iVertex].fX, > asEdgeNorm[iVertex].fY, asEdgeNorm[iVertex].fZ); >glVertex3f(asEdgeVertex[iVertex].fX, > asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ); >} >} So, for example, you would convert this code by appending each iVertex used to indicesp in turn rather than rendering the corresponding vertex immediately. It appears there's a slight complication in that all the arrays could contain items that have already been added previously and these may affect your indices, but you should be able to figure this out from the existing code. Aidan ___ 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] Oh, the drama. (was: Viewer blacklist...)
On Fri, Apr 30, 2010 at 10:51 PM, Rob Nelson wrote: > As a person who is trying to patch (a now rather old version) of OpenSim > to handle voxel terrain, there's MANY, MANY flaws to the messaging > subsystem of both the viewer and the server. > > For one, I wanted to tack on an additional UDP/TCP message to handle > voxelmap transmissions and modification. Unfortunately, it appears that > even a tiny change to the messaging template would completely destroy > compatibility with SL, and even adding one packet handler in OpenSim > would involve changing LibOMV, 3 packet handling packages, and an > extremely long PacketType enum. This is NOT a flexible protocol that > we're using. Yeah. You can try using GenericMessage - apparently RealExtend have - but it has the rather interesting limit that each Parameter is limited to 255 bytes. ___ 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list
On Thu, Apr 15, 2010 at 3:09 PM, Lance Corrimal wrote: > Am Mittwoch, 14. April 2010 20:49:59 schrieb Joe Linden: > >> **we've had a lot of internal debate around cost/benefit of OS **... and >> we're fully committed to redoubling our commitment to make this a >> successful program*." > > > then... how about... opensourcing the SERVER (like someone pretty high up > suggested several years ago)? > > > and there's no reason to be afraid that giving away the other half of the > software would cause you longtime harm anyways... > > ...after all, the grid is more than server & client. the grid also is all > those boxes that it is running on... no way that a competitior could pull > 1 PCs out of a hat on short notice. > > on the other hand, I would like to bet actual money on the following > predictions: > > - 48 hours after the server code is out in the open, the 25 groups limit has > been lifted, AND the whole IM/group chat subsystem has been migrated to XMPP > (including voice via XMPP); another day and there's the possibility to connect > to jabber.sl.net with any xmpp client, AND talk to friends at any jabber > service. XMPP doesn't actually scale that well, unfortunately; a lot of the really big installs actually run their own protocol internally with better scaling. > - a few weeks later, all communications between client and server, and the > various server subsystems, has been ported to tcp/ssl and is transaction safe. Unlikely. Transactions are hard. There's some low-hanging fruit with regards to LSL support though. In theory, one should be able to statically verify nearly all traditional non-Mono LSL scripts, and then optionally compile them down to native code. (The static verification would probably take a day or two to code; compilation down to native code would take longer and have more interesting tradeoffs. Direct threading might be a better approach.) ___ 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] Can you legally agree to incomprehensible conditions
On Fri, Apr 2, 2010 at 4:49 PM, Gareth Nelson wrote: > It's a lot of work to maintain, trust me - anyway, it'd be better to > convince the opensim team to allow viewer developers in. Yep - people seem to end up writing their own simulator from scratch instead as a result. I know that I did[1], and I recall that both you and John Hurliman had your own projects too (litesim and Simian respectively). [1] http://www.makomk.com/gitweb/?p=cajeput.git;a=summary ___ 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