3D cards with DRM support (Re: [sldev] Re: "It's Just Not Possible")

[Dale Mahalko]

On Wed, Jun 11, 2008 at 1:08 AM, Loom <loom at loomiverse.net> wrote:
> How does the encrypted cached copy of my house which is stored in your cache
> on your PC know whether to show my front door as open or closed?  or whether
> the windows are currently shaded or not?  you'd have to timeout prim
> packages in the cache every time I opened my front door, closed it or
> changed my windows from opaque to transparent and back again.

Only major state changes that would replace the previous cached
package, such as adding or removing assets to the package.

The positioning of prims in a linkset in a package would be encrypted,
but the positions and rotations of individual prims would not because
each separate prim is already in its own package, or are all copies of
one cached package.


Your door would form one package. When someone arrives at your home,
the door package positioning is sent to the client exactly like how
the positioning and rotations of linksets are loaded into the world
now..

Package states such as your window transparency could be handled as a
"default setting" encoded into the package. If your windows are fully
transparent in the default state, but right now they are 50%, and then
sim just informs the client of the minor differences when rezzing the
world. "Show asset package 'BayWindow' at position v, rotation r, and
also, set face 3 and 7 of prim 5 in package to current state of 50%
transparent."

The default stored package state could be accessible via scripting to
quickly revert it "back to normal":
   llResetPackageState();



If there were a way to directly create multiple different states into
an encrypted package, and naming or numbering those saved states, then
you have the beginnings of a fast client-side animation system --
duplicated on the sim of course, but less network traffic needed to
update the client object state.

The client would just need to be informed via a script to use this
extra state data that is already stored in the package. The stored
states would have access to all primitive and texture parameters for
content in the package, so moving objects around would be much quicker
and smoother than going through a long chain of SetPrimitiveParam /
SetTexture / SetPos commands sent from the server.

If the texture positions and prim movements are relatively linear
between saved states, then the client could even have the option to
tween betweeen states as if they were keyframes, permitting smooth
animations without the jerking and stuttering of complex animated
objects the way it works now.



All components that need to be moved around, resized, retextured, etc,
for each of these states are already in the client-side package, so
knowing UUIDs of items in the package is not necessary. The package
contents are all relative, with a single UUID needed for the package.

It wouldn't even be necessary for primitives in a package to be part
of a linkset, just so long as they're inside the normal 10x10x10
workspace around the center of the package. The package becomes just
more of a special folder, like a tar-archive that SL understands as a
general container for the objects inside, and which can be moved
around independent of each other from one stored state to the next..

- Scalar Tardis / Dale Mahalko