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
tikz-pgf coordinates tikz-3dplot
add a comment |
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
tikz-pgf coordinates tikz-3dplot
add a comment |
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
tikz-pgf coordinates tikz-3dplot
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
tikz-pgf coordinates tikz-3dplot
tikz-pgf coordinates tikz-3dplot
asked Feb 10 at 2:24
D. BogiokasD. Bogiokas
305
305
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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 the3d
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
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f474136%2ftikz-3dplot-causes-problems-to-let-operator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 the3d
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
add a comment |
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 the3d
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
add a comment |
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}
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}
edited Feb 10 at 2:45
answered Feb 10 at 2:34
marmotmarmot
116k5149280
116k5149280
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 the3d
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
add a comment |
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 the3d
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
P.S. You might be interested in this commit.
– marmot
Feb 10 at 2:36
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
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
@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
add a comment |
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f474136%2ftikz-3dplot-causes-problems-to-let-operator%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown