From: owner-3dui@hitl.washington.edu on behalf of Jeff Pierce
[jpierce@cs.cmu.edu]
Sent: Monday, August 21, 2000 5:19 PM
To: 3d-ui@hitl.washington.edu
Subject: Re: Topic: dynamically creating (copies of) objects

At 04:34 PM 8/21/00, Drew Kessler wrote:
> > (5) Problem: Rendering N views of an object effectively divides the maximum
> > frame rate by 1/N.
> > 
> > Technique: Instead the system could create N copies of the object, and
> > arrange the copies in front of the user to provide different views.  These
> > copies could also provide different constraints for manipulating the
> > object.  For example, a top down view of the object could be constrained to
> > move the original left/right and forward/back in the scene.  Instead of
> > activating different constraints on the same object, the user would then
> > just choose which constrained copy to pick up.
>
>Sorry, Jeff, but you lost me here.  Can you explain this idea further?

I must not have explained that well, because I got a few queries on it. The
idea was that to provide multiple, different views of an object (e.g. top
down, view of front side, view of left side) you could create multiple
copies of the object and render them in the view.  Thus instead of walking
the screen graph X times to render X different views in different windows,
you just render that object's geometry X times with a different
transformation each time.  Saves you from re-rendering the background
multiple times, and it should be easier to work with in an HMD.  Plus you
can then impose different constraints on the different copies of the objects.

Does that make sense?

>...
> > (7) Problem: Most systems for multi-user worlds unnecessarily restrict
> > operations on objects so that only one user can be working with an object
> > at a time.  However, in a virtual world there is no reason that one user
> > couldn't be painting an object while another user is repositioning it.
> > 
> > Technique: Create copies of an object on demand so that multiple users can
> > work with it, and lock the object by operation (e.g. painting, positioning,
> > manipulating limb positions, etc).
>
>This is a great idea... I can say so because it has come up a few
>times :)  See, for example:
>
>Brook Conner and Loring Holden, "Providing a low latency user
>experience in a high latency application." Proceedings of the 1997
>symposium on Interactive 3D graphics, April 27 - 30, 1997, Providence,
>RI USA.

Ah, but Conner's paper still allows only one user to lock the object at a
time.  When a user first picks up the object it is transparent, and it
turns opaque when they get the lock (or fades away if they don't).
However, they never actually create multiple copies of the object so that
each user can work with one.

>Un-Jae Sung; Jae-Heon Yang; Kwang-Yun Wohn, "Concurrency control in
>CIAO," Virtual Reality, 1999. Proceedings., IEEE , 1999

I haven't read this one, but I just grabbed a copy (gotta love the Web) and
I'll take a look.


>...
> > (6) Problem: Techniques for transporting objects (e.g. Fix and Float, Cut
> > and Paste, Toolspaces and Glances) require that users determine in advance
> > which objects they will need in another location (a task we aren't always
> > very good at).
> > 
> > Technique: The system could create a copy of any object that we ever walk
> > within 20 meters of.  We could then access those copies later to retrieve
> > an object we realize later we need.  If the system preserves the spatial
> > arrangement of these copies, they could also provide a means of returning
> > to previously visited locations (a la flying into the WIM).
> > 
>...
> > 
> > (8) Problem: Precise placement is difficult and time consuming in virtual
> > worlds.  Approaches like gridding may unnecessarily restrict the locations
> > where users can place objects.
> > 
> > Technique: While the user is moving an object the system can attempt to
> > infer potential resting places and create copies at those locations.  The
> > user can drop the the object and touch a copy to cause the placement.  This
> > allows the system to suggest possible placements rather than enforcing a
> > particular one.
>
>I've grouped these because, although they are good ideas, I think they 
>demonstrate the down-side of using object copies:  having to select a
>particular copy in a sea of copies.  I would be particularly concerned 
>about the reverse-crumb-dropping technique (7 above): rather than
>dropping crumbs to remember a path, "picking up" landmark copies to
>have a hook to get back to a place.  The key to this technique would
>be organizing the copies so that the user can select the one desired,
>and have the right object to location association.

Yup.  Taken to the limit technique 6 (I presume that's the one you mean)
collapses to giving the user a WIM that includes the entire world, but
you've still got the problem of finding the exact object you want.  I think
the key to making this work would be finding the right scope (e.g. objects
I've walked near in the last 5 minutes, or objects I frequently work with)
plus the right retrieval method.

You can also have the user explicitly create copies of objects
("souvenirs") to act as hooks for later retrieving the object or accessing
the space its in.  Imagine carrying a small copy of your desk around so
that you can access your office anywhere you go.

>For technique 8, you would want to limit the number of copies, which
>leads to the same restrictions imposed by a gridding or "object
>gravity" selection of possible locations (there isn't too much of a
>difference between showing a copy at the nearest selected location, or 
>showing copies at the n nearest selected locations).

You definitely wouldn't want to use (8) to suggest different placement
locations, each 1 inch apart.  As Drew pointed out, creating copies for
placement is useful when the copies are far enough away to be visually
distinct.  Consider the following two examples:

1. In the object associations video, dragging the cup under the desk
doesn't move the cup to the top of the desk until the desk occludes your
view of the object.  This could be problematic if the desk is flush against
the wall, and you _can't_ drag the cup so that the desk hides it from your
current viewpoint.  Consider adding copies to object associations so that
when you drag the cup under the desk the system creates a transparent copy
on top of the desk; if that's what you want you can switch objects and make
that the "actual" cup.

2. You're dragging a desk with the mouse in a desktop 3D world, and you
want to place it against a wall.  Gridding will allow you to precisely
place it against the wall, but you've still got to drag it across all the
intervening space.  The system could look at the desk's trajectory, figure
out what lies along that path, and then create copies at likely resting
places.  Sort of like a grid with semantically determined gridpoints and
visual feedback.


>In my mind, I see the following uses of object copies:
>
> - Creating a new object this is just like another, but different.
>
> - Using a copy for indirect manipulation.
>
> - Using one or more copies to provide choices (add an "abort"
>   function to the previous use, and you have two choices: keep what
>   you had or use what you've changed).
>
> - Using copies to provide different views or the same thing.
>
>Except for the last one, Jeff described a few examples of these uses.
>An example of the last use would be a collaborative design building
>design session, where the electrician, plumber, structural engineer,
>and client would each want to see different details of the same
>building model, perhaps to discuss the design (client asks, "can I put 
>another outlet on that wall?").

Raimund mentioned another example of the latter: two views of a car, one of
which might be showing a specific subsystem while the other shows the
subsystem in the context of the other systems.

There's also the idea of showing multiple copies of an object, each showing
different stages in its evolution.

>Did I miss anything?

That's what I'm hoping we'll find out.  =)

Jeff