Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-04-07 Thread Daniel Roßberg
Rakshika,

Maybe you should write yourself some code which tests your ideas for
feasibility.

Daniel
Am 07.04.2016 3:14 nachm. schrieb "Rakshika Bagavathy" <
rakshika.bagava...@gmail.com>:

> Daniel,
>
> Sorry for the lack of interaction, i'm in the middle of my tests and
> assignments.
> What i meant was not incorporating OpenSCAD code as such, but just
> elements that reflect it. Meaning, we make a data strcuture which has
> variables that are either present in BRL-CAD or OpenSCAD. This way the
> conversion process becomes hassle-free. For any element of the data
> structure which is not applicable to either one of the organisations, we
> just place a NULL value.
> The OpenSCAD primitive looks quite different from the BRL-CAD, i haven't
> been able to spend much time on it. I will get back as soon as i can, with
> concrete substance of what exactly i mean.
>
> Regards,
> Rakshika.
>
>
> --
>
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-04-07 Thread Rakshika Bagavathy
Daniel,

Sorry for the lack of interaction, i'm in the middle of my tests and
assignments.
What i meant was not incorporating OpenSCAD code as such, but just elements
that reflect it. Meaning, we make a data strcuture which has variables that
are either present in BRL-CAD or OpenSCAD. This way the conversion process
becomes hassle-free. For any element of the data structure which is not
applicable to either one of the organisations, we just place a NULL value.
The OpenSCAD primitive looks quite different from the BRL-CAD, i haven't
been able to spend much time on it. I will get back as soon as i can, with
concrete substance of what exactly i mean.

Regards,
Rakshika.
--
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-04-01 Thread Daniel Roßberg
2016-04-01 11:25 GMT+02:00 Rakshika Bagavathy :
> Daniel,
>
> I get what you meant. So, in essence, the polygonal_mesh gets its attributes
> from the appropriate mesh (bot/polyset) and then uses those under the name
> of polygonal_mesh. So, quite a bit of design is required here.
>
> How about we design a data structure that can talk to both the primitives
> (essentially, not losing any of the extra features of both the native
> structures)? Maybe like a kind of union of both the primitives. So, when we
> need to convert, we never have to compromise on any piece of information.
> This is like an extension to the merging method i had mentioned before. Does
> this seem feasible?

I don't think this is a good idea because, e.g., BRL-CAD had to
include a part of OpenSCAD then.

If BRL-CAD has a function automatic_polygonal_mesh_healing() which has
a polygonal_mesh parameter which knows OpenSCAD's PolySet then BRL-CAD
had to contain the PolySet header and source code files to compile
this.  This is unnecessary.


Regards,
Daniel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-04-01 Thread Rakshika Bagavathy
Daniel,

I get what you meant. So, in essence, the polygonal_mesh gets its
attributes from the appropriate mesh (bot/polyset) and then uses those
under the name of polygonal_mesh. So, quite a bit of design is required
here.

How about we design a data structure that can talk to both the primitives
(essentially, not losing any of the extra features of both the native
structures)? Maybe like a kind of union of both the primitives. So, when we
need to convert, we never have to compromise on any piece of information.
This is like an extension to the merging method i had mentioned
before. Does this seem feasible?

Regards,
Rakshika.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-04-01 Thread Daniel Roßberg
2016-03-31 19:15 GMT+02:00 Rakshika Bagavathy :
...
> I now understand that the base class has the polygonal_mesh structure and we
> work with that, but just implement the structure differently for both the
> derived classes. Did i understand it right?

I don't think so.
The Adapter is a design pattern in the object oriented software
development.  (BTW, you can develop object oriented in C as well.)
There many design decisions are behavior driven.  In our case this
means to ask: How should polygonal_mesh behave?

For example (only "pseudocode"):
class polygonal_mesh {
virtual int NumberOfFaces(void) = 0;
virtual int[3] GetFace(int) = 0;
virtual double[3] GetVertex(int) = 0;
virtual int AddVertex(double[3]) = 0;
virtual int AddFace(int[3]) = 0;
virtual RemoveFace(int) = 0;
};

Notice that there is no data in polygonal_mesh.
As the functions are pure virtual (= 0) there cannot be created an
instance of this class.  To do this we have to derive, e.g.:
class brlcad_bot_polygonal_mesh : public polygonal_mesh {
// implement the virtual functions here
virtual int NumberOfFaces(void) {
return m_data->num_faces;
}
   

rt_bot_internal* m_data;
}:

I.e. your algorithm would use polygonal_mesh and you would have to
provide the classes brlcad_bot_polygonal_mesh,
openscad_polyset_polygonal_mesh, and maybe brlcad_nmg_polygonal_mesh
to adapt the different polygonal meshes to your algorithm.

However, this is only a raw overview of how the adapter pattern could
be used here.  To get a full design some more work is necessary.


Regards,
Daniel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-31 Thread Rakshika Bagavathy
Daniel,

> Generally it sounds OK, if it's feasible.  I.e. you have the original
> mesh, a healed simplified mesh and you want to combine them to get the
> result, right?
>
> Yes, that's what i intended.

 The intention of my question was that you think about possible
> consequences of changing the order of triangles and vertices. Are there any?


I don't think there are any consequences to the change in order, as far as
i understand. All the algorithms assume the order of the vertices and the
faces to be in some arbitrary order, so a shuffle will not change anything,
i think.

I now understand that the base class has the polygonal_mesh structure and
we work with that, but just implement the structure differently for both
the derived classes. Did i understand it right?

I will get back after understanding the OpenSCAD code. I'll be able to
decide on the method better then.

Thank you so much for all the advice, i'm getting the hang of it better
now. :)

Regards,
Rakshika.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-31 Thread Daniel Roßberg
2016-03-31 17:15 GMT+02:00 Rakshika Bagavathy :
>> Rakshika,
>>
>> 2016-03-30 19:35 GMT+02:00 Rakshika Bagavathy
>> :
>> > Hello Sean and Daniel,
>> >
>> > After reading your inputs on the task, i have a few questions:
>> >
>> > 1. Daniel mentioned that some additional features of bots that might be
>> > lost
>> > in conversion. I'm unable to understand what those are. Also, all the
>> > algorithms i mentioned in the proposal use just the basic vertices and
>> > faces
>> > (with indexed vertices) as the input. So, what are those extra features
>> > that
>> > we don't want to lose? either way, while returning a healed polygonal
>> > mesh
>> > structure we can just change the vertices, faces, and normals (if
>> > required).
>>
>> Please have a look at struct rt_bot_internal in include/rt/geom.h.
>> Did you understand all entries of this struct?  How about OpenSCAD?  I
>> know nothing about its internal structures, but I'm pretty sure that
>> e.g. the polygonal mesh (how many do they have?) isn't trivial.
>
>
> Yes, i have looked at it and understood the entries. I'm looking through the
> OpenSCAD primitive (which is in class PolySet, as i found). I do realise
> that they are not trivial. What i meant to say was that,  after we convert a
> bot/polyset to the intermediate structure, we preserve the native
> structures, work on the intermediate structure, and while converting it back
> we'll need to be primarily changing only the vertices and faces and other
> things such as normals and face normals can be computed, and some other
> things like orientation, mode, etc. will still remain the same, which can be
> used for topology correction. Am i missing something through this approach?

Generally it sounds OK, if it's feasible.  I.e. you have the original
mesh, a healed simplified mesh and you want to combine them to get the
result, right?

>> > 2. Sean mentioned that there will be topology changes, but as far as i
>> > think, it won't matter much because we are going to be healing them
>> > after
>> > those changes, right?
>>
>> Changes the topology doesn't necessarily mean that a mesh is broken.
>> Think at a perfect mesh.  "Healing" it should change nothing, but
>> applying conversions to it could perhaps change the order of triangles
>> or the order of vertices in a triangle.  Could this cause problems?
>
>
> Well, i don't think there would be problems when we convert from bot to the
> intermediate structure (with just vertices and the faces with indexed
> vertices), as we go from more information to less information. I'm not too
> sure about the OpenSCAD primitive, still looking into it. If we're
> converting from the intermediate structure to bot, if we followed the method
> i mentioned above, would it not be fine? Essentially, if we performed the
> topology corrections alone native to the two organizations separately, the
> geometric operations can be combined through the portable module.

The intention of my question was that you think about possible
consequences of changing the order of triangles and vertices.  Are
there any?

>> > So, would it be fine to go forward with an STL like format which can be
>> > inter-converted to both BRL-CAD and OpenSCAD's primitives?
>>
>> It depends.  Can you write converters which don't damage the mesh?
>> How much time would you need to do it?
>
>
> Please review the method i mentioned above. Time required to code might
> depend on that.
>>
>>
>>
>> Did you understand the alternatives?
>
>
> Yes i did. The method with compiler switches would essentially mean writing
> the algorithm twice, right?

No, there would be only one implementation of the algorithm itself.
But whenever the algorithm accesses the original mesh, this would
happen in #ifdef clauses.  However, I don't want to recommend "method
2.)".  It's only there for completeness.

> Wouldn't the same problem come with the base and
> derived classes as well?

No.  Please read the chapter about adapters in the book "Design
Patterns" from Gamma, Helm, Johnson and Vlissides.

> Using the intermediate structure seems like the
> most efficient way possible.

Maybe.  That's the question which has to be answered.

>> > Or, we could first solve all topological defects and then use the
>> > half-edge
>> > data structure (as non-manifold meshes are the only ones that cannot be
>> > represented by a half-edge data structure, am i missing anything?) to
>> > correct all the other defects. Whichever one is the most optimal would
>> > be
>> > fine.
>>
>> This sounds like doing the second step before the first one: Solve
>> defects, but with which structure?
>
>
> How about what i mentioned above: Solving the topological defects (singular
> vertices, singular edges, orientation inconsistency) for both the structures
> separately and performing only the geometric defects removal in the portable
> module?
>
> Sorry if i'm going about anything the wrong way.

You aren't 

Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-31 Thread Rakshika Bagavathy
>
> Rakshika,
>
> 2016-03-30 19:35 GMT+02:00 Rakshika Bagavathy <
> rakshika.bagava...@gmail.com>:
> > Hello Sean and Daniel,
> >
> > After reading your inputs on the task, i have a few questions:
> >
> > 1. Daniel mentioned that some additional features of bots that might be
> lost
> > in conversion. I'm unable to understand what those are. Also, all the
> > algorithms i mentioned in the proposal use just the basic vertices and
> faces
> > (with indexed vertices) as the input. So, what are those extra features
> that
> > we don't want to lose? either way, while returning a healed polygonal
> mesh
> > structure we can just change the vertices, faces, and normals (if
> required).
>
> Please have a look at struct rt_bot_internal in include/rt/geom.h.
> Did you understand all entries of this struct?  How about OpenSCAD?  I
> know nothing about its internal structures, but I'm pretty sure that
> e.g. the polygonal mesh (how many do they have?) isn't trivial.


Yes, i have looked at it and understood the entries. I'm looking through
the OpenSCAD primitive (which is in class PolySet, as i found). I do
realise that they are not trivial. What i meant to say was that,  after we
convert a bot/polyset to the intermediate structure, we preserve the native
structures, work on the intermediate structure, and while converting it
back we'll need to be primarily changing only the vertices and faces and
other things such as normals and face normals can be computed, and some
other things like orientation, mode, etc. will still remain the same, which
can be used for topology correction. Am i missing something through this
approach?

>
>
> > 2. Sean mentioned that there will be topology changes, but as far as i
> > think, it won't matter much because we are going to be healing them after
> > those changes, right?
>
> Changes the topology doesn't necessarily mean that a mesh is broken.
> Think at a perfect mesh.  "Healing" it should change nothing, but
> applying conversions to it could perhaps change the order of triangles
> or the order of vertices in a triangle.  Could this cause problems?


Well, i don't think there would be problems when we convert from bot to the
intermediate structure (with just vertices and the faces with indexed
vertices), as we go from more information to less information. I'm not too
sure about the OpenSCAD primitive, still looking into it. If we're
converting from the intermediate structure to bot, if we followed the
method i mentioned above, would it not be fine? Essentially, if we
performed the topology corrections alone native to the two organizations
separately, the geometric operations can be combined through the portable
module.

>
>
> > So, would it be fine to go forward with an STL like format which can be
> > inter-converted to both BRL-CAD and OpenSCAD's primitives?
>
> It depends.  Can you write converters which don't damage the mesh?
> How much time would you need to do it?


Please review the method i mentioned above. Time required to code might
depend on that.

>
>
> Did you understand the alternatives?


Yes i did. The method with compiler switches would essentially mean writing
the algorithm twice, right? Wouldn't the same problem come with the base
and derived classes as well? Using the intermediate structure seems like
the most efficient way possible.

>
>
> > Or, we could first solve all topological defects and then use the
> half-edge
> > data structure (as non-manifold meshes are the only ones that cannot be
> > represented by a half-edge data structure, am i missing anything?) to
> > correct all the other defects. Whichever one is the most optimal would be
> > fine.
>
> This sounds like doing the second step before the first one: Solve
> defects, but with which structure?


How about what i mentioned above: Solving the topological defects (singular
vertices, singular edges, orientation inconsistency) for both the
structures separately and performing only the geometric defects removal in
the portable module?

Sorry if i'm going about anything the wrong way.

Regards,
Rakshika.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-31 Thread Daniel Roßberg
Rakshika,

2016-03-30 19:35 GMT+02:00 Rakshika Bagavathy :
> Hello Sean and Daniel,
>
> After reading your inputs on the task, i have a few questions:
>
> 1. Daniel mentioned that some additional features of bots that might be lost
> in conversion. I'm unable to understand what those are. Also, all the
> algorithms i mentioned in the proposal use just the basic vertices and faces
> (with indexed vertices) as the input. So, what are those extra features that
> we don't want to lose? either way, while returning a healed polygonal mesh
> structure we can just change the vertices, faces, and normals (if required).

Please have a look at struct rt_bot_internal in include/rt/geom.h.
Did you understand all entries of this struct?  How about OpenSCAD?  I
know nothing about its internal structures, but I'm pretty sure that
e.g. the polygonal mesh (how many do they have?) isn't trivial.

> 2. Sean mentioned that there will be topology changes, but as far as i
> think, it won't matter much because we are going to be healing them after
> those changes, right?

Changes the topology doesn't necessarily mean that a mesh is broken.
Think at a perfect mesh.  "Healing" it should change nothing, but
applying conversions to it could perhaps change the order of triangles
or the order of vertices in a triangle.  Could this cause problems?

> So, would it be fine to go forward with an STL like format which can be
> inter-converted to both BRL-CAD and OpenSCAD's primitives?

It depends.  Can you write converters which don't damage the mesh?
How much time would you need to do it?

Did you understand the alternatives?

> Or, we could first solve all topological defects and then use the half-edge
> data structure (as non-manifold meshes are the only ones that cannot be
> represented by a half-edge data structure, am i missing anything?) to
> correct all the other defects. Whichever one is the most optimal would be
> fine.

This sounds like doing the second step before the first one: Solve
defects, but with which structure?


Regards,
Daniel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-31 Thread Vasco Alexandre da Silva Costa
On Wed, Mar 30, 2016 at 6:35 PM, Rakshika Bagavathy <
rakshika.bagava...@gmail.com> wrote:

> Hello Sean and Daniel,
>
> After reading your inputs on the task, i have a few questions:
>
> 1. Daniel mentioned that some additional features of bots that might be
> lost in conversion. I'm unable to understand what those are. Also, all the
> algorithms i mentioned in the proposal use just the basic vertices and
> faces (with indexed vertices) as the input. So, what are those extra
> features that we don't want to lose? either way, while returning a healed
>

Plate mode?


> polygonal mesh structure we can just change the vertices, faces, and
> normals (if required).
>
> 2. Sean mentioned that there will be topology changes, but as far as i
> think, it won't matter much because we are going to be healing them after
> those changes, right?
>
> So, would it be fine to go forward with an STL like format which can be
> inter-converted to both BRL-CAD and OpenSCAD's primitives?
>
> Or, we could first solve all topological defects and then use the
> half-edge data structure (as non-manifold meshes are the only ones that
> cannot be represented by a half-edge data structure, am i missing
> anything?) to correct all the other defects. Whichever one is the most
> optimal would be fine.
>
> Regards,
> Rakshika.
>
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>


-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-30 Thread Rakshika Bagavathy
Hello Sean and Daniel,

After reading your inputs on the task, i have a few questions:

1. Daniel mentioned that some additional features of bots that might be
lost in conversion. I'm unable to understand what those are. Also, all the
algorithms i mentioned in the proposal use just the basic vertices and
faces (with indexed vertices) as the input. So, what are those extra
features that we don't want to lose? either way, while returning a healed
polygonal mesh structure we can just change the vertices, faces, and
normals (if required).

2. Sean mentioned that there will be topology changes, but as far as i
think, it won't matter much because we are going to be healing them after
those changes, right?

So, would it be fine to go forward with an STL like format which can be
inter-converted to both BRL-CAD and OpenSCAD's primitives?

Or, we could first solve all topological defects and then use the half-edge
data structure (as non-manifold meshes are the only ones that cannot be
represented by a half-edge data structure, am i missing anything?) to
correct all the other defects. Whichever one is the most optimal would be
fine.

Regards,
Rakshika.
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-30 Thread Daniel Roßberg
2016-03-30 14:54 GMT+02:00 Christopher Sean Morrison :
>
> On Mar 30, 2016, at 7:39 AM, Daniel Roßberg 
> wrote:
>
> 2016-03-29 17:20 GMT+02:00 Christopher Sean Morrison :
>
>
>
> The project can define a polygonal mesh structure that is compatible with
> the STL format, which both OpenSCAD and BRL-CAD support.  It's a simple and
> limited format, but trivial to convert to/from.  It is essentially an array
> of floating point vertices and an array of faces with integer references
> into the vertex array [*].
>
> [snip]
>
> [*] This is essentially what BRL-CAD's BoT structure implements, but this
> shared library could implement a simpler compatible structure.
>
>
> This would mean that the mesh healing function changes (somebody could
> say "destroys") the original mesh structure because the additional
> features of BoT, NMG and OpenSCAD get lost simply by converting the
> mesh back and forth, which is not optimal.
>
>
> This is true.  There can be a topological/connectivity/ordering change with
> a simpler common structure.  However, that by itself shouldn’t change the
> geometry shape.

I thought at the BoT's normals.  They can heavily influence the look.
OpenSCAD could have similar issues.
The "heal" command is likely to be used to fix problems, not to cause ones.

> The alternative is picking something that directly reflects NMG or
> OpenSCAD’s structure like you suggested, creating the same mesh conversion
> problem for the other and anyone else not using that structure … unless they
> happen to all use the more general radial-edge structure like Blender and
> BRL-CAD.  :)
>
> Inflicting that complexity on others seems somewhat cruel and unusual.
> Picking something like half-edge means some meshes simply cannot be
> represented.  Do we know what OpenSCAD uses?
>
> I can see it working either way myself, no attachment to and tradeoffs with
> either approach.  It’s worth noting that mesh healing will be changing the
> topology/connectivity/ordering implicitly, so I wouldn’t think topology
> matters much by the time someone is needing something healed.

The hole issue looks like a classical application for an adapter to
me.  Such objects are usually much more easily to implement as
converters.

However, thinks Rakshika of it?


Regards,
Daniel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-30 Thread Daniel Roßberg
2016-03-29 17:20 GMT+02:00 Christopher Sean Morrison :
>
>
> On Mar 29, 2016, at 10:01 AM, Daniel Roßberg 
> wrote:
>
> Therefore, you want to write a function
> automatic_polygonal_mesh_healing(struct polygonal_mesh mesh)
> which can be used both in BRL-CAD and OpenSCAD. The main problem for
> a portable module here is the polygonal_mesh structure which both
> applications have to provide. Possible solutions could be:
>
> 1.) There are converters for BRL-CAD and OpenSCAD which convert the
> specific mesh structures (e.g. bot in BRL-CAD) to "struct
> polygonal_mesh" and back.
> [snip]
> 4.)
>
>
> The project can define a polygonal mesh structure that is compatible with
> the STL format, which both OpenSCAD and BRL-CAD support.  It's a simple and
> limited format, but trivial to convert to/from.  It is essentially an array
> of floating point vertices and an array of faces with integer references
> into the vertex array [*].
[snip]
> [*] This is essentially what BRL-CAD's BoT structure implements, but this
> shared library could implement a simpler compatible structure.

This would mean that the mesh healing function changes (somebody could
say "destroys") the original mesh structure because the additional
features of BoT, NMG and OpenSCAD get lost simply by converting the
mesh back and forth, which is not optimal.

Regards,
Daniel

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-29 Thread Christopher Sean Morrison




On Mar 29, 2016, at 10:01 AM, Daniel Roßberg  wrote:


Therefore, you want to write a function
automatic_polygonal_mesh_healing(struct polygonal_mesh mesh)
which can be used both in BRL-CAD and OpenSCAD. The main problem for
a portable module here is the polygonal_mesh structure which both
applications have to provide. Possible solutions could be:

1.) There are converters for BRL-CAD and OpenSCAD which convert the
specific mesh structures (e.g. bot in BRL-CAD) to "struct
polygonal_mesh" and back.
[snip]
4.)


The project can define a polygonal mesh structure that is compatible with the 
STL format, which both OpenSCAD and BRL-CAD support.  It's a simple and limited 
format, but trivial to convert to/from.  It is essentially an array of floating 
point vertices and an array of faces with integer references into the vertex 
array [*].  Doing anything more complex will probably need to be discussed in 
further detail with both groups to make sure converting to our respectively 
more advanced mesh structures (e.g., BRL-CAD NMG) will not be a problem.  This 
of course would not preclude you from using a more complex structure yourself 
under the hood for processing convenience.



I had submitted the proposal 'Automatic Polygonal Mesh Healing'. On the IRC,
kintel had said that OpenSCAD required similar functionalities, and so
suggested a portable module that could be used by both organisations. I
would like to know how to go forward with this.


This is what our collaboration is all about so please do ensure that creating a 
shared reusable library is part of your project plan, and that you include time 
to discuss and test with both communities, should your proposal get selected.



Cheers!

Sean





[*] This is essentially what BRL-CAD's BoT structure implements, but this 
shared library could implement a simpler compatible structure.



--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic Polygonal Mesh Healing

2016-03-29 Thread Daniel Roßberg
Rakshika,

Therefore, you want to write a function
automatic_polygonal_mesh_healing(struct polygonal_mesh mesh)
which can be used both in BRL-CAD and OpenSCAD.  The main problem for
a portable module here is the polygonal_mesh structure which both
applications have to provide.  Possible solutions could be:

1.) There are converters for BRL-CAD and OpenSCAD which convert the
specific mesh structures (e.g. bot in BRL-CAD) to "struct
polygonal_mesh" and back.

2.) polygonal_mesh is the application specific mesh structure.  Access
to it is handled via compiler switches:
#if defined(BRLCAD)
use polygonal_mesh like a bot
#elif defined(OPENSCAD)
use polygonal_mesh like a OpenSCAD mesh structure
#endif

3.) Use C++.  polygonal_mesh is an abstract base class with
instantiable implementations for BRL-CAD and OpenSCAD which has
methods for all types of accesses needed by your algorithm.

4.) ?


Regards,
Daniel

2016-03-28 16:09 GMT+02:00 Rakshika Bagavathy :
> Hello all,
>
> I had submitted the proposal 'Automatic Polygonal Mesh Healing'. On the IRC,
> kintel had said that OpenSCAD required similar functionalities, and so
> suggested a portable module that could be used by both organisations. I
> would like to know how to go forward with this.
>
> Regards,
> Rakshika
>
> --
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785471=/4140
___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic polygonal mesh healing project

2016-03-09 Thread Christopher Sean Morrison

> This is just a suggestion but you can get an idea of how mesh healing 
> techniques work in practice by looking at the MeshLab program:
> http://meshlab.sourceforge.net/ 

A word of caution — Meshlab is GPL software.  While I would love to incorporate 
them wholesale, their source code is not compatible with ours and should not be 
directly examined (the end result is a derivative and must be GPL-licensed).  
That said, studying how the tools themselves work and reading up on the methods 
they use is fine.  Just don’t look at their code if the goal is to implement 
that capability in a non-GPL code like ours.

> That program features a whole suite of mesh editing tools including some 
> which do mesh healing. I don't know how relevant the techniques are in terms 
> of the requirements for BRL-CAD but quite often 3D scanned models need some 
> touching up before 3D printing so these tools quite often quite useful. Even 
> some non-printing use cases require watertight surfaces or meshes.

They are otherwise quite relevant. :)

Cheers!
Sean

--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel


Re: [brlcad-devel] Automatic polygonal mesh healing project

2016-03-09 Thread Vasco Alexandre da Silva Costa
On Wed, Mar 9, 2016 at 5:16 PM, Rakshika Bagavathy <
rakshika.bagava...@gmail.com> wrote:

> Hello,
>
> I read on the mailing list that 'Automatic polygonal mesh healing' is a
> viable project. I got interested and familiarized myself with the
> techniques.
>
> My knowledge right now is that there may be gaps, overlaps, T-joints and
> slivers in the geometry objects and we process them one by one.
>
> 1. After triangulating the mesh (using the paving algorithm) we first
> identify gaps and overlaps and solve them using the nodal merging
> algorithm.
> 2. Then we identify and solve T-joints using nodal insertion and element
> splitting algorithm.
> 3. Larger gaps and holes are solved using a triangulation technique based
> on the advancing front algorithm.
> 4. Sliver mesh patches and skewed elements are solved by merging nodes and
> by edge swapping (based on the overall shape factor).
>
> The inputs from the user would be the edge length (for the paving
> algorithm), and the merging tolerance (while checking if two edges are
> close by).
>
> Is my approach right in this?
> Also, could i be directed towards the existing code for polygonal mesh
> healing?
>

This is just a suggestion but you can get an idea of how mesh healing
techniques work in practice by looking at the MeshLab program:
http://meshlab.sourceforge.net/

That program features a whole suite of mesh editing tools including some
which do mesh healing. I don't know how relevant the techniques are in
terms of the requirements for BRL-CAD but quite often 3D scanned models
need some touching up before 3D printing so these tools quite often quite
useful. Even some non-printing use cases require watertight surfaces or
meshes.

--
> Transform Data into Opportunity.
> Accelerate data analysis in your applications with
> Intel Data Analytics Acceleration Library.
> Click to learn more.
> http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140
> ___
> BRL-CAD Developer mailing list
> brlcad-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>
>


-- 
Vasco Alexandre da Silva Costa
PhD in Computer Engineering (Computer Graphics)
Instituto Superior Técnico/University of Lisbon, Portugal
--
Transform Data into Opportunity.
Accelerate data analysis in your applications with
Intel Data Analytics Acceleration Library.
Click to learn more.
http://pubads.g.doubleclick.net/gampad/clk?id=278785111=/4140___
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel