(0015250)
Ken Moreland (manager)
2009-02-20 10:13

Does it make sense to have blocks selected before sets instead of them? In that case, if they are both there the blocks get selected and if only the set is there then that gets selected.

Implementation-wise, that basically reverses the order in which blocks are picked during a selection.

(0023325)
Ken Moreland (manager)
2010-11-16 23:58

To elaborate a bit (now that I am reminded of the bug as it is assigned), the issue is that ParaView makes no distinctions between blocks and side sets. Both Exodus II entities are represented as blocks in a vtkMultiBlockDataSet.

I am highly skeptical that there is no use case for not selected a side set (as a block). I am even skeptical that there is any real confusion about invoking "select block" and having a side set selected. I believe the real issue is that this is a special case of blocks with coincident geometry.

In general, this is a rare (and usually anomalous) condition, but it happens to be common between Exodus II block and side sets. In this one case, it would be nice if blocks took precedence over side sets. Since blocks are listed first in the multiblock data set, if you could prefer those blocks listed first if there are coincident blocks would be sufficient to resolve the problem.

If this fix is not easy (for example, if you are at the mercy of how rendering hardware creates a pick render), I contend that this bug is unimportant (or at least less important than the damage that a "fix" might cause). Alan may have a different opinion.

(0023349)
Alan Scott (manager)
2010-11-17 11:21

I think I agree with Ken. Unless Utkarsh thinks otherwise, please mark this bug as resolved.

(0023350)
Utkarsh Ayachit (administrator)
2010-11-17 11:24

As Ken said, that's indeed the case. We are at the mercy of the rendering hardware as to which block ends up are being selected when we have coincident polygons. And since Alan agrees, I am marking this resolved.

(0023509)
Alan Scott (manager)
2010-11-22 22:16

Closed, as per Ken, Utkarsh, Dave, and Alan. :-)

Issue History
Date Modified	Username	Field	Change
2009-02-19 18:51	Alan Scott	New Issue
2009-02-20 10:13	Ken Moreland	Note Added: 0015250
2009-05-13 13:40	Utkarsh Ayachit	Target Version	=> 3.8
2010-11-16 09:53	David Partyka	Assigned To	=> David Partyka
2010-11-16 09:53	David Partyka	Status	backlog => tabled
2010-11-16 23:58	Ken Moreland	Note Added: 0023325
2010-11-17 11:21	Alan Scott	Note Added: 0023349
2010-11-17 11:24	Utkarsh Ayachit	Note Added: 0023350
2010-11-17 11:25	Utkarsh Ayachit	Status	tabled => @80@
2010-11-17 11:25	Utkarsh Ayachit	Resolution	open => won't fix
2010-11-22 22:16	Alan Scott	Note Added: 0023509
2010-11-22 22:16	Alan Scott	Status	@80@ => closed
2011-06-16 13:10	Zack Galbreath	Category	=> (No Category)

Notes
(0015250) Ken Moreland (manager) 2009-02-20 10:13	Does it make sense to have blocks selected before sets instead of them? In that case, if they are both there the blocks get selected and if only the set is there then that gets selected. Implementation-wise, that basically reverses the order in which blocks are picked during a selection.

(0023325) Ken Moreland (manager) 2010-11-16 23:58	To elaborate a bit (now that I am reminded of the bug as it is assigned), the issue is that ParaView makes no distinctions between blocks and side sets. Both Exodus II entities are represented as blocks in a vtkMultiBlockDataSet. I am highly skeptical that there is no use case for not selected a side set (as a block). I am even skeptical that there is any real confusion about invoking "select block" and having a side set selected. I believe the real issue is that this is a special case of blocks with coincident geometry. In general, this is a rare (and usually anomalous) condition, but it happens to be common between Exodus II block and side sets. In this one case, it would be nice if blocks took precedence over side sets. Since blocks are listed first in the multiblock data set, if you could prefer those blocks listed first if there are coincident blocks would be sufficient to resolve the problem. If this fix is not easy (for example, if you are at the mercy of how rendering hardware creates a pick render), I contend that this bug is unimportant (or at least less important than the damage that a "fix" might cause). Alan may have a different opinion.

(0023349) Alan Scott (manager) 2010-11-17 11:21	I think I agree with Ken. Unless Utkarsh thinks otherwise, please mark this bug as resolved.

(0023350) Utkarsh Ayachit (administrator) 2010-11-17 11:24	As Ken said, that's indeed the case. We are at the mercy of the rendering hardware as to which block ends up are being selected when we have coincident polygons. And since Alan agrees, I am marking this resolved.

(0023509) Alan Scott (manager) 2010-11-22 22:16	Closed, as per Ken, Utkarsh, Dave, and Alan. :-)

Relationships