[IGSTK-Developers] CylinderSpatialObjectRepresentation

[Julien Jomier]

Luis,

I would not say that. What we are enforcing here is consistency between 
tools/objects in IGSTK.
I've used a CylinderSpatialObject as a tracked needle as it was before 
without any issues.

Would it be nice if IGSTK users can only change one line of code to 
track an UltrasoundProbe instead of a needle? This will only be the case 
if the orientation of the objects are the same.

my two cents,

Julien

Luis Ibanez wrote:
> 
> 
> It is a matter of concern that the CylinderSpatialObjectRepresentation
> is being customized for satisfying a very specific use, namely:
> 
> 
>             "To make it look like a pointer in a scene"
> 
> 
> This is a missuse of a generic geometrical class, and a poor approach
> for a toolkit based on Object Oriented Programming.
> 
> 
> 
> If we need a "ScenePointer" object, we should introduce a specific class
> such as:
> 
>                     "ScenePointerSpatialObject"
> 
> 
> then customize it with properties (e.g. Transforms) such as having
> the axis to be parallel to Z, and the end to be in the point (0,0,0).
> 
> 
> 
>      IGSTK Classes should map straight to well defined concepts.
> 
> 
> 
> We already discussed this issue with regard to the NeedleSpatialObject,
> and it seems that now we are proceeding backwards.
> 
> 
> 
>     Luis
> 
> 
> 
> -------------------
> Julien Jomier wrote:
> 
>> Patrick,
>>
>>  > I guess David meant the Pointer is pointing towards the -Z direction.
>>  > But anyway, only when I remove the '-' sign, that the cylinderObject
>>  > will be on the right side.
>>
>> No the pointer is pointing towards the Z direction. This shouldn't 
>> matter, you should be able to set the CalibrationTransform to satisfy 
>> your needs. To me your registration should only try to optimize the 
>> PatientTransform and you should set the CalibrationTransform so that 
>> it's inline with your tracker.
>>
>> 1. The CylinderSpatialObject is mainly a data container when we talk 
>> about tracking because the Tracker will modify its transform directly.
>> It is not true that it is only when we visualize that the orientation 
>> is correct. The orientation is correct when we track the object 
>> because the tracker will place the object in the real-world 
>> coordinates correctly.
>>
>> 2. To me the real principal axis is Z for now and then. The tracker 
>> (i.e the CalibrationTransform and the PatientTransform) should take 
>> care placing the object in the correct position/orientation.
>>
>> 3. I don't think we have to.
>>
>> Hope that makes sense,
>>
>> Julien
>>
>>
>> Patrick Cheng wrote:
>>
>>> I guess David meant the Pointer is pointing towards the -Z direction.
>>> But anyway, only when I remove the '-' sign, that the cylinderObject 
>>> will be on the right side.
>>>
>>> The PrincipalAxisCalibration is taking the known principal axis of 
>>> the Spatial Object(cylinder) and Tracker Tool(pointer) in their own 
>>> coordinate system. eg. By default, the cylinder is along it's Y axis, 
>>> and pointer is along its Z axis. The PrincipalAxisCalibration then 
>>> take the two principal axis, and figure out what rotation we need to 
>>> take to align the cylinder with the pointer (in another word, 
>>> transform the cylinder's coordinate system to the pointer's 
>>> coordinate system).
>>>
>>> Julien, I have questions about your approach (add an transform to actor)
>>>
>>> 1. The final CylinderSpatialObject is actually not carrying the 
>>> correct transform. Only when we visualize it, we add another 
>>> transform to make the actor look right. I believe we should have the 
>>> CylinderSpatialObject transform right instead of altering the actor's 
>>> transform. suppose we need to do path planing or collision detection, 
>>> we are working with the SpatialObject's transform, not the actor's 
>>> transform.
>>>
>>> 2. This will conflict with the PrincipalAxisCalibration, as people 
>>> get confused what is the real principal axis is. Here the principal 
>>> axis for the cylinder is still Y, and Pointer is Z. But since we are 
>>> going to have a rotation when we visualize it, we don't need the 
>>> PrincipalAxisCalibration here.
>>>
>>> 3. maybe we can move the rotation and shift of origin in the 
>>> CylinderSpatialObject class.
>>>
>>> Patrick
>>>
>>> Julien Jomier wrote:
>>>
>>>> Hi Patrick,
>>>>
>>>> David told me that the cylinder should be located in the [-Z,0], 
>>>> therefore the cylinder should be translated by 
>>>> -m_CylinderSpatialObject->GetHeight()/2.0
>>>>
>>>>  > One quick question: If we can just change the transform when we 
>>>> create
>>>>  > the actor, what do we need the PrincipalAxisCalibration for?
>>>>
>>>> I don't know what the PrincipalAxisCalibration class is actually 
>>>> doing, but the user cannot change the actor, so we need a way to 
>>>> calibrate the tool anyway.
>>>>
>>>> Julien
>>>>
>>>> Patrick Cheng wrote:
>>>>
>>>>> Hi Julien,
>>>>>
>>>>> I checked out your recent change in the 
>>>>> CylinderSpatialObjectRepresentation class. Now without setting the 
>>>>> rotation part of the CalibrationTransform, the orientation of the 
>>>>> CylinderObject will be correct, but with one little bug, in line 
>>>>> 152 (igstkCylinderObjectRepresentation.cxx)
>>>>> cylinderActor->SetPosition(0,0,-m_CylinderSpatialObject->GetHeight()/2.0); 
>>>>>
>>>>> There should be no '-' sign. I tested it in the application.
>>>>>
>>>>> One quick question: If we can just change the transform when we 
>>>>> create the actor, what do we need the PrincipalAxisCalibration for?
>>>>>
>>>>> Patrick
>>>>>
>>>>
>>>>
>>>
>>>
>> _______________________________________________
>> IGSTK-Developers mailing list
>> IGSTK-Developers at public.kitware.com
>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>
>>
> 
> 
>