[Ves] Extending the App

[Aashish Chaudhary]

On Tue, Feb 19, 2013 at 12:40 AM, Eduardo Poyart <poyart at gmail.com> wrote:
> Perfect! Thanks.

Since STL shared pts stores the count outside the actual object you
get different values if it would have been ref counted then you would
have got 3 in both of these cases.

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
>>> >> >>>>
>>> >> >>>
>>> >> >>
>>> >> >
>>> >
>>> >
>>
>>
> _______________________________________________
> Ves mailing list
> Ves at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/ves



-- 
| Aashish Chaudhary
| R&D Engineer
| Kitware Inc.
| www.kitware.com