2016-03-31 17:15 GMT+02:00 Rakshika Bagavathy <rakshika.bagava...@gmail.com>:
>> 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?
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 going the wrong way ;) You are about to understand the
problem and the different approaches to solve it. At the end YOU will
decide what should be done in your GSoC project. I only want to make
sure that you understood the relevant points.
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&iu=/4140
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
