Hi Anselm I concur with much of what you say but would like to address a few of your points.
1. You may not be aware of this but last year X3D added a Network Sensor Node. This is a listener spec that allows for things such as multi-user shared state and live data updates from external sensors. The Network Sensor is already implemented in many of the X3D viewers. 2. You make a comment that VRML and X3D "are very heavy bulky formats". I don't see a basis for this comment. Most real-time 3D formats are highly related and of similar file sizes. An X3D binary is about as small as you can get short of a stripped down triangle list. 3. I quite agree with you about the importance of federation and shared data to make AR useful. Next week, the Web 3D Consortium will be announcing a call for participation, at the Engage virtual worlds show in San Jose (Sept 23-24), to complete a fully open specification for shared multi-user worlds that can be used by AR applications. Much of this work is already complete but topics such as shared communications and MU servers still need to be resolved. Leveraging other important open efforts such as XMPP/OpenFire, PostGISql, MySQL and Geoserver will be hot topics. Please get involved! Thank you David Colleen Planet 9 I would not use GML or GIS based approaches. I would use GeoRSS for simple features and X3D for rich features. To elaborate: It doesn't seem like the AR focus would be say on connectivity of street segments or different geodetic systems or say raster analysis of different layers of ground cover, or doing transformations on rendering with different styles. It seems like those extra powers while useful are not core to the deliverable. Rather In my mind I see AR as more focusing on painting a high quality UX experience on top of the real world. Keeping that experience registered and in sync with the real world as much as possible and providing interactivity and dynamic behavior. In many ways I see AR as drawing more on video game development conventions rather than on GIS conventions. If I was asked to build an end-to-end AR system from scratch I'd feel like I could get the job done faster, safer and in a more durable way if it was based on more similar practices instead. The kinds of conventions that a 3d video game has - and that VRML and X3D have tend to reflect a different set of concerns. They tend to utilize scene graphs http://en.wikipedia.org/wiki/Scene_graph and tend to include concepts like : [ grouping node to group things ] [ transform nodes expressing 4x4 homogeneous world coordinates ] [ model node expressing 3d polyhedra ] [ appearance node expressing model textures and the like ] [ instance node; specifying an instance of a model ] [ behavior node; specifying rules over time to apply to an instance ] The big win would be that your artists, designers and modelers could use tools that they were already comfortable with. As a developer you could grab tools that largely would already process, compress and render the data. The key benefit however would be highly dynamic rendering. GML systems tend to reflect a kind of 'static' scenery. A scenery that doesn't update very often. VRML conventions tend to reflect a need for dynamic behavior more - the increased emphasis on transforms, multiple instancing and the like. All these grammars are isomorphic, but they are tuned to their landscapes. I feel that it's easier to use a representation that is closer to the goal rather than stretching another representation. VRML and X3D have many flaws as well; they tend to focus more on presentational aspects - although often in the real world form is a side effect of underlying function - and are very heavy bulky formats. However they're heir to the legacy of games development and in my mind AR will in turn start to be about visualization of highly dynamic behavior that is constantly changing rather than say just showing you where subways are. When I mean "dynamic" I mean AR views will start to show say where friends are moving to, and the dynamic and fickle constantly changing sets of relationships between people and objects around them, the density of information clouds, dynamic personal routing options based on traffic flows, coupons and redemption awards that shift from moment to moment, historical re-enactments of stories embedded in the landscape that you are traveling over, fantasy situations overlaid over top of the ennui of real life, dynamic rewriting of placards and billboards to remove annoyances from field of vision, constantly changing statistics over-top of people that you are talking to... it's going to be a very cartoon world very soon. Pragmatically however what's going on in an AR world is no different from what we were doing 15 years ago with heads up displays. The same problems of registration ( and of the headache inducing nausea that comes from failing to keep registration in sync ) , the need to manufacture a separate display for each eye in order to provide the illusion of depth, the need to efficiently cull sort and manage the potentially visible set, the need to balance very limited computational resources - this is all completely utterly routine. The joystick input is a GPS not just a position in an abstract 3d virtual space. The only new thing is the need for new algorithms to keep the overlay registered against arbitrary real world views. And perhaps in the larger scale of AR there will be a need to finally solve federated data and behavior publishing problems such as were tackled by Second Life. If AR proposes to be distributed - so that instead of seeing just LAYAR data or somebody elses data - that there is a federated way to aggregate and share layers and have a consolidated view across datasets from many vendors - then I'd just suggest GeoRSS personally for simple features and X3D for rich features. In fact this whole burgeoning field may breathe new life in to X3D... ( otherwise we'll have to invent some kind of rdf3d I suppose ) . It would be nice if GeoRSS supported a hint about the orientation and velocity of an object ( although these can be determined by two successive GeoRSS publication events of a given object over time ). _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org _______________________________________________ Geowanking mailing list [email protected] http://geowanking.org/mailman/listinfo/geowanking_geowanking.org
