Happy birthday Ch3ck.
Say hi to your wife and the seven-year old kid.
On Fri, Jul 19, 2013 at 9:18 PM, <[email protected]
> wrote:
> Send brlcad-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of brlcad-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Idea for surface/surface sub-surface intersections
> (Clifford Yapp)
> 2. Re: Idea for surface/surface sub-surface intersections
> (Christopher Sean Morrison)
> 3. GSoC midterm approaching (Christopher Sean Morrison)
> 4. Hello (check.nyah)
> 5. Re: Hello (Christopher Sean Morrison)
> 6. Re: Hello (check.nyah)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 19 Jul 2013 07:32:02 -0400
> From: Clifford Yapp <[email protected]>
> Subject: Re: [brlcad-devel] Idea for surface/surface sub-surface
> intersections
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID:
> <
> cahsgyarzvnd_vdqfrnt3x-y+4rffwd6arx7bop+imuh0tgx...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Jul 18, 2013 at 11:47 PM, phoenix <[email protected]> wrote:
>
>
> > As currently we can get the boundary curve segments of the overlap
> regions
> > (with "noisy" segments), the next we should do may be to construct the
> > overlap regions with the boundary information. See the figure attached.
> In
> > gray is the "knot grid" of the surface. If we sub-divide the surface to
> > Bezier patches, each patch should be correspondent to one grid (a small
> > square). And overlap regions must be bounded by the boundaries of the
> > Bezier patches, which are the vertical or horizontal lines in the figure
> > (or that of the other surface and projected to this surface's UV space,
> > that's why we have a non-linear curve here). So we tests the vertical
> lines
> > and horizontal lines with the other surfaces with curve-surface overlaps
> > (vice versa), and we get the blue and red segments. The blue ones should
> be
> > the finally boundary while the red ones are "noise" and should be
> > eliminated. As we know, the boundary of a close overlap region should
> form
> > a loop, so we link curves that share a same end point together, and
> finally
> > the blue segments are link together to a closed loop, while the red ones
> > cannot be linked together. (More discussions are needed for this step,
> > because I'm not sure whether it can work for all cases.)
> >
>
> Excellent picture, that helps a lot - yes, I think we agree, as long as
> that other paper's assertion that once we're down to Bezier patches we
> won't have any "patch internal" shared sub-surface intersection activity
> without involving the edges proves to be correct.
>
> After we get the boundaries, we need to decide whether it's an outer loop
> > (the overlap is inside the closed region) or an inner loop (the overlap
> is
> > outside the closed region).
> >
>
> Won't we know that already? If we have a set of loops in UV space and the
> "red" grid identifies the contiguous sub-pieces of the patch, the loop
> whose 2D bounding box contains all the 2D bounding boxes of the other loops
> is the outer loop for that "patch". Any inner loop of blue lines that is
> not fully inside another "inner" loop's bounding box is an inner trimming
> loop to the outer loop. Any "inner" loop that *is* fully within the
> bounding box of another inner loop would have to be a new outer loop for a
> new surface, working within the constraints of how openNURBS defines
> surfaces with trims.
>
> I remember having to decide which loop was an "outer" loop for the mesh ->
> nurbs logic, and the best test I could come up with was the 2D bounding box
> in the projection. (In that case, because of the nature of the patches, it
> was an actual 3D projection of the patch to a plane, but doing the test in
> the UV domain may actually make a lot more sense - it should be much more
> robust.)
>
>
> > We may like to choose an arbitrary point inside that region (take care of
> > there may be also an inner loop inside), and tests it's an overlap point
> or
> > not.
> >
>
> Maybe I'm not following properly, but will there be a situation involving
> Bezier patches where knowing which are the "red", "gray" and "blue" lines
> won't give us sufficient information? I.e. do we need to test the patch
> interiors when we know what is happening on their boundaries, and where
> ("blue" lines) there is a behaviour change between shared and non-shared?
> I.e. a patch that has all four edges red is part of *some* intersection
> surface, which one being determined by the smallest outer loop that is
> fully bounding its bounding box?
>
> Cheers,
> CY
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 2
> Date: Fri, 19 Jul 2013 10:07:45 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: Re: [brlcad-devel] Idea for surface/surface sub-surface
> intersections
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jul 19, 2013, at 7:32 AM, Clifford Yapp wrote:
>
> > Excellent picture, that helps a lot - yes, I think we agree, as long as
> that other paper's assertion that once we're down to Bezier patches we
> won't have any "patch internal" shared sub-surface intersection activity
> without involving the edges proves to be correct.
>
> It's a shame we have to use Bezier patches at all. I wonder if sorting
> through the surface tree to find overlapping subregions would be faster
> (since it's work we already had to do, yes?) than the work to decompose
> into Bezier patches and back. It'd be sampled, but should be no worse than
> our ray tracing.
>
> Just a thought.
>
> The slower this evaluation is, the harder we're going to have to work at
> optimization later because we're going to ultimately need the evaluation to
> happen within a couple seconds for most of our sample geometry.
>
> Cheers!
> Sean
>
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 19 Jul 2013 14:06:54 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: [brlcad-devel] GSoC midterm approaching
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> The GSoC midterm evaluations are less than two weeks away! Mentors,
> please check in with your students if they've not reported their progress
> lately and check on the status of their work. Students, this is your
> reminder to check your timeline and see whether you're on-track. Make sure
> your dev log is up to date, commits/patches/discussions are daily, and let
> others know what you're up to.
>
> I do have one specific request for each of the mentors -- actually, from
> every committer. Please review and help resolve at least one open patch
> [1].
>
> We have MANY unreviewed patch submissions that have built up and I believe
> two or three GSoC devs that don't yet have commit access (but may be
> eligible if their patches are perfect). Some (most) are backed up because
> of release preparations, others because they were late or had problems,
> *and* we have increased contributions from other new contributors.
>
> There are 20+ open patches since June and I obviously can't personally
> review them all that quickly! ;) So please, if you have commit access, do
> take the time to help resolve at least one patch, any open patch, within
> the next couple days.
>
> Cheers!
> Sean
>
> [1] https://sourceforge.net/p/brlcad/patches/
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 19 Jul 2013 21:02:54 +0100
> From: "check.nyah" <[email protected]>
> Subject: [brlcad-devel] Hello
> To: cliffyapp <[email protected]>, BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID:
> <CA+W8M+9+zKFGnFFaxU2k5fK+n1qRG1iuG=
> [email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi Everyone,
>
> I will like all developers and GSoC participants for BRL-CAD to join me in
> celebrating my birthday tomorrow.
> which I will be taking the day off to celebrate at home with friends and
> family.
>
> Cheers!
>
> Nyah
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 5
> Date: Fri, 19 Jul 2013 16:13:35 -0400
> From: Christopher Sean Morrison <[email protected]>
> Subject: Re: [brlcad-devel] Hello
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=us-ascii
>
>
> On Jul 19, 2013, at 4:02 PM, check.nyah wrote:
>
> > Hi Everyone,
> >
> > I will like all developers and GSoC participants for BRL-CAD to join me
> in celebrating my birthday tomorrow.
> > which I will be taking the day off to celebrate at home with friends and
> family.
>
> Hope you have a fantastic birthday!
>
> Cheers,
> Sean
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 19 Jul 2013 21:18:46 +0100
> From: "check.nyah" <[email protected]>
> Subject: Re: [brlcad-devel] Hello
> To: BRL-CAD Developer Mailing List
> <[email protected]>
> Message-ID:
> <
> ca+w8m+-r5uoyaycrc8daocrs0srooc16knnublot4j+g-oy...@mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Thanks Sean :)
>
>
> On Fri, Jul 19, 2013 at 9:13 PM, Christopher Sean Morrison
> <[email protected]>wrote:
>
> >
> > On Jul 19, 2013, at 4:02 PM, check.nyah wrote:
> >
> > > Hi Everyone,
> > >
> > > I will like all developers and GSoC participants for BRL-CAD to join me
> > in celebrating my birthday tomorrow.
> > > which I will be taking the day off to celebrate at home with friends
> and
> > family.
> >
> > Hope you have a fantastic birthday!
> >
> > Cheers,
> > Sean
> >
> >
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> > _______________________________________________
> > BRL-CAD Developer mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/brlcad-devel
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> ------------------------------
>
> _______________________________________________
> brlcad-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
> End of brlcad-devel Digest, Vol 350, Issue 2
> ********************************************
>
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
