[Ves] Extending the App

[Eduardo Poyart]

Pat,

Thank you for the quick reply. Indeed it was not a const problem, it
was a problem with the types wrapped in shared pointers. I managed to
find a way to coerce the types. This is my old code:

        vesSharedPtr<vesActor> actor = vesSharedPtr<vesActor>(rep->actor());
        transform->addChild(actor);

The compiler fails with the following error: "cannot initialize a
member subobject of type 'vesNode *' with an lvalue of type 'vesActor
*const'".

I changed it to:

        vesSharedPtr<vesNode> actor =
vesSharedPtr<vesNode>((vesNode*)rep->actor().get());
        transform->addChild(actor);

This compiles fine. Hopefully I'm not leaking memory or anything! :)

Thanks
Eduardo



On Mon, Feb 18, 2013 at 7:13 PM, Pat Marion <pat.marion at kitware.com> wrote:
> Hi,
>
> Hmm, are you sure about that?  The get actor method on
> vesKiwiPolyDataRepresentation should look like this:
>
>   vesSharedPtr<vesActor> actor() const;
>
> So the returned pointer is not const.  Did you mean the sceneRoot() method
> on vesRenderer?
>
> The reason for the code comment you saw, it's actually an old comment, at
> the time the VES api was being heavily refactored, so client code that used
> the ves objects would break, the kiwi class attempts to be a convenience
> layer that would sheild client code from the api changes.  At this point the
> VES api has stabilized, so I no longer have plans to move those methods to
> be protected.
>
> Pat
>
>
>
> On Tue, Feb 19, 2013 at 12:14 PM, Eduardo Poyart <poyart at gmail.com> wrote:
>>
>> Hi Pat,
>>
>> Answering your question about my ImageWidgetRepresentation, I have
>> modified vesKiwiImageWidgetRepresentation to apply a few filters to the
>> dataset, and to change the contour level set value in real time.
>>
>> Now that I have a more well-defined ImageWidgetRepresentation, I have
>> another question.
>>
>> I'm modifying the sample to show two models, with independent translations
>> and rotations. The ideal solution is to add a vesTransformNode to the root
>> node, instead of adding the actors directly to root. It would be great to
>> use this sene-graph convenience.
>>
>> However, the actual adding to root is done in vesRenderer::addActor. So
>> instead I thought I could get the root node with vesRenderer::sceneRoot()
>> and add the actors. The problem is that, from vesKiwiPolyDataRepresentation,
>> I can only get a const actor. Furthermore, to my dismay, there is a comment
>> in vesKiwiPolyDataRepresentation saying that actor() will be moved to
>> protected in the future, therefore making this class even more inflexible.
>>
>> It's not a clean solution to use the Actor's built-in transformation. One
>> vesKiwiWidgetRepresentation contains multiple internal representations
>> (image planes, contour, frame). So, I would have to create loops to set the
>> same transform to the various actors.
>>
>> On the other hand, if I subclass vesKiwiPolyDataRepresentation, I can't
>> access Actor since it's in the Internal section. Entirely copying the
>> vesKiwiPolyDataRepresentation and modifying it would be even more
>> undesirable.
>>
>> If you have any solution, I would appreciate the suggestion. For now, I
>> think I'll end up manually setting up all of the Actor's transformations. I
>> hope my use-case explanation is useful for further development of ves!
>>
>> Thanks
>> Eduardo
>>
>>
>> On Tue, Feb 12, 2013 at 7:57 PM, Pat Marion <pat.marion at kitware.com>
>> wrote:
>>>
>>> Hi Eduardo,
>>>
>>> You're correct that the vesKiwiViewerApp api is insufficient.  There's a
>>> branch called kiwi-update which has a new version of the code which adds
>>> methods to access the internal representations, and add new ones to the
>>> list.  You could use this branch, or modify your copy of vesKiwiViewerApp.
>>> The kiwi-update branch has a lot of changes to it though, so if don't want
>>> the disruption then I would recommend you just modify vesKiwiViewerApp to
>>> add accessors to the internal representations vector.
>>>
>>> But, you might be interested in some of the changes, there are new
>>> features to the existing image widget class
>>> vesKiwiImageWidgetRepresentation.  I'd be interested to hear from you if you
>>> want to share what you are doing with your ImageWidgetRepresentation class,
>>> and if you have any suggestions for improvements to the
>>> vesKiwiWidgetRepresentation base class.  Thanks!
>>>
>>> Pat
>>>
>>> On Wed, Feb 13, 2013 at 9:43 AM, Eduardo Poyart <poyart at gmail.com> wrote:
>>>>
>>>> Hello,
>>>>
>>>> I extended vesKiwiViewerApp with my own subclass ViewerApp. I also
>>>> needed to create a new representation, which I called
>>>> ImageWidgetRepresentation, extending from vesKiwiWidgetRepresentation.
>>>>
>>>> I wrote a custom load routine in ViewerApp, and now I need to add the
>>>> data to Internal, with something like:
>>>>
>>>> this->Internal->DataRepresentations.push_back(rep);
>>>>
>>>> However this can't be done since vesKiwiViewerApp.Internal is private.
>>>> What is the correct design pattern in this case?
>>>>
>>>> Thanks
>>>> Eduardo
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Ves mailing list
>>>> Ves at public.kitware.com
>>>> http://public.kitware.com/cgi-bin/mailman/listinfo/ves
>>>>
>>>
>>
>