[vtkusers] Fwd: vtkCubeAxesActor positions text labels incorrectly on axis
Michael Arnold
myk321 at gmail.com
Mon Jun 27 07:43:35 EDT 2016
Thanks Dave,
It looks like mantis user registration is down, so I'll put the defect
logging task into my diary for later:
"User registration is currently disabled due to recent spam attacks. For
now please report your problem to a relevant project user mailing list
instead."
With the correction below, the problem is now limited to axes with 10
elements. I've attached some screen-shots showing axes with 9 elements
(ok), 10 element (problem), 11 elements (ok), 12 elements (ok). The 10
element problem I have highlighted with a red circle - where the
expectation is that the label position should be back from the end of the
axis, like it is for the 12 element example.
I'll try and see if I can get the paraview code to work.
Kind regards,
Michael
On Fri, Jun 24, 2016 at 7:50 PM, David Lonie <david.lonie at kitware.com>
wrote:
> Hi Michael,
>
> Looking at our change log, it doesn't appear that the vtkCubeAxesActor has
> seen many significant changes since 6.1, so I doubt a newer version would
> work any differently. I'm not aware of anyone currently working on this
> class, but I do know that there is a replacement in development in
> ParaView, vtkGridAxes3DActor:
>
>
> https://github.com/Kitware/ParaView/blob/master/ParaViewCore/VTKExtensions/Default/vtkGridAxes3DActor.h
>
> There's been talk of moving it into VTK, but I'm not aware of any firm
> plans at this point.
>
> In the meantime, feel free to file a bug report / feature request for this
> so it doesn't get lost.
>
> Dave
>
> On Fri, Jun 24, 2016 at 7:12 AM, Michael Arnold <myk321 at gmail.com> wrote:
>
>> Sorry - my bad:
>> cubeAxesActor->SetXAxisRange(0.0, Labels.size() * 1.0);
>> needs to be:
>> cubeAxesActor->SetXAxisRange(1.0, Labels.size() * 1.0);
>>
>> Michael
>>
>>
>> -----------------------------------------------------------------------------------------
>>
>> Problem: for axis labels created using vtkCubeAxesActor, if we have more
>> than 10 text labels, the labels and the data don't line-up, because the
>> labels are positioned incorrectly on the axis.
>>
>> What are we Getting in more Detail:
>> (a) If we have 9 data points (<10) we get 9 label points, with the last
>> label at the end of the axis. So the labels can be 1,2,3,4,5,6,7,8,9,
>> which lines-up nicely with the data: all is good in the world.
>> (b) If we have 10 data points, we get get 6 labels points with the last
>> label one at the end of the axis. We compute a label skip factor of 2. We
>> start at the beginning of the axis. We label 1,3,5,7,9,11 <- what category
>> is this last label?? We only have 10 data points! So the last data label
>> does not line-up with its data.
>> (c) If we have 11 data points, we again get 6 label points with the last
>> label positioned a short distance back from the end of the axis. Again we
>> compute a label skip factor of 2. We begin to label at the beginning of
>> the axis. So we get 1,3,5,7,9,11. Ok, because we had 11 data-points, but
>> now we land-up with the label for the last data element being back from the
>> end of the axis i.e. the data label does not line-up with its data.
>>
>> What we want:
>> (a) VTK seems to make a quite reasonable assumption to limit the number of
>> labels to less than 10, so lets stick with that.
>> (b) VTK works fine with data sets with 9 or fewer elements, so lets focus
>> on data-sets with 10 or more data-points.
>> (c) We need to handle data-sets with an even count of elements slightly
>> differently from data-sets with an odd count of elements. (For a more
>> generic handling this would be if the count of the elements is divisible by
>> the skip factor, but for the moment lets stick to a skip factor of 2 and
>> thus even or odd element counts).
>> (d) For a data-set with an odd count of elements (lets say 11) we can
>> easily imagine the handling to be:
>> Smallest at the start (e.g. 1)
>> Biggest at the end (eg. 11)
>> Then fill-in the labels using the skip factor (2 in this case), so we get
>> something like 1,3,5,7,9,11
>> (e) For a data-set with an even count of elements (lets say 10), we need to
>> have a gap between the last label and the end of the axis. The end of the
>> axis seems most logical place for this gap, so the last label point is back
>> a bit from the end of the axis. So:
>> Smallest at the start (e.g. 1)
>> Then fill in the labels using the skip factor, so something like 1,3,5,7,9
>> and we happily land-up with a label of 9 being a bit back from the end of
>> the axis.
>>
>> So what was the difference between what we want and what we are getting?
>> The problem is not about the calculation of the number of labels - that is
>> fine.
>> The problem is the positioning of the labels on the axis - is the last
>> label at the end of the axis or bit back from the end?
>> Today, for data-sets with an even number of elements, we are getting the
>> last label at the end of the axis. This is incorrect because for an even
>> number of elements, we want the last label to be positioned back from the
>> end of axis.
>> Today, for data-sets with odd number of elements, we are getting the last
>> label positioned with a gap before the end of the axis. Again this is
>> incorrect, because the label should be positioned at the end of the axis.
>>
>> Questions:
>> I'm using an old'ish version of VTK 6.1 - has this issue been fixed in a
>> newer version?
>> Am I misunderstanding something or can I raise a defect for this?
>>
>> Some Code:
>>
>> vtkSmartPointer<vtkCubeAxesActor> cubeAxesActor =
>> vtkSmartPointer<vtkCubeAxesActor>::New();
>> cubeAxesActor->SetBounds(outputPolyData->GetBounds());
>> cubeAxesActor->SetCamera(Renderer->GetActiveCamera());
>> cubeAxesActor->GetTitleTextProperty(0)->SetColor(1.0, 1.0, 1.0); //White
>> cubeAxesActor->GetLabelTextProperty(0)->SetColor(1.0, 1.0, 1.0); //White
>> cubeAxesActor->SetXTitle("X-Axis");
>> cubeAxesActor->GetXAxesGridlinesProperty()->SetColor(1.0, 1.0, 1.0);
>> //White
>>
>> cubeAxesActor->DrawXGridlinesOn();
>> cubeAxesActor->SetGridLineLocation(VTK_GRID_LINES_FURTHEST);
>> cubeAxesActor->SetFlyModeToOuterEdges(); //Place the axes on the
>> outer edges of the cube
>>
>> //Set the labels on the x-axis
>> vtkSmartPointer<vtkStringArray> XAxisLabels =
>> vtkSmartPointer<vtkStringArray>::New();
>> std::vector<std::string> Labels = ResultsServer->GetXLabels(); //Get a
>> list of axis labels
>> if (!Labels.empty()) {
>>
>> int32_t SkipFactor = (Labels.size() / 10) + 1;
>> int32_t Counter = 0;
>>
>> //Evenly divisble
>> for (auto LabelsIt = std::begin(Labels); LabelsIt != std::end(Labels);
>> ++LabelsIt)
>> if (Counter++ % SkipFactor == 0)
>> XAxisLabels->InsertNextValue(LabelsIt->c_str());
>>
>> cubeAxesActor->SetXAxisRange(0.0, Labels.size() * 1.0);
>> cubeAxesActor->GetLabelTextProperty(0)->SetFontSize(20);
>> cubeAxesActor->GetLabelTextProperty(0)->SetOrientation(90.0);
>> cubeAxesActor->SetAxisLabels(0, XAxisLabels);
>>
>> Labels.clear();
>> }
>>
>> Kind regards,
>> Michael
>>
>>
>>
>> _______________________________________________
>> Powered by www.kitware.com
>>
>> Visit other Kitware open-source projects at
>> http://www.kitware.com/opensource/opensource.html
>>
>> Please keep messages on-topic and check the VTK FAQ at:
>> http://www.vtk.org/Wiki/VTK_FAQ
>>
>> Search the list archives at: http://markmail.org/search/?q=vtkusers
>>
>> Follow this link to subscribe/unsubscribe:
>> http://public.kitware.com/mailman/listinfo/vtkusers
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160627/0b3a32f4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 10element_problem.png
Type: image/png
Size: 11083 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160627/0b3a32f4/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 11elements_ok.png
Type: image/png
Size: 6118 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160627/0b3a32f4/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 12elements_ok.png
Type: image/png
Size: 13933 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160627/0b3a32f4/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 9elements_ok.png
Type: image/png
Size: 6173 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20160627/0b3a32f4/attachment-0007.png>
More information about the vtkusers
mailing list