Prev: close figure in MATLAB
Next: Realtime Windows Target causes Blue-Screen-Of-Death error
From: Chris Middleton on 28 Jun 2010 05:19
Thanks for taking the time to read this and any help would be greatly appreciated.

My collegues and I have developed software within Matlab which uses the (soon to be obsolete) function delaunay to create meshes. Along with this, the software also imports custom meshes in the same format. It is essential to be able to select the traingles along a path; currently tsearch is being used extensivly in our software.

The problem will be when tsearch is no longer availible. We can easily change to DelaunayTri for the meshes created withing Matlab and then use pointLocation. However, it does not seem possible for our custom meshes. You can place the custom meshes within the TriRep class but it does not seem possible to convert this to a DelauneyTri class.

Unfortunately there is no pointLocation kind of method for TriRep.

Thanks for any help.

Chris
From: Rune Allnor on 28 Jun 2010 05:29
On 28 Jun, 11:19, "Chris Middleton" <chrism...(a)hotmail.com> wrote:
> Thanks for taking the time to read this and any help would be greatly appreciated.
>
> My collegues and I have developed software within Matlab which uses the (soon to be obsolete) function delaunay to create meshes.  Along with this, the software also imports custom meshes in the same format.  It is essential to be able to select the traingles along a path; currently tsearch is being used extensivly in our software.
>
> The problem will be when tsearch is no longer availible.  We can easily change to DelaunayTri for the meshes created withing Matlab and then use pointLocation.  However, it does not seem possible for our custom meshes.  You can place the custom meshes within the TriRep class but it does not seem possible to convert this to a DelauneyTri class.
>
> Unfortunately there is no pointLocation kind of method for TriRep.
>
> Thanks for any help.
>
> Chris

In other words, you are asking about the internal representation
of the meshes with the new functions.

Don't have too high hopes, these things are seriously complicated
with a number of possible algorithms, each with a myriad of
variations.
The problem is that efficient point location algorithms build a
search
data structure along with the mesh. So you can not just export the
vertices and edges between software packages, you also need to export
the exact topology of the mesh (which edges emanate from a given
vertice,
their relative order) as well as on a format that is understood by
the
target software.

You might actually find that it is easier if you start from scratch
and re-code everything with the new matlab functions, including
the stuff you so far have done in other packages.

Rune
From: Chris Middleton on 28 Jun 2010 05:59
Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <78db5029-8110-4781-849f-ff0dcf8a175c(a)r27g2000yqb.googlegroups.com>...
> On 28 Jun, 11:19, "Chris Middleton" <chrism...(a)hotmail.com> wrote:
> > Thanks for taking the time to read this and any help would be greatly appreciated.
> >
> > My collegues and I have developed software within Matlab which uses the (soon to be obsolete) function delaunay to create meshes.  Along with this, the software also imports custom meshes in the same format.  It is essential to be able to select the traingles along a path; currently tsearch is being used extensivly in our software.
> >
> > The problem will be when tsearch is no longer availible.  We can easily change to DelaunayTri for the meshes created withing Matlab and then use pointLocation.  However, it does not seem possible for our custom meshes.  You can place the custom meshes within the TriRep class but it does not seem possible to convert this to a DelauneyTri class.
> >
> > Unfortunately there is no pointLocation kind of method for TriRep.
> >
> > Thanks for any help.
> >
> > Chris
>
> In other words, you are asking about the internal representation
> of the meshes with the new functions.
>
> Don't have too high hopes, these things are seriously complicated
> with a number of possible algorithms, each with a myriad of
> variations.
> The problem is that efficient point location algorithms build a
> search
> data structure along with the mesh. So you can not just export the
> vertices and edges between software packages, you also need to export
> the exact topology of the mesh (which edges emanate from a given
> vertice,
> their relative order) as well as on a format that is understood by
> the
> target software.
>
> You might actually find that it is easier if you start from scratch
> and re-code everything with the new matlab functions, including
> the stuff you so far have done in other packages.
>
> Rune

Thanks for a quick reply.

So the imported mesh is in the same format. If you imagine the DelaunayTri class is a strcuture, I can put the imported data in exactly the same format. All i then want to do is use the pointLocation method on my imported data, which isn't possible.

I don't want to remesh the data in Matlab as the meshing would be a little different and no longer comparible with the software is was exported from. So ideally I want to override the automatic meshing in DelaunayTri and say how it should be meshed.

With the old functions this was possible.

Chris
From: Rune Allnor on 28 Jun 2010 06:07
On 28 Jun, 11:59, "Chris Middleton" <chrism...(a)hotmail.com> wrote:

> So the imported mesh is in the same format.  If you imagine the DelaunayTri class is a strcuture, I can put the imported data in exactly the same format.  All i then want to do is use the pointLocation method on my imported data, which isn't possible.

It might have been *possible* in the past, but it was not
*efficient*.

I'd hazard a guess that the old functions used a brute force
search to find which triangle of the mesh, if any, contains
the query point.

You can implement that kind of thing yourself, quite easily.
It wouldn't take that much to come up with a 'fast' MEX version
either.

I would expect these new functions to use the far more efficient
point location algorithms that require knowledge of the intimate
details of the mesh that would only be know deep inside the
triangulation engine.

Rune
From: Chris Middleton on 28 Jun 2010 07:26
Rune Allnor <allnor(a)tele.ntnu.no> wrote in message <65af5d39-2662-4f31-a7c5-c5c0e22c7a4b(a)d16g2000yqb.googlegroups.com>...
> On 28 Jun, 11:59, "Chris Middleton" <chrism...(a)hotmail.com> wrote:
>
> > So the imported mesh is in the same format.  If you imagine the DelaunayTri class is a strcuture, I can put the imported data in exactly the same format.  All i then want to do is use the pointLocation method on my imported data, which isn't possible.
>
> It might have been *possible* in the past, but it was not
> *efficient*.
>
> I'd hazard a guess that the old functions used a brute force
> search to find which triangle of the mesh, if any, contains
> the query point.
>
> You can implement that kind of thing yourself, quite easily.
> It wouldn't take that much to come up with a 'fast' MEX version
> either.
>
> I would expect these new functions to use the far more efficient
> point location algorithms that require knowledge of the intimate
> details of the mesh that would only be know deep inside the
> triangulation engine.
>
> Rune

Thanks Rune, what you say makes sense. I was just hoping against writing my own brute force code as my coding will not me as effecient as the Matlab code.

Chris
 |  Next  |  Last
Pages: 1 2
Prev: close figure in MATLAB
Next: Realtime Windows Target causes Blue-Screen-Of-Death error