Welcome to the Second Life Forums Archive

These forums are CLOSED. Please visit the new forums HERE

llOpenGL / llOpenAL

Jeffrey Gomez
Cubed™
Join date: 11 Jun 2004
Posts: 3,522
11-21-2005 02:32
Okay, so this is essentially in line with the old API talks, in a spun, new way. Bear with me here.

Warning: This post will be highly technical. If you have a poor hand-to-yawn ratio, skip to the bottom.




It stands to fact that we're fairly limited in Second Life when it comes to the core. When we want a shiny new feature, the community needs to sit on their collective hands waiting for the Linden worker bees to magically make it happen.

Of course, it doesn't need to be that way.


So why not let us make our own calls to the graphics and audio system, if the permissions are there? Essentially, make an opt-in system for richer, more open content creation above LL's existing system.





And so I propose:

llOpenGL(list clients, list params) and llOpenAL(list clients, list params)

As defined by library specifications here and here. The key being the ability to rely on standard commands that are easily accessible for advanced applications.





Consider it thusly.

You rez into an open field and find a wooden box labelled "touch me" in floating text. When you touch the object, a permissions dialog asks you if you would like to accept OpenGL and OpenAL calls. You accept.


Suddenly, your client begins downloading the region in streaming, real-time 3D. In reality, the box you just touched is sending your client OpenGL operations directly, requesting new assets to be downloaded in a specific way.


Now you're looking at an entire game world that just rezzed inside of your client's buffer. In the field's place is a giant roller-coaster, held together by meshes and audio signals, all from the asset server and prim you just clicked. Completely new, realistic-looking content has been placed in your viewer, inviting you in.






This is essentially a partial API. The benefits, of course:

- Privacy

Allow calls to be targetted to specific avatars through such a system. If they aren't targetted, they can't see what it is you're doing.


- Scalability

Allow users to encapsulate entire sims in a small system of scripts and notecard-driven meshes (described below). Make Second Life competitive with the rest of the 3D industry.


- Portability

Direct OpenGL/AL calls make the code very portable to and from Second Life. Code would need only to fit in each script or notecard and be in the asset system.


- Richer Content

Allow Second Life to use meshes, already! Give people the ability to store the data in a notecard and call it with OpenGL.


- Standardization

Allows builders to get away from the broken content problem by standardizing the interface. Less of a moving target, more working content.


- Modularity

Highly modifiable at the core levels. Since you're making direct calls to the rendering system, there's no doubt on whether it's you that screw up or the command itself.


- Second Life does most of this already

It uses OpenGL already. Some have even run "OpenGL hooks" to do interesting things with what's already there.




At the end of the day, we should just have an API, but this would be a good start in getting content creators where they should be: Competitive with the rest of the world. For a good example of such an API, read here

Essentially, LL should just let us make calls to the graphics and audio system and share those with others.

And so, I've gotten that off my chest. Good day.
_____________________
---
Strife Onizuka
Moonchild
Join date: 3 Mar 2004
Posts: 5,887
11-21-2005 03:53
Streamed OpenGL commands would be... slow

Though if we had client side scripting...

Dreams in Mono...
_____________________
Truth is a river that is always splitting up into arms that reunite. Islanded between the arms, the inhabitants argue for a lifetime as to which is the main river.
- Cyril Connolly

Without the political will to find common ground, the continual friction of tactic and counter tactic, only creates suspicion and hatred and vengeance, and perpetuates the cycle of violence.
- James Nachtwey
Nargus Asturias
Registered User
Join date: 16 Sep 2005
Posts: 499
11-22-2005 08:09
Will be cool.... but.... that mean we'll need to download the whole 3d WoW-detail-level meshes-riched world from LL server before we can see the graphic? :eek: I can imagine how slow that can be on my connection :(
_____________________
Nargus Asturias, aka, StreamWarrior
Blue Eastern Water Dragon
Brown-skinned Utahraptor from an Old Time
Neil Protagonist
FX Monkey
Join date: 11 Jul 2003
Posts: 346
O! Hell yes!
11-22-2005 12:51
A most excellent idea. I am a fan of any idea to open SL more to coders. I can see this generating some amazing new things in sl.

Obviously there are several things that would need to be overcome but I think it is an excellent idea to contemplate and figure out a way for it or something similar to work.

Not only could we do meshes but also GL shaders and texture mapping I believe. My god I would love the ability to use UV maps. Not to mention the myriad of other cool things that can be done with openGL.
_____________________
"Control the things you can control, maggot. Let everything else take a flying f**k at you, and if you must go down, go down with your guns blazing." -Cort

Need fire? Visit my FX Store in Bisque(232, 48)
Sick-N-Wrong

Like Anime? Visit Nakama!
Zepp Zaftig
Unregistered Abuser
Join date: 20 Mar 2005
Posts: 470
01-31-2006 12:49
This would be really really cool. I'm wondering though how much bandwith would it take to stream a relatively detailed 3d scene made with this, anyone have a clue?
Csven Concord
*
Join date: 19 Mar 2005
Posts: 1,015
02-01-2006 19:23
This addresses something about which I've wondered and am actually poking my nose in here to find out about. However, I'm not thinking entire game level (though some might aspire to that). I'm thinking integration.

Has this sort of thing not come up before? Sure seems like it would have.