Full Version: Remove tiny face on object

Show messages:  1-20  21-32

Hi

Ok my first post. I have attached an object that is imported from Solid Edge via a Step-file. I am trying to make a chamfer on the edge of this object but it does not work. I am guessing something is wrong. If I zoom in a lot I have discovered that the curve is not perfectly smooth. There is a small "cut" that I want to remove. How do I do that? I don't know the program very well but am trying to learn.

Maybe something else is wrong too but I don't know what.

Attachments:
Object.3dm

Image Attachments:
Example.jpg 

---

Hi henricius, there are a couple of different ways to fix something like that. One would be to extract all the curves which is done by selecting the edges and using copy/paste to duplicate them as regular curves, fix up the curves and build a new extrusion from the improved curves.

But another way that's a bit more "surgical" using some more advanced low level tools would be something like this:

Select the tiny face and the smallish one nearby it as well:



Push delete to remove those faces leaving a hole like this:



Select these 2 edges:



And run Construct > Blend to build a smooth blend surface between them, it will look like this:



So now there's a little bit of extra material on the top and bottom faces that's sticking out and needs to be removed. You can do that by selecting the top face, then run the Edit > Trim command, then select the top edge of the blend surface as the cutting object. That will cut the top face and then you want to pick this fragment as the piece to remove:



Once you have trimmed out that area from both the top and bottom faces you'll now have a repaired set of surfaces which all match up, select them all and run Edit > Join to glue them back into a solid:



- Michael

Image Attachments:
henricius_repair1.jpg  henricius_repair2.jpg  henricius_repair3.jpg  henricius_repair4.jpg  henricius_repair5.jpg  henricius_repair6.jpg 

---

Hi Michael

Wow! Thanks, it works perfectly. I like this program more and more.

Best Regard Henrik

---

Hi Michael.

I've got and idea....maybe nothing special and for sure maybe very slow if applied on too many objects, but....better than nothing :)

I think we could use a "modified" version of "CVolume v.2.0 - Dinos, Max Smirnov. 2015" script to automatically find all single surfaces that
fall into a given range (min and max of the area).

The script should iterate over all selected objects, investigate every single surface and calculate the area of each.

I don't know if I have the skill to create such a script because my difficult is to deal with Moi's HTML part of the script.
It should display two sliders or at least two numeric fields to specify the area limits of the surfaces to find.

This is a brief video of how the CVolume script actually works : http://take.ms/rhJhG

What do you think ?

Thanks.

Marco (mkdm)

---

Hi Marco, I guess that could be possible but it may be difficult because the way CVolume works is by generating a triangulated .obj file. Currently you can't export just one face object out of a larger brep to a file. I guess it could be possible to also separate the object into individual surfaces and export them to a temp file one by one but yeah that's likely to be very slow.

For v4 I can add some more methods like something on a face to calculate its surface area without having to save it to a file and read it back in again, that should work much better.

- Michael

---

Hi Micheal.

Thanks for clarifying.

@You : "...For v4 I can add some more methods like something on a face to calculate its surface area without having to save it to a file and read it back in again, that should work much better..."

You hit a very important point for me that I've been waiting for a really long time.

I know that actually this can't be a top entry in your "to-do" list,
but I always thought it would be really great to have Moi's Api providing a bunch of investigation methods.

I mean, without the need to calculate that things ourself (admitted it's possible) with very slow methods.

For example it would be very useful to have these Api methods :

1) Get the area of a single surface or a joined surface

2) A method that should perform an internal fast search of things (all levels...objects, surfaces, curves, edges) based on input criteria :
object name, min and max length, min and max area, using multiple input criteria.
That is, for example, let's say we want to get the list of all entities name "wood" of type "surface" with the area between 20 and 30.
Or get the list of all entities name "wire" of type "edge" having the area length between 5 and 10.
All these searches should have and also an input filed that specify that starting set of entities to filter (for example only "selected objects")

3) A method that should return all the control points of a surface along with the "normal" of each point.

And so on...

I know that actually some of these investigations could be done with the current Api but, even when possible,
the elaboration is very limited and very very slow, due to the actual Api implementation.

I hope that, soon or later, you will add all these kind of "pre-calculated" things, applying these information directly
to the Moi's entities (within its "DOM").

I say this from my developer point of view.

I hope I made myself clear :)

Thanks a lot for help and have a nice day.

Marco (mkdm)


P.S. I apologize if I repeat these things often in my messages, but I think that the current Moi's Api is too limited if we want to let Moi jumping to a "next level", for a very powerful scripting.

---

Hi Marco, yes I do want to add more information querying methods for v4.

The tricky part about adding things to the API is that it tends to be difficult to modify the API later on since a bunch of stuff is depending on it to work how it currently is. So that's one of the reasons I've been pretty conservative about it.

- Michael

---

Hello Marco,

select the geometry and RMB to the selected node -> update -> run
better than nothing;-)

Have a nice day
Karsten

p.s.:And so, my fellow Moionese: ask not what your system can do for you — ask what you can do for your system:-)

Attachments:
select_mini.nod

---

Hi Karsten.

Thanks you very much for sharing this node. Very interesting !

Thanks a lot.

The unique and big problem, if I understood well the way it works, is that the final result of the elaboration is a duplicate of the original geometry.

But this is not useful because instead I need simply the selection of the resulting faces and not new objects.

Because my aim is this : Given a set of input geometry, getting as result all the surfaces that have the area falling into a range, to be automatically selected.
In this way I can, for example, delete them.

Is there a way to get this behavior ?

Some way to tell to nodeeditor "select this things instead of creating new entities" ?

Thanks anyway.

---

Hi Michael.

@You : "...The tricky part about adding things to the API is that it tends to be difficult to modify the API later on since a bunch of stuff is depending on it to work how it currently is..."

You could simply add a special new "tag" field to every entities of the Moi's DOM that should point to a new data structure that could contain all informative data.

Is it feasible ?

Marco (mkdm)

---

Hello Marco,

you can inverse the selection and join the result to a joint surface - it depends on what you want to do with the selection of the tiny faces in the original Version? Automaticaly repair a topological/geometrical structure with simplifing the base geometry? That's a really hard peace of cake.

Cheers
Karsten

---

@You : "...Automaticaly repair a topological/geometrical structure with simplifing the base geometry? That's a really hard peace of cake...."

Oh no, certainly not this :)

For the moment I simply want to have a tool (script or nodeeditor) with which perform this task :

1) Select some geometry (whole objects and/or single surfaces, mixed selection)
2) Input a "min" and "max" values that represents the range of the area that I want to search
3) Get, as the final result, all the single surfaces (not joined surfaces) whose area fall within that range, automatically selecetd
(without generating new geometry).

Nothing more than that :)

Thanks.

---

Sorry, but I can't help at this point.
Karsten

---

Ok. No problem Karsten.
Thanks a lot anyway for your help!

Cheers.

---

Hi Marco,

> You could simply add a special new "tag" field to every entities of the Moi's DOM that should
> point to a new data structure that could contain all informative data.
>
> Is it feasible ?

Well there can be complications for some of the things you mentioned, for example calculating volume or surface area can be an expensive computation so it may not work that well to try and present it in the same way as a simple directly accessible property.

Common properties such as name and style are already implemented as properties on a base "GeomObject" class, so adding them to a separate new data structure would involve some duplication of existing functionality.

There is also already existing functionality for filtering through the object list implementation. For example given an initial object list with any kind of objects in it, you can build a filtered list containing only edges by calling the .getEdges() method. So for example to start with all selected objects and filter that down to a list of just edges you can do this currently:

var edges = moi.geometryDatabase.getSelectedObjects().getEdges();

The current object list filtering methods are all based around object type, they include:

getBReps()
getSolids()
getOpenBReps()
getSingleFaceBReps()
getFaces()
getEdges()
getStandaloneCurves()
getCurves()
getPoints()
getConstructionLines()
getTopLevelObjects()

It would probably fit in best to add additional filtering methods to the already existing object list filtering functionality rather than make something totally different. It would mainly be a convenience factor though, I wouldn't really expect any performance difference from looping through them as you would do currently.

- Michael

---

Hi Marco,

re:
> For the moment I simply want to have a tool (script or nodeeditor) with which perform this task :
>
> 1) Select some geometry (whole objects and/or single surfaces, mixed selection)
> 2) Input a "min" and "max" values that represents the range of the area that I want to search
> 3) Get, as the final result, all the single surfaces (not joined surfaces) whose area fall within that
> range, automatically selecetd
> (without generating new geometry).

Just adding in a .getArea() method for breps and faces would be enough to enable this.

- Michael

---

Hi Michael.

Thank you very much for taking the time to write such a detailed reply. Much appreciated.

@You : "...just adding in a .getArea() method for breps and faces would be enough to enable this..."

OK. Thank's a lot. This could be very helpful!
Could you add it right now for the current version of Moi or you're always referring to the upcoming V4 ?

With that said...

Well...I read your reply with great interest and, of course, I can agree with you that some of the things that I mentioned
would involve writing some extension or maybe a rethink of some area of Moi's Api.

And I can understand that this would not be an effortless work :)

But this part of your sentence puzzles me a little bit :
"...I wouldn't really expect any performance difference from looping through them as you would do currently."

I say this because I assumed that making a call of any method directly compiled into Moi's core engine (or DLLs)
must be many times faster that the code executed inside a loop within some script, that, more or less (I assume), must run
into some kind of scripting environment that should "talk" in some way to the Moi's core engine.

I don't know if I made myself clear.

What I want to say is this : Let's say, for example, we want to filter all closed curves.

Now...one thing is to write a script that should filter all curves with getCurves() and, inside a loop, on each curve should call another method to check if it is opened or not.
A different thing (I think) is to write a script that simply could make a call to a method named getclosedCurves() to get all closed curves in one single shot.
Because, I think, in this case that method can make a direct query into the Moi's Object Model and not within the scripting environment.

I don't know if I'm thinking right.


Anyway, thanks a lot for your help!

Have a nice day...or night...i don't know what's your meridian :)

Ciao.

Marco (mkdm)

---

Hi Marco,

> Could you add it right now for the current version of Moi or you're
> always referring to the upcoming V4 ?

I'm referring to v4, sometime during the v4 beta period. That's when I'll be doing releases on a regular schedule and so it's easier for me to add stuff. Adding it to the current version would involve all sorts of release related work like making a new build, testing it, uploading it, updating version numbers and web pages and various stuff like that.


> But this part of your sentence puzzles me a little bit :
> "...I wouldn't really expect any performance difference from looping through them as you would do currently."

I was thinking of your example that you had specifically mentioned: "Input a "min" and "max" values that represents the range of the area that I want to search" . The way to do that is going to be to loop through all the faces, calculate the area of each one and compare it to the min and max values. In all that work 99.99% of the time will be in just the area calculations so for performance whether the loop is done in script or done in the back end API implementation doesn't make any measurable difference.


> What I want to say is this : Let's say, for example, we want to filter all closed curves.
>
> Now...one thing is to write a script that should filter all curves with getCurves() and, inside a
> loop, on each curve should call another method to check if it is opened or not.

Right, and what I was referring to would be that any filtering mechanism that I'd be able to write in a reasonable time would just be doing the same thing in the back end code. It's still useful to have such a thing but it's useful for a convenience factor of writing more concise scripts, not for performance.


> A different thing (I think) is to write a script that simply could make a call to a method named
> getclosedCurves() to get all closed curves in one single shot.
> Because, I think, in this case that method can make a direct query into the Moi's Object Model
> and not within the scripting environment.

Well, there is no such query capability existing currently. I guess one way to implement an O(1) "single shot" closed curve query would be to build an index of the closed curves inside the object list every time an object list is created, and make sure the index is updated every time the list is modified by adding or removing objects. That would indeed speed up retrieval of all closed curves from an object list at query time but the cost would be shifted to the list creation and update times instead and you'd pay that cost all the time even if retrieval of closed curves wasn't actually ever needed during the current program run.

In order to justify that cost, retrieving closed curves would need to be some kind of important bottleneck that was being frequently encountered.

Hope that makes sense!

- Michael

---

Hi Michael.

Thanks a lot for your technical reply.

@You : "...In order to justify that cost, retrieving closed curves would need to be some kind of important bottleneck that was being frequently encountered.
Hope that makes sense!"

Oh yeah. That makes more sense of course!

I perfectly understand that there are two main big different approaches that are fighting each other :

1) Giving priority to viewport responsiveness
2) Giving priority to scripting performance

I know, and I agree with you, that Moi is mainly focused on easy of use and viewport responsiveness.
Nothing to say about that.

@You : "... I guess one way to implement an O(1) "single shot" closed curve query would be to build an index of the closed curves inside the object list every time an object list is created..."

So, I ask you if you could add, for V4, a user setting that could give us the chance to choose the way Moi works :
1) Priority to Viewport : everything remains just as it is now
2) Priority to Scripting : all (or some) of the additional data of the objects are calculated on he ffly after creation/modification.
In this way all that information could be available immediatly during Scripting execution.

Is it feasible ?

Thanks a lot for your "high quality" support.

Marco (mkdm)

---

Hi Marco,

re:
> So, I ask you if you could add, for V4, a user setting that could give us the chance
> to choose the way Moi works :
> 1) Priority to Viewport : everything remains just as it is now
> 2) Priority to Scripting : all (or some) of the additional data of the objects are calculated
> on he ffly after creation/modification.
> In this way all that information could be available immediatly during Scripting execution.

I'm sorry Marco but it doesn't seem very feasible to do this. It's not a good recipe for stability and robustness to have settings that dramatically alter how basic things behave, it would add a lot of complexity to the design and multiply the amount of testing I'd need to do to make sure things were functioning properly. There are also implementation and maintenance costs like these that have to be considered as well.

Also right now I don't understand what specific problem you're trying to solve with this - do you have something you're working on where gathering lists of closed curves is currently a performance bottleneck that is preventing something from working as you need?

Indexing some information for set queries without any loops later could be possible to do in the script itself - it's likely to be a lot more feasible to do it that way since the solution can then be targeted to the particular needs of the script.

If you have a poorly performing script that needs quicker set information retrieval could you please post the script and describe what you're trying to do in some more detail?

- Michael

---

Show messages:  1-20  21-32