# tikz-3dplot causes problems to let operator

I am trying to use the 3d-plot library. The plan is to define some basic 2d coordinates at the beginning and then use them to define all kind of 3d points, using the "let" operator:

\documentclass{standalone}
\usepackage{tikz}
\usepackage{tikz-3dplot}
\usetikzlibrary{positioning,calc}
\begin{document}

\tdplotsetmaincoords{0}{0} %doing nothing for now
\begin{tikzpicture}[tdplot_main_coords]
\draw[red,->] (0,0,0)--(1,0,0);
\draw[red,->] (0,0,0)--(0,1,0); %just for reference

\coordinate (A) at (1,1);
\draw let \p1=(A) in (0,0,0)--(\x1,1,0); %this is problematic
\draw[green] (1,1,0)--(28.45,1,0);
\draw[blue] let \p1=(A) in (0,0,0)--(\x1,1);
\end{tikzpicture}
\end{document}


The problem is that the output does not make any sense:
-tikz seems to know how to draw point (1,1,0) (first point of green line).
-tikz seems to know that \x1 of (A) equals 1 (blue line).
-tikz somehow multiplies \x1 by ~28.45 for no apparent reason, when \x1 is used inside 3d coordinates.
(note that experimenting with defining (A) to be 3d - i.e. (1,1,0) - changed nothing)

I find this problem fascinating, so I'd like it very much to wrap my head around it, but if someone has apart from it a solution on how to define a pair of numbers to use afterwards in tikz, behaving well with tikz-3dplot, I would also be interested

Welcome to TeX.SE! The let operator works still fine. The problem you are seeing is that the 3d coordinate system installed by tikz-3dplot tacitly works with cm units whereas the calc syntax yields pt. To see this more explicitly, let's look at the definition of \tdplotsetmaincoords in tikz-3dplot.sty,

\newcommand{\tdplotsetmaincoords}[2]{%
%perform some trig for the display transformation
%
%
%store the user-specified angles for possible future use
\pgfmathsetmacro{\tdplotmaintheta}{#1}
\pgfmathsetmacro{\tdplotmainphi}{#2}
%
%
\tdplotcalctransformmainscreen
%
%now here is where the output is performed
\tikzset{tdplot_main_coords/.style={x={(\raarot cm,\rbarot cm)},y={(\rabrot cm, \rbbrot cm)},z={(\racrot cm, \rbcrot cm)}}}%
}


Here, the coordinates get (unfortunately, one may perhaps add) multiplied by cm. (The macros \racrot are just entries of the rotation matrix, i.e. an orthogonal 3x3 matrix parametrized in the conventions of the package.) I should, however, add that overall I love that package, so I am very far from criticizing the author. The more so since the problem can be fixed really easily.

The arguably simplest fix is to convert back to cm by just dividing by 1cm/1pt.

\documentclass[tikz,border=3.14mm]{standalone}
\usepackage{tikz-3dplot}
\usetikzlibrary{positioning,calc}
\begin{document}

\tdplotsetmaincoords{0}{0} %doing nothing for now
\begin{tikzpicture}[tdplot_main_coords]
\draw[red,->] (0,0,0)--(1,0,0);
\draw[red,->] (0,0,0)--(0,1,0); %just for reference

\coordinate (A) at (1,1);
\draw let \p1=(A) in (0,0,0)--({\x1*1pt/1cm},1,0); %this is problematic
%\draw[green] (1,1,0)--(28.45,1,0);
\draw[blue] let \p1=(A) in (0,0,0)-- (\x1,1);
\end{tikzpicture}
\end{document}


• P.S. You might be interested in this commit. – marmot Feb 10 at 2:36
• Perfect answer. Thank you very much. I knew I had seen this 28.sth before :) P.S. This \coord thing seems indeed interesting, I will check it out. – D. Bogiokas Feb 10 at 2:45
• @D.Bogiokas You're welcome! There are ideas to add the orthonormal transformations to the 3d library. However, if this happens, it won't happen tomorrow, and questions like this one will certainly greatly help to avoid some pitfalls. – marmot Feb 10 at 2:47