Full Version: Remove tiny face on object

Show messages:  1-5  6-25  26-32

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

---

Ok Michael.

@You : "..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..."

I understand. No problem. Thanks anyway for taking the time to reply.

@You : "...Also right now I don't understand what specific problem you're trying to solve with this...
...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..."

Ok, so...

My main problem with the current implementation of Moi's Api is just that gathering objects information, or we can call them "meta-data",
is very slow inside loops.
This is not evident for few objects, but even with only a few dozen of objects this is particular evident.

I'm referring here to specific situations where you have to iterate many times over the same loop, for example when a slider change or a numeric input value change.

In these situation, also with my fast desktop, performance are very poor.

For example, let's say I have 100 surfaces (not so much), joined or not, and I'm running the script that should filter the surfaces based on their area.

Well, every time I simply change the input range (min and max area) the script needs to recalculate the area for each object every time
the code enter the loop.

Ok. I can agree with you that "......Indexing some information for set queries without any loops later could be possible to do in the script itself...".

It could be possible if, for example, I store all the metadata into an array when the loop is executing for the very first time, and later I could access
to that pre-calculated array instead of call Moi's Api to recalculate the same thing in each loop.

But I don't know if this could be an effective method in order to get a true improvement of script execution time.

---

Hi Michael.

Just in order to close our conversation about this matter (attempt to optimize the fetching of Moi objects's data within a javascript loop),
I want to make some test on my own.

But I have only one problem :)

I missed the link to the web URL of the documentation of Moi's Api.

Could you give that link ?

If I remember correctly it should be an html file made by Max.

Thanks a lot.

Ciao!

---

Hi Marco,

> In these situation, also with my fast desktop, performance are very poor.
>
> For example, let's say I have 100 surfaces (not so much), joined or not, and
> I'm running the script that should filter the surfaces based on their area.

Sorry now I'm really confused, how are you running that script currently when the surface area method hasn't been added yet?


> Well, every time I simply change the input range (min and max area) the script needs
> to recalculate the area for each object every time the code enter the loop.

How long is it taking?

Again, please post the script with the performance issues so I can take a look at what's going on and see if I can give some advice.


re: script API docs I think everything currently available is gathered on the scripting page of the wiki, go to http://moi3d.com , then the resources page and then the "Scripting" link is the 7th one down from the top.

- Michael

---

Hi Michael.

@You : "..re: script API docs I think everything current..."

Thank you very much!

@You : "...sorry now I'm really confused, how are you running that script currently when the surface area method hasn't been added yet?.."

I apologize if I didn't make that clear.

I was referring to the "hypothetical" script that doesn't exist yet :)
Something that I was trying to extract from the CVolume script made by max, before you wrote me that this is not feasible at the moment.

Anyway, let's get rid for the moment of the area calculation and let's say that I simply want to filter a set of curves based by length (in range).

I mean, doing this is in a javascript loop, and let's say that the script must process 2000 curves (or edges).

@You : "...How long is it taking?
Again, please post the script with the performance issues so I can take a look at what's going on and see if I can give some advice..."

Ok. Now I put together a bunch of lines of javascript code to test the speed of filtering a given amount of curves by lenght inside a loop.

And I will do that in two ways :

1) using a "proxy" (a javascript array). I will fill this array the very first time I enter the loop and then I will use that array instead of
repeatedly querying Moi's data with the method getLength()

2) using the standard way, that is, calling getLength() continuously within the loop.

I will post to you the final results (the timing of first and second method).

Thanks for the willingness!

---

Hi Marco,

> I was referring to the "hypothetical" script that doesn't exist yet :)

Ok, but I'm sorry it's not practical for me to do a lot of work to optimize something that's just hypothetical.


> Anyway, let's get rid for the moment of the area calculation and let's say that I simply want to
> filter a set of curves based by length (in range).

Is this just another hypothetical situation again though? What modeling task are you trying to accomplish where you need to do this?

- Michael

---

Show messages:  1-5  6-25  26-32