Dave Zeeman please read!

Dear Dave, I am most humbled and sorry for the events that occured on 4/5/2003 in Second Life and while I am still a bit... frustrated that your "posse" took it upon themselves to tell me what to do with my land I respect the fact that you hate us( the Noise Tanks) and we are planning to move far, far away...
Note that this is a formal apology to you(and ONLY you Dave) for any transgression that may have occured while you were on.

I am sorry to say i cannot forgive or apologize for what happened after you left, since your group of followers deteriated into the missing link and had me pinned down for near 1/2 hour in which case I had to re-taliate...

But anyway, no crying over spilled milk yes?

I would be happy to meet you in game (pending Linden gives me my account back...) and discuss our lives (the second ones over a cup of tea...

-Zeddicus Zu'l Zorander (Smith to the normz...)
"Ours shall rise into the sky, ours shall consume all, ours is...NEO!!!"

NOISE TANKS!!!

Haha, maaan.

Yeah, apology accepted. I myself was just having a goofrific time covering up your tower, nothing personal but the thing really was a pain on the eye-sockets, ESPECIALLY during night time. I'm sorry to hear your account got taken away, I would only wish that upon a select few and you weren't really on that list.

Personally I think things just got out of hand and tempers flared too much. Oh well. Visit me anytime you like, my home will always and forever be in Minna.

Dear Zeddicus,

I'm sorry you harbor such feeling toward those in my community. We don't mind the noice, the loud music, and we can even tolerate unusual structures, after all, everyone has unique tases and opinions are utterly subjective. SL is about expressing yourself. Everyone has that right.

However, in a densely populated areal, you purchased a 4x4 square in the center of us, erected what would be equated to a 200 foot tower or flashing, rotating, animated rings, sphere's and boxed with pulsing textures. This caused everyone a great amount of lag, not to mention you built it in such confined quarters that the first time you build it on my land!

Along with Rygars pulsing 'rave machine' your sructure gained simwide recognition as a lag tower, except yours doesn't sing to the sim, Rygar's does... the whole sim. This we tolerated, we crashed, we lagged, and then you began killing our company. New people that would gravitate toward our area because of the welcoming atmosphere we present. (Many have learned to build in my living room.) and as they came, you shot them... people who did not know how to set home, and were completely unarmed. Sure it's always an ever present liability in the outlands, but we in our community, despite it being in the outlands, uphold a certain ethical standard. Shooting us while in away mode, or while building was tolerable, sporting even, but doing it repeatedly was annoying, yet we said nothing.

Finally, as Sassy kept crashing as soon as she steped over the sim line due to you extremeist tower, we decided collectively it would be appropriate to ask you to tone down the exaggerated animations. You told us to kindly "F Off." Then Dave, witnessing our plight, covered your building if just to subdue it, you retorted by going on a killing spree, the neighborhoor, 8 or 9 people, lashed back. I'm deeply sorry it was delt with in this manner, but your combative attitude and unwillingess to negotiate drew this upon yourself.

So your mature response was o take your massive scripts of flashinganimations and rotating boxes and enlarge them as much as possible and place them all over on our properties, in the sky above our properties and on the water, a dozen or so, on roofs, in rooms, everywhere. This finally led to you being reported, and the Lindens taking action on you, having the screenhots as proff of your harrassment. Andrew was nice enough to come and remove the litter (Dana was away for the weekent and Andres had to clean her property) and your tower.

I am not an advocate of banning anyone, and would never want to think myself responsible for that kind of disciplinary action, but your harsh attitude, your blatant display of immature reasoning, and your antics make you responsiblefor the result, no one else.

In any event I hope things work out for you.

Sincerely,
Phaylen

In response to this thread, when provoked, even the gentlest of creatures will bark and/or bite. Unfortunately, we (the residents of the Shipley/Hawthorne border) were provoked.

We tried communicating.
We tried peaceful protest.
We tried war.

The end result wasn't the result of anything WE, as a community did, but as a result of what Zeddicus did himself.

No, it was probably not handled as maturely as it could have been... on either side. However, let us not forget that many efforts WERE made before it got out of control, degenerating into a name-calling free-for-all and shoot-em-up fest. Oh, and for the record, I still can't shoot a gun in SL. I can arm myself and LOOK defended, but all I've managed to do so far is "shout" that I'm gonna attack.

Sorry to see this sort of thing happen in the world - so soon...and I do stress "so soon" because this sort of thing WILL happen again - and more violently than what we experienced I'm sure. If memory serves, a threat or two from Zeddicus directed at the Lindens themselves had something to do with "corrupt files" or some level of pseudo-hacking/virus-uploading, and I'm sure that could/would have been the next level. Either way, I suspect this does not make anyone on Team Linden shake in fear, but I do think it speaks for the nature of the "abuse" that was going on. It would probably be safe to assume many such efforts will be attempted by the bored and disgruntled as time goes on and issues/conflicts arise.

I said it Saturday night and I reiterate it now: Though I'm sorry to see it happen at all, I'm glad to see this sort of situation happen *now* and get resolved. It shows definite promise that things will not have to get totally out of control before the volatility can be relieved and some sense of normalcy returned to the world.

Yes, I'm a "n00b," in the world of SL, but I'm making friends here, learning tons, and (with minor exception) enjoying SL immensely.

Good luck in your endeavors, Noise Tanks. We bear you no ill will, and I hope whatever your future efforts involve, they bring you success. See you all in SL.

-Voodoo

I wasnt there, I have no clue whats up but I CAN say that the lag still exists. Check your bandwidth, its very high out there. Flashing lights alone won't create lag. Whatever else transpired, the tower wasnt the lag problem.. or at least wasnt all of it.

Just an fyi, no comment for or against anyone involved.

Oh by the by not to be mean or anything just stating the facts. Once second life is released my rave station will be a little (vary little)percent of the band with problems.......any way i forgot her name but shes working on a script to make it to where my station can be turned off and on so soon it will be much beter. Thanx for your time reading this.

Rygar,

Maybe you could try putting your rave setup inside a warehouse style building. Then at least the people who want to check it out can go inside and have fun, and the people who might find it a bit too bright and flashy and obnoxious would really only have to put up with seeing your warehouse from the outside.

And as far as the sound goes, if you wanted to add music to it, just create an invisible/hidden sound object directly in the center of the warehouse, and set it's volume correctly so the sound only plays as far out as the walls of warehouse, that way you also wouldn't be disturbing anyone outside the warehouse with the sounds.

Just an idea.

i think ill get to work on that the only reasion i made it flashy is cus it atracts attention to my place....

Damn it! There was a war.. and I wasn't invited!

Yeah. Well you could still maybe have a simple neon sign out front saying "RAVE" or "PARTY" or whatever, which could be colour cycling, etc. One flashy sign is a little easier to deal with than a large collection of psychedlic objects.

just one question wouldnt still bring down the bandwith?

Based on the way any optimised graphics engine should work, if your client cannot "see" an object because it is obscured by another, larger object (or because the object is behind you, or underground, etc), the client should not use up any cpu time to render that object.

It will still use up a small amount of time to "think" about the object, i.e. its position, size, etc. but that is far less to do than actually rendering the object.

Same thing applies to textures. If you have 50 different textures applied to an object, but the object is not actually visible in your client, then the client should not have to load any of those textures until the object does become visible.

Same thing applies to sounds. If a sound is out of "hearing" distance of the client, the client should not have to load the sound.

As far as any scripts are concerned, that one I'm not sure about. I think as long as your script isn't shouting things to the whole sim, or creating objects that are flying out everywhere, I think the client will "ignore" the script until it decides that it needs to dedicate some time to the script (i.e., when the object the script is on is visible).



But, bottom line... If you have a complex object with a lot of textures and sounds on it, but you "hide" that object inside something else, and you make sure the sounds do not reach out very far, other people should not be affected by the object until they actually decide to go and check it out.

The cilent will spend a small amount of time thinking about that object and deciding whether or not it needs to download textures/sounds/objects, but once it realises they are hidden that should be all it has to do.

It'd be cool if a Linden or more advanced user could reply to this post and confirm if any of what I just said is accurate or not. It seems like it should be. Being a programmer myself, I understand that for something like Second Life to succeed it needs to be highly optimised. The things I just mentioned are very simplified versions of actual methods of optimised a 3D graphics engine, so I would think something similar would really be implemented into the SL client.


*shrug*


Sorry for rambling (as usual heh).

sounds interesting ill give it a shot......what could it hurt.

RYGAR:

I think the offer to assist you with your color-cycling script so that it stopped querying the server for the next random color (which is what I have come to understand causes the excessive lag in your situation) came to you from Catherine Omega. She is brilliant and has an amazing eye for design and style, not to mention being extremely friendly, knowledgeable, funny, and just plain sweet.

-Voodoo

O I loves my new forum avatar

But that's a /girl/.

Ed'z not a girl, Ed'z an IT (We never were quite shure if Ed was a guy or a chick...[they never specified])

SHE is too flexible to be a guy

1. Ed is a girl, end of story.

2. Thanks for your kind comments, but I can't take all the credit with the script -- BBC had to show me what I was doing wrong.

3. The problem is not that your tower was (I notice you're no longer in Shipley?) flashing, Rygar, but how it was flashing. A new set of RGB values was calculated randomly 10 times a second by the server then that data sent to everyone within viewing distance, whether we could actually see the tower or not. (There's no backface culling or draw-blocking currently.)

Suffice it to say, the bandwidth consumption was incredible. All the modified script does is simply offer an on/off switch to the random colour generation so that it can at least be turned off.

Anyway, I just want to make it perfectly clear that aesthetics weren't my concern, performance was. We all have the "right" (actually, we don't have any rights; it's Linden's property!) to build big flashing things, and honestly, we shouldn't complain about other people's stuff. However, resource-hogging builds affect everyone nearby.

Good luck when you choose to relocate your tower, Rygar. You might want to consider the potential impact of it though.

Catherine Omega


---

Uh, I should note that I'm not trying to jump down anyone's throat here, just explain what was going on.

Well... for the curious... some tech details:

The rendering engine of SL doesn't yet actually precompute visibility in the manner in which it it is done in most static 3D engines. This is made near impossible by the ability that you as users have to move objects around in real-time.

Indeed, what is really impressive about SL is our ability to maintain good frame rates (well as often as we can!) with considerably more polys 'in-scene'. We are often processing in excess of 100K polys per frame (so 2-3M per second).

There is some clever next-gen stuff we will do to fix this further. It is true that a non-visible object will sometimes put a slightly lower 'fill' load on the GPU... for example a tree behind a wall is better, but this isn't the dominant load.

So to reduce the frame rate load imposed by something like a flashing object:

Make the object smaller so that you need to be nearer to first stream it.

Opaque objects are lower load than transparent (they don't have to be z-sorted).

Movement and lighting changes simultaneously will cause the heaviest load. So a moving light near a rotating torus, or something like that, is worst case. Sometimes you can get an equally cool effect by holding the light still and moving an object - when you can, opt for that.

Heh, pretty good. On a lot of graphics engines, this is the case. On most FPS games like Quake, they generate a BSP tree so from any point in the world, you can very quickly determine what objects are visible.

However, BSP trees are very slow to generate - and can change whenever any object in the world moves. Since in Second Life any object can potentially move at any time, the amount of time that would be spent generating something like a fully correct BSP tree with occlusion is actually longer than just rendering everything, at least right now. There are other ways of doing real-time occlusion culling (at least in research), but given the power of most graphics cards nowadays, your occlusion culling algorithm needs to be REALLY fast in order to be faster than just drawing all of the geometry (minus really simple stuff like simple view-frustum culling). Also, given the number of calculations that can be pushed to higher-end graphics cards nowadays, your graphics engine can often be limited more by how fast you can push data down the bus to the graphics card.

Of course, as time goes on, we'll spend more time optimizing the rendering engine, CPU's will get faster, graphics cards will have more and more features, and all of this will change.



To some extent this is the case. However, since we have to stream textures to you, which can take quite a bit of time, we do have to make sure that you have most textures near you. It's very easy to walk around a corner and suddenly see a whole wall of textures.

So in greatly simplified form, textures/sounds work on a distance/radius basis - if it's close enough to you that you could potentially need it for rendering, it's going to have to be using up some resources - pushing several dozen large textures to the video card takes a while, even over the AGP bus.



Script load consists of three parts - server CPU usage, network bandwidth, and viewer load.

CPU usage, of course, depends on if your script is running, or doing complex calculations. So, for example, a simple counter script that runs in a timer doesn't take much CPU load, since the script doesn't run except for when the timer is called. However, this is more complicated than it seems. While a sensor callback may never get called, sensors can potentially take a large amount of load waiting for the callback condition, "sensing"

Network use by a script, of course, depends on needing to transmit something that the clients need to know about. So, for example, changing the texture of an object requires us to send information to all of the clients who can see it.

And viewer load, of course, depends on how much the viewer has to do as a result of whatever change occured.



Unfortunately, hiding something inside a box is not necessarily going to reduce viewer load/bandwidth. But adding an on/off switch will, or using calls that don't use up much bandwidth will (like the texture animation function, which works entirely viewer-side). You could potentially use a sensor to decide to turn the lights on/off, - I'm not absolutely certain how much server load that generates, but you could put the calls to it on a slow timer (say every minute) to reduce the load.

But the simplest answer right now is, llSetTextureAnim() is your friend. If you have a need to have lots of rapidly changing colors and textures, use that, and everybody will be happier (plus it'll probably look better). I'm sorry about the cruddy documentation, I wrote it myself, and everybody knows better to let the engineer write the docs.

- Doug

And by the way, Ed is DEFINITELY a girl. It's mentioned at the end of the episode where they introduce her - Faye states so VERY loudly.

DAMMIT fine! I did'nt really pick ED because of gender anyway, I picked HER because she looks like a Raver wearing those internet goggles!!

hehe.. thanks for the reply, Doug... I was kinda barking up the right (BSP) tree... or maybe a tree pretty close to that tree.