Suggested ice-breaker topics for discussion in 協力
Ryan McDougall
"Assets"
- precise definitions of what assets are, how meta-data is attached to
them, how they are cached, how they are logically discriminated based
on the metadata, and the security model
-- suggest starting from CB's Asset service model
"Inventory"
- precise definitions of how assets relate to each other, how they are
organized by humans, and the security model
-- suggest starting from CB's "Filesystem model" for inventory
"Authentication"
- Does OpenID provide a superior solution for authentication over a
federated network? What if we add XRD?
- Does oAuth provide a superior way of negotiating resource sharing
over a federated network?
- Are there other options?
"Trust Models and Service Discovery"
- in a distributed, federated internet, how can decoupled simulators,
servers, and viewers learn to trust each other and discover each
others' resources?
-- suggest starting from CB's federation and service discovery model
Propose your own!!
== Libraries
COLLADA
- clearly each world has it's own optimized asset formats which cannot
be abandoned for performance reasons. COLLADA is meant to solve this
problem, but since it is designed for content pipeline interchange,
not run-time interchange, how can it be adapted to allow different
worlds to at least approximate foreign simulations?
Ogre3D resource parsing
- Ogre3D is a powerful way to jump-start a 3D viewer, but it's
resource files are not meant for streamed loading over a CDN.
Descriptions of nested asset names need to be converted from local
names to globally addressable URIs. Moreover there is no inherent
notion of security within, so that has to be added on as an external
layer.
- Ogre3D may have their own custom file formats, but would not similar
engines have similar formats? Is there a common abstraction that can
prove more useful beyond Ogre3D?
Structured Streams (http://pdos.csail.mit.edu/uia/sst/)
- Would anyone's streaming transport implementation benefit from using
SST? Would the state of collaboration improve if we shared this
library?
What would you like to see??
Hope that I have provided some ideas, and hope that some time soon I
can submit my own proposals for discussion (after our release and the
well earned summer vacation!!)
Cheers,
Antti Ilomäki
Tommi Laukkanen
engine namely Axiom. Axiom does not have Collada support so I am
tempted to agree but there are issues:
I find it highly unlike that other rendering engines will write
importers Ogres native format:
* It feels unfair to them. Lets not underestimate the human ego
factor.
* Ogre format is not designed as standard. As such it might not be
easy to comprehend or implement.
* Ogre might not commit to standard procedures in the future
development of their format.
* Ogre format probably does not support referring aggregate assets
with Uri's which is quite desirable.
We need to be able to use the models/meshes on all tiers like servers
doing collision detection and physics. Hence it would be good to have
libraries to several languages instead of clunky native library
bindings.
Collada on the other is a standard. There is a process to develop it.
Both schema and document are easy to understand and refer to assets
with uris. Collada also supports some useful features like shader
languages for defining materials like fur. Collada was designed for
asset exchange in the tool chains but there is no real difference in
asset distribution to the servers and clients. If required the collada
documents can be gzipped when transporter as defined by http
protocol.
It is true that media distribution in the games like WoW is a big
issue but how large amount of that media data consists of models,
skeletal animations and key frame animations? The bulk of it is video,
music, speech and images/textures.
To summarize: I think we would be optimizing the wrong end if we would
go for native binary format in this stage instead of existing
standard. My evaluation of Collada schema is that it is quite sane and
to the point which can not be said of too many standards in this
field. Probably because Collada was designed by industry to fulfill
their existing needs.
On the other hand if we do not have libraries for importing Collada to
Ogre and to our other system components maybe we do not have other
options than use Ogre format for now. In the mean time I would use all
available means to propel the Collada import functionality to ogre and
other needed libraries forward. I understand that there is some kind
of Collada import plugin being developed for Ogre but I am not sure
how feature complete it is.
regards,
Tommi