In my emerging cosmology, energy is the fourth dimension, not time.
Arkowitz
Thursday, December 25, 2008
time in virtual worlds
Godel's extension of Einstein's work shows us that time does not really exist. It is imaginary. There is no time - only space and energy.
Just as the past is not an additional "dimension" into which we could ever travel, because the past exists only in our heads and the heads of many other organisms as well; the future is imaginary too. There is only the distribution of energy through space right now.
This only is the only of science, logic, and some aspects of the "creative" art of philosophy. Time surely exists because we bring it into being; we the participants in shared sensory experiences; communication.
This is the role of virtual worlds as well.
I hereby redefine a virtual world as a shared space-energy, no longer a shared spacetime. The time part will emerge as a direct result of the messages sent to the bubble server; I used to think croquet's teatime did this but then I read something that made me think it doesn't; rather, it enforces an arbitrary definition of time; a synchronized clock. We will not synchronize a clock; we will make time a function of messages arriving. Messages are packets of energy in space, and they appear to move, to us.
Arkowitz/Ben
ps - Beth Coleman's analogy of a chess game applies quite well to virtual worlds and will be the subject of my next post hopefully
Just as the past is not an additional "dimension" into which we could ever travel, because the past exists only in our heads and the heads of many other organisms as well; the future is imaginary too. There is only the distribution of energy through space right now.
This only is the only of science, logic, and some aspects of the "creative" art of philosophy. Time surely exists because we bring it into being; we the participants in shared sensory experiences; communication.
This is the role of virtual worlds as well.
I hereby redefine a virtual world as a shared space-energy, no longer a shared spacetime. The time part will emerge as a direct result of the messages sent to the bubble server; I used to think croquet's teatime did this but then I read something that made me think it doesn't; rather, it enforces an arbitrary definition of time; a synchronized clock. We will not synchronize a clock; we will make time a function of messages arriving. Messages are packets of energy in space, and they appear to move, to us.
Arkowitz/Ben
ps - Beth Coleman's analogy of a chess game applies quite well to virtual worlds and will be the subject of my next post hopefully
Monday, December 22, 2008
new focus on biotech
Green Phosphor has joined a small business incubator, run by FAMU and the SBA. This has allowed us to move into fantastic office space in Innovation Park. When I look out my window I see two buildings: the National High Magnetic Field Laboratory and the Northwest Regional Data Center.
I'm very close to finalizing Green Phosphor's business plan. We're focusing on the biotech industry, and will be using our patent-pending 3D user interface technology to create an appliance for model based drug development. I can't wait to see genes, codons, hormones, proteins, and their interactions - all in 3D within the virtual world. Here's a video we just made, introducing the technology.
Ed has been working very hard on the first public beta of our Glasshouse gateway. It's a Java application which can be launched from our website and used to connect to your own databases, allowing you and other users to see the data you publish in 3D in our public Sun Wonderland sandbox, Second Life, or your own Wonderland instance! We'll have it live within a couple weeks!
I'm very excited about the new year!
currently reading: Mona Lisa Overdrive by William Gibson
Cheers,
Ben
I'm very close to finalizing Green Phosphor's business plan. We're focusing on the biotech industry, and will be using our patent-pending 3D user interface technology to create an appliance for model based drug development. I can't wait to see genes, codons, hormones, proteins, and their interactions - all in 3D within the virtual world. Here's a video we just made, introducing the technology.
Ed has been working very hard on the first public beta of our Glasshouse gateway. It's a Java application which can be launched from our website and used to connect to your own databases, allowing you and other users to see the data you publish in 3D in our public Sun Wonderland sandbox, Second Life, or your own Wonderland instance! We'll have it live within a couple weeks!
I'm very excited about the new year!
currently reading: Mona Lisa Overdrive by William Gibson
Cheers,
Ben
Sunday, November 23, 2008
Monday, November 17, 2008
unification
As things move forward through time, they lose energy. This entropy is an increase in complexity. Thought processes suffer from an increase in complexity as well; take as a simple example the counting of the whole numbers starting from 1. Every prime encountered along the way is a major increase in complexity.
Life is the process of architecting a solution to the multidimensional prediction problem of how to continue life.
Life uses information flow to optimize its fight against entropy.
Information flow may be accomplished using resonance of spinning fields with one another. Resonance may be the way to solve the uncertainty problem; a system may be measured but not interfered with if we have another system achieve resonance with it and then measure the second system.
Imagine a unification of Einstein, Godel, Heisenberg, and ... Tesla.
Arkowitz
Life is the process of architecting a solution to the multidimensional prediction problem of how to continue life.
Life uses information flow to optimize its fight against entropy.
Information flow may be accomplished using resonance of spinning fields with one another. Resonance may be the way to solve the uncertainty problem; a system may be measured but not interfered with if we have another system achieve resonance with it and then measure the second system.
Imagine a unification of Einstein, Godel, Heisenberg, and ... Tesla.
Arkowitz
Friday, November 14, 2008
Heisenberg and Language
I've been reading Werner Heisenberg's book Physics and Philosophy: the Revolution in Modern Science. He talks about how language is necessary for science. Until now science has used two languages: natural language and mathematics.
Now we have a new tool: programming languages. A programming language combines the precision of mathematics with the expressiveness of natural language and can be used to create a perceivable manifestation of a model; this allows the communication of concepts and models without need for language at all. This is a virtual world.
One may say that whatever we do with computers will suffer from "finiteness" and predictability not reflective of the real world, and that a computer program may be defined mathematically. I respond that the network introduces chance into the picture. Is it possible to always predict accurately what a ping time will be? I don't think so.
I think we have the ingredients for something significant.
---
I've been thinking about a definition of Architecture which applies to computer science and IT as well as to physical projects such as buildings and bridges. Here's what I've come up with:
Architecture is the creation of a set of rules which, when followed by a group of actors, results in the construction of something persistent.
---
Ever notice that the only metaphors we have for the workings of our minds are the machines we have constructed? Switches and gears...
Arkowitz
Now we have a new tool: programming languages. A programming language combines the precision of mathematics with the expressiveness of natural language and can be used to create a perceivable manifestation of a model; this allows the communication of concepts and models without need for language at all. This is a virtual world.
One may say that whatever we do with computers will suffer from "finiteness" and predictability not reflective of the real world, and that a computer program may be defined mathematically. I respond that the network introduces chance into the picture. Is it possible to always predict accurately what a ping time will be? I don't think so.
I think we have the ingredients for something significant.
---
I've been thinking about a definition of Architecture which applies to computer science and IT as well as to physical projects such as buildings and bridges. Here's what I've come up with:
Architecture is the creation of a set of rules which, when followed by a group of actors, results in the construction of something persistent.
---
Ever notice that the only metaphors we have for the workings of our minds are the machines we have constructed? Switches and gears...
Arkowitz
Friday, October 31, 2008
Massive Update
I've been working with Tommi Laukkanen on a universal protocol for virtual worlds. It will be the second version of CICP, as well as the next version of Tommi's protocol, SETP... so for now we are calling it SETP/CICPv2. My main contribution so far has been much of the language in the Domain Model. Jon Watte of Forterra has been contributing as well. I'm very excited about the effort. Visit the SETP wiki to see what we are up to... go to the domain model page. I'm going to paste the whole page at the bottom of this blog post, too.
Green Phosphor has a new website designed for us by Derek Au, one of the brightest programmers I know... who has abandoned programming for pottery, specifically brilliant porcelain constructions he has been making in China. I feel very fortunate to have him on board.
Just over a week ago Green Phosphor completed the filing of two patent applications. One covers our gateway between a virtual world and an analytical database; this is the IP that we are building our for-profit business around. The other app covers CICP, and we will always give that one away for free. Trolls beware, this patent app will hopefully end up protecting some very valuable open source technology: a flexible, efficient, cross-platform protocol for sharing interactive content within bubbles of simulated spacetime.
---
Domain Model
This page is a place to define the key entities of distributed virtual environments and SETP/CICPv2 protocol.
Theoretical Entities
-----------------------
Shared Spacetime
The overall goal of our protocol is to enable multiple participants to experience a shared, simulated, spacetime. Mathematically a spacetime is a four-dimensional continuum. We constrain this continuum such that the time dimension only moves forward and is constantly incremented by some sort of clock synchronization among the participants. We also may constrain this continuum such that there are a finite number of positions between two given points rather than an infinite number. This means it is not necessarily a continuum in the formal sense of the word.
Multiple shared spacetime bubbles may exist, and need not exist within the same coordinate system. A spacetime bubble may exist within a region of another spacetime bubble. A spacetime bubble may also border another spacetime bubble. Spacetime bubbles may also overlap.
Participant
Participants are entities which are able to perceive aspects of the simulation and/or have an effect on aspects of the simulation. Participant types are: humans, daemon processes, artificial intelligence scripts and applications.
Injection
Process where participant adds an object it owns to a spacetime bubble.
Ejection
Process where participant removes an object it owns from a space time bubble.
Object
An object is an atomic unit of content. An object's effect on a spacetime may be comprised of multiple types and occurrences of content, but is treated such that either the entire object exists within a given spacetime, or none of it exists. If a spacetime is assumed to have a boundary, and some object overlaps that boundary, the object can still be expressed in terms of the coordinate system of that spacetime and as such is considered to exist fully within that spacetime.
Injection commands are executed against individual objects. Update and ejection commands may be executed against individual objects or groups of objects.
Every object affecting a given spacetime belongs to a participant in that spacetime. If a program issues an injection command, placing an object into a spacetime, that program is a participant in that spacetime. If the program is a human interface, the human using the human interface is considered a participant.
Interaction
Interaction is an event where one object changes the state of another object. Without interactions it could be thought that all objects have their private spacetime. Participants use their avatar as a proxy when interacting with objects they do not own.
Avatar
An avatar is an object which is used to represent the identity of its owning participant.
State
Object external state can be observed and internal state is not immediately visible. State could
be categorized the same way as interactions. External states which are expressed with the protocol and internal states which are simulated but with entirely different model.
Content
Content is anything which can be perceived in the spacetime. Content only exists as a part of an object. Map can consists of one or more objects. All participation in a shared spacetime involves content. This includes images or textures, three-dimensional shapes, audio, fog, and light; it also includes changes occurring to any of these. Content may be injected into a spacetime, updated within a spacetime, ejected from a spacetime, or perceived within a spacetime. Injection, update, or ejection of content is performed via the protocol, by use of a command; perception of content is indicated via the protocol by receipt of an event. Injection, update, and ejection of content all result in perception events.
Awareness
Objects have awareness bounds. However they are defined geometrically, the awareness bounds indicate a region of space within a spacetime. If this region of space is affected by other objects, via injection, update, or ejection commands, events representing those effects will be sent to the participant responsible for the object. Objects may be defined with an empty awareness bounds, indicating that no events should be received.
Upon issuing an injection command for an object, a participant will receive events which correspond to all objects which were already affecting the spacetime within the awareness bounds of the new object.
Observation
An event where object observes another object inside its awareness bounds.
Migration (Teleporting / SimCrossing )
Process where objects teleport from one bubble to another. Teleporting can be seamless if bubbles overlap.
Visibility
Visibility is an attribute which reflects whether object or state can be observed through the spacetime. If transparent bottle is empty the state is visible as it can be observed with the mechanisms of the spacetime. If the state has to be inquired in an interaction it is not visible.
Appearance
When object is added to the world it appears. Objects and participants need to be aware of these events.
Disappearance
When object is removed from the world it disappears. Objects and participants need to be aware of these events.
Architecture Entities
--------------------------
Bubble (Simulation / Sim)
A volume of space simulated over time.
Cloud of Bubbles (Cluster / Grid)
A group of linked bubbles simulating distributed spacetime located in the same or separate bubble servers.
Bubble Server (World Server / Simulation Server)
A bubble server is a program which handles command and event processing for a spacetime. The bubble server is responsible for determining which events go to which participants, based on the awareness bounds and update coordinates of the objects the participants place into the spacetime. The bubble server may be essentially a messaging hub that is spatially aware only in terms of rough bounds and is not expected to perform physics simulation or collision detection. Bubble server will also contain object daemon (artificial active participant) injecting long lived persistent objects. Other daemon could be a physics daemon.
Human Interface / User Interface (Viewer/Browser/Client)
A human interface is a piece of software which uses the protocol and a user interface to enable a human to participate in a shared spacetime.
Subscription
Participants may inject objects which have a subscription capability. This means that other participants may receive updates involving that object directly from the owning participant. This can be useful to avoid network bottlenecking of a server; it is also useful when object updates take the form of a stream such as video or audio. The world server need not understand or process a particular video stream if the participant generating it streams it directly to all the other participants.
It has been suggested by Jon that subscription mechanisms and peer to peer streams could be defined in a separate protocol. - Tommi
I agree with this as well. All the SETP/CICPv2 protocol needs to do is allow an object to publicize the fact that it has a subscription capability and where to get it. --ark
Collision Detection
There should be a capability for a server module or special participant to handle collision detection for objects and trigger events based on that; it should also be possible for participants to handle their own collision detection.
It has been suggested by Jon that owning participant should always handle collision detection of an object. Another view point is that the bubble provides fundamental laws like collision detection. If several bubbles (sims from different providers) overlap then the bubble which is the primary bubble for an object (first point of injection) executes collision detection for that object. - Tommi
Reply: Collision detection is part of simulation of an object. Whether an object is squishy or hard, collides as a convex hull, sphere, mesh, or something else is part of the definition of the object. What the object does when colliding is part of the simulation (for example, does it bounce, or stick, or explode, or turn on a light, or ...). If you want to support simulating an object on a host other than the host that initially injected the object, then you'd have to also support injection and transfer of behavior, which is a Hard Problem and hasn't actually ever been solved well. Thus, an object is owned by its injector, its simulation is handled by its injector, and the lifetime of the object is constrained by the lifetime of the injector(!) If two injectors want to negotiate transfer of ownership separately from the protocol, and remove/re-inject the object (or perhaps more elegantly, allow transfer of ownership), then that's fine, but not necessarily part of this particular protocol.
I figure that since the bubble server has to be able to figure out the overlapping of awareness bounds and physical bounds of objects in order to do its job, why not enable it to also serve the participants with a basic collision (overlap of physical bounds and physical bounds) detection service. Objects have to somehow define their rough physical bounds to the bubble server anyway for awareness detection... the key is to keep it rough and simple. I am willing to ditch the idea of participants delegating collision detection for their objects to other participants; too complicated. Must eject and re-inject instead. --ark
Interaction Options for an Object
Every object may have interaction options which the owning participant has defined for it. Another participant may choose to activate on of these interaction options, which results in an event being sent to the owning participant; the owning participant is then expected to do something and update the object to reflect what is has done.
A human interface should allow a human to indicate a desire to interact with an object, and then display to the human the list of interaction options for that object. The human should then be able to select one, thereby triggering that event to the object's owner.
Green Phosphor has a new website designed for us by Derek Au, one of the brightest programmers I know... who has abandoned programming for pottery, specifically brilliant porcelain constructions he has been making in China. I feel very fortunate to have him on board.
Just over a week ago Green Phosphor completed the filing of two patent applications. One covers our gateway between a virtual world and an analytical database; this is the IP that we are building our for-profit business around. The other app covers CICP, and we will always give that one away for free. Trolls beware, this patent app will hopefully end up protecting some very valuable open source technology: a flexible, efficient, cross-platform protocol for sharing interactive content within bubbles of simulated spacetime.
---
Domain Model
This page is a place to define the key entities of distributed virtual environments and SETP/CICPv2 protocol.
Theoretical Entities
-----------------------
Shared Spacetime
The overall goal of our protocol is to enable multiple participants to experience a shared, simulated, spacetime. Mathematically a spacetime is a four-dimensional continuum. We constrain this continuum such that the time dimension only moves forward and is constantly incremented by some sort of clock synchronization among the participants. We also may constrain this continuum such that there are a finite number of positions between two given points rather than an infinite number. This means it is not necessarily a continuum in the formal sense of the word.
Multiple shared spacetime bubbles may exist, and need not exist within the same coordinate system. A spacetime bubble may exist within a region of another spacetime bubble. A spacetime bubble may also border another spacetime bubble. Spacetime bubbles may also overlap.
Participant
Participants are entities which are able to perceive aspects of the simulation and/or have an effect on aspects of the simulation. Participant types are: humans, daemon processes, artificial intelligence scripts and applications.
Injection
Process where participant adds an object it owns to a spacetime bubble.
Ejection
Process where participant removes an object it owns from a space time bubble.
Object
An object is an atomic unit of content. An object's effect on a spacetime may be comprised of multiple types and occurrences of content, but is treated such that either the entire object exists within a given spacetime, or none of it exists. If a spacetime is assumed to have a boundary, and some object overlaps that boundary, the object can still be expressed in terms of the coordinate system of that spacetime and as such is considered to exist fully within that spacetime.
Injection commands are executed against individual objects. Update and ejection commands may be executed against individual objects or groups of objects.
Every object affecting a given spacetime belongs to a participant in that spacetime. If a program issues an injection command, placing an object into a spacetime, that program is a participant in that spacetime. If the program is a human interface, the human using the human interface is considered a participant.
Interaction
Interaction is an event where one object changes the state of another object. Without interactions it could be thought that all objects have their private spacetime. Participants use their avatar as a proxy when interacting with objects they do not own.
Avatar
An avatar is an object which is used to represent the identity of its owning participant.
State
Object external state can be observed and internal state is not immediately visible. State could
be categorized the same way as interactions. External states which are expressed with the protocol and internal states which are simulated but with entirely different model.
Content
Content is anything which can be perceived in the spacetime. Content only exists as a part of an object. Map can consists of one or more objects. All participation in a shared spacetime involves content. This includes images or textures, three-dimensional shapes, audio, fog, and light; it also includes changes occurring to any of these. Content may be injected into a spacetime, updated within a spacetime, ejected from a spacetime, or perceived within a spacetime. Injection, update, or ejection of content is performed via the protocol, by use of a command; perception of content is indicated via the protocol by receipt of an event. Injection, update, and ejection of content all result in perception events.
Awareness
Objects have awareness bounds. However they are defined geometrically, the awareness bounds indicate a region of space within a spacetime. If this region of space is affected by other objects, via injection, update, or ejection commands, events representing those effects will be sent to the participant responsible for the object. Objects may be defined with an empty awareness bounds, indicating that no events should be received.
Upon issuing an injection command for an object, a participant will receive events which correspond to all objects which were already affecting the spacetime within the awareness bounds of the new object.
Observation
An event where object observes another object inside its awareness bounds.
Migration (Teleporting / SimCrossing )
Process where objects teleport from one bubble to another. Teleporting can be seamless if bubbles overlap.
Visibility
Visibility is an attribute which reflects whether object or state can be observed through the spacetime. If transparent bottle is empty the state is visible as it can be observed with the mechanisms of the spacetime. If the state has to be inquired in an interaction it is not visible.
Appearance
When object is added to the world it appears. Objects and participants need to be aware of these events.
Disappearance
When object is removed from the world it disappears. Objects and participants need to be aware of these events.
Architecture Entities
--------------------------
Bubble (Simulation / Sim)
A volume of space simulated over time.
Cloud of Bubbles (Cluster / Grid)
A group of linked bubbles simulating distributed spacetime located in the same or separate bubble servers.
Bubble Server (World Server / Simulation Server)
A bubble server is a program which handles command and event processing for a spacetime. The bubble server is responsible for determining which events go to which participants, based on the awareness bounds and update coordinates of the objects the participants place into the spacetime. The bubble server may be essentially a messaging hub that is spatially aware only in terms of rough bounds and is not expected to perform physics simulation or collision detection. Bubble server will also contain object daemon (artificial active participant) injecting long lived persistent objects. Other daemon could be a physics daemon.
Human Interface / User Interface (Viewer/Browser/Client)
A human interface is a piece of software which uses the protocol and a user interface to enable a human to participate in a shared spacetime.
Subscription
Participants may inject objects which have a subscription capability. This means that other participants may receive updates involving that object directly from the owning participant. This can be useful to avoid network bottlenecking of a server; it is also useful when object updates take the form of a stream such as video or audio. The world server need not understand or process a particular video stream if the participant generating it streams it directly to all the other participants.
It has been suggested by Jon that subscription mechanisms and peer to peer streams could be defined in a separate protocol. - Tommi
I agree with this as well. All the SETP/CICPv2 protocol needs to do is allow an object to publicize the fact that it has a subscription capability and where to get it. --ark
Collision Detection
There should be a capability for a server module or special participant to handle collision detection for objects and trigger events based on that; it should also be possible for participants to handle their own collision detection.
It has been suggested by Jon that owning participant should always handle collision detection of an object. Another view point is that the bubble provides fundamental laws like collision detection. If several bubbles (sims from different providers) overlap then the bubble which is the primary bubble for an object (first point of injection) executes collision detection for that object. - Tommi
Reply: Collision detection is part of simulation of an object. Whether an object is squishy or hard, collides as a convex hull, sphere, mesh, or something else is part of the definition of the object. What the object does when colliding is part of the simulation (for example, does it bounce, or stick, or explode, or turn on a light, or ...). If you want to support simulating an object on a host other than the host that initially injected the object, then you'd have to also support injection and transfer of behavior, which is a Hard Problem and hasn't actually ever been solved well. Thus, an object is owned by its injector, its simulation is handled by its injector, and the lifetime of the object is constrained by the lifetime of the injector(!) If two injectors want to negotiate transfer of ownership separately from the protocol, and remove/re-inject the object (or perhaps more elegantly, allow transfer of ownership), then that's fine, but not necessarily part of this particular protocol.
I figure that since the bubble server has to be able to figure out the overlapping of awareness bounds and physical bounds of objects in order to do its job, why not enable it to also serve the participants with a basic collision (overlap of physical bounds and physical bounds) detection service. Objects have to somehow define their rough physical bounds to the bubble server anyway for awareness detection... the key is to keep it rough and simple. I am willing to ditch the idea of participants delegating collision detection for their objects to other participants; too complicated. Must eject and re-inject instead. --ark
Interaction Options for an Object
Every object may have interaction options which the owning participant has defined for it. Another participant may choose to activate on of these interaction options, which results in an event being sent to the owning participant; the owning participant is then expected to do something and update the object to reflect what is has done.
A human interface should allow a human to indicate a desire to interact with an object, and then display to the human the list of interaction options for that object. The human should then be able to select one, thereby triggering that event to the object's owner.
Subscribe to:
Posts (Atom)
