Showing posts with label ossviewer. Show all posts
Showing posts with label ossviewer. Show all posts

Saturday, February 03, 2007

Arbitrary Prim Attributes

What a super idea! I've got the YAYZERAMA HANDS too now!!

Features like this (and other cool things, too!) could be added to the viewer client, 'specially now that it's open source, but so many features require just a little bit of help from the server to do it properly.

For example, right now there's no good way for the sim to remember "This prim has a saturation of 0.5 on all its sides" and tell that to everybody that comes by, so there isn't any way to share the desaturated goodness with anyone else! (Maybe you could store some cryptic data in the prim's name or description for other special viewers to notice, but that would be a dirty, dirty hack. Yuck!)

Sure, we could tug on the Linden programmers' shirt tails every time there's a new client-side feature we'd like the sim to store a little bit of data for. But, even if they were just twiddling their thumbs all day and waiting for something to do, there would never be enough time to add something for every feature that someone thinks up. (Plus they'd have to do a grid-wide update every 15 minutes.)

A better way would be to give each prim a little pocket where it can hold some arbitrary data to give to viewers that see it. There would be a hard limit on the size of the data (maybe 1k, or 5k), and it would be completely up to the viewer software to decide what to do with it. And of course, scripts would have to be able to read and write this data!

Ideally, objects and prims in SL should be sent as XML, kinda like this:

<primitive 
name="My Awesome Prim"
description="The best prim ever made."
shape="torus"
texture_uuid="top: [uuid], bottom: [uuid]"
contents="[first_item_uuid], [second_item_uuid]"
size="8m 2m 2m"
skew="80%"
awesomeness="23.5" />
Then the scripts could do something like this:
if( llGetAttribute( "shape" ) == "torus" )
{
llSetAttribute( "awesomeness", "infinity" );
}
Or if we had a decent scripting language, like ruby, it would be like this:
if self.shape == "torus"
self.awesomeness = "infinity"
end
And if you had a special viewer client that was programmed to understand the "awesomeness" attribute, the client could do something cool like write "This prim is so awesome!!" on your screen with a big squiggly arrow pointing to it.

That would be awesome.

P.S. If you're worried that this would contribute to sim load because of the increased amount of data being sent, remember that textures are the #1 cause of teen pregnancy sim lag. Plus, the sim could enforce a data size for the prim declaration, by dropping out some nonstandard attributes if it gets too big.

P.P.S. Yeah, I know this could be a big ol' security hole. What isn't? 'specially if you're using a custom viewer client provided by some homeless person down the street.

Monday, January 22, 2007

Local subversion repository

Another post? It's like a post overload!

I've set up a local subversion (svn) repository to manage the viewer source code as I make revisions, allowing me to easily save old versions, view what I've changed, and revert to the older version if something bad happens. It's not accessible over the internet (at least not yet), which means that it is of very limited usefulness to other people. But hey, I know how fun it is to read about what other people are doing that doesn't really affect me personally, so now my readers (I think I have some of those? Maybe I'm thinking of lemurs.) can enjoy the same luxury.

Here's the plan for repository layout:

  • linden — contains the most recent vanilla source code from Linden Lab.
  • jacek — contains my tinkered source code.
You might be wondering why I would maintain a directory with the untouched source code, when I can always revert any changes that I've made. My reasoning has to do with managing changes to the linden branch and merging them into my own branch as needed. When a new version of the source comes out, I can update the linden branch, see what changed, and apply those changes to my branch—without overwriting any changes I may have made to the same files.

I might also make more branches off of jacek if I ever decide to implement something that takes a really long time to code, then merge the changes back when I'm done.

OSS Viewer success

Minor news bulletin: I compiled the latest viewer source and successfully connected to the grid today. I'm not sure exactly why it worked this time, but there are a few major possibilities:

  1. I used the faster, but proprietary jpeg2000 decoder library.
  2. I actually followed all the instructions.
But there's no way of knowing exactly which it was... so, um... yeah.

Saturday, January 13, 2007

Status Update 01-13

I've compiled the vanilla viewer 3 times so far, twice as "release" and once as "releasefordownload". I've also connected to the Grid (Agni) several times, but each time the connection was apparently interrupted or died or was deauthorized soon after log-in.

Movement, teleportation, profile viewing, map viewing, and who knows what else were non-operational. The Friends list seemed to work, and I tried to send a couple IMs to my online friends, but they were not received. L$ balance was blank, and some menu options were disabled (specifically "Appearance" and "Upload ____"). My avatar was invisible except for a few attachments attachments, and no in-world objects were visible. The terrain was visible, however.

There were several varieties of suspicious/interesting messages which flooded the console at various times.

The first variety looked like this:

[INFO] tile 1 of 1
[INFO] - tiers-1 took 1.032843 s
[INFO] - dwt took 2.815572 s
[INFO] - tile decoded in 4.792272 s
I think it is reporting on the download and decoding of texture files from jpeg2000 format. Some time after the log-in process began, an increasing amount show up like this:
[INFO] tile 1 of 1
[ERROR] tcd_decode: incomplete bistream
[INFO] - tiers-1 took 0.117982 s
[INFO] - dwt took 0.406939 s
[INFO] - tile decoded in 0.736888 s
[ERROR] read error
If I try to move or fly, I get messages like this:
2007-01-11T23:22:44Z WARNING: sendMessage - Trying to send AgentUpdate on unknown circuit 72.5.13.29:13004
If I try other things, I get the same message, but with "AgentUpdate" replaced with other message names, like "ViewerEffect" or "TeleportLandmarkRequest" or "AgentPause" or "LogoutRequest".

Finally, here is an example of the message log summary I get when I quit the viewer.
2007-01-13T23:04:01Z INFO: START MESSAGE LOG SUMMARY
2007-01-13T23:04:01Z Run time: 591.330 seconds
2007-01-13T23:04:01Z Incoming:
2007-01-13T23:04:01Z Total bytes received: 78004 ( 1.06 kbits per second)
2007-01-13T23:04:01Z Total packets received: 403 ( 0.68 packets per second)
2007-01-13T23:04:01Z Average packet size: 194 bytes
2007-01-13T23:04:01Z Total reliable packets: 24 ( 5.94%)
2007-01-13T23:04:01Z Total compressed packets: 71 (17.57%)
2007-01-13T23:04:01Z Total compression savings: 8097 bytes
2007-01-13T23:04:01Z Avg comp packet savings: 112 ( 1.38 : 1)
2007-01-13T23:04:01Z Avg overall comp savings: 20 ( 1.10 : 1)
2007-01-13T23:04:01Z
2007-01-13T23:04:01Z Outgoing:
2007-01-13T23:04:01Z Total bytes sent: 2000 ( 0.03 kbits per second)
2007-01-13T23:04:01Z Total packets sent: 437 ( 0.74 packets per second)
2007-01-13T23:04:01Z Average packet size: 5 bytes
2007-01-13T23:04:01Z Total reliable packets: 71 (16.21%)
2007-01-13T23:04:01Z Total compressed packets: 14 ( 3.20%)
2007-01-13T23:04:01Z Total compression savings: 244 bytes
2007-01-13T23:04:01Z Avg comp packet savings: 16 ( 1.22 : 1)
2007-01-13T23:04:01Z Avg overall comp savings: 0 ( 1.12 : 1)
2007-01-13T23:04:01Z
2007-01-13T23:04:01Z SendPacket failures: 0
2007-01-13T23:04:01Z Dropped packets: 10
2007-01-13T23:04:01Z Resent packets: 34
2007-01-13T23:04:01Z Failed reliable resends: 42
2007-01-13T23:04:01Z Off-circuit rejected packets: 267
2007-01-13T23:04:01Z On-circuit invalid packets: 0
2007-01-13T23:04:01Z
2007-01-13T23:04:01Z Decoding:
2007-01-13T23:04:01Z Message Count Time Max Avg
2007-01-13T23:04:01Z END MESSAGE LOG SUMMARY
On the plus side: except for not being able to log in or do much of anything, it works great! ...

Wednesday, January 10, 2007

Miscellaneous Feature Ideas

Just brainstorming features (large and small) that would be both possible and desirable to add to the Second Life viewer client. Things which would require server changes don't fit here, only things which can be accomplished by changing the client only. I'm also focusing only on new features for this post; I might make another post of bugs that should be fixed.

  • Menu items for builder tools (e.g. Edit Linked Parts, Ruler Modes, Color/Texture Pickers).
  • Hide/show specific UI elements. (Tateru gets the credit for thinking up this one.)
  • Arbitrary number of clothing layers on all body sections.
  • Improved avatar mesh UV maps, so clothing and skins are easier to create and align.
  • Improved avatar mesh weighting, so joints don't bend in such an ugly way.
  • Modifiable menus (rearrange and set shortcuts on the fly).
  • UI color schemes.
  • Additional image file formats (e.g. PNG).
  • Client-side script API, allowing interpreted scripts to access client functions.
Here's how I would rank them:

The three least difficult to accomplish, in increasing difficulty:
  1. Menu items for builder tools.
  2. Hide/show UI elements.
  3. Improved avatar mesh weighting.
The three most beneficial, in decreasing benefit:
  1. Client-side script API.
  2. Arbitrary clothing layers.
  3. Modifiable menus.
The three best time investments (most gain for time spent), in decreasing return on investment:
  1. Client-side script API. (The gain is simply astounding.)
  2. Menu items for builder tools. (The gain is only moderate, but the effort is minimal.)
  3. Arbitrary clothing layers. (The gain is very great.)
If you care to comment on how you would rank the listed items differently, please do so. I'm not asking for new ideas for features, though; I think there are more appropriate (and worthwhile) channels to be heard.

Monday, January 08, 2007

Post-OSS Plans

I've dived head-first into the client source code. For the moment, I'm just orienting myself, poking my head around to see what goes where, building up a mental map of how the pieces fit.

An obvious next step is to attempt a compile of the viewer as-provided, before making any changes. That way, if something doesn't work, I will know that at least it used to work, so something I did broke it.

I'm also familiarizing myself with Linden Lab's issue tracker, wiki, mailing list, etc.—all the new stuff that appeared. I'll probably see if there are any little bugs in the issue tracker that I can fix.

In the meantime, I'm noting areas of the source code that interest me, so that I can focus and specialize in them. At the moment, improving the user interface seems to be where I get my kicks. The things I noted in my exploration of XUI as being impossible without access to the source code are now, of course, possible.

Lots of new toys to play with.

Second Life Viewer Open-Sourced

This is quite simply the most important SL news ever. Don't I seem excited? Well, I am. You could say I am cautiously optimistic.

Linden Lab has put a lot of thought and planning into this move, as evidenced by the info-laden open source page and new wiki. I can only hope they know what they are doing.

Yes, part of me worries about the negative effects we will almost certainly see in the near future. This has the potential to be much worse than the CopyBot scare, and with good reason—this turns the Grid upside-down. The assumptions that had been in place are now defenestrated, and business models will have to adapt, and adapt fast. Except for scripters and sex workers, there is no SL market I can think of that will not have to fundamentally rearrange itself.

Honestly, Linden Lab should have given an announcement several days prior to the source code release, to give time for preparation. I would not be surprised if many content providers close down temporarily, until they decide what to do.

We will probably see theft and panic. Temporary economic instability. But people will adapt. New business models will emerge. And most importantly, new tools will be created to improve Second Life.

Let's have hope for the future. The next few days will be rough as vendors panic, but things will calm down. Later, probably within a week, some new tool will be released to exploit some security hole, and more people will panic. But things will calm down again.

And then we'll see some really neat stuff. The kind of stuff that restores your faith in humanity.

That's how I see it, anyway. Time will tell.