Chart3DPercent

[Yeray]

Hello Jim,

TChartSeries.CalcXPos and TChartSeries.CalcYPos call TChartAxis.XPosValueCheck and TChartAxis.YPosValueCheck respectivelly. These functions return the sceen pixel that corresponds to a given ValueIndex.
TCustom3DSeries.CalcZPos does the same with the Z axis.
These pixel values are calculated relative to the axis position, size, and scale.

[JimR]

Perhaps I am looking in the wrong place but it seems that when CalcXpos etc. are called in the VCLTee.Series unit the coordinates are already in pixel units.

I need some earlier procedure where the relationship between the values along the axes are defined in terms of pixels. I need to adjust the definitions so all axes will be in the same units. This would also solve the 2D problem and in a much simpler way than what I did earlier. I thought the conversion should be defined in the Chart unit so it would be common to all series but I could not find it.

For my little demo program (above) I am drawing 3D vectors using the TeeSurfa unit. Same problem there the DrawArrow procedure is called using pixel coordinates.

Must be something clever being done for speed that I have not yet found.

Jim

[Yeray]

Hello,

Let me try to explain how CalcXPos and similar functions translate values into pixels.
One of the keys is the ChartRect, the drawing zone that corresponds to the area determined by the axes when in 2D. This rectangle is already in pixels; it is ons of the first things that are calculated during the drawing routine, and it is adjusted when other parts are calculated, like the legend. From this ChartRect rectangle, the chart calculates the axes size/length, also in pixels.
Then, knowing the minimum&maximum (values) of an axis, and this size (in pixels), the "Calc*" functions calculate the pixel that corresponds to a value with a simple operation. Simplifying XPosValueCheck function, this is what it does with a non inverted axis:

Code: Select all

Function TChartAxis.XPosValueCheck(Const Value:TChartValue):Integer;
var tmp : TAxisValue;
begin
  tmp:=(Value-IMinimum)*IAxisSizeRange;
  result:=IStartPos+Round(tmp);
end;

[JimR]

ok but that does not provide a solution to the iso problem. The dimensions of the ChartRect need to be adjusted before a procedure like XPosValueCheck is called so that the two (or three axes) can be in the same units in the final plot. Thus, one has to go back a step to where the ChartRect is defined in order to fix the problem.

In additions, where is the length of the z axis determined? In the Calc3DPos procedure, for example, the z axis is already in pixels before the viewing rotation is applied (for example, zz := Z * c2 - x * s2;).

Thanks

[JimR]

Any help possible on my question?

[JimR]

Any updates? suggestions?

[Marc]

Hello Jim,

You mention this in an earlier post:

Yes, the same problem I commented on previously there and several prior times as the problem is not yet solved. The problem should not be a difficult "challenge" as the projection equations are quite straight-forward. Just need to add another option to use those equations rather that what is presently used in TChart. Using these equations will probably slow the rendering so it should just be an option for those applications that require it.

Whilst we've not been able to give the time to this issue that we would have hoped to thus far, perhaps we can still help to get the projection equations in. If you have something in a format that we can work with, perhaps we can take a look and help with the placement of it in the TeeChart code.

Regards,
Marc

[JimR]

Well, it is difficult for me to just give a projection equation because the details will depend on the internal structure of your software which I have not been able to trace very well, hence my prior questions about where certain operations are performed. For example, me question "In additions, where is the length of the z axis determined? In the Calc3DPos procedure, for example, the z axis is already in pixels before the viewing rotation is applied (for example, when the projection zz := Z * c2 - x * s2; is applied)." That projection equation is ok. The problem is that that when it is applied the Z variable is already in pixels and does not have the proper number of pixels so as to permit the axes to be in the proper units. The projection needs to be performed in the original user specified units and then converted to pixel units after the projection. That is, the rotation, translation, and projection needs to be performed in the original user units and then convert the final x,y coordinates to pixels so that a unit along the x-axis equals a unit along the y-axis. What I noticed in Calc3DPos was that the projection was computed after the conversion to pixels. At that final step to convert to pixels one also needs to correct, if necessary, for pixels that are not square.

For 2D plots I was able to get an ugly work-around. Cannot for 3D because, as mentioned above, the z-axis is converted to pixels before the projection is computed. That seems to block anyway to adjust the final result.

I would also like the option to do this be indicated by setting a global variable like tchart1.iso := true that would apply to both 2D and 3D plots.

I would greatly appreciate any help on this. Because it changes the order of some operations there may be unintended consequences. would be happy to try a 'beta' version while possible side-effects are being checked.

Jim

[Marc]

Hello Jim,

An approach may be to vary the Chart3DPercent to influence the length of the depth Axis, the Z-dimension. The relationship between scale and Chart3DPercent can probably be arrived at quite quickly and may be retro-used to control how the scale should appear.

Regards,
Marc

[JimR]

I did look at that initially but could not see a way to get the desired effect. Perhaps there may be a clever way to trick the software but the direct and correct solution has to be that when the projection operation is performed the 3 axes are already be in the same units (all user units or all pixels). As I mentioned earlier, the projection operation in the Calc3DPos routine uses the z value in pixels but x and y in user units. Geometrically that does not make sense.

Jim

[JimR]

I am checking back to see whether there has been any progress in solving the problem of proper scaling of 3D plots (i.e., so a cube would still look like a cube after a user rotates it. I did not see a feature like that mentioned in the 2018.25 update.

I hope something can be done. After much work my project is dead and cannot be released until there is a solution. A shame after working a couple of years trying to get TeeChart to work for 3D plots. If not, then perhaps someone can suggest other software I could use instead for 3D scatter point plots.

Jim