Re: [vos-d] Online Space
Peter Amstutz wrote: > I think this fits in very well with using portals in VOS. It might be worthwhile to have spatial nodes or space "tiles" that have implicit portals to their neighbors, so you don't need to set up the portals manually. They could be a new tile object, or maybe just sectors with special neighbor links. A simplistic renderer could even ignore the "tiles" or spatial nodes and just transform all the children and render them in the same space. They could also form another level of information that a server-determined client view or a client's search query could be based on. Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Online Space
When I speak of a single continuous world space I am referring only to
the subset of the application that is being used in the display
system: the part of the app that includes the grahics pipeline. This
is where we are forced to used single precision because of hardware
limits and performance and this is where it is good to avoid overheads
or artificial boundaries in an apparently confinuous space (like in
Morrowind, when walking along a path, it would halt and you'd get a
message like "loading external environment" and then you can
continue). At any one time it is only a subset of the aplication
space.
for more background you may want to look at these papers:
published in Cyberworlds 2006:
http://planet-earth.org/cw06/thorne-CW06.pdf
to be published in the Journal of Ubiquitous Computing and
Intelligence special issue on Cyberworlds:
http://planet-earth.org/ubcw/thorne-UBCW.pdf
published in proceedings of Cyberworlds05:
http://planet-earth.org/cw05/FloatingOrigin.pdf
That is not to say this model cannot work as a hybrid system with
portals at doorways, for space jumps etc. In fact, for very large
scale solar/galaxy systems you would have to either use very high
precision in the object system or maybe double precision with portals.
but to get optimal accuracy, scalability etc throughout where the
avatar travels then the graohics engine should be looking at a
continous floating origin.
The best description of a on-the-fly origin shifting system I have
seen is O'Neil's "A Real-Time Procedural Universe, Part Three:
Matters of Scale":
http://www.gamasutra.com/features/20020712/oneil_01.htm
Although it is not a true continuous floating origin it gives similar effect.
On 2/7/07, Peter Amstutz <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 02, 2007 at 12:15:47PM +0900, chris wrote:
> >
> > Yes - that's why we use a single continuous world space. Many systems
> > like VGIS divide the earth into fixed sized sectors. This sort of
> > segmentation creates many overheads.
> > The Dungeon Siege game segmented its world into SiegeNodes, each
> > with its own local coordinate space. When the viewpoint crossed a
> > boundary between nodes, the local coordinate system changed to that
> > of the node being entered and a ``Space Walk'' began.
> > The space walk visited each active node and recalculated coordinate
> > transforms to shift objects closer to the new local origin. This
> > ensured coordinates did not get large enough to cause noticeable spatial
> > jitter. It uses considerable processing resources to do space walk and
> > the frequency of performing recalculations has to be limited: ``as
> > infrequently as possible to
> > avoid bogging down the CPU'' {Bilas}:
> > http://www.drizzle.com/~scottb/gdc/continuous-world.htm
>
> Okay, I've had a chance to read over and digest the "continous world"
> document. As I understand it, the "world" is basically a set of "nodes"
> which are connected to form an adjacency graph. The edges describes how
> the nodes are oriented/transformed in space in relation to each
> surrounding node. The camera works in the coordinate space of whatever
> particular node it's on, and everything else is recentered relative to
> the current node.
>
> I think this fits in very well with using portals in VOS. A normal
> portal is a polygon in space which causes the renderer to recursively
> start rendering the sector behind the portal, clipped to the portal
> polygon. This works nicely for indoor areas because if the portal isn't
> visible, it doesn't have to consider the room behind the portal at all.
> It's also used by some engines to connect indoor and outdoor areas (for
> example, I believe indoor areas in World of Warcraft are portals to a
> separate map, so that a viewer who is outside the building doesn't have
> to consider the building interior in rendering.)
>
> The second kind of portal is a space-warping portal. This works the
> same as a normal portal, except that a space transform (rotation and
> translation) is applied to the target sector. This means that target
> sector no longer has to be in the same coordinate system as your current
> space. Your current space has one origin, the space on the other side
> of the portal has another origin, and they're defined relative to each
> other. Thus, crossing the portal boundary is in effect recentering the
> entire space.
>
> I've always been against a unified coordinate system for virtual worlds
> for philosophical and pragmatic reasons (you're never going to get
> people to agree on how to allocate "space" except via some central
> authority), so it's good to consider that this is probably the best
> technical solution as well.
agreed - as far as the object system, which is the main part of the
application - you need appropriate coordinate system(s) - like lat,
lon, height and reference system for geospatial. And for outer space
some segmentation is likely.
The translation from object system coordinate system to display sy
Re: [vos-d] Is this helpful?
I'm not sure I get what you are after. I have software to compress audio (eg, make an MP3), resample it (eg, make 32-bit into 16-bit and reset 44.1khz as 22khz, 11khz or yeaccchhh 8khz). What you may be looking for is something like Soundcast that streams it to the PCs. JOI uses that as I recall for their in-world radio programs. This uses the web browser sound so I am told and the directional sound properties are lost doing that. For example, when building an immersive album with VRML, I use the spatial audio (22khz mono) for ambient sounds (water, wind, doors open and close, etc.) and turn the spatial off for presentation audio (eg, songs, backgrounds for presentations). So not exactly sure what you are after. The Soundcast sounds *pretty good* compared to say chunking it into 11khz mono (never drop below 22khz or musicians will hunt you down and flay you with dull guitar picks). OTOH, nothing I've heard on the web is as good as wav files (don't start me going on about mp3: it is turning your ears into tin) at 44khz stereo. len -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jason Heblack Is this helpful? Does anybody have softwares which let you shrink your audio and then send the file as fast as possible so that after composition it could be played back quick in the model of *Citizens' Band radio* (/CB/) but instead using better sound? ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] Is this helpful?
Is this helpful? Does anybody have softwares which let you shrink your audio and then send the file as fast as possible so that after composition it could be played back quick in the model of *Citizens' Band radio* (/CB/) but instead using better sound? -- Documentonoguardado1.sig Filter name: poop For incoming messages that:Match any of the following Subject-unclean From-unclean Body-unclean Perform these actions: Move Messages to Local FoldersTo save disk space,do notdownload:Messages larger than 5 KB ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] Online Space
On Fri, Feb 02, 2007 at 12:15:47PM +0900, chris wrote:
>
> Yes - that's why we use a single continuous world space. Many systems
> like VGIS divide the earth into fixed sized sectors. This sort of
> segmentation creates many overheads.
> The Dungeon Siege game segmented its world into SiegeNodes, each
> with its own local coordinate space. When the viewpoint crossed a
> boundary between nodes, the local coordinate system changed to that
> of the node being entered and a ``Space Walk'' began.
> The space walk visited each active node and recalculated coordinate
> transforms to shift objects closer to the new local origin. This
> ensured coordinates did not get large enough to cause noticeable spatial
> jitter. It uses considerable processing resources to do space walk and
> the frequency of performing recalculations has to be limited: ``as
> infrequently as possible to
> avoid bogging down the CPU'' {Bilas}:
> http://www.drizzle.com/~scottb/gdc/continuous-world.htm
Okay, I've had a chance to read over and digest the "continous world"
document. As I understand it, the "world" is basically a set of "nodes"
which are connected to form an adjacency graph. The edges describes how
the nodes are oriented/transformed in space in relation to each
surrounding node. The camera works in the coordinate space of whatever
particular node it's on, and everything else is recentered relative to
the current node.
I think this fits in very well with using portals in VOS. A normal
portal is a polygon in space which causes the renderer to recursively
start rendering the sector behind the portal, clipped to the portal
polygon. This works nicely for indoor areas because if the portal isn't
visible, it doesn't have to consider the room behind the portal at all.
It's also used by some engines to connect indoor and outdoor areas (for
example, I believe indoor areas in World of Warcraft are portals to a
separate map, so that a viewer who is outside the building doesn't have
to consider the building interior in rendering.)
The second kind of portal is a space-warping portal. This works the
same as a normal portal, except that a space transform (rotation and
translation) is applied to the target sector. This means that target
sector no longer has to be in the same coordinate system as your current
space. Your current space has one origin, the space on the other side
of the portal has another origin, and they're defined relative to each
other. Thus, crossing the portal boundary is in effect recentering the
entire space.
I've always been against a unified coordinate system for virtual worlds
for philosophical and pragmatic reasons (you're never going to get
people to agree on how to allocate "space" except via some central
authority), so it's good to consider that this is probably the best
technical solution as well.
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] OpenID
WinterKnight and I were talking on IRC last night about this. He (as
well as Kao and others) all agree that a "portable identity" (single
sign-on) across many sites is the way to go, instead of having to sign
up for every stupid little web site and 3D world you might want to walk
in to.
One thing that came up was that it would make sense for the
authentication server to maybe also have some minimal presence
information -- since logging in indicates that you're online, it's the
logical place to publish that information to others. You could then
contact your friends and find out which world(s) they are logged on to
and go join them. It would just be a matchmaking/directory service, I
don't think it would even necessarily pass instant messages, but rather
provide the tools to find people, set up a direct chat conversation,
etc.
There's also the "Liberty Alliance" which is a business-oriented
identity management framework:
http://www.projectliberty.org/ (the page for the suits)
and
http://www.openliberty.org/ ("open source community" page)
They use SAML 2.0 (I think, anyone know about this?):
http://en.wikipedia.org/wiki/SAML
Finally, I think you can do authentication over LDAP as well, and
there's a bunch of proprietary technologies like Active Directory.
I'm beginning to have a better appreciation for how important security
and identity management is going to be for online 3D.
On Tue, Feb 06, 2007 at 10:37:42AM -0500, Reed Hedges wrote:
>
> Talking about authentication/identity in future 3D worlds etc.:
>
> Just found out about this: http://openid.net/
>
> Decentralized shared ID thing. Anyone know anythnig about it?
>
> Reed
>
>
>
> ___
> vos-d mailing list
> vos-d@interreality.org
> http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
--
[ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] OpenID
Never heard of it before. Sounds like the site is talking about a single type of functionality that needs the support of other layers to provide a full trust and identification service. Perhaps a better idea would be to use a Jabber style user server, where your profile is held? In which case all you have to do is decide which bits of your profile information are public, and which are secure and can only be exposed to authorized world login queries. Reed Hedges wrote: > Talking about authentication/identity in future 3D worlds etc.: > > Just found out about this: http://openid.net/ > > Decentralized shared ID thing. Anyone know anythnig about it? ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
[vos-d] OpenID
Talking about authentication/identity in future 3D worlds etc.: Just found out about this: http://openid.net/ Decentralized shared ID thing. Anyone know anythnig about it? Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] second draft requirements
On Sat, Feb 03, 2007 at 05:10:48PM -0500, Peter Amstutz wrote: > Meshes and Effects > Forgot Billboards I think. (Also terrain?) >The system shall support geometric primitives: cube, cylinder, >cone, sphere. > >The system shall support Lindin Labs "prims". In what manner? I.e. by import/export? Or directly in A3DL? (Or do we not seed to specify for the requirements?) Reed ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
