Full Version: Remove tiny face on object

Show messages:  1-16  17-32

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

---

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

No Michael. It's not hypothetical :)

This is very frustrating...

Unfortunately you don't speak Italian and I'm forced to use English that is not my language.

If only I could speak with you in Italian I can say that in less than 5 minutes I could explain what I want to do.

It's very difficult to me to write always in English (or trying to do so).

Please remember that in one of my previous message I said that I was attempting to create
a script that should have filter a bunch of surfaces based on their area, within a loop and with fast execution.

This is because I want to create a useful script for cleaning up models with very tiny surfaces.

And also I want to create some utility script to find and select super tiny edges or curves,
very useful also for cleanup purposes.

And to do all that things I need to execute code in loop as fast as possible.

Is for this reason that I asked you to expand actual Moi's Api with some pre-compiled new filtering methods.

I hope this way I made myself clear :)

Thanks.

---

Hi Marco,

re:
> And to do all that things I need to execute code in loop as fast as possible.

But no, this isn't correct - if you are doing that just a couple of times a day it is not necessary for the code to execute as fast as it possibly can, it only needs to execute in a reasonable time for accomplishing the task at hand.

For example if it currently takes 1 second to execute the script, optimizing it down so it's instantaneous will only save you a tiny amount of time if it's only performed infrequently.

So the actual practical usage is an important factor, it's not worthwhile to put a lot of effort into optimizing things that are not causing an actual problem in real life use.

- Michael

---

@You : "...So the actual practical usage is an important factor, it's not worthwhile to put a lot of effort into optimizing things that are not causing an actual problem in real life use.

...For example if it currently takes 1 second to execute the script..."

If I want to use the script I'm attempting to create in order to cleanup a model made by thousands of curves (or edges),
specifying the length (in a range) dragging a slider, I don't think that we are talking about 1 second...I think much longer.

Anyway, I want to thank you for your suggestion and I will write here the results of my speed test of this kind of codes (loop).

Please consider that execution time in loop is very important if I want later to translate this cleanup scripts into nodes
for P. Elephant.

There, usually we drag slider to easily input values, and when you drag a slider and the code is not optimized,
the slowness is very evident.

This is what I want to do.
First write this cleanup script and then translate them for P. Elephant.

Thanks a lot for your support.

Marco (mkdm)

---

Hi Marco, so for the slider case it should definitely work to get the lengths once when it first starts up, and then refer back to that when the sliders are manipulated rather than doing it every time.

And if a loop through the cached lengths is taking significant time for the loop itself it should also be possible to optimize the script in other ways that are specific to its own particular needs. For example after gathering the lengths it could sort them so it could do a binary search rather than a full loop. But I would recommend a simple approach first.

These methods are appropriate to implement within the script itself, I would not expect to implement them in MoI's API directly. The stuff at the API level is more for general purpose stuff that may be used by many different scripts.

- Michael

---

@You : "...For example after gathering the lengths it could sort them so it could do a binary search rather than a full loop..."

Yes! I was thinking about this solution too.

Thanks a lot for suggestion.

@You : "...I would not expect to implement them in MoI's API directly..."

OK Michael. Understood :)

I hope that for V4 you could add at least "getArea()" method.....but I hope more...

Thank you very much for this very interesting conversation.

Have a nice day.

---

You're welcome Marco!

---

Hi Michael.

So...after the long conversation I've produced some little thing.

I hope that this is only the first step :)

Please read it at http://moi3d.com/forum/index.php?webtag=MOI&msg=8608.1

Thanks a lot.

---

Show messages:  1-16  17-32