http://interreality.org/ developes VirtualObjectSystem
might suite FirstAndLast well? e.g. http://interreality.org/docs/api-html/classAvatar.html for FirstAndLast:AvataR ?
discussing FirstAndLast:FrontPage :
20:22 < reed> i like the idea
20:22 < reed> and it's exactly the kind of thing we would like to make possible :)
20:23 < reed> ideally you could just use terangreal, and put all the logic in servers
20:24 < reed> that's the goal at least
..
20:33 < antont> do you think someone would be interested in putting a Python API in place, or at least
helping me trying to make one? (no experience of such)
20:34 < reed> yeah
20:34 < reed> tetron would
20:34 < reed> or i could
20:34 < antont> ok
20:34 < reed> it's been a low priority, waiting until someone wanted it :)
20:34 < antont> right :)
20:34 < reed> i'm putting our todo lists online so you can see what our ideas for the future are
20:34 < antont> ok great
more talk about FirstAndLast:FrontPage
17:25 < neil> antont: what have you been doing with VOS, have you got stuff working yet?
17:25 < antont> compiled it, set up a server, tested that with terangreal and the shell client
17:25 < antont> then have been busy for a couple of weeks doing other stuff
17:26 < reed> any problems so far?
17:26 < antont> hm, not really
17:27 < antont> should continue experimenting with cob making (or tell the others do some :)
17:27 < antont> and set up a server somewhere accessible perhaps
17:28 < antont> the functionality, like simple cross-over algos with the mating of avatars, we need for
studio.kyperjokki.fi/FirstAndLast, i thought of trying first in either Blender (with
which i did a previous project) or Soya (which seems nice and elegant)
17:30 < antont> of course could try that with somehow with VOS too, and there having the Python API
would help, so could try to do that with SWIG too (or if someone else does :)
17:31 < reed> if you want to get swig to generate python that would be great
17:32 < reed> if not, we'll get to it sometime... we'll make it more of a priority if we know that you
are waiting for it :)
17:32 < reed> what is Soya?
17:33 < antont> a 3d engine written mostly in Python, http://oomadness.tuxfamily.org/en/soya/ seems to
be protesting agains software patents thought
17:33 < reed> also if you think some example code that is close to what you want to do is useful, i can
write some
17:33 < reed> i actually had a new idea... was in a linguistics lecture and had an idea for selecting
subsets of phonemes from a a list and seeing the sets visually indicated
17:33 < antont> hm
17:34 < reed> or maybe just something with colors
17:34 < antont> what sets?
17:34 < antont> the onces you selected?-o
17:35 < antont> where, in some corpus? i didn't quite get your idea yet
17:35 < antont> but started to think about what code we need and where
17:36 < reed> es
17:36 < reed> like a typewriter keyboard
17:36 < reed> and you select "voiced consonants" and the voiced consonants are raised up a bit
17:36 < antont> to start with, terangreal might be fine, and also the server - so just need two model
and write the logics of the worlds .. and they can run on the server, hm
17:36 < reed> you select things from a checklist in another window
17:37 < antont> ah
17:37 < reed> i just added a useful little feature to the vosworld program where it will automatically
spaws "auxilliary" programs if you give them on the command line
17:37 < reed> it can also do "plugins" if you want your code to run inside the vosworld process (but
won't work with python i guess){
17:38 < antont> i guess i don't nead that, auxilary is probably fine
17:38 < reed> its safer too
17:38 < antont> but how's the interface, then? (starts digging up the doc)
17:39 < reed> what do you mean?
17:39 < antont> what and how would that program get from vosworld and vice versa
17:40 < reed> vosworld sets an environment variable "VOS_STARTING_OBJECT" which is sort of a standard in
several vos programs actually
17:40 < reed> that has the URL of the world root sector
17:40 < antont> right, saw that when starting the server
17:43 < neil> hey
17:44 < neil> antont: the thing with vos is that all programs can access the same objects via the way
you use it
17:45 < neil> as long as they can connect to program which owns the object using the VOP layer, it
doesn't matter where they are
17:45 < neil> that's the general idea
17:45 < antont> right, and it's nice .. might come in use for us at some point
17:46 < antont> but i still somehow don't see the basic architecture (am also quite tired but shouldn't
be that bad :)
17:46 < antont> i mean
17:46 < antont> ok, there's the world root sector
17:46 < neil> well it's good cause if you want to create a system you can make it from multiple programs
17:47 < reed> you've read the unpublished paper, right? have you read the manual too?
17:47 < antont> right
17:47 < antont> yes
17:47 < reed> let us know what's unclear in there
17:47 < neil> all with different responsibilties, and each program can be moved to another server and it
will do the same thing
17:47 < reed> so we can fix it :)
17:47 < antont> probably nothing, the unclarity is in how i should apply it :)
17:47 < reed> ah :)
17:48 < reed> i can tell you how my mobile robot interface works if that will help
17:48 < antont> so for example, would there be a world object (like we have started to draft in
http://studio.kyperjokki.fi/FirstAndLast/WorlD)
17:48 < antont> and then bunch of other objects that are there
17:49 < reed> in a3dl there are object called "sectors" which contain other objects
17:49 < antont> and then different programs in different places could control those
17:49 < antont> right
17:49 < reed> we also call sectors "worlds" sometimes
17:49 < reed> which is confusing
17:49 < reed> so with terangreal you "connect to a sector"
17:49 < antont> yep ok that's clear
17:49 < reed> and you are then "in" that sector with the other objects
17:50 < reed> you've encountered the listeners right?
17:50 < antont> y
17:50 < reed> so for example you could have a program listening to the sector for new child objects
17:50 < reed> when a child is added, you can check if it's an avatar
17:50 < reed> and then you can listen to that avatar's properties
17:50 < reed> e.g. position
17:51 < antont> hm
17:51 < reed> and you can do something like, change the sky color to green if any avatar goes near some
spot
17:51 < antont> and what can add abjects, change the position of an avatar etc. is basically open to be
designed and can be controlled with the access controls?
17:52 < reed> well, the sector object's access control determines if something can be added
17:52 < antont> right
17:52 < reed> my avatar object's AC decides if the position can change
17:52 < reed> AC is a chain of callbacks basically: if all of those callbacks say OK, then the action
can happen
17:52 < antont> ok
17:53 < neil> antont: objects work simply by child-parent links. so you can have an access control on
the operation of modifying those in any way possible. the local site will implement those
access control checks
17:53 < reed> the position AC would be "PropertyAccessControl" and the secter child AC would be
"VobjectAccessControl"
17:54 < antont> and the avatar, and hence the AC for it, can reside either in the server or client..
17:55 < reed> well in the normal scheme of things it's in terangreal, the "client"
17:55 < antont> yep
17:55 < reed> but it can also be in the server
17:55 < antont> we might need both
17:55 < reed> there is a littel protocol for negotiating this when terangreal connects
17:55 < reed> (it's a "policy")
17:56 < reed> to deal with firewalls and things the avatar has to be on the server
17:56 < reed> pete is improving this stuff right now, it will be in 0.13
17:56 < neil> reed: have u implented client-mode?
17:57 < antont> e.g. the installation server (if you've checked the plan) could be a client that hosts
all the avatars that are there (controlled by participants with remote controls
17:57 < reed> neil: pete has it partially done
17:57 < reed> yes
17:57 < reed> as it stands, almost all access control is "no" ac
17:57 < reed> so you can change other people's properties freely
17:57 < antont> but then for remote participants using desktop clients there would be at least on option
for having them on server
17:57 < reed> but the plan is tot make that more configurable, involving site credentials, etc.
17:58 < reed> and right now you can of course write you own AC classes: the infrastructure is there and
it works
17:58 < reed> antont: yes
18:02 * reed reads more about first & last
18:02 < reed> what is a "place"?
18:03 < reed> it looks like for "beings" you want to use the Avatar type, maybe attach your own type to
it as well
18:03 < antont> (we are discussing related things here live)
18:03 < reed> for "Prop" static object3ds
18:03 < antont> yep, though in some cases they need to be somehow dynamic too
18:04 < reed> ok
18:04 < reed> yeah
18:04 < reed> and Object3D objects can be basic shapes, general polygons, or can just include embeded
18:04 < antont> place is just a .. place in a world, a viewport in some cases
18:04 < reed> hmm
18:04 < reed> ok
18:05 < reed> maybe analogous to Viewpoint, not sure
18:05 < antont> it came from some model for agent design (them being in places), i hear from the friend
here
18:06 < reed> so it's more than just one position configuration?
18:06 < reed> it involves context and such
18:06 < reed> ?
18:06 < antont> the ontology is being worked on now but it's really quite basic and normal
18:06 < reed> yeah
18:07 < antont> yes, places are about context
18:07 < antont> but it won't be even needed in first experiments
18:08 < reed> "context" can get really complicated... since no one is really sure what it means :)
18:08 < antont> yep
18:08 < antont> luckily we don't need to implement anything complicated to begin with :)
18:08 < reed> so you can attach arbitrary properties to things
18:08 < reed> so you can just stick the DNA info into a property and attach it to an avatar
18:09 < antont> such abstractions can yet live in future dev. ideas
18:09 < reed> right now that will work since the AC in terangreal is completely permissive
18:09 < reed> how you trigger a crossover is one question though
18:09 < reed> and how you change appearances
18:09 < antont> yes
18:09 < reed> what are the current ideas?
18:10 < antont> with the python app i have (http://studio.kyperjokki.fi/engine/KyperMover/) that uses
blender i might test crossover simple with non-visual characteristics, like speed
18:11 < antont> for changing appearances, some cases need creating the meshes in the program
18:11 < reed> could start with color or something, pretty easy
18:11 < antont> yep
18:11 < reed> maybe there is some free software somewhere that can "morph" 3d geometry
18:11 < antont> hm, perhaps
18:11 < reed> dunno
18:12 < reed> coulde be really strange results, would be fun :)
18:12 < antont> but another way is to build them frominterchangeble parts
18:12 < antont> yes, unexpected morphing /mutationswould be great :)
18:14 < reed> or maybe beings carry around more abstract "source" data that is easy to combine that
generates the visual geometry by some algorithm? I guess that makes sense, by analogy with
genetics :)
18:16 < antont> yep
18:16 < antont> i've thought about that in PlantWorld where that would be easily done with l-systems
18:16 < antont> but of course many other things are possibly too
18:17 < antont> just that some game engines, like unreal tournament 2003, are not capable of that
really, i've understood
18:17 < antont> but here there seems to be no problem
18:17 < reed> what do you mean?
18:17 < reed> since they just load unreal-format model files and that's it?
18:18 < antont> creating objects algorhitmically in the fly
18:18 < reed> oh yeeah
18:18 < antont> hm, yes, and i don't think you can even load new models on the fly
18:18 < antont> (if you had some other program making those for the engine to load)
18:18 < reed> well i don't know if terangreal will update geometry if e.g. vertices change, but if it
doesn't then ite's a bug
18:18 < reed> so we'll fix it :)
18:19 < antont> which could be perhaps also worked around by deleting the object and creating a new one
in the same place? which is not really a nice way to morph though, but would suffice for
the offspring
18:19 < antont> but nice to hear there's no need for such tricks :)
18:20 < reed> yeah that should work too in theory
18:20 < reed> probably works in practice too
18:20 < reed> i know that texture updating doesn't work yet, but that's also a bug that needs tobe fixed
:)
18:20 < antont> that's the only way in the blender game-engine currently..