[Ves] Extending the App
Pat Marion
pat.marion at kitware.com
Mon Feb 18 22:13:34 EST 2013
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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ves/attachments/20130219/e7b8f34e/attachment-0001.html>
More information about the Ves
mailing list