[Ves] Extending the App

[Pat Marion]

You should be able to do the conversion without casting.  Perhaps you are
missing an #include <vesActor.h> so that the compiler knows vesActor is a
subclass of vesNode? This line should compile:

vesSharedPtr<vesNode> node = rep->actor();

Also, if you do need to cast, for example to go from vesNode down to
vesActor, this is the proper way to do it:

vesSharedPtr<vesActor> actor =
std::tr1::dynamic_pointer_cast<vesActor>(node);

(or use static_pointer_cast if you prefer)

Also, note that vesNode::Ptr is equivalent to vesSharedPtr<vesNode> and it
can save you some extra characters :)

Pat

On Tue, Feb 19, 2013 at 3:05 PM, Eduardo Poyart <poyart at gmail.com> wrote:

> 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
> >>>>
> >>>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ves/attachments/20130219/dabda659/attachment-0001.html>