Mantis - Croquet
Viewing Issue Advanced Details
865 Any minor always 02-07-05 12:41 02-15-05 21:37
grit  
 
normal  
feedback  
open  
none    
none  
0000865: Pointer points at wrong object when using several instances of one geometry
I reuse a geometry in my croquet world, so I have several instances of it there. The pointer always points at the last created one, no matter at which of them I point. This bug only effects the visualization of the pointer ray. The event handling works fine. :)

Notes
(0001152)
dfaught   
02-15-05 15:06   
Maybe we could see an example of your code? This is done in other places without any problem, such as the ODE demos.
(0001153)
grit   
02-15-05 16:20   
In the >>initializeDefaultSpace method I call two methods to create two new spaces, where I do basically the same thing:

...
    thereDoor := TDoorMT new.
    thereDoor translationX: 5.0 y: -4.0 z: 5.0.
    sp addChild: thereDoor.

    hereDoor := TDoorMT new.
    hereDoor portal rotationAroundY: 180.
    hereDoor translationX: 0 y: 1.0 z: 40.0.
    sp2 addChild: hereDoor.

    thereDoor linkDoor: hereDoor.
...

where sp is the default space and sp2 is the space behind the portal. #TDoorMT is a subclass of TGroup that has a portal that is a #TPortal and consists of some geometry (doorFrame and doorBlatt). >>linkDoor: links the portals of two TDoorMT instances.

I paste the #TDoorMT>>initialize method here. Maybe the crux is somewhere in there?:

initialize
    | doorBlattMesh |
    super initialize.
    doorBlattRotation _ 0.0.
    openClose _ -1.
    doorFrame _ CroquetGlobals theTeapotMorph loadURL: 'http://www.reed.com/TeaLand/content/magrathea/rahmen.tea'. [^]
    doorFrame
        ifNil: [doorFrame _ (TLoad3DSMax new
                        initializeWithFileName: (FileDirectory pathFrom: {FileDirectory default pathName. 'Content'. 'magrathea'. 'rahmen.ASE'})
                        scale: 0.1) frame.
            doorFrame boundsDepth: 2.
            doorFrame initBounds.
            TExporter export: doorFrame asBinary: 'http://www.reed.com/TeaLand/content/magrathea/rahmen.tea']. [^]
    doorFrame objectOwner: nil.
    self addChild: doorFrame.
    doorBlatt _ TGroup new.
    doorBlattMesh _ CroquetGlobals theTeapotMorph loadURL: 'http://www.reed.com/TeaLand/content/magrathea/tuer.tea'. [^]
    doorBlattMesh
        ifNil: [doorBlattMesh _ (TLoad3DSMax new
                        initializeWithFileName: (FileDirectory pathFrom: {FileDirectory default pathName. 'Content'. 'magrathea'. 'tuer.ASE'})
                        scale: 0.1) frame.
            "doorBlattMesh rotationAroundY:180."
            doorBlattMesh boundsDepth: 2.
            doorBlattMesh initBounds.
            TExporter export: doorBlattMesh asBinary: 'http://www.reed.com/TeaLand/content/magrathea/tuer.tea']. [^]
    doorBlattMesh
        translationX: 0.0
        y: 0.0
        z: 0.0.
    doorBlatt addChild: doorBlattMesh.
    doorBlatt objectOwner: nil.
    doorBlatt
        translationX: 2.1
        y: 4.0
        z: 0.27.
    self addChild: doorBlatt.
    portal _ TPortal new.
    portal extent: doorFrame boundingBox extent x @ doorFrame boundingBox extent y.
    portal
        translationX: 0
        y: 4.2
        z: 0.2.
    portal visible: false.
    self addChild: portal.
    self initBounds


If I point and click on one of the two doors that exist in default space, it opens and closes as it is intended to, just the pointer ray looks as if I always would point on the door last created, no matter on which one I'm pointing.

Here is the event handling method of #TDoorMT. I can't imagine that the problem lies there, though:

pointerDown: pointer
    self changeOpenClose.
    doorBlattRotation _ doorBlattRotation + (5.0 * openClose).
    self swing.
    self swingOtherDoor.
    ^ true

>>swing and >>swingOtherDoor just rotates the geometry of the door and of the linked door behind the portal in the other space. As said, that works fine.

Any ideas????
(0001154)
grit   
02-15-05 18:24   
I have built a rather simple example that shows how the pointer ray really points in a wrong way if you have several objects that share the same geometry.
Just start a Teapot using the following initializing method:

initializeDefaultSpace
    | space cube cube1 cube2 |
    space _ TSpace new.
    space addChild: TLight new.

    cube _ TCube new.
    cube objectOwner: nil.

    cube1 := TGroup new.
    cube1 addChild: cube.
    cube1 startScript: [1 to: -1 by: -0.125 do: [:i| cube1 jump: i; waitTick]] when: #pointerDown.
    space addChild: cube1.

    cube2 := TGroup new.
    cube2 addChild: cube.
    cube2 translationX: 4 y: 0 z: 0.
    cube2 startScript: [1 to: -1 by: -0.125 do: [:i| cube2 jump: i; waitTick]] when: #pointerDown.
    space addChild: cube2.



    ^space
(0001155)
dfaught   
02-15-05 20:44   
I am not the expert here, but my take on this (referring to the last simple example you provided) is that you have only defined one visible object, the "cube" TCube instance. The fact that you are defining two TGroup instances to contain it and making them appear in the space basically just gives you two views of the same object. Why not just have two TCube instances? Usually TGroups are used to contain, well, groups of objects, like several TCube instances that make up a set of stairs, so that they can be moved around or manipulated in space together.
(0001156)
Croqueteer   
02-15-05 21:37   
FYI - Support for "instancing" - that is, having a single TFrame instanced in multiple places at a time may go away in the future. We may replace this with an architecture that breaks the TFrame hierarchical part of the object from the actual rendered object.