TDOTRI(3NCARG)

πŸ“¦ version 6.6.2, in epel 9, fedora 43, fedora 44

πŸ’– TDOTRI πŸ’–

okay bestie so this is a page from the NCAR GRAPHICS manual, and the star of the show is TDOTRI β€” a lil routine whose whole job is deciding what order to draw your triangles in. yes it's giving "who goes first at the lunch table" but for 3D rendering. and honestly? it ate. ✨


🌸 NAME 🌸

TDOTRI β€” order the triangles defined by a triangle list. that's it, that's the vibe. πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

CALL TDOTRI (RTRI, MTRI, NTRI, RTWK, ITWK, IORD)

πŸ¦‹ C-BINDING SYNOPSIS πŸ¦‹

#include <ncarg/ncargC.h>

void c_tdotri(float *rtri, int mtri, int *ntri, float *rtwk, int *itwk,
int iord)

✨ DESCRIPTION ✨

so here's the tea, bestie. you hand this routine a list of NTRI triangles sitting in the array RTRI, plus a real scratch array RTWK that's at least MTRI x 2 long, and it figures out the order in which the triangles are to be rendered. then it hands you back a permutation of the integers from 1 to NTRI in the array ITWK, which is literally just that permutation, spelled out. iconic behavior honestly. πŸ‘‘

and you, the caller, get to pick any of three ways the triangles get ordered β€” the first two are basically twins, lowkey:

  • when IORD is 0, it computes the distances of the midpoints of the triangles from the viewpoint and sorts the triangles by decreasing order of those distances. πŸ“
  • when IORD is -1, it's the same result, except it uses the distances of the farthest points of the triangles from the viewpoint and puts them in decreasing order of those distances.

both of these? totally appropriate for situations where the triangles represent smooth surfaces that don't intersect each other or themselves. the occasional small errors in the resulting rendering order should be acceptable β€” ngl that's just how it be sometimes. πŸ™ˆ

now. if any of the triangles in the list intersect each other, or if the surfaces being depicted are too rough, then you need the third option, no cap:

  • when IORD is +1, TDOTRI executes an algorithm taken from the reference "Computer Graphics Principles and Practice", by Foley and Van Dam. it starts by ordering the triangles as if IORD had the value -1 (using distances of the far points of the triangles from the viewpoint), but then it checks for situations in which this ordering is in error and fixes the errors. πŸ› οΈ
heads up bestie: executing this algorithm can be time-consuming, so it should not be done unless it is really necessary. one possible way to proceed might be to use IORD = -1 while checking out a code and then use IORD = +1 only when doing final plots. like, save the expensive one for the glow-up photo, not the mirror selfie. πŸ“Έ

sometimes, when IORD = +1, triangles must be broken into smaller triangles, thereby increasing the total number of triangles in RTRI. and if, as a result of this, NTRI becomes equal to MTRI, no error exit is taken β€” instead, TDOTRI just returns control to the caller. so yeah, it's a good idea, after calling TDOTRI, to check the value of NTRI against the dimension MTRI. if they're equal, it probably means the triangle list filled up and that using the permutation returned in ITWK will result in an incorrect rendering of the triangles. 😭 check your receipts!!


🧚 the arguments of TDOTRI, one by one 🧚

  • RTRI β€” an input/output array, of type REAL, dimensioned 10 x MTRI. it's a list of triangles, probably created by means of calls to TDSTRI, TDITRI, and/or TDMTRI. and as described above, the number of triangles in the list may increase as a result of calling TDOTRI. so it's a glow-up that grows. πŸ’–
  • MTRI β€” an input expression of type INTEGER. it's the second dimension of RTRI and thus the maximum number of triangles the triangle list will hold. the ceiling. the limit. the cap (literally). πŸŽ€
  • NTRI β€” an input/output variable of type INTEGER. specifies the number of triangles currently in the list. it is the user's responsibility to zero this initially; its value is increased by each call to a triangle-generating routine like TDSTRI or TDITRI and may be increased by a call to TDOTRI. yes bestie you have to zero it yourself, that's just the deal. 🫢
  • RTWK β€” a scratch array of type REAL, dimensioned at least MTRI x 2. it's the lil notepad the routine scribbles on. πŸ“
  • ITWK β€” an output array, of type INTEGER, dimensioned at least MTRI. returned containing a permutation of the integers from 1 to NTRI, specifying the order in which the triangles ought to be rendered. this is the whole point of the whole page. ⭐
  • IORD β€” an input expression of type INTEGER. says how the triangles are to be ordered:
    • the value 0 implies ordering by decreasing distance of the triangle midpoints from the eye
    • -1 implies ordering by decreasing distance of the triangle farpoints from the eye
    • +1 implies ordering by decreasing distance of the triangle farpoints from the eye, with adjustments made by running an algorithm from the reference "Computer Graphics Principles and Practice", by Foley and Van Dam πŸ“š

🌈 C-BINDING DESCRIPTION 🌈

the C-binding argument descriptions are the same as the FORTRAN argument descriptions. same energy, different font. iykyk. πŸ’œ


πŸ‘‘ ACCESS πŸ‘‘

to use TDOTRI or c_tdotri, load the NCAR Graphics libraries ncarg, ncarg_gks, and ncarg_c, preferably in that order. order matters bestie, we don't do chaos here (except in rendering order, which is literally this entire manual page). ✨


🌸 SEE ALSO 🌸

online, go peek at: tdclrs, tdctri, tddtri, tdgeti, tdgetr, tdgrds, tdgrid, tdgtrs, tdinit, tditri, tdlbla, tdlbls, tdline, tdlnpa, tdmtri, tdpack, tdpack_params, tdpara, tdplch, tdprpa, tdprpi, tdprpt, tdseti, tdsetr, tdsort, tdstri, tdstrs. it's giving a whole friend group. πŸ¦‹


Copyright (C) 1987-2009
University Corporation for Atmospheric Research

The use of this Software is governed by a License Agreement.

and that's the whole page bestie!! this one shipped as part of NCAR GRAPHICS on UNIX, dated July 1997, and it lives at section 3NCARG as TDOTRI(3NCARG). periodt. πŸ’–βœ¨πŸŽ€

πŸ“¦ where this page comes from