Full Version: V4 beta Dec-12-2017 available now

Show messages:  1-15  …  56-75  76-95  96-115  116-135  136-155  156-175  176

Hi ...
Yes, I am a long time MoI user. I have noticed it, too. It's a big too, though it usually lasts only a few seconds so I have not reported it. I also recently had to acquire a different primary computer and thought it might be a hardware peculiarity.
cheers,
eric

---

Hi eric & alksndr - a couple of things you could try to see if it behaves any better are to disable anything labeled "threaded optimization" in the nVidia control panel settings, and you also might try setting DisplayThreadLimit=1 in moi.ini, it's in the [View] section.

- Michael

---

Here is a gif of the "frame skipping" issue - https://i.imgur.com/GwAndSt.gifv

I'm running windows 10. I'm on drivers from October so I will give updating a shot in a few hours.

---

Hi alksndr, another thing you might try is to open Task Manager, have it show processes from all users and then get it sorted by CPU usage. Then take a look at that while you're rotating the view around and see if some other process is hopping to the top of the list when you see the stuttering.

- Michael

---

Thanks for the help Michael. There's nothing wrong with the processes, just tried it. Changing the threaded optimization to off for Moi3D in Nvidia settings and setting the thread limit to 1 in the ini file has helped a lot. It still happens but I would say its 2x better now :)

---

Hi Michael

What seems to happen here is that when MoI is in perspective view full screen and I rotated the 3d image rapidly MoI tries to change the view to another one or more than one subdivision on the screen. This lasts for only a brief time and when it is happening rotation is frozen. This only lasts about a second. I have not reset the Nvidea settings though I did add '1' into the moi view ini settings as you suggested ... did not seem to make any change.

This, for me, is not often enough or serious enough to consider it a nuisance. But it does seem to be a slight glitz.

cheers,
eric

---

I SPOKE TOO SOON.
I changed the Nvidea setting right after I sent the last post and I couldn't duplicate the glitch again.
Thanks Michael. Your responses are incredibly fast. I have been waiting days for a response about Sim 8.
cheers,
eric

---

Hi Michael.

Thanks for the tip.

Could you explain more in depth what those settings do (both for Nvidia side and Moi) ?

They do a downgrade of the performance ?

Thanks.

Marco (mkdm)

---

Hi Marco, those settings make the video driver or MoI make use of multiple CPU cores to do some portion of the display work. But using multiple cores is an inherently difficult thing to make work properly, every thread that might access the same memory has to be synchronized with each other. In some versions of the nVidia display driver this has been buggy so if there is any odd display behavior it can be good to try turning off that option in the nVidia driver. There will be some performance cost to that, it's hard to say how much exactly it's going to be system specific.

- Michael

---

Ok Michael.

Thanks a lot for clarification.

I have a brand new Gtx 1080 Ti and I didn't notice particular issue with MoiV4 so far.
But ASAP I will make other tests.

What I really wait is the ability by Moi to use "all" this GPU power for its display routines,
because till now all my GPU cudas and VRAM (11 GB) are almost unused by Moi.

But I know that you already told me that this feature will be implemented as soon as V4 will be very stable and tested,
so no problem :)

I can wait.

Have a nice day.

---

Hi Marco, well if you had this problem it seems like you'd have noticed it by now. Your combination of driver + system setup probably doesn't expose whatever driver bug is happening here. If you have not seen any intermittent freezing you shouldn't modify these settings.

- Michael

---

@You : "If you have not seen any intermittent freezing you shouldn't modify these settings."

OK! Got it.

Anyway ASAP i will make other tests with some heavy 3dm scenes in 3D view full screen inside Moi.

I will let you know.

We'll catch up.

---

Hi Marco,

> Anyway ASAP i will make other tests with some heavy 3dm scenes in
> 3D view full screen inside Moi.

If the purpose of your test is to see if you have the intermittent freezing issue that's been recently discussed you just need to test a very light scene as alksndr was showing here:
https://imgur.com/GwAndSt

- Michael

---

Got it!

OK, I'll do that, then

Thanks :)

---

I'm currently using the Moi 4 BETA to clean up some .SAT files. While importing the object it is fully joined. After I repair some areas, save the file and reopen the object is separated so all surfaces are not joined. This wasn't happening with V3. Has something changed which is separating the objects after deleting some areas and/or saving?

---

Hi Puz, it is possible for it to happen in v3 too - the SAT importer will do this if it has certain kinds of errors when processing the imported trimming boundaries.

So it's likely to be something that's specific to that particular file. If you make something simple in v4 like a box and then export it and import it back again do you get a solid?

Is it possible for you to send the file to me at moi@moi3d.com so I can take a look?

- Michael

---

Hi Michael,

I tested the same file on both versions of Moi. I'm assuming it must be related to the file, but wasn't sure why 3 wasn't separating it, but 4 was.

Unfortunately, I cannot send the file. Although I did test exporting/importing a simple shape and that behaved correctly. I guess you'll have to file this one under "odd behaviour of complex file error". I'll make some further tests to see if it happens again.

---

Hi Max, I've finally had a chance to examine the SpherePoints+ performance issue you wrote about here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=8682.16

After some testing to rule out draw performance I was able to determine that it's due to the script using window.setInterval() to look for updates. It seems that recent WebKit and Chrome browsers delay the .setInterval timers if there is other intensive activity like continuous movement of the mouse I guess. I'm not sure why it only happens in MoI on the Mac version, maybe only the Mac OS happens to have the support for it.

There's a discussion of it in Chrome here:
https://bugs.chromium.org/p/chromium/issues/detail?id=570845

I haven't found the checkin that added it to Webkit but a lot of times Webkit and Chrome copy stuff from each other since only a few years ago they were the same codebase.

It sounds like it might be possible to use a different web timer api "requestAnimationFrame" which might not get delayed like setInterval:
https://stackoverflow.com/a/43951402
but I did not test that.

For this script it would be better to not use a timer at all and instead update things when a UI event is fired, that should ensure no delaying and also not burn CPU cycles by continuous polling when nothing is being actually changed in the UI. I've attached a modified version of SpherePoints+ that does it like that and it seems to solve this Mac performance issue. If you have this same problem in other scripts that are also using window.setInterval then it's likely to be the same thing there. Please let me know if you have seen any other script performance regressions in v4 that do not involve setInterval.

Hope this helps! - Michael

EDIT: forgot attachment

Attachments:
_SpherePoints2.zip

---

Hi Michael,

Yes, there something strange with webkit timers. Nodeeditor also uses setInterval, but it works much smoother than my SpherePoints script.
When I move mouse cursor inside Nodeeditor window - everything works good, but when I move cursor outside the window - a significant stutters appears.

Thank you for links, I'll read it tomorrow.


Yes, you're right. Your script works faster.


I tested all my scripts with MacOS 10.13.2 - everything works great (except the scripts which uses setInterval). I noticed significant performance increase!
For example, Cloth simulation script works about two times faster than before. I'm impressed.

---

Hi Max,

> I tested all my scripts with MacOS 10.13.2 - everything works great (except the scripts which
> uses setInterval). I noticed significant performance increase!
> For example, Cloth simulation script works about two times faster than before. I'm impressed.

Great! I wasn't really sure exactly how the 64-bit build work out for script performance.

The one other v4 performance regression that's been reported is Extrude giving lagging feedback in the Mac version. I've got a fix for that for the next beta.

- Michael

---

Show messages:  1-15  …  56-75  76-95  96-115  116-135  136-155  156-175  176