Full Version: V4 beta Feb-9-2018 available now

Show messages:  1-20  21-40  41-60  61-80  81-100  101-120  121-140  …  161-163

Ciao Michael!

I have done another benchmark to compare V3 and V4 in the hope that it can be useful for you :)

This time I've used the "pipe" command on a bunch of half-circle replicated 572 times around 4 sphere of 100 mm diameter each.
The "pipe" was 1 mm of radius.

I have selected all the curves and fired the "pipe" command in one shot both in V3 and V4

My config is :

Windows 10 Pro 64 Bit
i7-7700K 4.5 Ghz
32 Gb DDR4 Ram 3000 Mhz
Nvidia Gtx 1080 Ti (11 Gb GDDR5X Ram and 3600 cuda cores)
Moi installed on Samsung EVO M.2 NVME SSD

Settings on both Moi V3 and V4 : Mesh Angle to 5 with Add details to inflections


These are the results :

FIRST TEST IN V3
-------------------

TOTAL TIME : 1 MIN E 30 SECS

TOTAL MEMORY ALLOCATED : 1.609 MB


SECOND TEST IN V4
-------------------

TIME : 28 SECS !!!

TOTAL MEMORY ALLOCATED : 1.786 MB

This is the final scene :





CONCLUSIONS
--------------------

V4 was 3.21 times faster than V3 !!!

But...there's one thing that doesn't convince me...

You can see it in this video : http://take.ms/ezQw8

I know that some times ago you told us that now V4 has a different internal mechanism to running scripts/commands.
They're executed into the MAIN thread, the same thread that handle the UI.

Now, this is perfect with regard to the speed, but now I can't have any control after the command has launched.
If the command, like the case of my benchmark, takes a certain amount of time, Moi freezes and I cannot stop the execution of the command.

Some times ago I didn't able to stop a custom command, I don't remember which, that during the execution has encountered a problem,
but I had to do a force close of Moi, and I've lost the entire work because I didn't save.

What I want to say is that is perfect to have a better speed, perfect, but given that now we can't do anything to stop the execution of a script/command that takes too long, we can only do a force close of Moi.

My requests are :

1) Is it possible to have the chance to decide in which way we want to fire a command/script : old way, with total control of the UI, new way as it is actually in V4 ?

2) If the first request if not feasible, could you give Moi the feature of "recover" the last work when we have to do a force close ?

Thanks a lot for support.

I stay tuned.

---

Hi Marco, thanks for running the benchmark!

> 1) Is it possible to have the chance to decide in which way we want to fire a command/script :
> old way, with total control of the UI, new way as it is actually in V4 ?

No, I don't expect that it will be feasible to do this. It would require a lot of work to add interprocess script marshaling support for the new cross platform script interface. That functionality used to be provided by the windows specific COM API.


> 2) If the first request if not feasible, could you give Moi the feature of "recover" the
> last work when we have to do a force close ?

It might be possible to set up something that would trigger an exception and then you'd get the crash dialog which has a save option on it.

But an already existing way would be to use the regular Sweep command for doing this, it should be interruptable unlike the Pipe command.

It's probably possible to update the Pipe script to be interruptable too, it's a matter of using the factory.update() and factory.commit() calls instead of factory.calculate() , or maybe even just checking if there is a cancel event inside its inner loop where it builds all the pipes.

- Michael

---

Thanks a lot Michael for the detailed reply.

@You : "...No, I don't expect that it will be feasible to do this..."

Ok. I understand. No problem.

@You : "...It might be possible to set up something that would trigger an exception and then you'd get the crash dialog which has a save option on it..."

Perfect! This could be sufficient :)

@You : "...But an already existing way would be to use the regular Sweep command for doing this, it should be interruptable unlike the Pipe command..."

Thanks for the tip.

But, besides the benchmark and "pipe" or any other command I simply wanted to talk about the problem of "non interruptable" things and "lost work" because of forced closing of Moi.

Anyway, thanks a lot for your support.

---

Hi Marco,

re:
> But, besides the benchmark and "pipe" or any other command I simply wanted to talk about the
> problem of "non interruptable" things and "lost work" because of forced closing of Moi.

The regular commands built into MoI like Sweep, Fillet, Booleans, Extrude, etc... have all been created specifically to be interruptable. They avoid doing any calculation loops in their scripts, the only loops they do in a script file are event loops.

So with those commands you should not see problems like that.

Custom scripts are another matter, it's more likely that they will do calculations in loops because they don't have the careful separation between script and a factory back-end set up specifically for it that makes interruption and not blocking the UI possible.

So one thing you can do if you are very worried about not being able to interrupt something is to not run any custom commands and only use the built in ones, that would probably solve your problem.

I have an idea though that may help with custom commands too, I can probably make a few key methods like factory.calculate() return a script exception if the escape key is held down and the script has not waited for any events for a little while. That should probably force most scripts to exit without needing to rewrite their inner loops to be "interruption-aware". I'll give that a try for the next beta.

- Michael

---

Ciao Michael and good morning.

Thanks for your detailed reply.

@You : "...I have an idea though that may help with custom commands too, I can probably make a few key methods like factory.calculate() return a script exception if the escape key is held down and the script has not waited for any events for a little while. That should probably force most scripts to exit without needing to rewrite their inner loops to be "interruption-aware". I'll give that a try for the next beta..."

I think that this could be an excellent solution!

@You : "..The regular commands built into MoI like Sweep, Fillet..."

Thanks a lot for explanation.

@You : "...So one thing you can do if you are very worried about not being able to interrupt something is to not run any custom commands and only use the built in ones, that would probably solve your problem...."

I'm sorry but this is absolutely not feasible for me because in my modelling sessions a deeply leverage on custom commands.

Anyway, just in order to better clarify what I wanted to say, please consider these two key aspects (for me)

1) Please, don't write any solution in the next beta that could degrade the speed performance of any custom command.
Most important thing for me is speed of execution!
For example, referring to my previous benchmark : As you have seen the "pipe" command was about V4 is about 3.21 times faster than V3 with that particular benchmark.

If, for example, the solution you thought (factory.calculate() that should return a script exception if the escape key.) will degrade the performance of the pipe command, please DON'T apply this new solution.


2) Keeping intact the speed of execution it would be enough for me to have the chance to SAVE the work with the solution you wrote in previous post :
@You : "..It might be possible to set up something that would trigger an exception and then you'd get the crash dialog which has a save option on it..."


I hope I made myself clear :)

Thank you very much for your kind support.

I stay tuned, please let me know what do you think about this post.

Ciao.

---

Hi Michael,

I did some tests, and the lagginess is present in both split views and maximised views, and it also occurs when I move objects. It feels as if the general viewport refresh rate is lower than before, causing a laggy response to my pen movements.

I assume you're using OpenGL 4.1?

It might simply be a case of the retina resolution having to redraw much more pixels than my previous resolution needed to.

Regards,

Metin

———————

visualization • illustration • animation • 3D (print) design — https://metinseven.com

---

Hi Marco,

re:
> If, for example, the solution you thought (factory.calculate() that should return a script exception
> if the escape key.) will degrade the performance of the pipe command, please DON'T apply this
> new solution.

I don't expect it to have any significant performance impact but it could be good to repeat the test after the next beta to see for sure.

This one is easier to set up than figuring out how to force the crash dialog to get triggered, so I'll try this method first to see if it solves this problem.

- Michael

---

Hi Metin,

> I assume you're using OpenGL 4.1?

No, currently it uses OpenGL 2.1 + extensions. That's to maintain compatibility with older OS versions and also because MoI doesn't currently need any of the newer OpenGL features.

It doesn't use the legacy pipeline functions though, it uses vertex buffers and shaders same as what's required by newer OpenGL versions.

- Michael

---

@You : "...
I don't expect it to have any significant performance impact but it could be good to repeat the test after the next beta to see for sure.
This one is easier to set up than figuring out how to force the crash dialog to get triggered, so I'll try this method first to see if it solves this problem."

Ok. Got it!

Thanks!

I'll try the next beta.

---

Hi Michael,

Ok, thanks. I might check with older drivers.
Wacom has great hardware but the drivers side often is not up to par.

In the past I had several other problems caused by the drivers that took me a while to figure out.

Marc

---

Hi Michael,

http://moi3d.com/forum/index.php?webtag=MOI&msg=6051.6
>>In the future I do want to add a display mode for showing back facing surfaces.

Is that on the focus vor v4 ?
Thanks

---

Hi EDDI - I'm sorry I can't promise exactly what will be in v4. Previously viewing backfaces hasn't been a major priority because nothing in MoI's own operation is sensitive to it and if an app that you are exporting into is sensitive to it, it kind of makes sense to me that they would have a flip function that works in it.

- Michael

---

Hi Michael
Yes it's ok, special commands have a flip function.

But in modeling space it's good to know:


regards

Image Attachments:
wind.JPG 

---

You look in the window!

---

Hi Rudl
I can ask differently, I stand in front of the window or behind it ?
So what is the position in front or behind, if you do not see "normal direction".
Regards and good neight.
I'm look in to my bed under back face from my blanket.

---

Hi EDDI -

re: window - in MoI if that's a solid I guess you'd say you're looking AT the window. There isn't anything built into MoI that considers one outer side of a solid to have a different property than the other side. The Flip command previously referenced only does something to a surface object, it doesn't do anything to a solid. A solid is automatically oriented to have its surface normals pointing to the outside region of the solid volume.

Similarly a "show backfaces" function will only show something of note on open surfaces, a solid doesn't have any visible backfacing polygons unless your eyepoint is located inside the solid itself which would then show all parts of the solid as backfaces.

- Michael

---

Good morning Michael,

re:re: window - in MoI if that's a solid....

That's why I also took this supposedly stupid example/question.
The windows glass panes are not solids in this example (why too).
1. With "show back faces" you can see it immediately.
2. And the answer for the position would be immediately visible.
3. If the normal's are aligned correctly,
and surface model is exported to other CAD with "show back faces" on (I mean, "on" inside other CAD),
it also looks clean and aesthetically.

But.... I belong to the faction of followers for "show back faces" and put my point of view.
If no further followers word annotate (there are some here),
then the discussion for this function is over here.

---

Hi Eddi,

I use for this purpose Orient Command inside MoI. I learned it from forum some time ago, but I cannot find this thread. On picture below you can find two windows. I've modelled frame (solid) and then glass (surface only), then I've copied this model and rotated by 180°. So now the windows surface is "flipped". In MoI both surfaces looks same, but if you select them and use Transform/Orient command you can see difference in axis orientation. When you use this model in some rendering software for example, you can see same difference as well.

This is very useful trick especial for mesh emitters in renderings sw.

Hope this helps.

Ciao
Mik

Image Attachments:
Orient Surface.gif 

---

You can make the same with Press TAB then write Flip (you can also make a shortcut with this hiden function Flip! )

Maybe more tricky when you have several objects with many orientations, forms etc...! ;)

And it's only the surface(s) who is flipped... can be useful in certain cases!

---

Hi Mik,

Thanks for comment.
>> I learned it from forum some time ago, but I cannot find this thread

I know the thread
The second method described was with command >SHELL<, that's wrong, I meant >OFFSET<



But all too much clicking in a big scene.

Image Attachments:
NOffs.gif 

---

Show messages:  1-20  21-40  41-60  61-80  81-100  101-120  121-140  …  161-163