Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Image/Data Conversion
Submitted By: Phoenix (phoenixyjll)
Assigned to: Nobody/Anonymous (nobody)
Summary: rt_ell_brep, rt_ehy_brep & rt_hyp_brep functions
The original version of function rt_ell_brep() can only deal with ellipsoids centered at the origin and A, B, C set along the X, Y, Z axis. This new one add rotation and translation to it, so it can deal with all ellipsoids.
There are a couple ways - the more common one is to raytrace from multiple
views and see if the shape "looks right" - that's how I noticed the hyp was
More rigorously, there is an option to the brep command to draw surface
normals, although I note it's missing from the brep command usage statement
(code is in src/librt/primitives/brep/brep_debug.cpp):
brep brep.s plot SN #
where # is the number of the individual surface you want normals for.
Right now it's just drawing lines, so you might want to enhance what it's
drawing slightly to make sure you know which way the line is pointing -
sometimes it's clear from the wireframe context, but in isolation you'll
probably want some kind of arrowhead.
Sorry I didn't notice it before. But I find that just V_REVERSE y_dir is
not enough, for the representation of the elliptical hyperboloic NURBS
surface may be wrong. So I think we should also V_REVERSE Bu in
hyp_brep.cpp:178 after VSCALE(Bu, y_dir, 1/MAGNITUDE(y_dir)).
But I don't know how to find whether a plate is "inside-out". Could you
Testing the hyp conversion, it looks like the top and bottom plates may be
"inside-out" - if I V_REVERSE y_dir after the VCROSS in hyp_brep.cpp:53, I
get a correct raytrace. Can anyone confirm?
I also modify the rt_ehy_brep function which has the same problems. Before,
only the bottom cap of ehy can be correctly drawn. Now it works well with
the curve surface. Rotation and Translation are added so that all ehys can
be dealt with.
Comment By: Sean Morrison (brlcad)
Date: 2012-03-30 10:18
Excellent work Phoenix, but I do see some room for improvements. If you
look at the math library functions and macros you're using (vmath.h and
bn.h), you'll see that MAT3X3VEC() does the transformation you're manually
doing to the origin and curve points. Especially for math code that
expands to a mess, it's almost always better to call existing API -- even
if it means copying some data into temporaries -- because the code becomes
easier to understand and maintain. Still, nice work regardless (assuming
it works, haven't tested!) as this was a non-trivial patch.