View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0003312VTK(No Category)public2006-06-02 08:522016-08-12 09:54
ReporterDave Slack 
Assigned ToWill Schroeder 
PrioritylowSeverityminorReproducibilityalways
StatusclosedResolutionmoved 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0003312: nested vtkAssembly visibility error
DescriptionI am using nested vtkAssembly's and am curious about the intended functionality of the Visibility. It's my understanding that if you have nested vtkAssembly's and you turn off the visibility of one of the vtkAssembly's somewhere in the heirarchy, that every vtkAssembly and prop that is a child of that vtkAssembly should not be visible. That, I have found, is not the functionality of the current cvs code (or at least the one I checked out a couple weeks ago). The functionality that I am seeing is that if you turn off the top vtkAssembly or the bottom viewProp, then the bottom viewProp becomes invisible. Turning off any intermediate vtkAssembly has no effect whatsoever on the bottom viewProp.

I have "fixed" this two different ways. The first was to add code to vtkAssembly::RenderOpaqueGeometry & vtkAssembly::RenderTranslucentGeometry
to loop over all the nodes paths in order to check visibility.

The second way I tried for fixing this was to put a check for visibility in the vtkAssembly::BuildPaths
so that it stop added props along a path as soon as one of the nodes was invisible. I wasn't sure if this impacted other code in a negative way, however.

I'm attach a cvs dif -u file that has both cvs dif call done separately but concatenated into one file.
TagsNo tags attached.
Project
Type
Attached Files? file icon dif [^] (2,986 bytes) 1969-12-31 19:00 [Show Content]
patch file icon vtkAssemblyPath.cxx.patch [^] (814 bytes) 1969-12-31 19:00 [Show Content]
patch file icon vtkAssemblyPath.h.patch [^] (838 bytes) 1969-12-31 19:00 [Show Content]
patch file icon vtkPropAssembly.cxx.patch [^] (1,104 bytes) 1969-12-31 19:00 [Show Content]
patch file icon vtkAssembly.cxx.patch [^] (1,131 bytes) 1969-12-31 19:00 [Show Content]
patch file icon proposal_v0.0_vtkAssembly.cxx.patch [^] (1,322 bytes) 1969-12-31 19:00 [Show Content]
patch file icon proposal_v0.0_vtkPropAssembly.cxx.patch [^] (1,527 bytes) 1969-12-31 19:00 [Show Content]

 Relationships

  Notes
(0004620)
Cory Quammen (reporter)
2006-08-03 16:02

I have another set of patches that will also set make sure that setting a parent assembly to invisible will make its children invisible. I've added a method to vtkAssemblyPath that checks to see if any node along the path is invisible. If it is, then the final node should not be rendered. This method is then called from vtkAssembly->RenderTranslucentGeometry() and vtkAssembly->RenderOpaqueGeometry() when deciding whether to draw a leaf instead of the current behavior, which checks to see if the leaf is visible. (It is also called within vtkPropAssembly->RenderTranslucentGeometry() and vtkPropAssembly->RenderOpaqueGeometry()).

I have attached four patches to enact these changes.
(0005961)
Heath Davis (reporter)
2006-12-12 20:30

The previous posts rely on changing the API to vtkAssemblyPath. This post should fix the problem with no API change.

I propose to change UpdatePaths and BuildPaths in the files vtkAssembly.cxx and vtkPropAssembly.cxx. Possibly unnecessary is the change from UpdatePaths calls to stronger InitPathTraversal calls in the Rendering functions.

The changes to lines 313 and 346 of vtkPropAssembly.cxx are part of the changes in bug#3688.

This change appears to treat visibility in a truly hierarchical fashion (subnodes need not set visibility to 0 when a parent is set to 0).

The files related to this post begin with: "proposal_v0.0_".
(0006582)
Bill McGrory (reporter)
2007-02-28 10:20

I believe that there is a bug in the patch submitted by
r_davis

in vtkPropAssembly.cxx the patch for changing lines 346c352,354 should read
path->AddNode(prop,prop->GetMatrix());

not this->GetMatrix()

to be consistent with the patch in bug 0003688
(0036873)
Kitware Robot (administrator)
2016-08-12 09:54

Resolving issue as `moved`.

This issue tracker is no longer used. Further discussion of this issue may take place in the current VTK Issues page linked in the banner at the top of this page.

 Issue History
Date Modified Username Field Change
2008-02-06 10:13 Jeff Baumes Assigned To Mathieu Malaterre => Will Schroeder
2008-02-06 10:13 Jeff Baumes Severity major => minor
2011-06-16 13:11 Zack Galbreath Category => (No Category)
2016-08-12 09:54 Kitware Robot Note Added: 0036873
2016-08-12 09:54 Kitware Robot Status expired => closed
2016-08-12 09:54 Kitware Robot Resolution open => moved


Copyright © 2000 - 2018 MantisBT Team