To those voting for Havok 2

If you are currently voting for Havok 2 with the new Feature Suggestion Voting System , I suggest you are throwing your vote away.

It has already been stated by the Lindens here that Havok 2 is in the works for the next major release. Even if it isn't included anytime soon I seriously doubt you will be missing out.

I suggest that you reexamine the proposal for html in sl (prop 5). This would allow usage of outside web interfaces inside of Second Life. Even more importantly this would allow for easy outside data storage for sl applications, even if web content was not being displayed to users. Example:

User touches an object, which loads a url of www.foo.com/data.php?user=avname&region=simname

You can begin to see the implication of this on scripting and persistent data storage. With a complete implementation of HTML in SL you could achieve instant I/O communications without crippled RPC hoops, inefficient mail systems, or serious possibility of abuse.

This feature could be a scripting revolution, I feel its important to the future of in world applications that this be included as soon as possible.

If you feel that this feature is unimportant, then I humbly request your vote go to Kris Ritters proposal 74, Prioritize bugfixing over new features. I myself would vote for this if I didn't feel HTML in SL is so critical.


Thank you for your time.

Are you sure that the result would be as you assume?

What makes you think any of the data from a web page would be available to a script? Surely this proposal would be implemented the same way streaming video is implemented ?

With video, no script gets any access to the video data, and it doesnt come via the SL server.

All that happens is that the SL client steals the output from the quicktime player on the client computer, warps it about, and pastes it into the correct place in the picture of the world.

"web page on prim" would surely be done the same way. Just steal the browser output, and paste it onto the picture. No script access to any data from the page. None of the benefits you describe.

Obviously what you assume would be great, but I dont think it is implicit in proposal 5.
Acceptance of proposal 5, I think, would not get you this.

I suggest you keep things clear by putting up a separate proposal for this hugely more difficult and complex thing you want - ie giving script access to web page content. I would think this would be an entirely different matter, as evidenced by the delays and difficulties implermenting XML/RPC.

All proposal 5 asks for is painting the browser output onto the face of a prim. Nothing more. Just like video.

I may, of course have misunderstood you.

If you HAVEN'T assumed a script can read the data, then please help me to see how this has more significance than simply being able to see web pages on prim faces, without being able to use them to control in-world events.

Don't get me wrong - its a great feature, a vital next step forward, and I want it. I just don't think it gives as much as you believe.

The assumption is that you would be able to chose the URL to view via a scripted interface.

You can already do this with video as it stands at the moment, but the limitations placed on video make it impractical. The unstated assumption here is that you would be able to select a different HTML texture per prim, possibly even per face. In addition I don't believe standing on a parcel would be required to use this function.

The URL itself, including any variables you have added to it via script, would be transmitted to web server, allowing the loaded page to do what it will with the data. Of course this is not a 2 way communication, but it does allow bulk data to be permanently stored, and you could certainly from there email or RPC the data back to the prim on request.

A complete implementation would of course be even better, but even a base addition of this feature would work wonders for data storage, in addition to its primary benefit of displaying data to users.

I believe you misunderstand what the voting process is specifically for. The first 40 or 50 props were actually Linden proposed, so incase you didn't notice, Havok 2 is a Linden proposal. What it means to have the most votes is that it will get the highest priority by the development team at Linden Lab. Of course, that's after they accept the proposal.

So what you need to understand is that this voting process is not just to get new ideas into the stream of development, but also to help prioritize those things that are already under development.

Dave,


Sounds like Andrew is ready to do this whether its a player prority or not.

Yes, Andrew Linden may be ready to implement Havok 2. In fact, Andrew may spend 100% of his work day hacking on Havok 2. But, maybe Andrew represents only 5% of the entire programming staff at LL. So, in voting for Havok 2, many SL residents are proposing that LL dedicate much more resources to Havok 2 implementation, than to other feature requests. In effect, instead of just assigning Andrew tha Havok 2 task, LL should assign 50% of their programming resources to the task. Instead of launching Havok 2 in December, we want Havok 2 launched by Summer.

Actually, Andrew is 16.67% of the developing power of LL



Good news for you, Editorial This is currently being addressed, and while the timeline for its release is not "official" yet, we'll have in-world web browsers "soon" (which means: probably before Havok2 or about the same time). I don't think that this process may be "accelerated" much by getting a top priority, since the work has already been started and is well under way (just like the work on Havok2). However, of course, if this item drops to the bottom of the priority list, LL may eventually drop it - like what happened with the Linux client, who was perhaps 90% ready, but an informal survey by LL showed that it was not so important to keep working at it (since people are able to run SL using Wine over Linux). The recent rise of the Linux client's priority in the Feature Voting list may have LL reconsider its priorities, however.

So it makes sense to keep HTML on the top of the list. While, as Editorial pointed out, Havok2 does only need to be listed there just to make sure people are really interested in it, because LL is going to implement both - and highly likely before summer.

As I understand it, Andrew is the majority if not sole owner of the physics engine. If this is actually the case that is significantly more power over the Havok2 feature than just being one of 6 possible programmers.

Do you have a source you can site for this information? Any more information on how Linden Lab intends to implement it?

Thanks, my point exactly. Here is hoping for HTML before summer )

I had a realization last night while talking with a friend about how people relate to SL and to the web. I am still very new to SL, and very aware of what it does to "players" and how they interact with each other and things in the world. The virtual world of SL is very real to our senses, and adding more realistic physics, via Havok 2 or otherwise, will strengthen the experience. For me, I don't require much suspension of disbelieve to feel I am there already. More physics done faster will make it more fun, more immersive, but already it is enough for me.

The dominant experience in SL is being there, making connections with people, feeling you really are there, and almost mind melding with them. It is a powerful experience that many of you have felt. And what do we do with our connections? Lot's of fun things, but one thing is that we share bits of information, usually lost to the ephemeral chat stream...

In contrast, the web is information first, with little or no feeling of being connected. In the early days of the WWW, people noticed the feeling of "going to a web site", and we still talk about it that way, but even though you are there, you are just a click away from not being there. And you don't (usually) see who else is there. The value of the web is access to the vast ocean of information, disorganized as it still is. The collaborative aspects are also valuable, but mostly limited to messaging, again with little feeling of being connected.

So what will be the effect of combining SL and the web, bridging the gap between information and connection? Will we be able to find each other more easily? Will web sites more to SL? I don't know if we can predict - the potential is enormous. Just remember how much the web changed the world, and multiply that by 3.

But what we mean by adding the WWW to SL could be very different depending on what features are supported. If the only feature we are talking about is static display of a web page on a prim, as if it were a texture, that would be a good start, but it wouldnt go very far. If we can make the URLs dynamically computed, that would allow a lot more, since it could be used to submit different requests to servers based on what the users are doing. But what about interacting with the page display? Can we click on links in the page, or invoke any of the other actions that web pages support? Click and keyboard events in SL must be translated into events on the web page to support that.

Beyond that, further integration of the WWW with SL is possible if the WWW browser is built into the SL client, not just a page pasted on a prim. It would be great if we could use JavaScript as the scripting language not only for dynamic web pages but for all SL objects. Then we could begin to dissolve the web page, make it an integrated part of SL, and vice versa.

How about making SL available on the web as well? An applet or plugin to the browser could provide a minimal UI with limited capability, enough to get more people experiencing the connectedness, and draw them into the full SL experience.

Since this was initially about the possible change to Havok 2, I would suggest people go research the Novodex physics engine and PhysX PPU card. (Prop 46)

If it is just an increase in possible avatars in a sim or better physics you are after than voting for Novodex would be a better choice. More information is available in the discussion portion of the Proposition.

Proposition

Discussion

My guess is that the first step will be to have the normal browser live and running, and to write its window into the SL world so that it fits onto a prim, replacing chosen texture, as video does. Since that is probably pretty easy now, I would hope that the problems now being solved are to do with transmitting screen clicks back to the browser so that we can click normally on browser links, and surf the web normally, on the prim.

Thats what I think we'll get first. Without clickability it would be not much use IMHO.

The only way to use this facility to control in-world events would be (as suggested above) to use an entirely different route back from webserver to world, like email or XML/RPC.

So no script could directly access, and act upon, any data displayed in the browser window. It just wouldn't have access to it.

Thems my guesses at the most it would be realistic to expect in the first implementation. Anybody disagree ? Anybody realistically expecting more ?

Sorry to be off subject (Havok 2) here but am wondering, if HTTP: in SL happens, wouldnt that allow us to view web supported video that isnt QT supported (such as avi) on our prims now? Just a thought

I have copied the relevant comments on this thread to this one to consolidate discussion. If you wish to continue posting about HTML and the WWW on a prim, please do so there.

/13/d1/44485/1.html

Thanks.

No, I can ALT-TAB if I want a browser. And I wouldn't trust a SL browser to be free of exploits.

Since LL has already announced Havok 2 will be in 1.7, one supposes everyone will get their votes back on Havok 2 pretty soon and they can all vote for NovodeX as the next physics upgrade. It doesn't seem likely that they're going to abandon the work they've done already on Havok 2.

Which is why I didn't spend a vote on Havok 2, of course. But if one of my other favorites gets implemented, I could see voting for NovodeX after 1.7. We'll see.

neko

Seems like the havok2 is not available on the macintosh...so this will mean loosing some SL players (ummm...i hear some win saying "well, who cares ...

I just informed.

here's the short version:
http://www.insidemacgames.com/features/view.php?ID=351

What? No.

The Havok2 physics engine is server-side only. The servers don't run on Macs, ergo they can use havok2.

There will be zero increased requirements due to havok2 coming out... in fact, it may lower some minimum requirements if it happens to increase sim performance, camera performance, and the like.

LF

Servers need a client...in the article seems quite clear...am i wrong?

All the physics happens on the server. The server then sends the results to the client. The clinet renders the results. This, fortunatly, does not require Havock on the client machine. So, Mac users will still be playing SL after 1.7

Since LL has already announced their approval of this for 1.7, can we please release all 2000+ votes for it?

par-a-noid

So they are not using the Havok 2 animation at all then, just the Havok 2 physics engine on the servers? Or both? They will be using the same graphics engine for the client so they don't have to waste time (re)coding two parts of the system? Just curious if anyone knows for certain.

There is no client side component that I know of. (with SL)