From: snowdond@cs.man.ac.uk (Dave Snowdon)
Subject: Re: TECH: My standard is better than your standard II
Date: 30 Jun 92 14:13:18 GMT
Organization: Department of Computer Science, University of Manchester



In article <1992Jun30.074058.12120@u.washington.edu>, s047@sand.sics.bu.oz.au (Jeremy Lee) writes:

    Inherited methods are almost useless, as each object is a seperate,
    individual object. It is encapsulated and complete in itself. This is my
    fundamental proposition. The object has to continue to exist if the
    parent object is deleted. If you want to move an object to another
    database, then why should you have to move it's parent?

    OO design is a static thing. VR is a dynamic environment. When I ask why
    OO is wanted, most people indicate a need to reduce the trouble when
    *creating* the object. If this is the case, then copy a "parent" object
    and redefine some scripts. If you want attributes of another object,
    then copy the scripts from inside that one.

This might be a real pain if you wanted to change some global aspect of the
environment. I remember reading somewhere about distributed implementations
of Smalltalk that are capable of shipping the code for a class to another
processor on demand - ie when that processor needs to examine/modify an
objects for which is does not have the definition in store. Maybe, with this sort of approach you could treat objects as if their defniitions were
independand, and let the system worry abouy where the code is actually defined.

[Jeremy Lee talking about collsion detection between objects] 
    I have noticed a problem with this. If you can redefine the basic
    geometrey of a patch between objects, then how do you get the
    environment to tell when two patches have intersected? You can't, unless
    patches are based on some sort of basic geometric model. Patch
    collisions revert to a (very complex) mathematical operation that tries
    to detect when two 3D manifolds intersect. If one is a fractal manifold,
    then this can be difficult. How do you do t without limiting the types
    of patches you can support? The only idea that I can come up with is
    setting crude "bounding boxes" around the objects for efficiency, and
    when the environment detects the intersection of these bounding solids,
    then it should get the two objects to talk to each other and find out
    whether an intersection has occured.

This is the sort of approach I'm using - letting the environment do the
coarse collision checking and then the objects need to negotiate for the
fine collision checks. The bounding extents described in "Ray Tracing
Complex Scenes" by Timothy L. Kay and James T. Kajiya in ACM Computer
Graphics vol 20, no 4 seem to be useful for this as they can be made to fit
objects arbitrarily tightly (at a cost of increased CPU to calculate the
extents and peform intersections) and checking for intersections between
extents seems to be quite simple.
 
    (Hmm, an algorithm to detect collisions has sprung fully-fledged
    into my head now, and it's even efficient!)
 
    Each object computes it's own bounding solid. It checks for an
    intersection with the bounding solid of any other object. If it does,
    then it calculates the intersection solid. Each object then computes the
    bounding boxes (multiple) that describe the disconnected parts of it's
    surface that extend into the previous intersection. The other object
    does the same. Each object now has a set of bounding boxes, and more
    tests are done to see if they intersect. The whole operation is done
    recursivley until (a) no intersection is found (the latest intersection
    volume is empty of either object) or (b) an intersection bounding box
    is reached of sufficiently small size to be indistinguishable from a
    point.
 
    All (all he says!) the individual objects have to do it compute their
    own bounding boxes, and tell their neighbors via messages. Aack! How do
    they know who their neighbours are? Forgot about that. Either we have to
    have a "God", or the enviroment has to watch intersecting bounding
    boxes. The more efficient, and pleasing solution would be to let the
    environment do it. But, we have reduced it down to approximatley 5 lines
    of code.

I like the sound of this algorithm.


PS
    I've had several requests for copies of the AVIARY paper I mentioned in
my last post. Its now available for anonymous ftp from m1.cs.man.ac.uk in
pub/vr

-- 
Dave Snowdon
Department of Computer Science   Tel:    (UK) 061 275 5717
Manchester University            E-mail: snowdond@cs.man.ac.uk
M13 9PL U.K.                          or snowdond@uk.ac.man.cs

  The Devil may care... But I don't mind (T.S.o.M.)