|
From: Hans-Bernhard B. <br...@ph...> - 2003-12-19 01:15:37
|
OK, let me expand on the details... > The key difference is in graph3d.c:cntr3d_lines() and friends: in 3.7, > they used clip_move() and clip_vector() to create (optionally > clipped/broken) polylines. In 3.8, we use draw3d_line directly, which > does both a term->move() and term->vector(), usually. > AFAICS, it was me who did that, as part of the big set of modifications > done on the "axis branch". Staring at the modifications in question for a while, I now found/remembered the actual background of this. It was me, indeed, and it was part of the 'axis' branch, but the rationale was different than I had first thought. The real problem with the old cntr3d_line code was that it output the lines in *2D* mode. clip_move() and clip_vector() are 2D functions, and on top of everything else, they don't really implement the move()/vector() semantics to create polylines. Instead, the global flag suppressMove is used for that. The problems with that were that contour lines couldn't be hidden in hidden3d mode, because the routine that drew them didn't have the necessary 3D information any more. I've now created a new pair of routines polyline3d_start() #may be renamed to *_move() polyline3d_next() #may be renamed to *_vector() and use those in cntr3d_lines, instead of draw3d_line(). If either the 'palette' line coloring option or hidden3d is in use, it still falls back to the 3.8 behaviour, though. Hidden3d just doesn't support polylines at this time. For paletted lines, polyline support wouldn't make sense anyway, so no harm done on that end. Besides the hidden3d limitation, all's looking fine so far. Some of you PM3D experts should test this a bit more thoroughly though, so I'm checking the current state of this in right away. Happy holy days, y'all... -- Hans-Bernhard Broeker (br...@ph...) Even if all the snow were burnt, ashes would remain. |