View Issue Details [ Jump to Notes ] | [ Print ] | ||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||
0003312 | VTK | (No Category) | public | 2006-06-02 08:52 | 2016-08-12 09:54 | ||||
Reporter | Dave Slack | ||||||||
Assigned To | Will Schroeder | ||||||||
Priority | low | Severity | minor | Reproducibility | always | ||||
Status | closed | Resolution | moved | ||||||
Platform | OS | OS Version | |||||||
Product Version | |||||||||
Target Version | Fixed in Version | ||||||||
Summary | 0003312: nested vtkAssembly visibility error | ||||||||
Description | I 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. | ||||||||
Tags | No tags attached. | ||||||||
Project | |||||||||
Type | |||||||||
Attached Files | dif [^] (2,986 bytes) 1969-12-31 19:00 [Show Content]
vtkAssemblyPath.cxx.patch [^] (814 bytes) 1969-12-31 19:00 [Show Content] vtkAssemblyPath.h.patch [^] (838 bytes) 1969-12-31 19:00 [Show Content] vtkPropAssembly.cxx.patch [^] (1,104 bytes) 1969-12-31 19:00 [Show Content] vtkAssembly.cxx.patch [^] (1,131 bytes) 1969-12-31 19:00 [Show Content] proposal_v0.0_vtkAssembly.cxx.patch [^] (1,322 bytes) 1969-12-31 19:00 [Show Content] proposal_v0.0_vtkPropAssembly.cxx.patch [^] (1,527 bytes) 1969-12-31 19:00 [Show Content] | ||||||||
Relationships | |
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. |
Notes |
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 |
Issue History |
Copyright © 2000 - 2018 MantisBT Team |