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

Show messages:  1-12  13-32  33-52  53-72  73-92  93-112  113-132  …  153-163

Michael, i have one GUI/usability bug report if possible to fix.

When i open *.step file and go to "Save as" then file requester for name is empty so i need to type in full name.
It would be good if it could remember name form opened object so we don't need to type in name form scratch if changing formats.
That system works if opened file is *.3dm so it keeps opened model name automatically so if i choose different format as *.OBJ, *.LWO, *.IGES i don't need to type in object name again, i just go and change extension/file format.

Thanks

---

Hi Metin,

re:
> The slight lag is apparent as soon as I initialise the creation of any object (curve or solid) by left-clicking
> once in the viewport and then moving the pen to determine the size.

Does it only happen with object creation and not anything else? If you draw a sphere and then after it has been create it and click and drag on it to move it, do you see it then?

Is there any difference in behavior with Split view mode vs a single view mode?

I'm not able to see anything like that here and I'm on really low end machines.


> <....> I don't know if you're using OpenCL. I've heard MacOS support for OpenCL is crappy
> compared to their Metal support.

I'm not using OpenCL but I am using OpenGL.

- Michael

---

Hi Marc, thanks!

> I don’t know if this has been pointed:
>
> On the Mac version : Hovering on a viewport and pressing middle button doesn’t pan (Wacom Intuos 5).
> Left clicking in the viewport first works.
>
> If I hover and use the touchpad it works ok.

I was able to track this down to a bug in the Wacom driver, some information here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=8731.101

I sent in a detailed bug report a little over a month ago with a simplified standalone program that reproduces the same behavior. I hope that they'll be able to fix it in their next driver update.

- Michael

---

Hi Lewis, so the reason why the current file name is only set when reading a 3DM file is that is the "native" format for MoI - it is the only format that MoI can store everything it can create into.

If you open a STEP file the current name isn't set so that if you do a plain "Save" it will open up a dialog for you to explicitly choose a format rather than just automatically saving back to a STEP file which will then lose views and background bitmaps that you may have created for example.

This is mostly a concern for a plain "Save" that doesn't show any dialog though. I'll have to think of it for a bit but it might be ok to do what you describe only for "SaveAs" or "Export" and not for "Save"...

- Michael

---

Thanks again Michael ...
I left my office for a few hours with the computer on and the framing model hidden but still on. When I started to work again the problem recurred. Rebooting, as you suggested, fixed it.
But I found some other problems with the model itself. Solids that I had arrayed are now joined surfaces (except the parent one). Fortunately, for this project that is not really a problem. I don't know if these are related to the freeze phenomenon but it seems like unusual behavior.
I should note that this is a model that has been revised numerous times so sloppy changes on my part may be some of the cause (though not the display freeze).
cheers,
eric

---

Hi eric, thanks for letting me know. That's a bummer that it is happening some more.

One thing that may work that's quicker than a full reboot is to use this keyboard shortcut: Ctrl+Win+Shift+B - on Windows 10 that will restart the graphics driver and it's likely to be as effective as a full reboot.

Hopefully it's something they will solve with a driver update.

re: arrayed solid becomes joined surface, that's not too likely to be related. It could be possible for that to happen if your solid had any areas of self-intersection in it, that can make a volumetric analysis of the object to behave inconsistently.

If you'd like to e-mail me the base object + copies that are behaving strangely I could take a look.

- Michael

---

Hi eric, also did you say before that you had disabled the "Threaded optimization" option in the nVidia driver settings?

- Michael

---

Hi Michael
<did you say before that you had disabled the "Threaded optimization" option in the nVidia driver settings?>
No I have not done that. I don't know how to. FOUND IT. IT IS OFF.
cheers
eric

---

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

---

Show messages:  1-12  13-32  33-52  53-72  73-92  93-112  113-132  …  153-163