Re: [vos-d] second draft requirements
Do you have any pointers to documentation on
how this combination now called SAI works then?
http://www.web3d.org/x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification/
You are saying that I write a script node and somehow have access to my
entire virtual machine, access to other script nodes running within the
virtual machine?
That usually not true. Your scipt node should run in a sandbox. The only
way to communicate between different script nodes should be by the way
of events and routes.
And by the means of the SAI of course.
Everything else might work with some browsers (e.g. if the Script nodes
do not run in a sandbox but share a VM) but IMO would be not standard
compliant.
public void initialize()
{
CommonObject o = Register.instance.GetCommonObject();
}
Node 2 -
...
public void initialize()
{
CommonObject o = Register.instance.GetCommonObject();
}
I believe this is not possible. How should this work, if one node were
implemented in JS and the other in Java? (Ok, we have .NET now :-)
public void initialize()
{
Node node = EAILikeInterface.CreateVrmlFromURL(url);
node.getEventOut(foo).advise(this, foo);
}
public void callback
Yeah that should be doable using the SAI.
I know of a browser which makes the SAI available through a web
interface and thus offers a quite generic way to communicate with the
scene.
I didn't quite understand this, you have a link?
The link is http://www.zgdv.de/avalon/, but it's closed source and there
seems to be information about the web interface available. Perhaps it is
not exactly making the SAI available externally, I might have be to rash
on that. But you can definitely visualize the scene graph and I believe
you can also modify fields.
Regards Ben
___
vos-d mailing list
vos-d@interreality.org
http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] second draft requirements
Assuming you are speaking about the step from VRML to X3D here:
They have not cut off support for the external API. The thing about X3D
is, that they've combined what was the EAI (external authoring
interface) and the Browser Script Interface in VRML into the SAI (scene
access interface) in X3D:
[The] scene access interface (SAI) [..] can be used to interact
with X3D worlds both from within the worlds or from external
programs.
Your nodes can be coded in any language supported by the browser with
the bindings for Java and ECMAScript being explicitly defined and
supported by most browsers.
Wow, what you are suggesting here is definitely news to me. As far as I
understood it, SAI was the term they used for providing script nodes used to
drive node logic, and EAI was the name for the browser api. Perhaps I got
confused by the naming them. Do you have any pointers to documentation on
how this combination now called SAI works then?
You are saying that I write a script node and somehow have access to my
entire virtual machine, access to other script nodes running within the
virtual machine? i.e. lets say I want to have two nodes share a common
object, they can both access it?
Something like this is possible:
Node 1 -
...
public void initialize()
{
CommonObject o = Register.instance.GetCommonObject();
}
Node 2 -
...
public void initialize()
{
CommonObject o = Register.instance.GetCommonObject();
}
And all of the node instantiation and event listening capabitilties are
still there?
SuperNode 1
public void initialize()
{
Node node = EAILikeInterface.CreateVrmlFromURL(url);
node.getEventOut(foo).advise(this, foo);
}
public void callback
I know of a browser which makes the SAI available through a web
interface and thus offers a quite generic way to communicate with the
scene.
I didn't quite understand this, you have a link?
Thanks for the correction,
Rob
_
With tax season right around the corner, make sure to follow these few
simple tips.
http://articles.moneycentral.msn.com/Taxes/PreparationTips/PreparationTips.aspx?icid=HMFebtagline
___
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 Fri, 23 Feb 2007 14:49:43 -0500, Peter Amstutz wrote: On Thu, Feb 22, 2007 at 11:16:24PM -0500, Rob Meyers wrote: In terms of your scripts section, it would be great to have a COM binding to your api. Although this is pretty winders specific, it opens up all your code to .Net. I've done some work with editing worlds while you are To be honest, I hate COM and our primary development platform has always been Linux, so it's not particularly high on the list of priorities. However, interoperability is going to be a strong focus of the next version, so some kind of COM binding may be down the road. Conversely, on Linux, I have long wanted to have d-bus bindings, which would achieve more or less the same effect. That is something that probably will be in s5 out of the box -- you add a site extension (assuming site extensions exist in s5; or whatever is the equivalent if they don't), and you get d-bus, similar to how you get VIP. best, Lalo Martins -- It doesn't bother me that people say things like you'll never get anywhere with this attitude. In a few decades, it will make a good paragraph in my biography. You know, for a laugh. best, Lalo Martins -- It doesn't bother me that people say things like you'll never get anywhere with this attitude. In a few decades, it will make a good paragraph in my biography. You know, for a laugh. -- http://www.laranja.org/mailto:[EMAIL PROTECTED] pgp key: http://www.laranja.org/pessoal/pgp ___ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
Re: [vos-d] second draft requirements
Glad you've stuck with us. I remember VRSpace (well, visiting the web page anyhow). What became of that? It looks like there's still some mailing list activity. Oh yeah, VRSpace is still kicking as I understand. I stopped working on it somewhere in 2004 so haven't really played much with it since then. Its main guy Josip Almasi I believe has been making modifications to it. In the intervening years I spent a lot of time programming in c# and I decided java didn't have what I needed to build the system I was looking for in VRSpace. My take on things is that the VRML world basically had the right idea about how to build one of these virtual space system, but things got out of wack. Ever read the Living Worlds document?, very cool, ahead of its time stuff. However, they got too caught up in VRML itself. First they build a nice standards 1.0 that let you set up a scene graph. Then they add animation, events, prototypes, for nodes and an external api for interacting with the scene. All very good, but they also added internal scripting languages, which is where they started to go off the deep end. As far I understand it now, they have cut off support for the external api, and expect you to fully program all your nodes in javascript. Say what? Basically they think VRML is everything, graphics, animation, all the underlying logic, networking, programming... way too much for someone building a VRML browser to be responsible for supporting. But still the abstract concept of an object living in a space with events, properties, perhaps geometry is the right one. Objects that can be discovered, reflected upon... So I want to turn the VRML concept inside out. Spaces (whether client side or server) are collections of special objects (VRObjects if you will) that are shared when the two spaces encounter each other (Client logs in for example). These objects may or may not have geometry associated to them, but they do have attributes that can be queried, and events that can be registered for. As an example, the most basic example of a VR chat system is: Server - Chat object with method Say. Client 2 - Merges with Server space, register a listener to Say method on chat object. Client 1 - Merges with Server space, sees Chat object, calls Say with parameter ( Hello World ) Client 2 - Receives the Say call, and maybe displays it. So why c#? basically they've got Serialization, Remoting, Attributes, and most importantly this notion of a ContextBoundObject, which together basically gives you a VRObject. A CBO lets you intercept any calls to it from another CBO (whether residing in another virtual machine or the same) and handle them as you wish. So in the above, register a listener with Chat and receive the Say call are handled transparently by intercepting the Say call and calling all the listeners. The remoting handles all the object serialization and communications, but most importantly whether you are calling methods on a server object from the client (chatObject.Say(Hello World) or from server to server object, you program it the same way. The fact that this method can be listened to at all, security etc. occurs by marking it up with attributes. In terms of seeing objects though in a virtual space, its all handled as above. You have classes called Transforms with associated objects VrmlFiles. You detect a transform and vrmlfile when encountering the space, you read off the Transform's location, the VrmlFile's resource blah.wrl and tell your browser to create the associated nodes. If you want to script a vrml node, you do it all by listening to the vrml nodes, and handling the events in the c# itself. So the vrml file is slave to the c# class, not the other way around which would be more the VRML evolved. So I know I am preaching to the choir here, which is why I think your project rocks. My take on your stuff is that you have built the entire protocol, the serialization, the CBOs, reflection, the attributes/security yourself. Very impressive. To be honest, I hate COM and our primary development platform has always been Linux, so it's not particularly high on the list of priorities. However, interoperability is going to be a strong focus of the next version, so some kind of COM binding may be down the road. I'm actually more interested in being able to interoperate with .NET directly than trying to do .NET via COM. The tricky part on Windows is that I also want to support compiling with cygwin/mingw, so we can't rely on tools that are only available with Visual Studio. I hear you. Yeah the only real reason for suggesting COM was for the interop with .Net. I suppose then you could make yourself a managed c++ assembly which wraps your api, but watch out for combining .Net memory management with your code, yikes! How about mono? Yes, we've been meaning to do that for a long time. It's just a matter of developer time and resources.
Re: [vos-d] second draft requirements
On Thu, Feb 22, 2007 at 11:16:24PM -0500, Rob Meyers wrote: Hey yall, last time I wrote to this group was several years ago, but I have been reading the messages as they come along. I took an interest in your work back then as I was struck by the similarities it had with the project VRSpace I was working on at the time. So I read this set of requirements and thought I would throw in my two cents. Glad you've stuck with us. I remember VRSpace (well, visiting the web page anyhow). What became of that? It looks like there's still some mailing list activity. In terms of your scripts section, it would be great to have a COM binding to your api. Although this is pretty winders specific, it opens up all your code to .Net. I've done some work with editing worlds while you are To be honest, I hate COM and our primary development platform has always been Linux, so it's not particularly high on the list of priorities. However, interoperability is going to be a strong focus of the next version, so some kind of COM binding may be down the road. I'm actually more interested in being able to interoperate with .NET directly than trying to do .NET via COM. The tricky part on Windows is that I also want to support compiling with cygwin/mingw, so we can't rely on tools that are only available with Visual Studio. in it, i.e. your interactivity section. Being able to click on the movable objects and having a visual interface to move it around is very helpful. But this idea can be taken a lot further, namely having an editor that allows you to click on an object and see all of its available properties, methods in and out and allows you to change these fields, invoke the methods, etc. Very useful for debugging. Yes, we've been meaning to do that for a long time. It's just a matter of developer time and resources. And if anything is on the wish list, having 3D versions of the most common controls available, i.e. panels, texboxes, labels, scrollbars, etc for building a front end in the hud would be fantastic. If field/events from these widgets are available throug the api, then viola 3d apps. No reason to restrict them to placement in the hud... so you can put a textbox on some object e.g. Either way this property editor mentioned above comes into to augment the front end building experience. Way back when, I think I suggested having the ability to drag a file onto the front end and have its geometry to pop up in the world. Basically, I am in support of anything that makes it easier to put content in the world and manipulate it. These are all good ideas, and I'll incorporate them into the requirements document when I get a chance. I've recently been building a new framework for making 3d apps called AstralX. To test out its capabilities, I originally wrote a chess program, but that was a boring game. So I've built a version of HeroQuest, a boardgame from way back, which is pretty much so completed. Check out some screenshots of the game in play at: https://sourceforge.net/project/screenshots.php?group_id=125518ssid=53527 https://sourceforge.net/projects/astralx/ AstralX is written in C#, uses BitManagement Contact, so all the geometry is VRML/X3D. I used to play Hero Quest! That game was great. I still have a boxful of plastic orcs lying around here somewhere... -- [ 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] second draft requirements
Hey yall, last time I wrote to this group was several years ago, but I have been reading the messages as they come along. I took an interest in your work back then as I was struck by the similarities it had with the project VRSpace I was working on at the time. So I read this set of requirements and thought I would throw in my two cents. In terms of your scripts section, it would be great to have a COM binding to your api. Although this is pretty winders specific, it opens up all your code to .Net. I've done some work with editing worlds while you are in it, i.e. your interactivity section. Being able to click on the movable objects and having a visual interface to move it around is very helpful. But this idea can be taken a lot further, namely having an editor that allows you to click on an object and see all of its available properties, methods in and out and allows you to change these fields, invoke the methods, etc. Very useful for debugging. And if anything is on the wish list, having 3D versions of the most common controls available, i.e. panels, texboxes, labels, scrollbars, etc for building a front end in the hud would be fantastic. If field/events from these widgets are available throug the api, then viola 3d apps. No reason to restrict them to placement in the hud... so you can put a textbox on some object e.g. Either way this property editor mentioned above comes into to augment the front end building experience. Way back when, I think I suggested having the ability to drag a file onto the front end and have its geometry to pop up in the world. Basically, I am in support of anything that makes it easier to put content in the world and manipulate it. I've recently been building a new framework for making 3d apps called AstralX. To test out its capabilities, I originally wrote a chess program, but that was a boring game. So I've built a version of HeroQuest, a boardgame from way back, which is pretty much so completed. Check out some screenshots of the game in play at: https://sourceforge.net/project/screenshots.php?group_id=125518ssid=53527 https://sourceforge.net/projects/astralx/ AstralX is written in C#, uses BitManagement Contact, so all the geometry is VRML/X3D. Good to see you guys still in action, Rob From: Peter Amstutz [EMAIL PROTECTED] Reply-To: VOS Discussion vos-d@interreality.org To: vos-d@interreality.org Subject: [vos-d] second draft requirements Date: Sat, 3 Feb 2007 17:10:48 -0500 Alright, here's a second draft of the requirements document, based on the input I've gotten back so far. Creating Interreality Version 0.30.0 Peter Amstutz Copyright007 Peter Amstutz Permission is granted to copy, distribute and/or modify this document under the terms of the GNU General Public License, Version 2 or any later version published by the Free Software Foundation. A copy of the license is included in the section entitled GNU General Public License. _ Table of Contents 1. Requirements 1.1. Mission Statement 1.2. Multiuser Requirements 1.3. Online Networking Requirements 1.4. Platform Requirements 1.4.1. Basic Requirements 1.4.2. Scripts 1.4.3. Interactivity 1.4.4. Authoring 1.4.5. Behaviors 1.4.6. Audio 1.5. Client Features 1.6. 3D Graphics Requirements 1.6.1. Meshes and Effects 1.6.2. Avatars 1.6.3. Portals 1.6.4. Animation _ Chapter 1. Requirements An unsorted list of all the thing we want Interreality 3D to do. See the Timeline at the end of this chapter for priorities and scheduling. Compiled from ideas and suggestions by Peter Amstutz, Reed Hedges, Karsten Otto and Ken Taylor. _ 1.1. Mission Statement Develop a free software platform for multiuser, online, collaborative 3D applications. What do we mean by this? Free Software Interreality 3D will be released under a free software license such as the GPL or LGPL. Multiuser Interreality 3D will allow many simultaneous users that are all able to see and interact with each other, and share a synchronized view of what is going on in the virual space. Online Interreality 3D will be Internet-based. This means it must be robust and usable over the real Internet where uneven latency, firewalls, packet loss, heterogeneous networks, narrow pipes, etc are the norm. Respecting the distributed nature of the Internet, Interreality 3D worlds will be spread across many hosts, and worlds will interconnect using portals
Re: [vos-d] second draft requirements
On Tue, Feb 06, 2007 at 09:52:51AM -0500, Reed Hedges wrote: On Sat, Feb 03, 2007 at 05:10:48PM -0500, Peter Amstutz wrote: Meshes and Effects Forgot Billboards I think. (Also terrain?) Right. I'll add those. 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?) Directly in A3DL. My thought was we can write an OTD that has the same parameterized fields that describe a SL primitive. The client needs to be able to render that, of course. Hugh Perkins has a library fractal spline which apparently can render SL prims that we can borrow. Having this functionality would make it trivially easy to incorporate SL content into VOS. -- [ 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] 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
Re: [vos-d] second draft requirements
Hi Peter, It's good to see you are adopting a plugin framework approach. on meshes I was thinking you should support the triangular strip array as that is a very efficient form for rendering. Also, there may be another common mesh format worth supporting such as the one used in Ogre3D. For image formats, one of this biggest performance problems with X3D is due to the size of images that are needed for textures. Better compression support, such as jpeg2000 is pretty much essential. On security, what can be done about network communications security - e.g. encryption and authentication? chris ___ 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 Sun, Feb 04, 2007 at 07:35:30AM +0900, chris wrote: Hi Peter, on meshes I was thinking you should support the triangular strip array as that is a very efficient form for rendering. Also, there may be another common mesh format worth supporting such as the one used in Ogre3D. For image formats, one of this biggest performance problems with X3D is due to the size of images that are needed for textures. Better compression support, such as jpeg2000 is pretty much essential. On security, what can be done about network communications security - e.g. encryption and authentication? I see these as mainly design or implementation issues -- the requirements document is about what it does, not how it does it. Otherwise yes, you're right, efficient data representation for meshes, textures, etc is going to be important. And security is a huge, enormous issue that we'll deal with the time comes. But we don't specify design in the requirements document, we specify design in the design document. That will come next when we're all happy with (or sick of) the requirements. -- [ 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
