Stream: brlcad

Topic: pnts in vol

Sean (Aug 18 2020 at 07:13):

@starseeker something about r76818 feels really off (designwise). I get what it's for, but it feels rather wrong design approach to me so highly specialized to points and new nomenclature (inside/outside) when the concept itself is common. you basically implemented the union operator on a point set.

A generality we've had on deck for a while is the introduction of a "cg" command to "compile geometry", which would bake/simplify a comb with expression "volobj u pntsobj" into a newcomb with "newpnts" expression. This would be an excellent first step.

Sean (Aug 18 2020 at 07:15):

That would set the stage for other automatic simplification, tree contractions, null object detections, etc. even if initially it only does this one union pnts case.

starseeker (Aug 18 2020 at 11:15):

I'm not quite following - maybe it's just me, but I would expect "cg volobj u pntsobj" to return something that incorporated both volobj and pntsobj. I think we're looking at intersect and subtraction operators here(?) which would make it:

cg pntsobj + volobj = pnts_inside_volobj
cg pntsobj - volobj = pnts_outside_volobj

starseeker (Aug 18 2020 at 11:17):

cg pntsobj u volobj would have to just return pntsobj, since volobj wouldn't have any points. For pnts on pnts interactions it would be better defined:

cg pngsobj u pntsobj2 = all_pnts_in_both
cg pntsobj + pntsobj2 = pnts_only_in_both
cg pntsobj - pntsobj2 = pnts_in_pntsobj_but_not_in_pntsobj2

starseeker (Aug 18 2020 at 11:19):

There would have to be some convention about the primitive type of the lefthand object dictating the type of the output object, or something along those lines.

starseeker (Aug 18 2020 at 11:20):

We'd also have to think about what something like cg sphobj u pntsobj would mean - do we expand the sphere to contain the points? What do we do with (say) cg sphobj u sketchobj?

starseeker (Aug 18 2020 at 16:00):

@Sean is r76830 reasonably close to what you were thinking?

Sean (Aug 18 2020 at 19:11):

no, no -- it would rely on existing object, not be args, and act just like a compiler. instead of an expression, you'd compile a given object like "cg some_comb" or "cg -o compiled_obj some_comb".

starseeker (Aug 18 2020 at 19:16):

So you'd have to make a comb and then evaluate it to do the point subset op?

Sean (Aug 18 2020 at 19:16):

yeah, the compiler would be written to recognize known patterns (just like the c/c++ optimizer in cc). so if we have some_comb = "volobj x pntsobj", it'd see OBJ1 OP OBJ2 and match OP==intersect with either OBJ1 or OBJ2 with a pnts type, and know it can reduce/replace some_comb with a new pnts object

Sean (Aug 18 2020 at 19:17):

codewise, it still just calls exactly what you wrote

Sean (Aug 18 2020 at 19:17):

just, UI is through a generalized optimization that we can extend with other optimizable patterns

starseeker (Aug 18 2020 at 19:18):

I guess my main difficulty is that's not going to be at all what I think of as a user when I'm asking "how do I figure out which points are inside this volume?" I'd never think to look to that feature to get there, personally...

Sean (Aug 18 2020 at 19:18):

like detecting subtractions that do nothing, or replacing huge bot subtractions with minimal bot subtractions, etc

Sean (Aug 18 2020 at 19:20):

well you wouldn't necessarily think to perform boolean operations to model geometry either -- that's just fundamentally learning the system

Sean (Aug 18 2020 at 19:20):

the generality and simplicity would give it powerful flexibility too

starseeker (Aug 18 2020 at 19:22):

I guess I think of it as a fundamentally analytic operation rather than a geometric one... I would probably have tried to get it in the analyze command somehow.

Anyway. I'll see if I can tweak the existing cg code to look for a comb of the right form, but anything involving tree walking usually means a headache...

Sean (Aug 18 2020 at 19:22):

also, you're currently concerned with points, but the question of what's inside something else is not intrinsically specific to points, and the idea of the concept extending to other object types quickly gets out of control

starseeker (Aug 18 2020 at 19:24):

Agreed. Conceptually though, what's the distinction between a CSG boolean expression and a comb tree? Isn't the former a serialization of the latter?

Sean (Aug 18 2020 at 19:24):

just as likely to what to know what rpp's or sph's are inside some other object, or what triangles are inside another mesh and so on.

Sean (Aug 18 2020 at 19:25):

comb tree is an object whose structure can be queried

starseeker (Aug 18 2020 at 19:26):

Right, but I mean from the cg command's perspective - why not feed in an evaluation string? (As one of the options - not arguing against combs)

Sean (Aug 18 2020 at 19:26):

an expression is just text. maybe conforms to a structure, maybe not, is it ad hoc? is it the same as comb command's expression parser or the ted command's or some other? is it prefix? postfix? infix?

starseeker (Aug 18 2020 at 19:27):

Sure, but we already have to solve the problem anyway for the comb command.

Sean (Aug 18 2020 at 19:28):

starseeker said:

Right, but I mean from the cg command's perspective - why not feed in an evaluation string? (As one of the options - not arguing against combs)

Same reason compilers typically don't support something like: cc "int main() {printf(\"hello world\\n\"); return 0;"

starseeker (Aug 18 2020 at 19:28):

Heh - I would have thought they would, actually...

Sean (Aug 18 2020 at 19:29):

I mean they could, but imagine how a compiler expands in complexity...

Sean (Aug 18 2020 at 19:30):

there's simplicity and improved usability in having consistency, you provide a file

Sean (Aug 18 2020 at 19:30):

making cg actually mirror cc would be good for the same reasons like having search mirror find

starseeker (Aug 18 2020 at 19:32):

/me winces. I see the argument and I'm willing to give it a shot, but it feels to me like a significant sacrifice in usability and intuitiveness to require compiler-esque thinking to do geometry operations.

starseeker (Aug 18 2020 at 19:33):

So what do you want me to get set up in the cg command to be "minimally functional?" I'd like to leave the functionality at least exposed (undocumented) where it can be accessed

Sean (Aug 18 2020 at 19:33):

I don't deny that it's non-obvious, but I think it's one of those things someone learns just once and then uses it and takes it for granted.

Sean (Aug 18 2020 at 19:34):

there is an alternative design we could go with that avoids the expansion of per-type subcommands

Sean (Aug 18 2020 at 19:34):

instead of cg

Sean (Aug 18 2020 at 19:35):

cg's "intent" is to reduce / optimize / evaluate geometry into a more optimal, condensed, pre-evaluated, or compressed form

Sean (Aug 18 2020 at 19:35):

you're wanting to filter geometry

Sean (Aug 18 2020 at 19:36):

while a compiler can do this particular filtering because it's a reduction, there's plenty it can't do as a compiler

Sean (Aug 18 2020 at 19:40):

towards that end, we could go with a different verb / action command that's more focused on lower level processing like an "inside" command (or "evaluate" command with an "inside" subcommand)

Sean (Aug 18 2020 at 19:41):

probably a way to merge it into "analyze"

starseeker (Aug 18 2020 at 19:42):

That feels like a conceptually better fit to me - the cg compile could then call the analyze operations as needed for the reduction.

starseeker (Aug 18 2020 at 19:44):

We'll need to tweak analyze - right now it takes a list of object names, no subcommands.

Sean (Aug 18 2020 at 19:45):

yeah, and this is a dramatically different "output" so does beg for subcommands to differentiate

starseeker (Aug 18 2020 at 19:46):

I guess the current behavior could be characterize as "summary" - existing behavior of analyze could then become "analyze summary", which in principle might be considered minimally impacting...

starseeker (Aug 18 2020 at 19:47):

or "summarize" if we're going noun verb

Sean (Aug 18 2020 at 19:49):

could also go the switch route ala gqa

Sean (Aug 18 2020 at 19:49):

since it's the other "analyze" command that it'd likely merge with eventually

starseeker (Aug 18 2020 at 19:51):

I'll experiment with refactoring analyze a bit - that's pretty simple, from the looks of things. I'll do it in a branch though - for release I think I just need to back this whole thing out. The immediate need was met, so there's no pressing need for the pnt in/out test in the main release right now.

Sean (Aug 18 2020 at 19:51):

actually now that I'm looking...

starseeker (Aug 18 2020 at 19:52):

I'm personally not a big fan of gqa's option handling... lots of negative user karma over the years.

Sean (Aug 18 2020 at 19:52):

I suggest mirroring "analyze" like the "check" command, at least in synopsys terms

starseeker (Aug 18 2020 at 19:52):

/me checks check

Sean (Aug 18 2020 at 19:52):

right, that's why I say it

Sean (Aug 18 2020 at 19:52):

nobody remembers -Av

Sean (Aug 18 2020 at 19:53):

but "check volume obj" is pretty darn simple and declarative

starseeker (Aug 18 2020 at 19:53):

/me nods - slightly different mechanism, but this looks similar in some ways to where I ended up with the brep command

Sean (Aug 18 2020 at 19:54):

yeah, mechanism doesn't have to be the same

Sean (Aug 18 2020 at 19:54):

I see check's not using bu_opt yet, so that'd be an improvement

starseeker (Aug 18 2020 at 19:55):

is check supposed to replace or merge with analyze eventually?

starseeker (Aug 18 2020 at 19:56):

/me is mentally substituting "analyze" for "check" in front of each of these and so far they all work...

Sean (Aug 18 2020 at 19:57):

I suppose they could but there is a problem with the different output types and that might be a reason to keep them separated

starseeker (Aug 18 2020 at 19:58):

/me nods

Sean (Aug 18 2020 at 19:58):

as analyze is currently written, yeah, they totally merge as the summary it produces is also analytic, numbers, info

Sean (Aug 18 2020 at 19:58):

it's having a command whose output is geometric that becomes very distinguishing

Sean (Aug 18 2020 at 19:59):

not to say the concepts couldn't merge cleanly

Sean (Aug 18 2020 at 20:01):

analyze volume -o output obj1 obj2 could work for example, but I'd probably expect 'output' to be an attribute object of some sort

starseeker (Aug 18 2020 at 20:02):

or a txt even, in that case...

starseeker (Aug 18 2020 at 20:02):

well, bo in BRL-CAD

Sean (Aug 18 2020 at 20:02):

we don't have txt objects yet

Sean (Aug 18 2020 at 20:02):

we have binunif, that'd be an alternative

starseeker (Aug 18 2020 at 20:03):

Ah, right - couldn't remember where we were with that.

Sean (Aug 18 2020 at 20:03):

better would probably be a json-style rich object

Sean (Aug 18 2020 at 20:04):

that way it could structurally contain the whole report in structured form

Sean (Aug 18 2020 at 20:04):

there is one issue, though..

Sean (Aug 18 2020 at 20:05):

how the usage would look for this command, without having completely different syntax (i.e., complexity), what [object(s)] means

Sean (Aug 18 2020 at 20:05):

e.g., analyze inside -o output obj1 obj2 obj3

Sean (Aug 18 2020 at 20:06):

could limit it to pairs of objects, then it'd be consistent

starseeker (Aug 18 2020 at 20:09):

/me figured the subcommands would have their own syntax

Sean (Aug 18 2020 at 20:09):

could change the command too, instead of "inside" it could be "intersect" and it applies that operation to all object args, so "obj1 obj2 obj3" is treated as if it were a "obj1 x obj2 x obj3" comb expression

starseeker (Aug 18 2020 at 20:11):

/me is OK with limiting inside to pairs, at least for a first cut

Sean (Aug 18 2020 at 20:11):

starseeker said:

/me figured the subcommands would have their own syntax

that's usually a sign they either don't belong together, or the design hasn't been sorted out to make it consistent ... otherwise, there's little point in them being subcommanded together when all the args that follow are different

Sean (Aug 18 2020 at 20:12):

we have a few mashups like that currently

Sean (Aug 18 2020 at 20:12):

they're usability nightmares imho

Sean (Aug 18 2020 at 20:12):

I know them, and I have to pull up the usage every time. that's just bad design.

starseeker (Aug 18 2020 at 20:13):

/me sees it mainly as a conceptual grouping - sort of like svn's subcommand's are all SVN related, even if they're individually very different.

starseeker (Aug 18 2020 at 20:14):

Or the per-primitive subcommands

Sean (Aug 18 2020 at 20:16):

er, nearly all of svn commands just take paths... super consistent

Sean (Aug 18 2020 at 20:16):

the deviation is on their options, not on what follows the options

Sean (Aug 18 2020 at 20:16):

big difference

starseeker (Aug 18 2020 at 20:17):

I guess I was thinking about svn merge taking two paths, where svn add can take many - that sort of thing

starseeker (Aug 18 2020 at 20:17):

well, three if you count the destination

starseeker (Aug 18 2020 at 20:18):

propset and friends I think are fairly structured as well

Sean (Aug 18 2020 at 20:20):

I'd just like to also acknowledge that considering the complexity of a revision control system is probably a terrible usability pattern to follow regardless ... :D

Sean (Aug 18 2020 at 20:20):

s/acknowledge/propose/

starseeker (Aug 18 2020 at 20:21):

/me grins - I actually go the other way. I think it's a good mapping to the conceptual complexity of the problem spaces we're working with.

Sean (Aug 18 2020 at 20:21):

I mean we're not talking about anything anywhere near as complex -- nearly everything we have can be simplified and made consistent because we have a specific taxonomy that is constrained

Sean (Aug 18 2020 at 20:22):

the complexity a developer puts up with is not on par of that of general users

Sean (Aug 18 2020 at 20:23):

we have a highly biased perspective as devs. it's helpful to be aware of that and resist complexity where we can through more considered design.

Sean (Aug 18 2020 at 20:24):

i'm happy to think through the design implications if you're not -- I just don't think we should punt and add options and have 2/3/4 synopsis lines to document command where we can avoid it

Sean (Aug 18 2020 at 20:26):

this seems like an easy case for example. we can just apply the same op to all listed objects in succession

starseeker (Aug 18 2020 at 20:27):

Well, there are subtitles with that - what does it mean, for example, to have a sph followed by a point cloud followed by an arb?

starseeker (Aug 18 2020 at 20:27):

That's the hesitation your sensing, I think - we can probably come up with a two object interpretation easily enough, but I'm not sure how it scales.

Sean (Aug 18 2020 at 20:28):

the operation you're using is still simply an intersection

Sean (Aug 18 2020 at 20:28):

A intersect B

Sean (Aug 18 2020 at 20:28):

A intersect B intersect C

starseeker (Aug 18 2020 at 20:29):

but what's the output? the points from the point cloud? the subset of the sphere from a gqa segment grid that overlaps the volumes of the other shapes?

Sean (Aug 18 2020 at 20:29):

the output is the geometric intersection of the three sets...

Sean (Aug 18 2020 at 20:30):

A intersect B where either is a pnts object will always be a pnts object or the nul set

Sean (Aug 18 2020 at 20:30):

that holds for any number of subsequent intersections

Sean (Aug 18 2020 at 20:30):

always a pnts result or nul

Sean (Aug 18 2020 at 20:31):

also generalizes nicely and can be extended to things like bot intersect bot

starseeker (Aug 18 2020 at 20:33):

So for points we have an answer - what should we return for (say) two CSG spheres?

Sean (Aug 18 2020 at 20:37):

we don't have a single implicit object that can represent the result, so I'd expect it to either return a comb with "A x B" (assuming we're talking about geometric output) or return a nurbs object with the evaluated result

Sean (Aug 18 2020 at 20:37):

would be an awesome place to hook the latter

starseeker (Aug 18 2020 at 20:37):

Now that you mention it I think there is a brep intersect subcommand somewhere...

Sean (Aug 18 2020 at 20:38):

could also envision there being something like a -t type option where you could specify bot, dsp, or some other object type

Sean (Aug 18 2020 at 20:38):

there is

starseeker (Aug 18 2020 at 20:38):

I guess the other risk of putting a general syntax out there is users are going to try a whole bunch of things we don't have implemented - won't there be a risk of negative perceptions about our capability/quality/completeness?

Sean (Aug 18 2020 at 20:39):

facetize does it for bots

starseeker (Aug 18 2020 at 20:39):

sort of another version of the step importer not handling a lot of things...

Sean (Aug 18 2020 at 20:42):

I think it'd be fine if it aborts with an error saying "ERROR: analyze intersect support limited to 'comb'+'pnts' objects" for starters. Documents the scope, sets expectation, and is easily expanded as support expands.

Sean (Aug 18 2020 at 20:43):

not that we should leave it that limited for long. I think the comb fallback would be good to implement off the bat so it's well behaved on anthing

starseeker (Aug 18 2020 at 20:44):

So another interpretation question - if I intersect two pnts sets, do I return only the points that are in both sets within tolerance?

Sean (Aug 18 2020 at 20:44):

that would be my expectation and interpretation, yes

Sean (Aug 18 2020 at 20:46):

someone wanting something else implies another operation, like this: analyze convexhull -o hull pnts; analyze intersection -o volpnts hull pnts2;

starseeker (Aug 18 2020 at 20:46):

OK. That's a separate implementation, so I'll have to think about how to do the pre-processing - whether to find and intersect pnt clouds first and then check them against other volumes...

starseeker (Aug 18 2020 at 20:48):

I'll make a branch and work with it a bit.

starseeker (Aug 18 2020 at 21:04):

Another interpretation question - what if someone unions a point cloud into an otherwise volumetric CSG hierarchy? Is it a no-op under those conditions?

Sean (Aug 18 2020 at 21:04):

you mean intersects?

starseeker (Aug 18 2020 at 21:05):

Well, I can think of a couple cases. If we do want to intersect it, what if the CSG hierarchy subtracts a volume from the point cloud? Do we first "strip down" the point cloud per the CSG hierarchy and then intersect it?

Sean (Aug 18 2020 at 21:05):

if it's unioned, it'll be essentially a no-op unless the ray happens to hit the pnt exactly or the pnts have a diameter

Sean (Aug 18 2020 at 21:06):

the functionally act like spheres

Sean (Aug 18 2020 at 21:06):

so really no different

Sean (Aug 18 2020 at 21:06):

just the radii might be infintessimally small (or they could be huge)

starseeker (Aug 18 2020 at 21:07):

But if we intersect two point clouds as discussed earlier (toleranced distance comparison) then the point cloud will act differently in a hierarchy

starseeker (Aug 18 2020 at 21:08):

Would that be surprising?

Sean (Aug 18 2020 at 21:08):

keep in mind that would be an analyzed intersection, which is what allows the tolerance and resulting behavior to be specified

Sean (Aug 18 2020 at 21:08):

the result is a pnt cloud

Sean (Aug 18 2020 at 21:09):

i'm not entirely following -- what would be surprising?

Sean (Aug 18 2020 at 21:10):

if I create rppA, pntsA, and pntsB; and combA is "pntsA - rppA" to cull some point, that's all pretty straightforward

Sean (Aug 18 2020 at 21:11):

if I "analyze intersection -o pntsC pntsA pntsB", thn pntsC will have those in common to both

Sean (Aug 18 2020 at 21:12):

explicitly

Sean (Aug 18 2020 at 21:12):

if I "comb combB pntsA x pntsB", thats the same result, but implicitly

starseeker (Aug 18 2020 at 21:12):

So, given a pnt cloud A intersecting with a hierarchy B containing pnt cloud C. If pnts in C are close within tolerance to pnts in A, such that A intersect C would yield a subset of point common to A and C, but A intersection tests against the hierarchy B using a ray in/out test points that would be part of the intersection only by the action of the point cloud C (i.e. none of the rest of volume of B interacts with A) would be skipped because the raytracing test would fail.

Sean (Aug 18 2020 at 21:14):

that's one massive run-on sentence... I'm having trouble parsing it

starseeker (Aug 18 2020 at 21:14):

So in the limit case, intersect point cloud A with the hierarchy B containing A and a sph C that doesn't overlap A at all.

starseeker (Aug 18 2020 at 21:15):

A ray inside test against B from any point in A will report outside.

starseeker (Aug 18 2020 at 21:15):

But A intersect A will return the set A.

Sean (Aug 18 2020 at 21:15):

when you say intersect, do you mean in the context of a comb intersect operation or this new intersection/intersect command?

starseeker (Aug 18 2020 at 21:16):

the new intersect command

Sean (Aug 18 2020 at 21:16):

okay

starseeker (Aug 18 2020 at 21:17):

I'm thinking about how I implemented the inside/outside test and what the implications are (or trying to - it's causing run-on sentences...)

Sean (Aug 18 2020 at 21:17):

if you have a point cloud A and a hierarchy B containing A (unioned), the result is going to be point cloud A...

starseeker (Aug 18 2020 at 21:18):

But I don't think it will - the ray interrogation won't report inside unless something other than A in the hierarchy contains pnts in A.

starseeker (Aug 18 2020 at 21:19):

Or put A' rather than exactly A in the hierarchy - just enough to throw off trivially exact hits, but close enough to pass a tolerance distance check.

Sean (Aug 18 2020 at 21:19):

I'm not saying what your code does, I don't know what it does.. i"m saying set theory is that A x A = A

starseeker (Aug 18 2020 at 21:20):

Right. But my point is I have to do two different comparisons when faced with A vs A' and A vs B - the latter uses the solid raytracer, and the former can't

starseeker (Aug 18 2020 at 21:21):

So I'll get different answers for A' depending on whether it is inside a hierarchy B or not, which seems wrong.

Sean (Aug 18 2020 at 21:21):

are you talking about the current limitation that pnts don't report hits from shot()??

starseeker (Aug 18 2020 at 21:22):

Kind of - but I think it's more fundamental than that...

Sean (Aug 18 2020 at 21:22):

if so, then yeah absolutely have to handle pnts specifically because they don't have a raytrace interpretation

Sean (Aug 18 2020 at 21:22):

ignore the tolerance issue first

starseeker (Aug 18 2020 at 21:23):

Right, so when we evaluate B (which uses the raytracer) there's a problem if a pnt cloud is included in B since the test won't work.

Sean (Aug 18 2020 at 21:23):

right but that's specifically because of this implementation detail, not theory -- you have to handle pnts

Sean (Aug 18 2020 at 21:23):

or implement shot() for them

starseeker (Aug 18 2020 at 21:25):

I'll have to construct a test case and see what happens, I guess - I think I know but I might be wrong.

Sean (Aug 18 2020 at 21:26):

it sounds like you're talking about an implementation concern, which is very much a yes -- you have to handle pnts and by handle pnts that means you have to recognize one is a pnts object and for each point, evaluate it against the other object

Sean (Aug 18 2020 at 21:27):

and if that other object is a comb, you'd have to scan it's logic and look for pnts (applying the right boolean recipe down the hierarchy) to evaluate them with a pnt-to-pnt distance calculation to get the right result...

starseeker (Aug 18 2020 at 21:28):

But if the other object is a mixed object (pnts unioned with other solids) what is the interpretation of the pnts object in the hierarchy? Is it OK to return none of those points since they're zero volume in a CSG hierarchy of solids, or do we need to somehow figure out which points in the hierarchy survive the boolean ops and test them as individual points?

Sean (Aug 18 2020 at 21:28):

or implement shot() and just look at whether your point is within the other object's partition list... ;)

Sean (Aug 18 2020 at 21:29):

starseeker said:

But if the other object is a mixed object (pnts unioned with other solids) what is the interpretation of the pnts object in the hierarchy? Is it OK to return none of those points since they're zero volume in a CSG hierarchy of solids, or do we need to somehow figure out which points in the hierarchy survive the boolean ops and test them as individual points?

to return the right set.. the latter!

Sean (Aug 18 2020 at 21:29):

unless you implement shot()

starseeker (Aug 18 2020 at 21:29):

Assuming my test rays happened to pass close enough to the other points to register... this is starting to sound nasty.

Sean (Aug 18 2020 at 21:30):

you know all it takes to minimally implement shot() is to iterate over all pnts and call sph_shot(). could even create a db of spheres during prep so you get spatial partitioning.

Sean (Aug 18 2020 at 21:31):

without implementing shot, you can just check the comb and only support whatever is easy

Sean (Aug 18 2020 at 21:31):

reject the complicated as not yet implemented

starseeker (Aug 18 2020 at 21:32):

heh - another use of the db_search filter

Sean (Aug 18 2020 at 21:32):

like you could support pnts+non-comb for starters, don't even support combs.

Sean (Aug 18 2020 at 21:32):

but seriously, shot() on pnts is downright trivial to implement

Sean (Aug 18 2020 at 21:33):

i I didn't have these commits I'm working through, I could have had an initial demo working already :)

starseeker (Aug 18 2020 at 21:33):

I don't know that that would be enough though - six rays for inside/outside solids vs. distance comparisons of pnt clouds are still different tests.

Sean (Aug 18 2020 at 21:33):

six what??

starseeker (Aug 18 2020 at 21:34):

that's how I'm doing the inside outside test - looking in +- X, Y and Z directions

Sean (Aug 18 2020 at 21:34):

uh, don't do that...

starseeker (Aug 18 2020 at 21:35):

Are the numerics solid enough to trust one ray?

starseeker (Aug 18 2020 at 21:36):

especially for bots and the like, I was concerned with edge cases

Sean (Aug 18 2020 at 21:37):

So you're willing to 6-folding the computational cost because of concern, without actually knowing...

Sean (Aug 18 2020 at 21:37):

heh, even if you care about edge cases, 3 rays would've been adequate

Sean (Aug 18 2020 at 21:38):

rays are infinite, you just need to backout the starting point

starseeker (Aug 18 2020 at 21:39):

/me shrugs - I was throwing something together to see if it worked, wasn't especially worried about performance.

Sean (Aug 18 2020 at 21:40):

that said, for this, I don't see without evidence why you'd want more than 1 ray per point. you shoot through the point from outside the bounds, and if that point is within a partition, it's a match

Sean (Aug 18 2020 at 21:41):

starseeker said:

/me shrugs - I was throwing something together to see if it worked, wasn't especially worried about performance.

heh, the same books that talk about premature optimization also talk very adamantly about making order-of-magnitude changing decisions like that without considering the implications!

Sean (Aug 18 2020 at 21:42):

that's so far beyond not being worried about performance...

starseeker (Aug 18 2020 at 21:43):

I knew there are grazing rays on objects that report solid partitions beyond their volume, so I just threw multiple directions at it to preclude that being an issue. Your right 3 would have done it.

Sean (Aug 18 2020 at 21:43):

even still

Sean (Aug 18 2020 at 21:44):

you're talking about plate mode

starseeker (Aug 18 2020 at 21:44):

I've seen it on NURBS

starseeker (Aug 18 2020 at 21:44):

(solid NURBS)

Sean (Aug 18 2020 at 21:47):

true, plate mode and nurbs can return incorrect partitions on grazing rays

Sean (Aug 18 2020 at 21:48):

but it's not right and shouldn't be allowed to spread like a disease to other algorithms because they got it wrong -- at least that's fundamentally wrong in my humble opinion

Sean (Aug 18 2020 at 21:48):

we should fix them, or get whoever is wanting this feature to pay us to fix them

Sean (Aug 18 2020 at 21:49):

could also reject those two -- relatively rare at this point -- outliers in the analyze command when it validates the args

Sean (Aug 18 2020 at 21:51):

plate mode is just wrong-wrong and shouldn't be accommodated anywhere imho.. nurbs is obviously a harder issue but can probably be handled in code by looking at the grazing flag and only shooting a second ray when it grazes

starseeker (Aug 18 2020 at 21:52):

@Sean as for who is wanting the point-inside-solid feature - it's just something I threw together for Caleb

Sean (Aug 18 2020 at 21:53):

I know, all the more reason I'd be concerned with what's left .. he's effectively done already

Sean (Aug 18 2020 at 21:54):

(i mean left in the code, it's going to long outlast his involvement and residual impact)

starseeker (Aug 18 2020 at 21:54):

Well, the original bit was part of the facetization work for Dave a while back. It's used by one of the fallback algorithms.

starseeker (Aug 18 2020 at 21:54):

(I already backed out the bit I put in for him in trunk.)

starseeker (Aug 18 2020 at 21:55):

That's why I was way more worried about robustness than performance at that juncture - I think it was some sort of crunch project for Dave.

Sean (Aug 18 2020 at 21:56):

Honestly, I think you should just shoot a ray through the point and if it returns a bogus result because the partitions are wrong, so be it -- that puts pressure on fixing the partition list, however small, over time. and it's completely justifiable.

starseeker (Aug 18 2020 at 21:58):

At the expense of distorted or failed factorization cases that would otherwise succeed? (Maybe that's not a serious risk - as you say I don't have stats on if or how frequent it is - but it would be a failure where we could potentially have succeeded.)

Sean (Aug 18 2020 at 21:58):

I don't mean to put you on the defensive.

starseeker (Aug 18 2020 at 22:00):

Sorry. I'm game to clean it up, if it makes sense to spend time on it.

Sean (Aug 18 2020 at 22:01):

I'll give you facetization just because we've hammered at that for decades unsuccessfully.

Sean (Aug 18 2020 at 22:01):

I don't think that liberty extends anywhere else in the code, though.

starseeker (Aug 18 2020 at 22:02):

Sure. I only pulled it from there 'cause when Caleb asked I remembered it being there - if it comes out "for real" we can certainly clean it up.

Sean (Aug 18 2020 at 22:03):

Until we can facetize reliably, or at least consistently complete, whatever that means, that's very much in the "lets get anything working camp".

starseeker (Aug 18 2020 at 22:04):

(By the way, one other case I know of where a ray test will fail is small triangles in meshes - I hit that with the JASP work earlier this year. I've got a unit test in there somewhere were I captured and isolated an individual triangle that gives the wrong answer.)

starseeker (Aug 18 2020 at 22:06):

That's why I'm using Dickinson's code, slow as it is, for the new brep meshing.

Sean (Aug 18 2020 at 22:06):

I'd still cringe at 6x vs 3x performance decisions in there if they're frequent, but as I said -- it is what it is until it works and facetize gets a hard pass because we've tried for so long.

Sean (Aug 18 2020 at 22:07):

I think it DOES matter the moment that code is used anywhere else though. Might as well not exist for use outside without having a critical re-write if it's been developed with a gloves-off approach.

starseeker (Aug 18 2020 at 22:08):

Fair enough.

Sean (Aug 18 2020 at 22:10):

starseeker said:

That's why I'm using Dickinson's code, slow as it is, for the new brep meshing.

With all due respect, this is rather dangerous thinking from an architecture and maintenance perspective. It means we have multiple shotliners doing different things. Both being maintained, both eventually being debugged. Both with potentially completely disjoint sets of bugs.

Sean (Aug 18 2020 at 22:10):

It's a green pasture fallacy. One works with a code long enough to find a flaw.

Sean (Aug 18 2020 at 22:11):

and then abandons using that code because of the flaw, in favor of something else less known but maybe known for that case

Sean (Aug 18 2020 at 22:12):

that's literally the struggle mentality we have with the s2 folks that have been replicating their own geometry code instead of investing in one place.

Sean (Aug 18 2020 at 22:13):

short term benefit, long term death

starseeker (Aug 18 2020 at 22:17):

It's the src/libbg/trimesh_pt_in.c point-in-polyhedron test. I ran it directly, side by side with the ray based inside/outside test and inspected reported differences - I'd be glad to ditch it if the issues with the ray test can be resolved, but I'm not sure yet how to do that without potentially impacting performance in some other way or introducing other breakage.

starseeker (Aug 18 2020 at 22:20):

(I remember when Keith tried to adjust our triangle intersection logic for small triangles and ended breaking the raytrace at larger scales, so I know it's not trivial...)

Sean (Aug 18 2020 at 22:22):

I know, that's why I didn't say anything when it was introduced, but those kinds of decisions do have significant consequence long term. If there's not time to debug it when you have the error right in front of you and a task that's provoking it, when else will it ever be prioritized? It simply won't and we end up with the duplication, complexity, and increasing costs.

Sean (Aug 18 2020 at 22:22):

it's a paper cut. any one of them can be tolerated.

Sean (Aug 18 2020 at 22:25):

and then we spend months defending against things like particular three-letter systems that can be adapted and changed far more easily because they aren't having to maintain that kind of cruft. and often have just as many or more issues, just not yet noticed.

Sean (Aug 18 2020 at 22:33):

if someone came across it perusing code without knowing the history, they would be entirely justified replacing the perceived duplication without hesitation for something in bn or rt. best we can hope for is putting up signs in the code that typically just scare away anyone but the original author from changing the code.

starseeker (Aug 18 2020 at 22:35):

And I agree that's far from ideal, but I'm not sure what else to do.

Sean (Aug 18 2020 at 22:42):

could debug the small triangle case, understand what's failing (if it really is failing) and why (more importantly). point in polyhedron is a very simple time-tested function in use throughout industry. there's only a few variants that mostly center around when/how a particular division happens.

Sean (Aug 18 2020 at 22:43):

If ours is failing, it's probably related to floating point tolerances used in the implementation, not likely the algorithm itself.

starseeker (Aug 20 2020 at 02:19):

I've taken an initial whack at the analyze command refactor here: https://sourceforge.net/p/brlcad/code/HEAD/tree/brlcad/branches/analyze_cmd/src/libged/analyze/

Current usage looks like:

analyze obj.s ... - old behavior, except when obj.s matches a command name.
analyze summarize obj.s ... - old behavior
analyze intersect -o interior.pnts pnts.s sph.s ... - intersect pnts object with one or more volumes, generate output pnts object
analyze subtract -o exterior.pnts pnts.s sph.s ... - subtract pnts from object that are inside one or more volumes, generate output pnts object.

I also made a stab at cleaning up the inside/outside test - it's in op_pnts_vol.cpp, uses one backed out ray.

Last updated: Jan 09 2025 at 00:46 UTC