LINE_P advanced form question

[keldor314]

Has anyone been successful getting LINE_P to accept a matrix for lines_definitions? I just get a syntax error, and have to use a list instead, which has some nasty performance issues for allocating large lists. TRIANGLE_P accepts matrices for both points_definitions and triangle_definitions, and the documentation for LINE_P suggests that it should work the same way, but I haven't gotten it to work.

[Mark Power]

I’ve struggled to get the advanced forms to work despite trying to follow this guidance:

https://hpmuseum.org/forum/thread-5122.html

[keldor314]

(11-21-2024 04:36 PM)Mark Power Wrote:  I’ve struggled to get the advanced forms to work despite trying to follow this guidance:

https://hpmuseum.org/forum/thread-5122.html

I've gotten it to mostly work, although those uninformative "syntax error"s are truely unhelpful.

Z clipping seems to be outright broken for LINE and LINE_P, although it works for TRIANGLE and TRIANGLE_P if you use "N" (and only then). You can see the clipping not functioning in the tetrahedron demo that comes with the calulator.

I finally managed to get matrices working everywhere, but there are some gotchas.

Point definitions should be in the 4 number form, x,y,z,c. Matrices can apparently be either row major or column major, and the calculator knows which way around it is according to the dimensions. Don't ask me which way it puts 4x4 matrices. Also, it will throw a invalid input error if there are fewer than 4 points. 3 number form works, but only for row major for some reason.

lines and triangle definitions work with 3 to 5 elements per point, so the 3 indices for triangle indices as expected, with color and alpha optional, but for line definitions, it still expects at least 3 elements, the 2 indices, and the 3rd for color manditory (but can be set to -1 to ignore it and use point colors). The calculator will throw a very helpful (hah!) "invalid input" error if you leave it out. TRIANGLE accepts both row major and column major, but LINE does not for some reason, and only works row major.

The transformation matrix works as either 2x2, 3x2, 3x3 or 4x3 matrices, depending whether you want 2D or 3D, and pure rotation vs rotation + translation.

You can use the {xmin3D, xmax3D... zmax3D} group of parameters to get it to clip the drawing to a box, but note that you need to give it the {eye_x...} coordinates or -1 for it to work.

Using lists of lists for points and definitions works, and is slightly more forgiving in terms of undocumented element counts, but should be avoided by all means since repeatedly creating large lists has the unfortunate side effect of taking longer and longer each time, with the performance degredation lasting until you force reset with on+symb or the reset button on the back of the calculator.

[keldor314]

On further inspection, it looks like the indexing on line_definitions is broken. It looks like it's checking dimensions as if the points were arranged in successive rows, but then only rendering the first 3 or 4 lines, where 3 or 4 is the number of columns in the matrix. I wonder if this has anything to do with the zclip not working on LINE bug....

[keldor314]

As far as performance issues around allocating large lists:

If you must use a list, use MatToList(MAKEMAT(...)) to allocate a large list. This will do the memory allocation all in one chunk.

DO NOT use MAKELIST(...) or try to build it up through any sort of element by element appending or inserting or what have you. Not only is this slow, but it tends to lead to memory fragmentation problems that will progressively make your calculator slower and slower until you do a hard reset.

Matrices and vectors are preferable over lists any time they can be used.