There are two "ground up" viewer projects that I'm aware of, Idealist and Openviewer. Here is a site which discusses them from a technical perspective: http://playsign.fi/engine/rex/viewerarchs Idealist can be found at: http://forge.opensimulator.org/gf/project/idealistviewer/ Openviewer can be found at: http://openviewer.org/
Then there is the Xenki viewer which aims to be a browser plug-in rather than a standalone viewer. Find it here: http://forge.opensimulator.org/gf/project/xenki/ On Tue, Jan 27, 2009 at 6:58 PM, John Sheridan <[email protected]> wrote: > Well, I'm glad someone's at least taking a swipe at the client from a > usability standpoint although it would be nice if they like a few of the > other client projects I've seen would consider starting with a ground up > rebuild of the code base. At least not only to solve the gpl vs bsd vs > <insert favorite license here> problem but as well to make it so one can > actually read and understand the code without loosing all grip on reality > (virtual or not) then curling up into a fetal position under their desk > while the world around them crumbles into some sort of bad rendering bug ala > The Matrix. And yes, for those who actually can read and understand the > Linden's coding style I am that much of a wimp. :) > > Thanks for the info Dahlia, :) > > - John / Orion Pseudo > > > Dahlia Trimble wrote: > > That would most likely require modifications to the sl viewer. I think the > Imprudence project is looking at providing a viewer with similar > capabilities: http://imprudenceviewer.org/ > > > On Tue, Jan 27, 2009 at 12:18 PM, John Sheridan <[email protected]>wrote: > >> While on the topic of weird ideas and in world apps... I posted this >> idea to the Lindens about a year ago back when I was first trying to >> figure out LSL, but it likely went off to the noobie duh bin as at the >> time I pretty much asked them to include a copy of Visual Basic in world >> :P Anywho, as it is we already have the LSL language with our own >> additions via the os functions. What I'm thinking would likely require >> client modifications which merely makes it something to think about for >> the future, but why not cobble together something that gives lsl access >> to the client's widget set? Optimally something like a Mono Winforms >> type of addition to lsl that would let a scripter actually use a real >> gui as an interface for their scripts instead of hacking one out with >> prims or a dialog box? >> >> Thanks, :) >> >> John / Orion Pseudo >> >> Dirk Krause wrote: >> > Hi, >> > >> > this thing came up when I was thinking about what to do for OpenSims 2nd >> birthday. >> > >> > I thought it would be really funny to reconstruct the Sony Home Arcades >> in OpenSim, basically for giggles. I unfortunately don't have access to Sony >> Home for now so I don't know exactly what effort it means to model this, >> being not a good builder myself (for reference - >> http://tinyurl.com/def8fn ) >> > >> > The interesting point would be the ability to play either MAME or C64 >> games on the machines in these 'OpenSim Home (tm) Arcades'. So I looked up a >> C# c64 emulator on the web ( http://tinyurl.com/bobw9y ) but then came to >> think where such an emulator would run. >> > >> > (the following holds probably true for all kinds of applications running >> in the OpenSim context, namely: >> > - graphic-heavy c# or c++ applications >> > - flash/silverlight/moonlight applications >> > - 'co-browsing', works in Rex with this nice trick: >> http://therexfiles.cybertechnews.org/?p=183 ) >> > >> > So, to stick with the arcade example, the good question is - where does >> the process run? >> > I think there are these possibilities in general >> > 1) SERVER - the application totally runs on the server side. One av >> takes over the game machine and his key strokes are transmitted to the >> server (via HUD?) and the emulator creates the graphic output. This would be >> a series of textures (not really good) or a video stream of sorts. >> > 2) CLIENT - the applications totally runs on the client. This is >> possibly the easiest way to implement it (and out of scope for opensim-dev) >> since it needs hacking the client. But just for the record: as soon as the >> client detects arcade.jp2 as the texture, it fires up ye old space invaders >> and renders2texture the graphic output to the client. Other people would >> see either >> > a) nothing but the standard texture as long as they are not playing it >> or >> > b) a screenshot every 5 secs or so, since the client sends every 5 secs >> or so a screenshot to the server, updating the view for the cheering >> bystanders >> > c) the real game, since their clients also fire up the emulator, receive >> the key strokes from the current player (while they are near him) which must >> be sent from the server of course. >> > 3) BOTH- the application runs on both server and client with >> synchronicity calls every N secs with some prediction by the client side >> when the calls don't get through fast enough (basically like networked >> physics in professional games works) >> > >> > All in all you are in synchronicity hell the more 'real' the output for >> everyone gets because there can be no real simultaneousness. >> > >> > So sorted by applications: >> > - Physics: >> > either only server sided (like it is now) which is sufficient for most >> use cases, or both when the physics is fast and heavy like in games. >> > - Video: >> > Number 2c is used to play video in SL right now - one av activates the >> script that start the media playing on all clients in the vicinity. if they >> didn't activate media support then they see nothing. If they did the video >> starts on all clients, probably 1 to N secs off each, depending on their >> network, also slowly drifting into asynchronicity the longer the video runs. >> If it should be more synchronous then a streaming server is mandatory. >> > >> > - Turn based games >> > could be implemented completely on server side. So a simple text >> adventure (Zork, anyone) or even a MUD could be implemented even on a >> different server with a gateway of sort. Come to think of it this could even >> be a tty terminal. >> > Same goes for >> > - co-browsing web pages, powerpoint projectors >> > Could be either server sided (like it is now via the php render trick) >> or client sided (via the Rex trick) >> > >> > So the interesting part stays where to implement, say, a moonlight >> application? Let's say people want to create micro/casual games or small >> apps,then it would be interesting to see whether there would be an >> infrastructure to hook these things into? >> > >> > I would even go so far that there could be a mechanism that handles LL >> or OS scripts in a way that it either runs on the client (libomv Test.exe >> with some script) or on the server side (the existing scripting >> architecture). >> > >> > Best regards, >> > Dirk/Barth >> > _______________________________________________ >> > Opensim-dev mailing list >> > [email protected] >> > https://lists.berlios.de/mailman/listinfo/opensim-dev >> > >> >> >> _______________________________________________ >> Opensim-dev mailing list >> [email protected] >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> > > ------------------------------ > _______________________________________________ > Opensim-dev mailing > [email protected]https://lists.berlios.de/mailman/listinfo/opensim-dev > > > > _______________________________________________ > Opensim-dev mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-dev > >
_______________________________________________ Opensim-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-dev
