From bc44e6b3339976fc08d86eecc79f972fb90aecab Mon Sep 17 00:00:00 2001 From: David Walter Seikel Date: Fri, 1 Jan 2016 21:57:24 +1000 Subject: Import the design docs from Drupal / MediaWiki. --- docs/BVJ.html | 160 ++ docs/BlackListAssetServersTracker.html | 7 + docs/ClientHamr.html | 10 + docs/Croquet-integration.html | 114 ++ docs/Grid-data-flow.html | 245 ++++ docs/Grid_data_flow.png | Bin 0 -> 207031 bytes docs/InworldAnimationEditor.html | 109 ++ docs/LSL-functions-implemented.html | 61 +- docs/LuaSL-New-scripting-engine.html | 796 ++++++++++ docs/NGIW.Commands.html | 45 + docs/NGIW.html | 49 + docs/Nails.html | 2514 ++++++++++++++++++++++++++++++++ docs/OMG-WTF-BBQ.html | 54 + docs/SledjHamr.html | 134 ++ docs/index.html | 31 + 15 files changed, 4299 insertions(+), 30 deletions(-) create mode 100644 docs/BVJ.html create mode 100644 docs/BlackListAssetServersTracker.html create mode 100644 docs/ClientHamr.html create mode 100644 docs/Croquet-integration.html create mode 100644 docs/Grid-data-flow.html create mode 100644 docs/Grid_data_flow.png create mode 100644 docs/InworldAnimationEditor.html create mode 100644 docs/LuaSL-New-scripting-engine.html create mode 100644 docs/NGIW.Commands.html create mode 100644 docs/NGIW.html create mode 100644 docs/Nails.html create mode 100644 docs/OMG-WTF-BBQ.html create mode 100644 docs/SledjHamr.html create mode 100644 docs/index.html (limited to 'docs') diff --git a/docs/BVJ.html b/docs/BVJ.html new file mode 100644 index 0000000..c96574d --- /dev/null +++ b/docs/BVJ.html @@ -0,0 +1,160 @@ + +
+ + +This example BVH is 20 lines 505 characters, and defines a pointless animation on a trivial skeleton.
+HIERARCHY + ROOT Hips + { + OFFSET 0.00 0.00 0.00 + CHANNELS 6 Xposition Yposition Zposition Zrotation Xrotation Yrotation + JOINT RightUpLeg + { + OFFSET -3.91 0.00 0.00 + CHANNELS 3 Zrotation Xrotation Yrotation + End Site + { + OFFSET 0.00 -3.46 0.00 + } + } + } + MOTION + Frames: 2 + Frame Time: 0.033333 + 8.03 35.01 88.36 -3.41 14.78 -164.35 13.09 40.30 -24.60 + 7.81 35.10 86.47 -3.78 12.94 -166.97 12.64 42.57 -22.34 ++
+
First the syntax is changed to be JSON. The sample above is transformed to 19 lines 715 characters:
+{ + "HIERARCHY":{ + "NAME":"Hips", + "OFFSET":[0.00,0.00,0.00], + "CHANNELS":["Xposition","Yposition","Zposition","Zrotation","Xrotation","Yrotation"], + "JOINTS":[ + { + "NAME": "RightUpLeg", + "OFFSET": [-3.91, 0.00, 0.00], + "CHANNELS": ["Zrotation", "Xrotation", "Yrotation"], + "JOINTS": [ + { + "END": true, + "OFFSET": [0.00, -3.46, 0.00]}]}]}, + "MOTION":{ + "Frame Time":0.033333, + "Frames":[ + [8.03,35.01,88.36,-3.41,14.78,-164.35,13.09,40.30,-24.60], + [7.81,35.10,86.47,-3.78,12.94,-166.97,12.64,42.57,-22.34]]}} + ++
or equivalently to 5 lines 469 characters:
+{"HIERARCHY":{"NAME":"Hips","OFFSET":[0.00,0.00,0.00],"CHANNELS":["Xposition","Yposition","Zposition","Zrotation","Xrotation","Yrotation"], + "JOINTS":[{"NAME":"RightUpLeg","OFFSET":[-3.91,0.00,0.00],"CHANNELS":["Zrotation","Xrotation","Yrotation"], + "JOINTS":[{"END":true,"OFFSET":[0.00,-3.46,0.00]}]}]}, + "MOTION":{"Frame Time":0.033333,"Frames":[[8.03,35.01,88.36,-3.41,14.78,-164.35,13.09,40.30,-24.60], + [7.81,35.10,86.47,-3.78,12.94,-166.97,12.64,42.57,-22.34]]}} ++
or equivalently 1 line of 461 characters, which I won't include in this document. I have worked though larger examples and this is a very typical compression ratio. A BVJ file (using sampling) is about the same size as a BVH file.
++
The semantics are that the "Hips" and the "RightUpLeg" of something are animated. The mapping from the BVJ file's "NAME" fields to the avatar skeleton is straightforward, the names in the BVJ are matched against the names of the skeleton components. Then the appropriate rotations and translations are applied frame by frame.
+The point of the hierarchy is so that when a joint moves or rotates, it's children get carried along for the ride. When you turn the hips left in the sample BVJ, the whole body turns left.
+Note that the "offset" value isn't actually used when animating avatars. The position of the hips and the angles are all used, but no attempt is made to match the skeleton bone lengths to the BVH segment lengths. So I propose that we can eliminate them or make them optional to reducing lag and file size. The offsets are useful in other tools because they define a skeleton that can be visualized.
++
The hierarchy portion of a BVJ is a fine place to express attachment points.
++
... + { + "NAME": "RightUpLeg", + "ATTACH": [12], + "OFFSET": [-3.91, 0.00, 0.00], + ... ++
+
The semantics are that an attachment point can be created for each item in the hierarchy at the midpoint between its parent's position, and the end of it's offset.
+When a client rezzes in, they could parse and read their current skeleton's BVJ, and use that to tell other clients what attachment point 103 means. No more prims stuck in your crotch floating in space as you walk away.
+Q: How to define the zero rotation at the attachment point? Need to match what is done now.
++
If I want to attach two things to my pelvis, say a skirt and a tail, I should be allowed to. There are two ways the client could communicate this to a server, depending on the servers rules. A nice server says "Sure, attach your whole inventory to your head, what do I care?". A mean one says "That attachment point is in use." For mean servers the client can just make a new attachment point at the same place. It would update it's skeleton BVJ to include:
+... + { + "NAME": "RightUpLeg", + "ATTACH": [12,99] + "OFFSET": [-3.91, 0.00, 0.00], + ... ++
+
I would like to further enhance the client to add attachments *at* the joints themselves with the semantics that they average (in some sense of the word) the directions of the two segments from the joint to the beginning of the parent segment and from the joint to end of child segment. The motivation is to have kneecaps/kneepads that move reasonably without special attention from an animator.
++
BVH was defined with skeletons in mind. But, at first glance it seems that if there were some two (or more) prim object with a root prim named "Hips" and another prim named "RightUpLeg" we should be able to animate that link set using this same BVH/BVJ file.
+The one issue is that segments in the BVH model are like vectors, they have a near end, a far end, a length, and they rotate about their near end. In particular bones have no width or depth, only length.
+So I propose adding "PIVOT":[x,y,z] to define about what part of a prim the prim rotates when being animated. When omitted the center of the prim is used, and is equivalent to "PIVOT":[0,0,0]. The pivot ranges from -1 to 1 on each axis with -1 meaning the small end and 1 the large end. For example consider a cylinder, "PIVOT":[0,0,0.5] would rotate about the point midway between the center of the cylinder and the +Z face of the cylinder, i.e. half way up to the top. "PIVOT":[0,0,1] would make the cylinder act like a normal bone making up a skeleton.
++
Things are interesting when I want to define an animation of my avy and an attachment to my avy. Suppose when applying an animation from a BVH or BVJ that I get to a joint named "tail" with a defined attachment point 103. If my avatar is wearing something at point 103, then search that object for a prim named "tail". If I find a prim named "tail" in the attachment then this joint's animation applies to that prim. And all the children of the "tail" joint in the animation are sought in the link set of the attachment.
++
Why yes, that *does* mean attachments can have attachments, glad you asked. Suppose my tail has three bones, and the attachment point defined for the last bone is 104. I could attach the tail to point 103, and a pretty bow to point 104. The data model would be avy attachment point 103 has "thin neko tail with pink tip" attached, and avy attachment point 104 has "pretty bow" attached. But because point 104 is defined on a child joint of the joint with atachment point 103, the object "Pretty Bow" would move with a part of the tail, not with some random part of the avy.
++
The BVH file format was originally created for motion capture. So it defines animations by means of sampling. The same way a motion picture film samples the world 24 times a second making still photographs, the BVH captures the values on all the channels at regular points in time. But not all animations are created by motion capture, perhaps most are made with a keyframing animation system.
+Keyframing is cool because it uses the computer to compute all the between states. We tell the computer at time T0 arm is at 13 degrees rotation, and at time T10 it is at 23 degrees rotation, and the computer figures out where the arm needs to be rotated at all points in time between T0 and T10. This can result in smaller animation files and lower CPU usage.
++
I propose adding keyframe syntax as an alternative to the existing "MOTION" section of BVH files.
+{ + "HIERARCHY":{...}, + "KEYFRAMES":[ + { + "AT":0.00, + "Hips":[8.03,35.01,88.36,-3.41,14.78,-164.35], + "RightUpLeg":[13.09,40.30,-24.60]}, + { + "AT":0.033333, + "Hips":[7.81,35.10,86.47,-3.78,12.94,-166.97], + "RightUpLeg":[12.64,42.57,-22.34]}]} ++
The semantics are that the value of any channel is the linear interpolation of it between the two closest keyframes in time. Though maybe should support other interpolation schemes such as quadratic, and cubic. I think it's obvious that this will often result in much smaller animation files. My example above is fairly pointless since it is just changing every sample in the BVH into a keyframe. As a result it is bigger, but a possible benefit is that it slightly better supports playback at frame rates other than that specified in the BVH.
++
Another enhancement I want to add is to capture all the elements of an in-world animation in the format. In world animations have things like priority, looped or one shot, loop start/end points, ease-in and ease-out etc.. There is no place for them in a BVH, but not much creativity is needed to put them in a BVJ file. Then we can edit those parameters, set them in the file before import, and save them in a file on export.
+I favor this placement
+{ + "priority":3.5, + "looped":false, + "HIERARCHY":{ ... } ...} ++
But can see arguments for this instead
+{ + "HIERARCHY":{ ... } + "MOTION": { + "priority":3.5, + "looped":false, + ...} ...} ++
+
+
The last enhancement I want to make is to add absolute time references. Consider using the BVJ file to define the animations of the hands on a analog clock. I would like to be able to express "At noon, all hands are pointing up." What this means is when invoking an animation we need to map from the Unix time to the animation's time. This is a linear mapping so two numbers are required, one expresses how many animation seconds elapse for each Unix second, the second specifies at what Unix time at which the animation time 0 occurs. There is a third number implied by looping animations. How long the animation is. Note a looping animation often begins to loop at some point after animation time 0 and ends before the largest animation time in the file. This is due to the types of interpolation used when keyframing. Linear interpolation requires two keyframes before a position can be known, quadratic 3, and cubic 4.
++
Currently there are none, but see InworldAnimationEditor for my ideas. It should be obvious how to transform a BVH into a BVJ file that uses sampling. By looking at the rates of change of channels it is possible to discover inflection points and use them to synthesize a keyframe representation that is a close match to a set of samples.
+And, of course, I want to make this file format editable in-world using nice GUI and 3D editing tools. Basically a clone of QAvimator in the client.
++
There are use cases where it makes good sense to communicate an animation between clients with almost no server interaction. Why pay 10 Bogus-Bucks to adjust the position of my hand as we sit next to each other. I'll just edit my avatar to move my hand and the client will make a BVJ file ship it to your client which will show it to you.
++
Fang Said: See the very last paragraph of SledjHamr, the "random notes from my old Web 3.0 document " section at the bottom, to see one suggested method of moving your hand.
+Alice Replied: Looks cool, but requires Inverse Kinematics (if you mean the touch commands), or some puppeteer protocol that I know nothing about.
+What I imagine right now is InworldAnimationEditor
+ + diff --git a/docs/BlackListAssetServersTracker.html b/docs/BlackListAssetServersTracker.html new file mode 100644 index 0000000..f1aae3e --- /dev/null +++ b/docs/BlackListAssetServersTracker.html @@ -0,0 +1,7 @@ + + + + +
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Consider your inventory. A mess huh. Well, what is it really, especially in a world like NGIW / OMG describes? It's just yet another hierarchy of folders and thingies. We are probably wasting our time writing any code for it. Why not leverage the users favourite hierarchy browser/editor. Maybe it's called FileDamager made by MicroCruft in Redstone Wishangton. Maybe it's called Netscape, or Nautilus. Many of the modern file browser tools will talk a protocol named WebDAV. If the asset server spoke WebDAV, then we could perhaps rip the inventory code clean out of the client.
+This little fantasy points in a really blue sky direction. Use existing protocols and tools to remove stuff from the client. Make it easy for tools that already exist to interact with the 3d world.
+That's the Client Hammer.
+Note - The simian grid has a WebDav front end to inventory. http://code.google.com/p/openmetaverse/
+ + diff --git a/docs/Croquet-integration.html b/docs/Croquet-integration.html new file mode 100644 index 0000000..943274e --- /dev/null +++ b/docs/Croquet-integration.html @@ -0,0 +1,114 @@ + + + + +I just stumbled on this - http://forum.world.st/OpenCobalt-Croquet-client-for-Opensim-td622809.html
++
I'll reproduce the relevant part here -
+Rich White wrote: + +> Thinking out loud regarding the feasible of a OpenCobalt /Croquet +> client/peer for Opensim ? +> +> * Connect to Opensim Server - much like Cobalt connects to Jabber now +> * Portal window opens to server - much like opening a stored file or +> connecting to another peer +> +> Convergence of the technologies would seem to bring the best of both +> "worlds" (peer/server/content) into one ecosystem. +> +> A few dangling pointers: +> http://opensimulator.org/wiki/OpenSim_Archives +> http://opensimulator.org/wiki/User_Documentation +> +> +> Ideas? Is a convergence possible? ... This though may be WAY off but +> wanted to bring it up and see what others thought. +> +> Cheers, +> Rich +> === +> +> +... [show rest of quote] + +Actually, I've been looking at merging SL and Croquet off and on for +several years, and there's far more interesting ways of merging the two +that can serve as a pattern for using Croquet in many situations besides +formal virtual worlds. + +The simplest is to simply use the SL media plugin or the equivalents +that work with 3rd party viewers, and create a "telepresence" between +worlds. I.E. a simple view-only portal or 2D equivalent using VNC, with +or without interaction: + + http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Media_Rendering_Plugin + +This particular use can be extended to provide a service that could be +added to SL instant messaging, so that you could create a temporary +world and invite a buncha people to join you in a private 3D chat +island, for collaboration or simply to "hangout" without having the +overhead of maintaining a genuine OpenSim or SL sim. + +Obviously, you can extend the concept to be an option for ANY kind of 2D +collaboration system, from Jabber to IRC to Google Wave to whatever. +Imagine having a "create Croquet island/invite people" option as +standard in any IRC client. + +Getting back to typical virtual worlds usage, the idea of a viewer +plugin that leverages all of Squeak/Croquet's functionality to enhance +some other viewer shouldn't be sneered at. Right now, the SL viewer (for +example) barely provides access to raw mouse coordinates for UV tracking +on a texture (the current media plugin scenario), but there's no reason +why any arbitrary event or internet packet couldn't be intercepted and +shunted off to squeak for pre/post processing. + +http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Proposed_Extension_to_Media_Plugin + + +I'm currently working on a proof of concept of this last by intercepting +arbitrary packets to/from the SL server/viewer using the Gridproxy +utility and/or injecting or pre/post processing such packets. When you +combine that with the ability to intercept mouse UV coordinates on a +texture in SL and render into said texture from Squeak/Croquet directly, +you get all sorts of possibilities. Add localhost/seaside into mix and +you've got a very powerful experimental system that can project control +surfaces via html on a prim, or in the SL built-in browser, or via +VNC-like interactions directly to a prim on the local SL viewer. +Combine that with broadcasting to streaming server, and you have a +virtual worlds whiteboard that can project into SL ala the metanomics +virtual lecture hall. + +http://www.metanomics.net/ + + +Start interacting with internal viewer events, and you can leverage +physics/graphics creation/etc from the Squeak/Croquet side, and merge it +directly into a local SL instance for custom puppeteering with the +possiblilty of doing a P2P collaboration mechanima where individual +avatars can be controlled by a single machine using a script and/or +timeline control interface. The resulting avatar activity can be +"filmed" for mechanima, or could be uploaded to a central server for +rebroadcast to a virtual world audience (or both). + +http://wiki.secondlife.com/wiki/User:Saijanai_Kuhn/Plugins_discussion#Puppeteering_Plugin + + +Instead of using 2D projections, you could also leverage the 3D portal +system of Croquet to inject 3D cenes from Croquet into a given virtual +world viewer, and either maintain a backk-end P2P connection between +participants, or shoot the composite scene to a central server in some +fashion using the existing virtual world protocols. + +The possibilities are endless for synergy between Croquet and other +virtual worlds, IMHO. + + +Lawson (Saijani Kuhn in Second Life) + + ++
In this section I will mention the stuff that I think I know, and why it might be wrong. There have been major changes in how these things have been dealt with, particularly with the introduction of ROBUST. Personally I have experience with the closed source OpenSim fork that was in use at M7, and the open source OpenSim fork that is used at IG.
+There are two types of assets - things that have been rezzed in a sim, and users inventory. While poking around in the M7 system I figured out that both are somewhat similar.
+There is database stuff that has meta data at least, and there is file based stuff that seems to include the actual asset data, things like script source, script binaries, texture, sounds, animations. I was not able to completely understand it all before M7 closed.
+Received wisdom is that sim assets are stored on the sims server, and that inventory assets are stored on the central database. Recent experience has suggested that this is not correct. While I was testing the IGnoble scripts, I loaded an OAR of my home sim into the sim I was running on my local computer. Surprisingly, my sim server spent the next three hours uploading .. something .. to the grid server (my upload speed is not spectacular, and there was a decent amount of data). Only after it had completed that, did it rez the sim in world, which happened quickly for me, but I was sitting on the same computer as the sim server. A quick inspection showed that I had the expected file based assets on my server, though they where in the cache directory.
+My theory is that the sim assets are also stored on the central server, but cached on the sim server. The big upload was probably the entire contents of the OAR file.
+Now, lets figure out what's really going on.
++
ROBUST seems to be the centre of the OS data flow universe. "ROBUST is a flexible server shell ..." the OS web site says, not sure exactly what that means. We shall find out. It basically seems to be a way to connect to arbitrary processing and storage modules, and the storage modules part is where our interest lies on this page.
+Sim servers point to one or more ROBUST servers for their services, These pointers are a HTTP URLs that is usually the grid server, and a port number. You can have different ROBUST services on different port numbers, or on different servers. The ROBUST servers can handle one or more of the services. ROBUST servers can point to others, acting as a proxy. ROBUST hosted services can have others as dependencies, they can point to other instances of ROBUST on other URL/ports.
+Robust has the concept of IN and OUT connectors. The IN's seem to be the ports used by sim servers and others to connect to the services, they load the proper OUT or code modules. The OUTS seem to be the connectors to the database, or perhaps the code performing the service. Or maybe the OUTs are for sending data back, and the modules are for doing the work?
+Apparently ROBUST is designed to allow code reuse.
+Note that this will allow us to easily integrate OMG, as we can do that in any language, implement the relevant parts of the ROBUST wire protocol, listen on a given HTTP port, then just tell the ROBUST clients to use that port. Nails:command pump in fact includes provisions to have wrappers for other protocols, which is a perfect match here. So glad we don't have to deal with direct interfacing to C# code. B-)
+The ROBUST wire protocol looks like it's HTTP POSTs to the URL and port number. The POST includes the service name, and a verbose (XML, ewww) text command to that service.
++
Sim servers have these, which include connection strings to the local database server -
+These only include a URL to the grid server -
+There are three possible asset caches, only one should be on, but none of them can be on -
++
A quick look shows the sims on the grid server seem to be setup the same way.
+ROBUST has this to say -
++
On sims -
+Asset and Inventory services include connection strings to the local database, and URLs to the ROBUST grid server. There is also the cache. Only flotsam cache will be looked at for now.
+On the grid server -
+Asset service includes a local file part, but may include a database part. Inventory service, dunno. Library service is file based, but not important right now.
+Soooo, what is stored where? Which are the real assets? Where's the data, database or file? Where's the cheese? B-)
+The source code is here -
++
Question - What does the sim use it's InventoryService database connection string for? Perhaps that's only needed for when the sim is not using ROBUST?
+Hmmm, according to OpenSim/Region/CoreModules/ServiceConnectorsOut/Inventory/InventoryCache.cs -> CacheInventoryServiceURL() there may already be a mechanism in place to use other inventory servers PER USER. For HG I think. Makes sense. B-)
++
+
The above is what tracing things from the configuration files gets you. But this is C#, an object oriented programming language. Like most such languages, it's carefully designed to hide implementation details from the programmer. Which is fine, unless it's the details that you really want to know. Then it sucks, and you sometimes have to understand the deep magic, and do a lot of searching and head scratching to figure things out.
+So, that's the provided frame work, let's see if we can sort out how that frame work is used, and if anything steps outside of that frame work.
+There is still a large piece of the puzzle missing. The above services only seem to deal with the metadata for assets, not with the actual data.
++
prims is the prims in the sim. primshapes is their shapes. primitems is the content of the sim prims.
+prims.RegionID prims.UUID == primshapes.UUID But what about primitems? That has (takes a deep breath) itemID, primID, assetID, and parentfolderID. primID seems to be exactly the same as parentfolderID. And indeed prims.UUID == primitems.primID. itemID and primID are keys, itemID is the primary. primitems.assetID=assets.id
+Primitems is only metadata, where is the actual data? Is this what itemID and/or assetID are all about? Primshapes has a Texture blob, but is it all the face textures that go into a prim?
+inventoryitems has - inventoryID and assetID (also avatarID and groupID). Oddly enough it has a groupOwned flag to. I thought inventory would only be owned by the person who's inventory it is in, but I have seen things in my own inventory owned by others. Once more, it's only metadata. InventoryID is the primary key.
+It appears all roads lead to Rome .. er the assets database. One ginormous amorphous blob of all our stuffs. It has some metadata, an id, and a data blob, the contents of the data blobs on the ones I have seen look to be about the correct size for being the actual data for the asset. id is the primary key. There still might be a file system as well? As a cache only? The assets table on sim servers seems to just be the default assets. The grid server assets table is almost 2 million records, or perhaps only half a million, the system gave two very different counts. Could be where all the damn asset data is stored. B-(
+The grid prims table only has assets for the grid sims, plus a few others that are old sims, which got deleted from the regions table automatically I think.
+Prims table is all the prims in the grid sims. Prim shapes is data about those prims. Primitems is the contents of those prims. Assets stores stuff for primitems.
+Umm, things that used to be in the sim get into the OAR? The new sims I created to test OS 0.7.2 now have stuff in their prim* tables from people that have not logged on. I copied them from Sandbox using OARs. It seems to be true, but why only one or three objects? I don't think OARs populated prim* tables on 0.7.1.
+NOTE - it takes a loooong time to search the assets database for a name.
++
+
Sim server opensim.prims.RegionUUID and UUID
+Sim server opensim.prims.UUID -> Sim server opensim.primshapes.UUID (one to one) The actual prim shape.
+Sim server opensim.prims.UUID -> Sim server opensim.primitems.primID (one to many) The meta data for the prims contents.
+Sim server opensim.primitems.assetID -> Grid server opensim.assets.id (one to one) The actual data for the prims contents.
+prims.SceneGroupID seems to be what ties a linkset together.
+Primshapes has two binary blobs, one called Texture, the other called ExtraParams.
+primshapes.ExtraParams includes flexi (various flexi parameters), light (local light parameters), sculpt (type, sculptMapTextureUUID), and projection (projectionTextureUUID, FOV, focus, amb).
+primshapes.Texture is an OpenMetaverse library binary object that includes data for the textures and colours on each prims side. primshapes.Texture includes texture UUIDs, directly stored as 16 bytes, plus the other texture information, stared as binary, some of it stored as bit fields. For prims with more than one texture, more copies of this data is stored. OpenMetaverse library is included in OpenSim as a binary, no source, but I found the source, just not sure which version.
+I'm assuming for the moment that actual texture data is all in the grids assets table, probably cached on the sim server using flotsam. In theory textures have to go into inventory first before they are applied to prims. In practice, OARs can bypass that.
++
All on the grid server.
+opensim.inventoryitems.inventoryID, avatarID, and parentFolderID
+opensim.inventoryitems.assetID -> assets.id (one to one) The actual data for the inventory.
+opensim.inventoryfolders.folderID, agentID, and ParentFolderID
+This seems pretty straight forward.
++ +
+
+
I tried configuring my home sim server to have it's own ROBUST server, and the sim running there to use it only for AssetService. The immediate result was horribly correct. It can't have been that easy. In the end, it was not that easy. It had the meta data about assets, but the assets data was still on the grid server. The sim shows up on the map as white. I was unable to rez things from inventory, but could create new stuff, and even move objects to the next sim running on someone else's server. Everything else seemed to be working fine, though one person (running on a very underpowered computer) had troubles rezzing herself, and switching back to the grid AssetService seemed to fix that. On the other hand, another person rezzed fine. Both these people where connecting to my home sim server from some other place on the planet than my home. The tests where not exhaustive, but the inability to rez from inventory was a show stopper. Something needs to be fixed for that to work. The fact that it still stored the assets data on the grid server means it was a failed experiment, as that's the primary goal.
+Refinements of that experiment would be to see what happens when a new sim is built up within that configuration from newly created prims. What happens during an OAR load? Will the new assets be stored locally, or sent to the grid server, or will it just not work?
++
This is more likely to succeed, as it's a similar mechanism to that used by HG, a pointer to an external InventoryService is stored with the HG users record on the grid they HGed to.
+UserAccounts.ServiceURLs has "HomeURI= GatekeeperURI= InventoryServerURI= AssetServerURI=", or blank, or NULL. It either has to be empty, or properly filled out. They are normal service URLs as used by ROBUST. I think they are only involved in HG. Only one person in the IG database has those filled out, I think that was a test Rizzy was doing. Not sure what HomeURI is, but the others look like the usual ROBUST services. Though GateKeeper is for incoming users? Wonder what HGers get if they are stored in this database table?
+HomeURI is the URI to the UserAgent service on their home grid. It's used to authenticate them with their home grid, and to form the URL part that is added to their name in world.
+Hmmm, does not look like GatekeeperURI is actually used. shrugs
++
In theory this should not work, since the prim metadata is on the old sim server, and not accessible from the new server.
++
I'll have to create a fake texture first, then see if I can fake an OAR with that texture.
+Should create a sim with just a test prim in it, with the default texture. Save the OAR. Then see if I can insert a faked texture onto that prim in the OAR.
+The terrain texture might be a good choice to experiment with to, they are easily changed in the OAR, and stored in the OAR. Their UUIDs are stored in the regionsettings table.
++
Just hijacking my own page here for a moment - The console uses the ? key to show help, no matter where you type it. So ? can't be use as part of a name or other arbitrary text. The offending lines are in OpenSim/Framework/Console/LocalConsole.cs starting at line 398.
+I just woke up and had an idea, it might turn out to be crap once I have actually thought about it. lol
+One of the biggest problems is that sim asset data is spread between the sim server and the grid server, this makes things hard. We can abuse the cache mechanism. Write a cache module that stores sim asset data on the sim server, in a format that matches the rest of OMG. It's not really a cache though, it's the new sim asset database. Have the sim server tell the grid server that it's OK to delete stuff from the asset server, it has it now. On the grid server side, have a "last accessed" time stamp on the assets database. Archive stuff that's not been used for awhile. Actually delete stuff if there's no inventory pointers to it, AND sims using it have said it's OK to delete. Adding some reference counting to that database might help this process to.
+
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.
Step 1: right click avy > edit pose > a list of currently playing animations displays and you can choose one. Or right click avy > new pose
+Step 2a: big edit style arrows sprout from the current joint (last edited, or hips by default). You can interact with it in all the standard ways users already know about with the build window. Move? Drag an arrow. Rotate? Drag a ring or the gray ball.
+Step 2b: The edit window opens to the animation tab, or perhaps a whole new GUI. As a first approximation, imagine grabbing all the stuff from qavimator, squishing it into one or two 'floaters' windows inside the client.
++
The GUI I imagine for IK, perhaps a tab on the animation editor?
++
To take advantage of the 'absolute time' feature, you need to edit multiple animations at one time to make them interact well. Each animation could sprout a new line in the time line window. Would need some indicator which is the current animation and way to switch so the numbers boxes and meta info displays make sense. Time between the many animations is synchronized, so stepping a frame forward, steps all animations forward.
+Most importantly, if you are granted permission, you should be able to right click on another avy, and choose edit pose.
++
Now, I described all this as if BVJ's only applied to avatars. They don't. But the commands and behaviors are the same when editing animations for a door, an avatar, or an attachment (to an attachment to...) to an avatar.
++
If you edit your pose, and the animations of 3 small balls, you could make a juggle animation with balls and hands synchronized. You can make "play catch" animations for two people and a ball. Be a multi-legged creature: add bones, attach prims, animate, enjoy.
+ + diff --git a/docs/LSL-functions-implemented.html b/docs/LSL-functions-implemented.html index 622d4e3..84a881e 100644 --- a/docs/LSL-functions-implemented.html +++ b/docs/LSL-functions-implemented.html @@ -23,7 +23,7 @@LSL function | SL notes | OpenSim notes | Codes |
---|
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
LSL function | SL notes | OpenSim notes | Codes |
---|
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes | D | |
---|---|---|---|---|---|
llGetLinkNumberOfSides | +llGetLinkNumberOfSides | D | @@ -1684,7 +1684,7 @@|||
llGetMinScaleFactor | +llGetMinScaleFactor | @@ -1920,7 +1920,7 @@ |
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes |
---|
-
LSL function | SL notes | OpenSim notes | Codes | |
---|---|---|---|---|
llUnescapeURL | +llUnescapeURLs |
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.