Mircea Lobo

Gee, I didn't know it's so absurd to find it ridiculous that Havoc are telling LL what to do with their own code. Which is NOT the same thing as to WHERE you are allowed to distribute that work. Distributing is a different matter... of course the license can tell you where to do or not do that. But it's the first time when I see an external company affecting actual code development in another company's project directly, and clauses which are out of place being invoked. Not allowed to distribute any part of the Havoc libs in their open-source repositories? Sure thing... THAT is a normal licensing situation. Having to remove --loginuri is a totally different story however. But really, I don't care about drama right now... and I think everyone made their point and thinks what they will.

I didn't say it's not part of it since I don't know about that. Problem is that until now, I've never heard of any project where including an external library gives authority to its developer to tell you how to code your own project, among the "rules" to distribute their library. For the Xbox example mentioned above, that is at least related to what platform you distribute your library on so it makes sense. But here, I don't believe any of the people at Havoc know what a simulator is or how SL even works. And to impose the removal of a parameter as simple as the --loginuri in that circumstance is silly. What would keep them from also telling LL "You can't use the latest Havoc code unless all physical objects affected by it are colored green", then Linden actually adding a limit for that in the viewer? If I were Linden (which I'm not), I'd drop Havoc and switch to BulletX or ODE, which work great with SL (confirmed on OpenSim). The SL viewer is open source either way, so this would make sense. Bullet physics are used by commercial projects as well, and I'm pretty sure there are pathfinding systems for these also. But that's one of the last things that would qualify as a priority now, so nothing to hope for anytime soon.

FireStorm is the main one, but it's extremely bloated and also slower and laggier so I don't like it. I currently use Teapot viewer. Both are viewer 3 based... I no longer care about viewer 1 so I'm only looking for those.

After a while, I've actually come to agree with this. It might be best for OpenSim in the end, since now they can probably make their own client and add viewer-side features that way (I don't know if that direction will be decided however). Still upset with LL simply cutting us off this way though, and this is a big loss at the same time.

@ Solar Legion: When OpenSim support was dropped, Linden specified that the reason they did that was because "The owners of Havoc would no longer allow them to connect to custom grids". Sorry, but am I the only one who finds that the one of the silliest claims in SL history? Havoc does not work at Linden Lab. They make a physics engine library for games, which they then sell to game companies that wish to use them. They normally have no authority over the development of SL or what the SL code does. I'd be amazed if anyone over at Havoc even knows what Second Life is in detail, what a simulator is, what --loginuri does, etc. Sure, the owner of the Havoc library get to say "You can include my work with this project or not", but I've never heard of an external person having the authority to give orders to a project they don't work at or know anything about, even in order to allow usage of their library. I still tend to believe this was just an excuse to cut OpenSim because it was ruining SL grid business. But in case I am wrong and what LL says was true behind closed doors, LL has was a very naive company to give authotiry to other corporations in the development of their project. Personally at least, I never heard of such a thing before. But as far as I'd understand, this makes Havoc part of the SL development team in that case.

@ Phil Deakins: The only "support" they gave to OpenSim was allowing the --loginuri parameter in their viewer, and usually no one ever asked them for more. But now they removed that as well... though thank god the SL viewer is open-source so there will always be viewers with custom grid support. Still, it's sad. Hence my colder attitude about path finding support, considering it likely wasn't a very crucial feature either (and they could have found ways to implement it without making up crazy and silly licensing claims).

@ Innula Zenovka: Thanks for that link. It's nice to see even more being done on the side of graphics and rendering @ Gadget Portal: Not really. I don't consider features bad because I don't use them. This one I consider useless because I couldn't think what anyone would use it for at all, but I see some people have plans. Only reason I'm upset about it is that "the package" came with removing OpenSim support, so I wanted to at least know what was so important to sacrifice it. Thought to be honest, like other people here stated, this might be better for OpenSim after all and set us free with our custom viewers.

I didn't know people were really interested in object pets and roaming primitives. Anyway, I imagined the LSL way wouldn't have been too laggy, though I never tried to do path finding in a LSL script. Other builders could have made a free navigation script and distributed it for free too, so other artists wouldn't worry about creating one themselves. Also, if some players wanted creature objects, I once again believe that the first thing LL should have given them is support for self-animated meshes (then fine, the path finding thing). I'm also surprised this is one of the first things LL decided to give attention to, in terms of major features. There are people who are suggesting important changes to them for many years, and for some the Lindens barely bothered to reply. For example, I've been wanting support for transparent + shiny surfaces for 5 years, which should be a cinch to implement at this day... yet such a basic thing still doesn't exist. Knowing LL they also never cared what the community wanted, and just went for ideas *they* considered are need (eg: Everyone hated web profiles but they still shoved them onto us and won't change their minds).

I've seen animations done that way years ago actually... like pets that roam around sims. But in my opinion that's a bad way of animating anything, and only used because it's currently the only way. IIRC the only animation function that works client-side at all is llTargetOmega. But you give that a constant direction, so you still need the server to update it every few milliseconds so limbs swing back and forth properly. This will always be laggy, no matter how good one's connection to the server is (not to mention you can't bend limbs and do many other things you can with armatures). I just find it bad priority ordering to add a feature that SL could perfectly live without, without adding mesh animation support first to even give it a complete purpose. It's like adding support for guns in a game where you don't even have players who can connect yet. That's just my opinion of course... I've been with SL for years and also in the development of many games, so I can only hope my vision on these things is usually correct.

Well, the part about automated vehicles would make some sense. Although in all the sims I've explored during the 7 years I've been with Second Life, I can't remember seeing any attempt to make automated vehicles anywhere (except maybe some trains). In the sense that it didn't seem like a feature anyone thought about, not because they couldn't do it. For animals or other creatures it make no sense. Since like I explained, there is no way to animate them. I seen some attempts to use LSL for animating limbs on some prim creatures, but that is both very limited and very laggy (since it's basically the server animating and sending animation changes). The only way objects could ever be used for creatues is when self-animated meshes will also be supported, which IMO should have been LL's priority instead of this. For either of the two cases however, making objects navigate a sim should have already been easy and possible. One way is: The sim owner could place invisible primitives as nodes on the ground, then a script inside the object would know to look for the nearest one in the chain and navigate there. Second way is not even using nodes, but tracing toward a location to see if there's anything there in a LSL script. But this would be more difficult and I don't know how possible it is exactly. Surely this was doable before LL wasted their time to add path finding however.

Since I finally managed to get Second Life running on Linux, I looked a bit into the recent things that happened in the SL community. I've been informed a while ago that Linden dropped OpenSim support due to a clause with an upcoming pathfinding algorithm. The licensing reason they invoked was so silly I'm not even going to comment on it... but I was curious to find out exactly what this is all about, and what was that important thing they cut OpenSim off for. So today I poked a bit more into this. Someone clarified and explained that it's a feature which would allow primitives to navigate a simulator. And the client part (for which they "needed" to cut off OpenSim) is a library to preview the navigation paths on a mesh. I assume this means that when a person uploads a mesh to Second Life, he / she might be interested how a primitive using such an algorithm would know to navigate on it, and needs to see a preview of that. Although I always like seeing new features put in, it's impossible for me to understand why Second Life would ever need something like this. Not to be rude, but I've been trying for an hour to think of a more useless thing SL could have than path finding support, and still haven't succeeded. Not only that I don't see why anyone would care for a primitive to navigate even between simple shapes (like blocks or cylinders), but meshes? I wasn't even sure if meshes have proper collision detection yet... since many games assign a bounding box and never bother to calculate these. There are modern games out there (like shooters) with cutting-edge graphics and technology, and I think even some of them don't have this. Why do I consider this the most useless feature in SL? First of all, there isn't (and probably never will be) support for actual characters and bots. OpenSim tries that by simulating automated clients / avatars, and even so they have no use but walking around. IIRC this has never been a purpose in Second Life either, though things can change. While with a good LSL script you can make objects seem sentient, I don't see a circumstance where this would be done at large scale and needs such accuracy and detail. Second, primitives can't even be animated yet! Sure, you can script child objects to change position and rotation (to simulate limb swinging for example), but that's not real animation and is very bad in all cases I've seen. They will always be simple and also very laggy, since the server needs to update them. The only way this could even remotely have an use is when Second Life will have self animated meshes, and LSL can set a model to loop an animation client-side (while walking for example). Priorities for LL are completely upside down IMO. Third, there are so many things of huge importance compared to path finding, that even considering this feature is silly. Second Life still doesn't have local movement (you wait at least 0.5 seconds for the avatar to start stepping after you press the forward button). It has no collisions for water yet... no support for transparent + reflective (shiny) surfaces, and so many other things. I'd see more sense in taking a copy of Quake 1 and adding path finding support to that. There's such a big list of features SL truly needs for years that people would laugh to even hear of mesh navigation. Those are just my 2 cents. I'm not looking to start drama, but I am pissed to see what LL decided to throw us OpenSim users away for. But other than that, my question is if anyone's ever going to use this feature at all. I've been a builder for years, but I think this is the first feature I'll never touch and can't find any real use for. If someone else can though, I'd like to see some concrete examples of what OS was sacrificed for.

Don't know about Debian, but installing the proper ATI driver on openSUSE (and probably any other distribution) has been a nightmare for years. As the package for my distribution from amd.com would never work for me and result in corrupt graphics. Thankfully at this day, someone has a properly packaged version on a software repository, so I simply install that from Yast and restart and it works perfectly well. Still sucks you need a proprietary driver to run 3D games in Linux...

I'd like to know when the fglrx driver distributed in the free Linux repositories will support 3D accleeration and games Though the proprietary one should work on any distro if packed properly. So far though, I'm very ok with openSUSE and not planning to move to another distribution. Only problem is I can't run SL from a repo like most other software

I heard that Firestorm fixed it in GIT, but since the SL viewer is one thing I don't know how to compile I just download the binaries. I'm waiting for their version to be updated. Issue is that for most software, I run it via software repositories, which is also easier to maintain and update. Would have liked being able to do that with SL as well, but I assume this means there are no rpm repos for it. And yeah, I heard about that licensing issue even if I don't understand it. That and why something like SL ever needs pathfinding support (it's not Grand Theft Auto lol). But I'm past caring at this point... just glad SL viewer is open-source and OpenSim won't suffer too badly from this decision. But yes, it does mean I'll want both the Linden viewer and something viewer 3 based that works with OpenSim.

Recently, I switched away from Windows to Linux (openSUSE). Although I was able to run the official SL some months ago, the latest version of any viewer crashes at startup and will not work. It's due to some libraries being incompatible or not packed properly... this time it was libfontconfig or something. The issue is being discussed somewhere else however, and debugging it is not the purpose of this thread. The problem is I frequently get library incompatibilities with software downloaded from other websites, and don't get them with programs I install from my distribution's software repositories. Although the Second Life client is open source, neither it or any custom viewer is available on the games repositories for Linux (at least my distro's). Best way to run SL would be fixing this and running it from a repo instead... but I don't know of any. Are there any software repositories that offer the latest version of the SL viewer, compatible with popular Linux distributions? I'm looking for one which offers both that and the Firestorm viewer... due to LL's dumb decision to remove OpenSim support from theirs. In my case I use an rpm-based distro, but feel free to link deb ones too for users who have those and get the same problem. Thanks.

Phil Deakins: Very interesting. Only way it could be done without glasses and on a normal TV is by using some trick with the colors or depth (within the normal image). Is there a video of it on Youtube or anywhere? I'd like to see what they did there.

Some nice news on this: I managed to see stereo without glasses today, by using side-by-side / horizontally split viewing in a game that has this feature. Looks really neat... and by using polarized glasses + cellophane to hide halves of the screen from each eye, you don't see the other two "screens" either. I managed to do this in fullscreen and could even get as close as I normally do to the monitor without the combined image breaking apart. However, it's very tiring for the eyes, and I'm not sure if it could even cause eye damage. After doing it for just a little my eyes were slightly hurting, and for a few minutes I had a hard time properly focusing them in real life (felt like they were focusing off). So I don't recommend doing it... at least not for long periods of time. The proper way is managing to put both channels over the same surface of the screen, but that remains a very hard task with normal hardware.

So this is the story: I play several games apart from Second Life (usually FOSS ones which new features can be easily added to) and have recently been interested in 3D image / visual stereo. Most support red + cyan anaglyph and until now I used that with my 3D glasses. But as everyone knows, this washes the colors out while using such glasses for too long tires my eyes. I only have a normal LCD monitor and am not looking to get a special video card / monitor / video drivers for this... just achieve it with existing hardware (apart from the necessary glasses). I've been googling about this, and most people say red-cyan anaglyph is the one and only way with normal monitors. I have however seen something that might work, and wanted to ask if anyone else has done it and what exactly must be used to achieve it. Second idea is something I've come up with, and wanted to ask if it's possible and being done too. Let me know what you think, and also if you know of another way to get 3D working on a normal monitor (if there is any after all). - Idea 1: I read about active and passive 3D glasses. Active ones require electricity to shut the lenses in sync with the screen, and cost a lot while requiring a special monitor, so no. Passive ones normally need a special monitor too, but the hack I heard of gets rid of this requirement. What I read is that by using a certain type of plastic foil you can invert the polarization of any LCD / LED screen. If done properly, covering half of the screen with a type of foil while covering the other half with the same foil but flipped would make one lens of the polarized glasses see one half of the screen and the other lens to see the other half. Some games allow side-by-side 3D, so if I could make each eye see only one side it might actually work. The problem with this is that for red-cyan anaglyph, both channels overlap on the whole surface of the screen. Hiding half of the screen for each eye might cause eye strain... if it's even possible at all without causing eye damage. Physically speaking, each eye needs to look in the same spot (otherwise you go derp), so I have no idea if both eyes looking at the center of the screen like this would still connect the images in the brain. The proper solution would be separating each picture / camera via refresh rate (one every line / pixel) but this gets into requiring special hardware. I only saw a video about this method, and would like more information. - Idea 2: Additionally, there is another idea I thought of that could be used to put an image on each eye with a normal monitor. Instead of separating by colors (eg: red and cyan) separate by brightness ranges. In this case, another pair of special glasses would be needed (which I doubt even exists); One where the left lens allows a brightness between black and a given level of gray, while the other filters brightness between the same level of gray and white. The 3D renderer would then divide each image / camera as follows: The image for the left eye would be darkened / scaled so that the brightest white becomes 50% gray (pure black remains unchanged) while the image for the right eye would be brightened / scaled so that the darkest black becomes 50% gray (pure white remains unchanged). Both eyes connecting the images should then achieve a normal brightness back to some extent. I'm not sure how overlapping those over the same area of the screen would work, and it would surely be annoying for each eye to see a different brightness level. Still, if this would work out it would allow visual stereo on a non-3D monitor without messing up colors. Are there any glasses that can filter by light intensity, and is this an usable alternative to red-cyan stereo?

I tried GTA 3 on my S3 as well today, sice it seemed relevant to this performance-wise. Works perfectly well... even faster than on the computer I had the day I first got GTA3 Also tried it out with the hacked settings file to enable effects (lights, flares, particles and such) and still get a perfect FPS. Here's a video I found of someone else trying it out on the S3: Since SL doesn't neet any fancier graphics to run, I'm pretty sure anything as strong as Galaxy S1 could run it perfectly at low draw distance and with reduced object detail (likely most smartphone models can, but I don't know the resources of others). On mine I estimate I could set draw distance as far as 128 at least, and geometrical detail to medium. For what Hitomi mentioned, that is useful to know. The renderer would probably need some remaking, and I don't know if Android can run original OpenGL code and the like. Only thing I know for sure is that it needs to be compiled to run on a different kind of processor, but that by itself simply means opening the source code and compiling for another platform. For each application this means changing different functions to be compatible more or less, or using alternatives for other libraries. No idea how much that is in the case of SL viewer. BTW. There's also a neat little 2D open-source game called Hedgewars. It's available for Windows, Linux, and also Android. I have it on both my computer and phone, and all versions are exactly the same with the exception that the Android one has a touchscreen interface. Pretty sure they're both compiled from the same source code, but I haven't asked so I might be wrong.

I recently got a Samsung Galaxy S3 smartphone as an upgrade to my Galaxy S. Both devices support 3D rendering, and there are many 3D games and clients available on the Android Market (such as a lite version of MineCraft). The S3 especially (with its 1GB of RAM and quad-core CPU) should support some high quality 3D at acceptable frame rates. Yet I can't find any client providing access to enough of SL's features to consider it usable. Yes, there are some which allow you to login and use the chat (even see the map), but none that let you see the 3D scene, yourself and other avatars, and support moving around. Not to mention in-world building, access to inventory, and wearables / avatar customization. Only free one I found on the market is Mobile Grid Client, which like I said allows the user to see the chat and the world map only. There is however one which renders the world (and seems to work a lot like the PC client) called Lumiya Viewer (web page here). But not so surprisingly, there's only a paid version available, and I prefer free and open-source software for everything. There are pretty much two options. First is someone writing an Android SL client from a scratch, which would be very difficult and take a lot of time to do (given all the features and systems SL has). The second and best option would be compiling the normal SL client for the Android platform and hardware. This is possible and many projects with simple ghaphics have done it. Best example is Rockstar Games having released an Android version of GTA3 two years ago, which I installed and it worked perfectly on my Galaxy S (on the S3 it should be even better). With simple changes for a touchscreen interface, compatible rendering and other functions, this should be possible to do with the normal Second Life client too. Are there any plans to do such a thing, or even downloadable clients which can be used at this date?

Ok... thanks again! Remember to test it with custom rotations also. When using one, the mapping works totally different (eg: Using a 45* rotation, though a 90* or 180* one also breaks everything currently).

I mentioned EFF because I got this in a subscription email from them. I'm seeing the article talks about a SOPA-like law, but other people stated it's about the past Megaupload incident. Wonder why the email was sent today then. Anyway, if that's correct, thanks for clearing it up... glad I didn't panic as much about this one. Makes me feel silly about myself that I'm taking every such article seriously without reading more, but the SOPA times come back and it's hard to not worry, and I really don't wanna lose all the websites and things I use on the internet.

Although I've been bringing a lot of "related news" to this thread since the initial discussion, I again received some shocking news from EFF by email (they're a serious source of information) about a potential revive of the actual SOPA / PIPA. http://act.demandprogress.org/act/vs_hollywood/?referring_akid=.661516.qyUGJ6&source=typ-tw It appears Hollywood is trying to shut down all cloud websites. Basically, it wishes to take down Youtube, Google Drive, and all cloud services out there, the same way Megaupload was removed. The article mentions them trying to circumvent congress so they can force their law through without a vote. What this means is most major websites which allow file storage would be gone... and we are back at SOPA as we know it. This comes just a few days after I heard about the ISP initiative and an update on CISPA. Jesus Christ... has the world gone completely mad? Are those groups desperate beyond limit to shut down this internet? They now want sites like Youtube to disappear forever... who almost entirely addressed the issue of copyright material being uploaded. Is this even about copyright any more, or is that just a pretext? Yeah, I agree... this is an outright war with the entertainment industry at this point. I don't feel like fueling the fire here so people can jump to their own conclusion... I just found the article and linked it. There will probably be more information soon, and if that's true likely another blackout. Feel free to re-post this post anywhere without asking.

On a separate note, I would like to inform everyone of something even more important. CISPA is going to expire soon and will be voted in the senate... probably secretly and under the desk like we've been used to seeing (so no date is known). Everyone who is against it is strongly advised to call their senators ASAP and firmly ask them to vote against it! I don't have a link but you should be able to find their phone numbers on google and older SOPA / CISPA articles... I'm too tired and outright sick of the whole thing to look them up myself. I consider this even more dangerous than the ISP initiative, and by all means hope this law won't happen either As usual, please spread the word and re-post wherever you can so everyone knows. We need to show the senators those who oppose it are large in number, since as with SOPA they will not be able to vote on a law that everyone is visibly against. The house already passed it, so this is even more urgent for that reason.

I have some good news everyone. It seems the project was delayed until past this July. There's no specific date as to when they wish to implement it, although evil corporations and ISP's are still hoping this year. http://torrentfreak.com/us-six-strikes-anti-piracy-scheme-delayed-120518/ That likely means they are scared, and have taken notice people are revolted. This is our chance to react and give them a good scare. What I hope will happen is people establishing a date when they can go to their ISP and protest... maybe knock at their door and have a nice heated discussion (I don't wish to imagine a worse scenario yet). If such happens the project will certainly be killed, and we would further send a message to those who wish to crush the internet so they understand once and for all we'll never accept it in any form. Including those who support CISPA, who they hopefully understand will also not pass for the sake of both sides and everyone else.