[Ves] Extending the App

Eduardo Poyart poyart at gmail.com
Mon Feb 18 21:14:04 EST 2013


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/20130218/08682185/attachment-0001.html>


More information about the Ves mailing list