[Ves] Extending the App

[Eduardo Poyart]

Perfect! Thanks.

(cc list, since I forgot to reply-all).

On Mon, Feb 18, 2013 at 9:35 PM, Pat Marion <pat.marion at kitware.com> wrote:
> No, it's correct.  Calling rep->actor() returns a copy of the shared ptr, so
> rep->actor()->use_count() will declare 1 more than actor->useCount().
>
> Pat
>
>
> On Tue, Feb 19, 2013 at 3:29 PM, Eduardo Poyart <poyart at gmail.com> wrote:
>>
>> Thanks! It was indeed the lack of #include "vesActor.h". That line
>> compiles now.
>>
>> I'm doing use_count tests and something seems strange. Here is the code:
>>
>>         int i1 = rep->actor().use_count();
>>         vesSharedPtr<vesNode> actor = rep->actor();
>>         int i2 = rep->actor().use_count();
>>         int i3 = actor.use_count();
>>         transform->addChild(actor);
>>
>> I get i1 = 2, i2 = 3 and i3 = 2.
>>
>> Shouldn't i3 be 3?
>>
>> Just trying to make sure I won't get a leak or premature deallocation.
>>
>> Cheers
>> Eduardo
>>
>> On Mon, Feb 18, 2013 at 9:18 PM, Pat Marion <pat.marion at kitware.com>
>> wrote:
>> > 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
>> >> >>>>
>> >> >>>
>> >> >>
>> >> >
>> >
>> >
>
>