Some time ago, a problem was brought to my attention regarding the polytope arc command. I finally cracked open the code and spent some time checking it out. It turned out to due how my numerical comparisons and conditional statements were written.

To compare a numerical value to another, I use the \pgfmathparse command as follows:

\pgfmathparse{\tdplotstartphi < \tdplotresphi}

The result of this will be a value written to \pgfmathresult that is 0 if false, or 1 if true.

Next, I perform conditional execution of subsequent commands using the \ifthenelse command from the ifthenpackage:

\ifthenelse{\equal{\pgfmathresult}{1.0}}
{
%code block for true condition
}
{
%code block for false condition
}

This is probably not the most elegant way to do things, but it works. Or at least it did when I wrote this package.

When the recent bug was brought to my attention, I drilled down into the execution of the tikz-3dplot package until I discovered that these conditional execution statements were not properly firing. They were always executing the false condition. It turned out that the \equal comparison between \pgfmathresult and 1.0 was no longer valid. Through trial and error, I found that it will now work if I use the following:

\ifthenelse{\equal{\pgfmathresult}{1}}
{
%code block for true condition
}
{
%code block for false condition
}

Note the subtle change of comparison, where I am now comparing /pgfmathresult to 1, rather than 1.0. My best guess is that the nature of the value returned by \pgfmathresult and how it is compared using \equal has been subtly changed, and so the comparison was no longer valid.

I’m not well versed on how LaTeX and PGF handles the storage and comparison of values, and I’ve always had the impression that there is no real data type structure to speak of, but my guess is that this is where the problem arises. I picture it to be the same as comparing two string literals that originated from numbers, and the conversion from number to string are different for each value, resulting in a different string.

So, long story short, lots of head scratching, and a subtle change repaired the issue. Enjoy!

This was recently pointed out to me, and a simple addition of some parenthesis appears to have done the trick. I have submitted the updated version to CTAN and it should be posted soon.

I am very grateful for all the feedback I have received, and hope to continue to receive bug reports and suggestions to improve this package.

To draw the x and y axes, a comparison is made between the current plotted angle and the angle where these axes exist. This check is performed to ensure that the axes appear at the right depth when the plot is rendered. Basically, any part of the plot “behind” the axis from the current perspective is rendered first, then the axis is drawn at the appropriate time by using this comparison, and then the rest of the shape is drawn.

My code was written to expect a result of “1.0″ when returning true on the comparison statement. The macro was returning “1″, and thus the conditional code was never executed, and the axes were never rendered.

After changing “1.0″ to “1″, all was well. The latest version is available on CTAN.

Now, it appears that, for some orientations, the shape is not fully rendering in a quadrant. I will poke around and see if I can fix this issue, and will post an update.

Recently, this package was submitted to CTAN, where other LaTeX users can easily access it and learn how to contact me to provide feedback. Up until now, the package development was documented on my personal blog. Recently, I have been receiving increased user feedback and suggestions for the continued development of this package. It is apparent that, through the help of this feedback, this package will continue to develop, and there will be more entries as time goes on. This dedicated blog has been created, since it seemed more appropriate to focus the tikz-3dplot package development in its own place.