(0028677)
Lawrence (reporter)
2012-06-07 17:15
edited on: 2012-06-07 17:47

This may also be a solution to
http://paraview.org/Bug/view.php?id=12615 [^]

I'd be very happy to see this bug fix in. Axes on an object should represent the underlying space of the object; not any display scaling. I'd prefer that the default is disruptive; as it is almostly always correct.

So far Paraview does not handle asymmetric scaling of objects well (many of the widgets do not display correctly). This would be a step in the right direction.

(0028720)
Cory Quammen (developer)
2012-06-25 13:36

I would like to add my voice to support this feature. I have users in high-energy particle physics who really want to scale one axis and have the axis labels reflect the original coordinates.

(0028745)
Lawrence (reporter)
2012-07-05 17:02

The suggested solution is incomplete (e.g. if the object is rotated and scaled). Also, there seem to be some issues when the Z scale is set back to one. I'll investigate this further.

(0028765)
Lawrence (reporter)
2012-07-11 15:44

Update -
Setting the Z scale back to one turned out to be a vkt bug. Described and suggested fix here-
http://vtk.org/Bug/view.php?id=13300 [^]

VTK does not yet support rotated (object-aligned axes), so Paraview cannot properly support rotated _and_ scaled.

My preference for this (13093) bug is that the axes _always_ use the object's original coordinates. I'll be able to suggest a much simpler fix to this bug shortly. (i.e. my personal opinion as a non-Paraview developer is that the GUI options in the above files are unnecessary). Best,Lawrence.

(0028769)
Sebastien Jourdain (manager)
2012-07-12 16:45

I've updated the UI to allow the user to specify any custom range he want. So the scaling won't work as ON/OFF, but a more as a range that the user will have to specify.

(0028774)
Utkarsh Ayachit (administrator)
2012-07-13 10:41

merged into master (if applicable)

(0028780)
Lawrence (reporter)
2012-07-13 16:49

Ouch. From the description above, I'm concerned this is not sufficient to automatically proper axes display of scaled and translated geographic surfaces. Please can I suggest the following alternative fix is sufficient to handle scaled and translated objects.
NB Rotated and scaled objects cannot be supported until VTK object-(rotate)-aligned axis is ready.

The following fix has been tested with wavelet source translated AND/OR scaled with default and CUSTOM bounds.

void vtkCubeAxesRepresentation::UpdateBounds()
{
  double *scale = this->Scale;
  double *position = this->Position;
  double *rotation = this->Orientation;

  double unscaledBounds[6];
  double transformedBounds[6];

  this->GetDataBounds(unscaledBounds);
  for(int i = 0;i < 6; i++)
      {
      if(this->CustomBoundsActive[ i / 2 ])
        {
        unscaledBounds[i] = this->CustomBounds[i];
        }
    }

  vtkSmartPointer<vtkTransform> transform =
      vtkSmartPointer<vtkTransform>::New();
  transform->Translate(position);
  transform->RotateZ(rotation[2]);
  transform->RotateX(rotation[0]);
  transform->RotateY(rotation[1]);
  transform->Scale(scale);
  vtkBoundingBox bbox;
  int i, j, k;
  double origX[3], x[3];
  // Visit all 8 corners of the transformed bounding box
  // NB This code will be unnecessary once axes can be aligned with rotated objects
  for (i = 0; i < 2; i++)
  {
      origX[0] = unscaledBounds[i];
      for (j = 0; j < 2; j++)
      {
          origX[1] = unscaledBounds[2 + j];
          for (k = 0; k < 2; k++)
          {
              origX[2] = unscaledBounds[4 + k];
              transform->TransformPoint(origX, x);
              bbox.AddPoint(x);
          }
      }
  }
  bbox.GetBounds(transformedBounds);

  this->CubeAxesActor->SetBounds(transformedBounds);
  if(UseBoundsRangeAsLabel)
    {
// vtkPrismCubeAxesRepresentation explicitly sets the bounds and sets UseBoundsRangeAsLabel to false
// Use the original (unscaled, untranslated) object range as the axes range to display
    this->CubeAxesActor->SetXAxisRange(&unscaledBounds[0]);
    this->CubeAxesActor->SetYAxisRange(&unscaledBounds[2]);
    this->CubeAxesActor->SetZAxisRange(&unscaledBounds[4]);
    }
}

(0028781)
Sebastien Jourdain (manager)
2012-07-13 16:54

Custom bounds and custom range are two different things that can work along independently.
I don't see how it can't work as we don't care about scaling and translation, we just label the axis from two arbitrary values... So the ticks will reflect only what you are interested in.

(0028782)
Lawrence (reporter)
2012-07-16 12:42

The arbitrary labels may be useful for some, but not for our geologist users.

Here's what the typical Use case: Geologist performs a global Z rescale of all objects in the scene (we have GUI toolbar to do this, or uses the Scale entry in the Display tab; geological objects tend to be very very wide and very flat). They do not want to hand-edit the axes bounds values of all items, every time the scale is change.

The displayed range of the object should just be underlying coordinate values.
So my preference would be- It's great that you allow arbitrary values, but please please use the original unscaled bounds of the object not the transformed coordinate system.

e.g. If you make a unit box (range -0.5 .. 0.5) or a wavelet source (range -10..10) and scale along Z by 4 and translate along Z by 10 using the Display Tab, the axes bounds should still show the original range.

(The above code does this; I hope there's a way to integrate it into your revised code to ensure untransformed bound vales are used for the displayed range.)
Hope this makes sense. Thanks!

(0028796)
Ian Curington (reporter)
2012-07-18 17:02

Thank you for the discussion, I think it is very helpful. I agree that my patch assumes scaling is non-rotated, axis aligned. I think this is the most common case, and certainly what we use in earth science applications. I don't know full scope of possible application, so I can see it should be extended for that case. We added UI control toggle, so it would not break current usage, but in our applications we leave it turned on for unscaled label mode. I also agree with Lawrence, I don't see such value in arbitrary labels here. Thanks!

(0028846)
Sebastien Jourdain (manager)
2012-07-19 10:50

Latest related notes are solved in 13093-allow-non-scaled-range-for-cube-axes

(0028889)
Ian Curington (reporter)
2012-07-20 11:42

Thank you!

(0028899)
Utkarsh Ayachit (administrator)
2012-07-24 10:48

merged into master, if applicable.

(0028937)
Alan Scott (manager)
2012-07-25 16:53

Tested local server, Linux, master.

Issue History
Date Modified	Username	Field	Change
2012-04-13 10:34	Ian Curington	New Issue
2012-04-13 10:34	Ian Curington	File Added: vtkCubeAxesRepresentation.h
2012-04-13 10:35	Ian Curington	File Added: vtkCubeAxesRepresentation.cxx
2012-04-13 10:35	Ian Curington	File Added: pqCubeAxesEditorDialog.cxx
2012-04-13 10:36	Ian Curington	File Added: pqCubeAxesEditorDialog.ui
2012-04-13 10:36	Ian Curington	File Added: views_and_representations.xml
2012-04-23 10:37	Utkarsh Ayachit	Category	(No Category) => Feature
2012-04-23 10:41	Utkarsh Ayachit	Project	TBD => ParaViewPro
2012-06-07 17:15	Lawrence	Note Added: 0028677
2012-06-07 17:47	Lawrence	Note Edited: 0028677
2012-06-25 13:36	Cory Quammen	Note Added: 0028720
2012-07-05 17:02	Lawrence	Note Added: 0028745
2012-07-11 15:44	Lawrence	Note Added: 0028765
2012-07-12 16:42	Sebastien Jourdain	Assigned To	=> Sebastien Jourdain
2012-07-12 16:42	Sebastien Jourdain	Status	backlog => todo
2012-07-12 16:42	Sebastien Jourdain	Status	todo => active development
2012-07-12 16:43	Sebastien Jourdain	Topic Name	=> 13262-non-orthogonal-source-plugin
2012-07-12 16:43	Sebastien Jourdain	Status	active development => gatekeeper review
2012-07-12 16:43	Sebastien Jourdain	Resolution	open => fixed
2012-07-12 16:45	Sebastien Jourdain	Note Added: 0028769
2012-07-13 10:41	Utkarsh Ayachit	Fixed in Version	=> git-master
2012-07-13 10:41	Utkarsh Ayachit	Status	gatekeeper review => customer review
2012-07-13 10:41	Utkarsh Ayachit	Note Added: 0028774
2012-07-13 16:49	Lawrence	Note Added: 0028780
2012-07-13 16:54	Sebastien Jourdain	Note Added: 0028781
2012-07-16 12:42	Lawrence	Note Added: 0028782
2012-07-18 17:02	Ian Curington	Note Added: 0028796
2012-07-19 10:50	Sebastien Jourdain	Note Added: 0028846
2012-07-19 10:50	Sebastien Jourdain	Status	customer review => gatekeeper review
2012-07-19 10:50	Sebastien Jourdain	Status	gatekeeper review => active development
2012-07-19 10:50	Sebastien Jourdain	Status	active development => gatekeeper review
2012-07-20 11:42	Ian Curington	Note Added: 0028889
2012-07-24 10:48	Utkarsh Ayachit	Status	gatekeeper review => customer review
2012-07-24 10:48	Utkarsh Ayachit	Note Added: 0028899
2012-07-25 16:53	Alan Scott	Note Added: 0028937
2012-07-25 16:53	Alan Scott	Status	customer review => closed
2012-10-29 17:04	Utkarsh Ayachit	Fixed in Version	git-master => 3.98.0

Notes
(0028677) Lawrence (reporter) 2012-06-07 17:15 edited on: 2012-06-07 17:47	This may also be a solution to http://paraview.org/Bug/view.php?id=12615 [^] I'd be very happy to see this bug fix in. Axes on an object should represent the underlying space of the object; not any display scaling. I'd prefer that the default is disruptive; as it is almostly always correct. So far Paraview does not handle asymmetric scaling of objects well (many of the widgets do not display correctly). This would be a step in the right direction.

(0028720) Cory Quammen (developer) 2012-06-25 13:36	I would like to add my voice to support this feature. I have users in high-energy particle physics who really want to scale one axis and have the axis labels reflect the original coordinates.

(0028745) Lawrence (reporter) 2012-07-05 17:02	The suggested solution is incomplete (e.g. if the object is rotated and scaled). Also, there seem to be some issues when the Z scale is set back to one. I'll investigate this further.

(0028765) Lawrence (reporter) 2012-07-11 15:44	Update - Setting the Z scale back to one turned out to be a vkt bug. Described and suggested fix here- http://vtk.org/Bug/view.php?id=13300 [^] VTK does not yet support rotated (object-aligned axes), so Paraview cannot properly support rotated _and_ scaled. My preference for this (13093) bug is that the axes _always_ use the object's original coordinates. I'll be able to suggest a much simpler fix to this bug shortly. (i.e. my personal opinion as a non-Paraview developer is that the GUI options in the above files are unnecessary). Best,Lawrence.

(0028769) Sebastien Jourdain (manager) 2012-07-12 16:45	I've updated the UI to allow the user to specify any custom range he want. So the scaling won't work as ON/OFF, but a more as a range that the user will have to specify.

(0028774) Utkarsh Ayachit (administrator) 2012-07-13 10:41	merged into master (if applicable)

(0028780) Lawrence (reporter) 2012-07-13 16:49	Ouch. From the description above, I'm concerned this is not sufficient to automatically proper axes display of scaled and translated geographic surfaces. Please can I suggest the following alternative fix is sufficient to handle scaled and translated objects. NB Rotated and scaled objects cannot be supported until VTK object-(rotate)-aligned axis is ready. The following fix has been tested with wavelet source translated AND/OR scaled with default and CUSTOM bounds. void vtkCubeAxesRepresentation::UpdateBounds() { double scale = this->Scale; double position = this->Position; double *rotation = this->Orientation; double unscaledBounds[6]; double transformedBounds[6]; this->GetDataBounds(unscaledBounds); for(int i = 0;i < 6; i++) { if(this->CustomBoundsActive[ i / 2 ]) { unscaledBounds[i] = this->CustomBounds[i]; } } vtkSmartPointer<vtkTransform> transform = vtkSmartPointer<vtkTransform>::New(); transform->Translate(position); transform->RotateZ(rotation[2]); transform->RotateX(rotation[0]); transform->RotateY(rotation[1]); transform->Scale(scale); vtkBoundingBox bbox; int i, j, k; double origX[3], x[3]; // Visit all 8 corners of the transformed bounding box // NB This code will be unnecessary once axes can be aligned with rotated objects for (i = 0; i < 2; i++) { origX[0] = unscaledBounds[i]; for (j = 0; j < 2; j++) { origX[1] = unscaledBounds[2 + j]; for (k = 0; k < 2; k++) { origX[2] = unscaledBounds[4 + k]; transform->TransformPoint(origX, x); bbox.AddPoint(x); } } } bbox.GetBounds(transformedBounds); this->CubeAxesActor->SetBounds(transformedBounds); if(UseBoundsRangeAsLabel) { // vtkPrismCubeAxesRepresentation explicitly sets the bounds and sets UseBoundsRangeAsLabel to false // Use the original (unscaled, untranslated) object range as the axes range to display this->CubeAxesActor->SetXAxisRange(&unscaledBounds[0]); this->CubeAxesActor->SetYAxisRange(&unscaledBounds[2]); this->CubeAxesActor->SetZAxisRange(&unscaledBounds[4]); } }

(0028781) Sebastien Jourdain (manager) 2012-07-13 16:54	Custom bounds and custom range are two different things that can work along independently. I don't see how it can't work as we don't care about scaling and translation, we just label the axis from two arbitrary values... So the ticks will reflect only what you are interested in.

(0028782) Lawrence (reporter) 2012-07-16 12:42	The arbitrary labels may be useful for some, but not for our geologist users. Here's what the typical Use case: Geologist performs a global Z rescale of all objects in the scene (we have GUI toolbar to do this, or uses the Scale entry in the Display tab; geological objects tend to be very very wide and very flat). They do not want to hand-edit the axes bounds values of all items, every time the scale is change. The displayed range of the object should just be underlying coordinate values. So my preference would be- It's great that you allow arbitrary values, but please please use the original unscaled bounds of the object not the transformed coordinate system. e.g. If you make a unit box (range -0.5 .. 0.5) or a wavelet source (range -10..10) and scale along Z by 4 and translate along Z by 10 using the Display Tab, the axes bounds should still show the original range. (The above code does this; I hope there's a way to integrate it into your revised code to ensure untransformed bound vales are used for the displayed range.) Hope this makes sense. Thanks!

(0028796) Ian Curington (reporter) 2012-07-18 17:02	Thank you for the discussion, I think it is very helpful. I agree that my patch assumes scaling is non-rotated, axis aligned. I think this is the most common case, and certainly what we use in earth science applications. I don't know full scope of possible application, so I can see it should be extended for that case. We added UI control toggle, so it would not break current usage, but in our applications we leave it turned on for unscaled label mode. I also agree with Lawrence, I don't see such value in arbitrary labels here. Thanks!

(0028846) Sebastien Jourdain (manager) 2012-07-19 10:50	Latest related notes are solved in 13093-allow-non-scaled-range-for-cube-axes

(0028889) Ian Curington (reporter) 2012-07-20 11:42	Thank you!

(0028899) Utkarsh Ayachit (administrator) 2012-07-24 10:48	merged into master, if applicable.

(0028937) Alan Scott (manager) 2012-07-25 16:53	Tested local server, Linux, master.

Relationships