On 8/9/2011 1:44 PM, David Barbour wrote:
On Tue, Aug 9, 2011 at 11:09 AM, Steve Wart <st...@wart.ca
<mailto:st...@wart.ca>> wrote:
3D design is extraordinarily expensive to develop properly
That is not an essential property of 3D design. We could have an
ontology / 'markup language' just for building and animating avatars,
similar to dressing up a doll, if we want to make one. And a modular
ontology for buildings (including concepts such as crenelations and
gargoyles). And another for environments. Etc. Given a suitably
modular meta-language, we can even have dedicated languages for
describing zombies.
I see the impoverished languages of today as an opportunity. For
accessibility reasons - e.g. desktop vs. iPhone access to a world - it
is preferable that we develop in these high-level ontologies anyway.
My own vague interest has steered me towards modular, reusable,
multi-player interactive fiction - with a lot of inspiration from the
Inform 7 language [1]. I have a bunch of half-formed designs from my
earlier work on the subject, and my efforts in language design.
yes, although sadly existing technology and tools have done a terrible
job at this, and are still mostly at the level of:
create a cube;
stretch it to about the right size;
put a "building exterior" texture or similar on it;
...;
call it done.
or, one wants to build a building, and so resorts to endless geometric
fiddling (placing/sizing/texturing cubes to make walls/doors, import a
chair model and copy/paste it a crapload of times, ...).
yes, granted, a few programs have procedural modeling features, ...
And also note the lack of porn (although WoW has a high level of
titillation it also has been very successful in attracting women).
Lol. Pornography is a human trait with an ancient and ignoble history,
even if male dominated. I once watched a rather funny (but somewhat
perverted) video called 'Ballad of the Sex Junkie' developed in WoW.
It's NSFW, but is tame enough for Youtube.
Anyhow, I'm speaking at the federated world level. It would be silly
to deny that those red-lights districts will exist. This rule is the
same for all computer security: you cannot protect against a threat by
ignoring it! I prefer soft security, wherever possible, and this means
recognizing and accommodating threats in order to gain some control of
them. By recognizing red lights districts, and the inevitable fallout
(such as naked avatars waltzing through worlds), we can isolate them
(e.g. by ensuring that the avatar has suitable clothing upon entering
a 'no shirt no shoes no service' world).
possibly, if done more like the existing web, then a person will have
different user accounts and different avatars for different servers.
transferring from one location to another, or going to favorite places,
may then inevitably involve some number login screens...
The original concept of VRML as a standard in the hypertext model
still makes sense to me, but the gaming platforms seem to prefer
the silo model.
VRML is an awfully low-level ontology for building 3D models! I would
suggest that this is part of /why/ we favor the silo model.
VRML also looked like a mishmash of things that would not normally go
together in game data files.
in many game engines, most of the game contents are spread across a
large number of different files, each format typically fairly
specialized, and integrated into a single combined world.
VRML seems to try to be more like HTML, and express the entire world
structure in a single file.
IMO, this is not a terribly great approach.
granted, I hold a similar complaint against Collada as well (although it
sees the world more from the POV of a traditional 3D modeling app).
Think about what it would take to build designs that let us achieve
something similar to CSS for 3D and avatar animation. Separation of
artistic rendition (presentation) from content is important. Anything
short of that is ultimately unsuitable for world mashups! Working with
cones and boxes is not the right level for this.
yep.
ideally, we should probably be working with higher-level "entities"
instead of lower-level geometry.
like, say, one goes about defining an entity type, allowing for certain
input parameters, ...
then, later, a piece of code may import the entity.
entity {
classname="someapp/my_entity_type"
origin="..."
...
}
Quake-series engines have generally done similar for most "higher-level"
entities (excluding basic map geometry).
to some extent (and with a different syntax) Valve is already doing
something vaguely similar with entities which may also import map
geometry (one can do things like, say, import premade world objects in
Hammer Editor, ...).
applying this at a larger scale may make some sense.
taken further, it could mean the elimination of "brushes" as
traditionally understood in the "map" sense, with brushes essentially
becoming entities as well (again, valve has partially done this at the
syntax level, abolishing the older brush-definition syntax).
this could mean though, instead of creating a brush from faces, one
could be like:
primitive {
classname="primitives/cube"
origin="..."
mins="..."
maxs="..."
texture="stone/cobblestone"
...
}
and have the 3D engine figure out trivia such as what the face-planes
and texture projection axes are (traditional Quake-style maps exist at
the level of specifying individual faces).
I think we really do need an ontology for architecture, avatars,
environments, etc. as a common foundation in the world.
possibly, ultimately all levels should be expressed, but what should be
fundamental, what should be expressed in each map, ... is potentially a
subject of debate.
The Teatime model seems promising
Teatime protocol is unscalable and insecure. It is suitable for LANs
where you trust the participants, but would die a slow, choking death
if faced with 'flash crowds', 'script kiddies', and their like. No
variation on Teatime will ever work at scale. Transactions scale
poorly and have plenty of flaws [2]
But there are some lessons you can take away from Teatime. Use of
temporal semantics is a suitable basis for consistency even without
transactions - we can tame this with a more commutative/idempotent
model and /eventual consistency/. Explicit delay is an effective
approach to achieve near wall-clock determinism in the face of
distribution latencies (e.g. a signal propagates to multiple clients,
but triggers at some specific time in the future).
I have developed a very simple and effective programming model -
Reactive Demand Programming - for solving these and related concerns
[3]. One might think of RDP as a fusion of eventless FRP and OOP -
i.e. OOP where messages and responses are replaced by continuous
control signals, and state is primarily replaced by continuous
integrals. RDP is, by no small margin, the most promising model for
developing modular, federated, distributed command and control
systems, augmented reality systems, and 3D worlds.
I am not familiar with the Teatime protocol. apparently Wikipedia
doesn't really know about it either...
Croquet always felt awkward to me, partly it was performance, but
it was also because some of the primitives were too primitive.
I agree that this is a problem. VRML is a problem for the same reason
- i.e. it is not clear what the physics should be, nor how we should
recharacterize for a different artistic style, and so on.
yep.
half-assedly ripping off Valve's designs and adapting them to a more
open world structure could make some sense...
then, say, one has something like:
entity {
classname="target_changelevel"
map="sghttp://www.someserver.com/foo.map";
targetname="t34"
}
or with a more Valve-like syntax:
entity {
"classname" "target_changelevel"
"map" "sghttp://www.someserver.com/foo.map";
"targetname" "t34"
}
note (Valve Map Format):
http://developer.valvesoftware.com/wiki/VMF_documentation
my own recent map format design is partly influenced by this format...
or such...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
