Hi,<br><br>Hmm, are you sure about that? The get actor method on vesKiwiPolyDataRepresentation should look like this:<br><br> vesSharedPtr<vesActor> actor() const;<br><br>So the returned pointer is not const. Did you mean the sceneRoot() method on vesRenderer?<br>
<br>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.<br>
<br>Pat<br><br><br><div class="gmail_quote">On Tue, Feb 19, 2013 at 12:14 PM, Eduardo Poyart <span dir="ltr"><<a href="mailto:poyart@gmail.com" target="_blank">poyart@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hi Pat,<div><br></div><div>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.</div>
<div><br></div><div>Now that I have a more well-defined ImageWidgetRepresentation, I have another question.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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!</div>
<div><br></div><div>Thanks</div><span class="HOEnZb"><font color="#888888"><div>Eduardo</div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Feb 12, 2013 at 7:57 PM, Pat Marion <span dir="ltr"><<a href="mailto:pat.marion@kitware.com" target="_blank">pat.marion@kitware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Eduardo,<br><br>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.<br>
<br>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!<br>
<br>Pat<br><br><div class="gmail_quote"><div><div>On Wed, Feb 13, 2013 at 9:43 AM, Eduardo Poyart <span dir="ltr"><<a href="mailto:poyart@gmail.com" target="_blank">poyart@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>
<div dir="ltr">Hello,<div><br></div><div>I extended vesKiwiViewerApp with my own subclass ViewerApp. I also needed to create a new representation, which I called ImageWidgetRepresentation, extending from vesKiwiWidgetRepresentation.</div>
<div><br></div><div>I wrote a custom load routine in ViewerApp, and now I need to add the data to Internal, with something like:</div><div><br></div>
<div><span>this</span>->Internal->DataRepresentations.push_back(rep);</div><div><br></div><div>However this can't be done since vesKiwiViewerApp.Internal is private. What is the correct design pattern in this case?</div>
<div><br></div><div>Thanks</div><span><font color="#888888"><div>Eduardo</div><div><br></div><div><br></div><div><br></div></font></span></div>
<br></div></div>_______________________________________________<br>
Ves mailing list<br>
<a href="mailto:Ves@public.kitware.com" target="_blank">Ves@public.kitware.com</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/ves" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/ves</a><br>
<br></blockquote></div><br>
</blockquote></div><br></div>
</div></div></blockquote></div><br>