Notes |
|
(0029283)
|
Utkarsh Ayachit
|
2012-09-25 14:00
|
|
Note for developer: the bug is that the Image data delivered to the client side by the "Slice" representation doesn't have the right origin. Hence it's placed on (0, 0, 0), rather than (-1.75, -1.25, 0) which is where the CubeAxes shows up. Thus, the bug is in the data delivery mechanism for Slice representation and not in the CubeAxes itself.
Also, note this only happens when local-rendering. When remote rendering, we're okay -- which validates the above theory. |
|
|
(0029315)
|
Utkarsh Ayachit
|
2012-10-03 16:04
|
|
commit 1af36b2078eb6f881c006d31a4ef0c94dae2e0b0
Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Date: Wed Oct 3 16:00:46 2012 -0400
BUG 0013469. Fixed image data delivery code.
vtkMPIMoveData was not passing along Origin information for vtkImageData due to
typo. As a result the image ended up at wrong locations on the client. Fixed
that. This fixes the bug seen with cube axes for BUG 0013469. |
|
|
(0029333)
|
Utkarsh Ayachit
|
2012-10-05 10:13
|
|
merged into master, if applicable. |
|
|
(0029354)
|
Alan Scott
|
2012-10-10 17:26
|
|
The location of the mandlebrot is now correct, but the text for the cube axis no longer draws correctly. Utkarsh replicated this. It occurs remote rendering, remote server (possibly multiple servers). Just follow directions in the main bug. I will attach a screenshot. |
|
|
(0029432)
|
Utkarsh Ayachit
|
2012-10-18 23:27
|
|
commit 33d4d818e62febb3712e018da749229b02d3bc5e
Author: Utkarsh Ayachit <utkarsh.ayachit@kitware.com>
Date: Thu Oct 18 23:23:52 2012 -0400
Fixed BUG 0013469. Fix clipping of cube-axes when parallel rendering.
Cube-axes labels were getting clipped with parallel rendering was used. This was
because the CubeAxes would only report its data bounds to the renderer and not
the actually rendered bounds. vtkIceTCompositePass uses those bounds to decide
what pixels need to be composited and that was resulting in the labels being
ditched. Fixed that by using a heuristic to scale the bounds reported by
CubeAxes. Since it has no rendering side-effects besides a few extra pixels
being composited, we opt for this heuristic based approach rather than anything
more concrete.
Change-Id: I41ee70919349a15f08ef14a40d6073bc9f64168c |
|
|
(0029471)
|
Utkarsh Ayachit
|
2012-10-22 10:51
|
|
merged into master, if applicable. |
|
|
(0029478)
|
Alan Scott
|
2012-10-22 17:28
|
|
Much closer, but still wrong. Try the following, multiple remote server (probably just remote server):
* Sources/Mandelbrot.
* Turn on Cube Axis Visibility.
* Click 2d (top left of the view), making this a 3 view
* Rotate object slightly.
<< bug >> You will see the cube axis come and go.
* -Z
<< bug >> Cube axis is gone.
* Click 3d, making this a 2d view.
<< bug >> Cube axis is gone.
|
|
|
(0029599)
|
Sebastien Jourdain
|
2012-10-30 13:27
|
|
commit 907a59e775a94c951c38785821167009ab440cfc
Author: Sebastien Jourdain <sebastien.jourdain@kitware.com>
Date: Tue Oct 30 08:55:54 2012 -0400
Make sure axis label are shown when looking at a 2D plane in 3D
Change-Id: Ie5e06e4f190ff5a354d863d1defd2b821059d04d
diff --git a/Rendering/Annotation/vtkAxisFollower.cxx b/Rendering/Annotation/vtkAxisFollower.cxx
index b7ac822..9fdd53a 100644
--- a/Rendering/Annotation/vtkAxisFollower.cxx
+++ b/Rendering/Annotation/vtkAxisFollower.cxx
@@ -16,6 +16,7 @@
#include "vtkAxisFollower.h"
#include "vtkAxisActor.h"
+#include "vtkBoundingBox.h"
#include "vtkCamera.h"
#include "vtkCoordinate.h"
#include "vtkMath.h"
@@ -444,6 +445,12 @@ int vtkAxisFollower::TestDistanceVisibility()
if(dist > maxVisibleDistanceFromCamera)
{
+ // Need to make sure we are not looking at a flat axis and therefore should enable it anyway
+ if(this->Axis)
+ {
+ vtkBoundingBox bbox(this->Axis->GetBounds());
+ return (bbox.GetDiagonalLength() > (cameraClippingRange[1] - cameraClippingRange[0])) ? 1 : 0;
+ }
return 0;
}
else |
|
|
(0029601)
|
Sebastien Jourdain
|
2012-10-30 13:42
|
|
This issue was related to CubeAxes behavior that disable labels that are on the 20% of the back of the clipped plane range.
In case of flat surface, when that surface was normal to the camera, almost all the geometry were inside that 20% end of the clipped range. Therefore, if the clipped range is pretty small (looking at something flat) compared to the size of the data length, we don't disable any label. |
|
|
(0029615)
|
Utkarsh Ayachit
|
2012-10-31 10:47
|
|
merged into master, if applicable. |
|
|
(0029635)
|
Alan Scott
|
2012-10-31 20:06
|
|
I am pretty sure this is correct. I am seeing some funkyness when you are looking down the plane, but that somewhat makes sense - the characters of the numbers and text are edge on and probably shouldn't draw.
Tested remote server, Linux, master. |
|