Re: [brlcad-devel] Automatic Polygonal Mesh Healing

[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

[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

[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

[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] REF: Primitive Patch

[Vasco Alexandre da Silva Costa]

On Thu, Mar 31, 2016 at 5:45 AM, benson chepkwony  wrote:

> Hi Vasco,
> I have added an ARBN primitive patch. This was to demonstrate how to port
> arbn to OpenCL and create arbn shot, however the work is not fully complete
> yet.
>

Right. The code isn't integrated with the current librt OpenCL ray-tracer.
Namely you would want to define a packing function instead of doing the
packing and sends using CL commands.


> The link to this patch is: https://sourceforge.net/p/brlcad/patches/439/


Try to only use OpenCL 1.2 commands as that is currently our minimum
requirement. AFAIK NVIDIA does not support OpenCL 2.0 very all yet.

-- 
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

[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