1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
|
#ifndef _LOVE_H_
#define _LOVE_H_
/*
What do we need as an internal world object format?
Can't call it Things, that's taken already.
"Stuffs" works though. B-)
Love server needs to manage in world stuffs, and send changes to everyone.
Extantz needs to manage what's shown in world, and edit that stuffs.
Combining the data structures seems sane. Letting the love server
define those data structures also seems sane, hence this file.
Extantz needs -
what it looks like (Evas_3D stuff)
"link sets"
what is attached to what
mesh
vertices, triangles, ...
local position and orientation relative to parent
material
textures
colours, including alpha
light
shade mode
where it is
position, orientation
animation stuff
common
UUID
name & description
owner
position, orientation
"link sets"
love needs
UUID
name & description
owner
position, orientation
"link sets"
LL used a list of prims, we can do better I'm sure.
Though for the sake of this experimental version, just use an array of stuffs.
contents
scripts, cards, other stuffs, animations, sounds, textures, ...
content types
*/
/* Stuffs is a single "primitive" object, it can be -
single mesh object - NOTE: Should include a list of materials.
LL style prim, including tree, defined as a small bunch of data defining the type and parameters
LL style mesh "file"
single mesh file, collada, other mesh format
height field, for land, or water
LuaSL script
"notecard", just a text file, with no limits
animation, BVH, Alice's BVJ, or perhaps any other animation file format
sounds, MP3, other sound formats
textures, PNG, JPEG, JPEG2000, TIFF, GIF, other texture formats
other LL stuff
landmark
clothing
body part, shape, skin, hair, or eyes
gesture
calling card
*/
#include "evas_macros.h"
#include "evas_3d_utils.h" // TODO - Hopefully I can convince the authors to make this public.
#include "Runnr.h"
typedef struct _vec4
{
float x;
float y;
float z;
float w;
} vec4;
typedef struct _vec3
{
float x;
float y;
float z;
} vec3;
typedef struct _vec2
{
float x;
float y;
} vec2;
typedef struct _material
{
int face;
//type?
char texture[PATH_MAX];
//colour
//alpha
//other stuff
} Material;
typedef struct _mesh
{
char fileName[PATH_MAX];
//type
vec3 pos;
vec4 rot;
Eina_Inarray materials; // Material
Eina_Inarray parts; // Mesh
} Mesh;
typedef struct _stuffs
{
char UUID[32], *name, *description, owner[32];
//type
union
{
Mesh *mesh;
script *scrip; // Not a typo, C++ is fussy about reusing names like this.
void *other;
} details;
} Stuffs;
typedef struct _loveStuffs
{
Stuffs stuffs;
Eina_Inarray contents; // Stuffs
} LoveStuffs;
/* Data flow
love server starts up
scans sim disk structure looking for scripts in stuffs
keep track of which script is in which stuffs
hashed by stuffs uuid, store pointer to script structure
-> LuaSL compile script
-> LuaSL load this saved state
-> LuaSL run script
Extantz client starts up
-> love login(name, password)
loads user details
<- love this is your user uuid
get sim details from lspace at this URL (or local disk directory file://)
-> lspace gimme the sim (or just pick up the index.omg file from disk)
<- lspace index.omg
figure out which mesh stuffs to load
-> lspace gimme(uuid) (or load it from disk)
<- lspace uuid.omg
figure out which mesh and texture files to load
-> lspace gimme this mesh file (or load it from disk)
<- lspace mesh file
-> lspace gimme this texture file (or load it from disk)
<- lspace texture file
user clicks on in world stuffs
-> love touched(user uuid, stuffs.uuid)
looks up stuffs, loops through scripts
-> LuaSL script.uuid.touch_start() and the detected stuff
user edits stuffs in world
-> love get contents(stuffs.uuid)
loads stuffs.omg from disk
loads stuffs.index.omg
<- love here's the list of contents Stuffs
-> love change this bit
changes that bit and stores on disk
send update nails commands to everyone/thing watching
*/
/* More thoughts about directory structure
A major goal is to have the disk structure of a sim (and inventory) be
decently human readable. The assets should be stored as normal files of
the appropriate type, so that they can be edited with normal editing
software like blender, gimp, a text editor, etc.
A major LL created problem is that in world objects can have the same
name, though stuff in an objects inventory is forced to have unique
names by automatically adding numbers to the names. In inventory you
can have stuff with the same name to. The same named objects don't have
to be the same object, they can be completely different. A simple
object name to file name matching, with directories for contents, just
wont work. Perhaps the automatic adding of numbers thing would be best?
All names have to be coerced into operating system friendly names
anyway, so there still needs to be some sort of mapping between objects
and their names. Not to mention URL escaping for names to. Try to
combine both.
Should have a tool to validate a sims files.
Sooo, directory structure of a sim -
"sim name" -> sim%20name
index.omg
lists objects in the sim, with details about UUID, position, orientation, and size
maps in world name <-> file name / URL name
actually use file:// style URLs, so that we can pass them to clients,
and have the posibility of pointing to assets on some other lspace server
the name is a duplicate of what's inside the objects .omg file
Should try to keep these in sync automaticallly
sim index.omg files are managed by the love server,
so fiddling with them outside is an expert thing to do
"object name" -> object%20name.omg and a directory called object%20name
this file name could also be munged if there are objects with duplicate names
an external lspace server would return the .omg file when the objects URL is requested
.omg file contains file names / URLs of other assets like actual mesh files and textures
also UUID, in world name, description, owner UUID.
owner UUID might be better dealt with elsewhere?
coz links
directory contains the contents of the object
index.omg
lists the stuffs in the objects contents, with UUID and type for each
maps in world name <-> file name / URL name
the asset files, plus things like compiled script binaries and temporaries
might be better to move compiled scripts and generated Lua source to the LuaSL server's own private store?
LuaSL needs to assign UUIDs to compiled script binaries, so it knows which running script is which
coz there might be lots of copies of scripts
on the other hand, each copy is uniquely named inside some objects contents,
even if it's a link,
so the UUID of the stuffs plus the UUID within the stuffs contents, for this copy / link of the script should suffice?
except links
Yes, this means that files and directories can be links in the case of duplicate assets.
Though the UUIDs inside .omg files would have to be unique?
Only for script binaries I think.
Would have to do copy on write for editing and other state changes, not including script state changes.
So links to object .omg files would all have the same UUID.
Which works well with using sha-1 content addressable assets. B-)
People could even be free to use their own organising directory
structure. A directory for ground level, and one for each sky box for
instance. Relative paths inside .omg files sorts that all out.
Actually, file names / URLs in .omg files would mostly be relative to
the file name / URL of the sim, and all the way down, so relative to the
directory things are in. It's up to the client to keep track of where
they are and build appropriate full URL / full path file names.
A sims index.omg file might be constantly updated for busy sims.
Could generate it on the fly by the lspace server, based on the actual contents of the sim directory.
Alternative lspace servers could just use a CMS system for all of this anyway.
They would still use the same structure for URLs and .omg files.
Storing avatars in this way isn't such a good idea?
Avatars could have their own index.omg dealing with shape, skin, clothes, attachments, etc.
But instead of client asking for a list, avatar arrivals and departures are driven by love.
Though try to keep avatars as "just ordinary object, but with a person controlling it".
Still, they move around a lot.
Right now I'm using Lua style .omg files, but eet would be a better
choice I think. Saves having to write a Lua table to C structure
system, which eet already has, sorta. Lua tables are at least more
readable while I consider the design, but likely use eet instead when I
have to write code to read the suckers.
Might be useful to have a UUID -> asset file .cache directory, or
something similar? Could save love server needing to keep that all in
memory all the time. Plus, an issue with using sha-1 UUIDs and keeping
them inside the .omg files is that this changes the sha-1 hash. Should
think about keeping uuid's outside of them. Perhaps a .sha1 file along
side each .omg file and asset file? Don't bother with links, if an
asset is a link, just look for the .sha1 file where the real file is.
The UUIDs are mostly for keeping in memory as keys to stuff, coz they
can shrink down to a long. On the other hand, duplicated objects still
need their own UUIDs to refer to each copy / link. Sha-1 the relative
path to the link? It all gets trickier when assets are on different
lspace servers, not to mention some OSes don't support links very well,
or at all.
objectName.omg + objectName.sha1 In each of these cases, the .sha1 file is the sha1 sum of the file it goes with, not of the file it points to.
objectName.lnk + objectName.sha1 .lnk is a relative file name to objectName.omg
objectName.url + objectName.sha1 .url is a URL to a the .omg on a different server
Probably need to store other info in the .url file, sha1 of the original file, other web cache info.
Which starts to encroach on web proxy / cache territory, which we may not want to do,
since we want to use real ones instead of crappy LL cache.
.cache
sha1 as file names of .lnk or .url files.
If the file system date stamps are different, then someone edited the file, recreate the sha1 files.
Which implies that lengthy sha1 calculations need to touch the file once done.
*/
#endif
|