- this API may need to be simplified. A lot of the closest point calculations, for example, should probably just concern themselves with the calculation itself and leave any tolerance based questions to a separate step.
Global bg_ray_vclip (point_t a, point_t b, const fastf_t *min_pt, const fastf_t *max_pt)
the function name implies this takes a point,dir for a,b but it actually takes a line segment going from points a to b!
Global bg_trimesh_hash (const int *f, size_t num_f, const point_t *p, size_t num_p, fastf_t dist_tol)
Global bn_sobol_sph_sample (point_t sample, const point_t center, const fastf_t radius, struct bn_soboldata *s)
investigate the http://www.dtic.mil/docs/citations/ADA510216 scrambling method to see if basic Sobol sequence can be improved on for spherical sampling Also relevant: people.sc.fsu.edu/~hcc8471/ssobol.pdf
consider a specifiable quote character and octal encoding instead of double quote wrapping. perhaps specifiable encode type: BU_ENCODE_QUOTE BU_ENCODE_OCTAL BU_ENCODE_XML
- are these accurate?): 0 - wireframe 1 - shaded bots and polysolids only (booleans NOT evaluated) 2 - shaded (booleans NOT evaluated) 3 - shaded (booleans evaluated) 4 - hidden line
- eventually these should probably be augmented by common purpose specific options (i.e. define a BV_X_CONSTRAIN so the calling application can map either x or X to the enabling of that particular motion constraint during editing, for example...) However, I think we'll also need to pass the lower level info as there are too many purpose specific possibilities to encode them all up front.
- rather than completely eliminating the rt_vlfree global, a better approach might be to make it optional - i.e., have our code fall back on it automatically if a user doesn't supply their own vlfree. That would allow user code to "just work" in all cases, but allow applications to manage their vlfree containers if they so choose (right now, once vlist memory is allocated, it generally gets added to rt_vlfree and memory usage grows until the app is shut down. This may be fine, but if an app wants to discard their vlfree memory for a particular use case to reduce memory footprint, or use different vlfree lists for multithreading situations, they should be able to manage their own vlfree to do so:
- these structs and ray_in_rpp are versions of librt functionality, and we need to think about how/where to merge them into a common function and struct that are available to both libraries without introducing a coupling dependency.
This function needs to be modified to eliminate the rt_gettree() call and the related parameters. In that case calling code needs to call another function before calling this function That function must create a union tree with tr_a.tu_op=OP_SOLID. It can look as follows : union tree * rt_comb_tree(const struct db_i *dbip, const
struct rt_db_internal *ip). The tree is set in the struct rt_db_internal * ip argument. Once a suitable tree is set in the ip, then this function can be called with the struct rt_db_internal
to return the BB properly without getting stuck during tree traversal in rt_bound_tree()
- right now, rt_db_internal doesn't encode any notion of data version, which appears to be a major reason some APIs need to pass a dbip through in addition to the rt_db_internal. Should we add an idb_version entry here to indicate idb_ptr data versioning?
- The format of keystr may be specific to individual primitives. In principle something complex like "F10E2V1" (for example) might be desirable to select a particular brep face/edge/vertex - right now the valid inputs aren't yet documented.
1.9.8