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

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

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.

Hi Michael,

In MoI4 beta, Feb 2018:
There appears to be a bug when changing the color Style of one or two curves that are to be blended again.

1. Draw two red curves that are to be blended.
2. Select the two curves, and blend them. The blend is red.
3. Delete the blend.
4. Change the color style of the two curves to blue.
5. Select the two curves and blend them. The blend is red.
For these two curves, blend is stuck on style red.
Replace the first curve with another curve, of a 3rd color style, next to the first curve. Blend is "stuck" on style red.

Also, the blend is stuck on the first two ends blended. A second Blend does not work between different selected ends. The first blend keeps reccurring.
(Maybe one of the reasons I commented about selecting "close to ends" of curve, with Blend the other day.)

I came across this while testing clothoid created between two end points of curve(s), versus Blend.

- Brian

(Also I see that Blend does not work between the ends of one open curve, in either MoI3 or MoI4beta.)