Frameworks for designing VE applications Why is this so hard

1
Frameworksfor designing VE applicationsWhy is
this so hard?

• Adrian West
• Advanced Interfaces Group
• Univ. Manchester
• http//aig.cs.man.ac.uk

We all know from personal experience that what
we aspire to gain is happiness and what we try to
avoid is suffering. Yet our actions and our
behaviour only lead to more suffering, and not to
the lasting joy and happiness that we seek. This
must surely mean that we are operating within the
framework of ignorance.
2
What do you want from a VE toolkit?

• Make it easy to specify a VE
• what it looks like - hard!
• what you can do in the VE - hard!
• Flexibility - cope with your application(s).
• Fast interactive, large models
• Distribution
• sharing
• cope with latencies and delays

3
also - (looking ahead) ...

• multiple applications
• seamless interworking
• plug and play with new peripherals/paradigms

4
UNC - office of the future
from UNC website
5
Framework responses

• Easy to specify VE graphics, activity ?
• Off-the-shelf - many tools built in
• The hard work done for us.
• many decisions have been made.
• Top-Heavy if it must do everything
• Flexible (cope with my particular needs) ?
• few pre-committed design decisions
• architecture still maleable
• infinite flexibility provides nothing - a space
  in which to write it all yourself.

6
Framework responses...

• A hope - can we plug existing technologies
  together?
• Java 3D, VRML, Corba (or equiv), AI, Icollide,
  WAP!
• Sounds great.
• Best of all worlds, or the worst?

7
How do we know what works?How do we measure
success?

• Functionally - can it do X?
• misleading - can it simulate a Turing machine?
• Ease of use - how easy is it to do X?
• c.f. languages, editors, oss.
• difficult to get others to use/test systems.

8
Where are we?(why so little progress?)

• Why so few really compelling VE demonstrations?
• Hardware?
• Peripherals?
• Software? - easy to imagine, hard to do.
• Applications?
• No grand challenge
• compelling applications elusive.

9
Lets look at some applications

• Consider the range of requirements a VR toolkit
  will have to cope with here.
• Consider whether these are compelling VEs.

10
Cityscapes

• eSCAPE
• graphically challenging
• occlusion culling key.
• uses?
• Tourist information?

11
Crime Scene reconstruction

• Speed of model build/capture.

12

• Realistic lighting - highly significant

13
Model capture - from video sequences

• Needs objects - not meshes
• Inverse Radiosity based materials property
  determination.

14
aig.cs.man.ac.uk/research/reveal
15
Kahun CityAIG/MMU

• Interactive shared teaching
• Egyptian Game

16
Kahun City
17
Architectural Walk-through

• Lightmaps, textures and geometry
• Complex model
• Automatic LOD and cell portal culling

18
Data visualisation

• Q-Pit (Lancaster U.)
• large numbers of objects dynamic hull recalc

19
Games-like effects

• Masters project

20
Distributed Legible City (escape)
21
Builder

• Interactive editing immersive (hmd) 2-handed
  (3D mice)
• Voice control

22
PlaceWorld

• escape. (ZKM,SICS,Lancaster U, AIG)
• Art Social Spaces Citizen-oriented

23
PlaceWorld

• Shared
• Trails, Traces, pathways...
• Multiple Applications

24
Conocos CMS2

• Massive models
• Legacy data and code stored in native CAD format
• Uses land-marking and navigation techniques

25
How to cope with this range of applications?

• Wide variety of applications requiring
  interactive performance
• Key optimisations application specific
• Importing model data in standard format often too
  limiting - flexible objects?

26
Our own framework experimentone idea to address
some of this

• use application knowledge (data
  structures/algorithms) directly, in each case.
• Avoids designing (and committing to) our own
  internal representation.
• Coping with huge models easier as data
  representation optimal. (e.g. on the fly lod).
• Can still provide functionality in remaining
  framework
• It copes well with the previous applications
• reuse existing material, customise where needed.

27
Data import - two representations
VE model
Application model
VE code
Display
Maverik - single model
Application model
Display
Maverik VR kernel
Run-time binding
28
downside

• Programming effort is required to customise the
  system to use the application specific data.
• Less convenient than an off-the-shelf tool if
  that does what you want directly.
• All sorts of other problems.

29
And so (conclusions)...

• Tools are a difficult issue
• Broad range of applications hard to cater for
  with a general mechanism. (one size fits all)
• performance requirements strict, and key
  optimisations application specific.
• Choices
• off-the-shelf good if it does what you want.
• Write your own - flexible, but hard work.
• A middle way? - quest for the right framework.