Hello all,
hello Michael. Hope everything is well there....

When I try to import a igs file of approx 1.5 MB into MOI, the program shuts itself.
I have opened it in rhino3 no problem, copy and paste it in MOI, again it shuts.

My computer is a bit old and slow....is it the reason?

I include the file
Thank you!
PS. Enjoying MOI more and more....

Rudy

Hi Rudy, thanks for posting the file for me to test.

It looks like MoI is creating an excessively large display mesh for this surface. One thing that will help with it is if you go to Options and uncheck "Add detail to inflections".

But even with that turned off, memory usage will spike up to 600 megs for a moment before it settles back down again. If you have less than 1GB of memory on your machine this will be a problem. You can also change 2 additional settings to reduce the memory consumption - set the "Surface angle" and "Trim curve angle" in the options dialog to 20 instead of the default 10. This will make a coarser display mesh which pretty much solves the problem that is happening in this particular case.

Later on when you are done working with this large surface you will probably want to turn these settings back to the default so regular objects look nice and smooth instead of more jaggedy.

I should be able to tune this up so that it works better and doesn't hog so much memory for larger single surfaces like this.

Thanks for reporting the problem!

- Michael

Thank you Michael,
Yes, my computer have less than 1GB ( I have another one which is more than 1GB...but I am used to work on my old Dell...), and yes, I have noticed that this particular relief was pretty large in size.
I will be careful to import only things that are pertinent to an actual workable project...this was just a test,

Just learning....
Good night Michael.

Hi Rudy, if you change those 2 settings in options ( Surface angle and Trim curve angle from default 10 to 20 ), then I think it should work ok even on your lower memory machine (as long as its not _too_ low in memory... )

Does it still not work for you even with those Options changes?

But I should be able to make it work better without messing around with any settings.

- Michael

Hi Rudy, I have tuned up the next beta to handle this type of large import relief surface better now.

I was able to reduce memory consumption by about 1/3 which should help. Also I automatically switch to a slightly rougher mesh density for large surfaces.

So the next beta should handle this well without you needing to mess with any settings.

- Michael

Great!,
Thank you Michael.

Rudy

I'm opening an IGES file that is rather complex (95,000 entities). MOI does open it (pre-set the surface and trim curve values from 10 to 20) if I zoom a viewport it gets to a certain point, stops, and the system is nearly hung. CPUs (it apparently isn't multi-cpu aware?) go to 68/65 and stay there. Getting to the Task Manager can be done but each screen update takes 10-30 seconds while drawing the window, buttons, text, menu bar & sub-menus over and over. It's interesting to watch the UI draw itself (never seen it in slow motion before) but after 20+ minutes, I enabled the fickle finger of fate and rebooted. I was using the /3GB switch, so started without it. No difference. Next time, I opened the model and immediately saved as a 3dm. No difference. Next time, I set CPU affinity to CPU1 only. The model zoomed out a little faster but stopped at a point not as far out then hung. Next time, I set the two values above to 30. Model loaded faster and I sequentially zoomed three viewports a little bit at a time each. One got about to the same point and hung the app.

XP32/SP2
2GB RAM
Dual AMD 2800+ MP-M
ASUS A7M266-D
PNY 6800GT 256 AGP 91.85 drivers

Hi Speed, thanks for the bug report.

It's going to be a bit tough to totally track down what is happening there since I can't reproduce the issue over here.

I presume the iges file is really large? Are you willing to put it on a CD-ROM and snail mail it to me? If you are willing to do that, I could then examine it over here and try to solve the problem.

Switching to running extremely slow is generally a symptom of RAM being completely full and having hard-disk swapping engaging.

But it is odd that it is triggered by zooming in. Is it when you zoom in especially tightly?

Normally I wouldn't think that zooming in would trigger a big spike in memory consumption - the only thing that I can think of that would be effected by a zoom-in is curve drawing (because the shaded surfaces have identical data regardless of zoom factor). I guess that curve drawing is going crazy on something in your model and spiking up in memory usage. Curve drawing is actually a pretty intensive procedure, a lot of time it actually takes more crunching than surface drawing for many models.

For now you may need to only work on a portion of the file at a time.

- Michael

Oh yeah, and the new beta that will be released in a couple of days has the 1/3 meshing memory reduction mentioned above in this thread, it's new for this coming beta.

That might help a bit too.

- Michael

>I presume the iges file is really large?

45MB, 95,000 entities. It opens in Rhino2 and can be worked with. A bit jerky when translating but that's to be expected with this many parts updating.

>Are you willing to put it on a CD-ROM and snail mail it to me?

Possibly. I'll have to check with the agency.

>Switching to running extremely slow is generally a symptom of RAM being completely full and having hard-disk swapping engaging.

Disk was silent. Looked like a memory leak. Running 2GB RAM. Just opened the model with Task Manager pre-opened and watched the memory. MoI started with 23 MB with no model loaded. Climbed to 212.6 MB with the IGES file loaded. VM use climbed to 201 MB. CPU never got over 50% each on a dual CPU system while this is working but it did show 66/68 when it hung.

>But it is odd that it is triggered by zooming in. Is it when you zoom in especially tightly?

I'm zooming out.

>Curve drawing is actually a pretty intensive procedure, a lot of time it actually takes more crunching than surface drawing for many models.

I'm guessing that this is the case. When zooming out the front view, internal curves that couldn't yet be seen in the top view re-drew themselves many times. this time, I tried zooming out really fast and it got past the point where it would hang previously. Memory climbed only to 224.6 MB. Zooming the side port, memory climbed to 229.6 MB. Zooming the front port out made no increase over the side port value. As the zooms progress, they update faster when more of the model is outside the viewport. As more comes into view, the updates become chunky. A clue, here, may be that when zooming the front port this fast, none of the curves had a chance to redraw. Once it got out far enough to display the whole model, they are small enough that they do not display.

While trying to export to OBJ, the CPUs go to 50%x2 and the dialogs that show asking for parameters exhibit the same slowdown as when the app hung. While this is going on (selecting quads & triangles in meshing options) memory slowly climbs at ~100K/s. This one dialog selection took about 5 minutes to complete. Through all this, peak memory use was 273 MB, so I'd guess that running out of RAM isn't the problem but the app running around in circles internally might be.

The OBJ hangs Deep/3D Explorations at object 5648, so can't see if it has done this correctly. 3dm seems to only export Rhino3 files, so can't look at this either.

[later] I think I found something. When the model did open and zoom/translate successfully without pegging the CPUs, it was in wireframe mode. Creating new geometry while this model was loaded created non-shaded representations. Closing the model and creating new geometry continued to create nurbs wireframes. Closing the app, re-opening and loading the IGES file, loaded it in shaded mode and MoI crashes when zooming. Presumably, this is due to hidden geometry re-draw that partially shows through the shaded surfaces, so I turned off display of hidden curves and edges. Model will zoom out farther and faster but presents the Unexpected condition (crash) dialog instead of hanging. Question is, how did/do I get into/out of wireframe?

But then MoI crashed XP entirely to a black screen reboot, rather than closing when hitting the "Close" button in the Unexpected condition dialog. This also happened the first time yesterday, where the 2nd through 8th times it hung with no dialog presented and a finger was required to continue.

> Question is, how did/do I get into/out of wireframe?

There isn't actually a wireframe mode (other than hiding selected faces after you load) - this would happen only if there was some error in calculating the display mesh, or potentially something has gone wrong at that point with your video card and something is not working properly when attempting to display shaded polygons. The latter could be due to either a bug in MoI or a bug in your video card's driver software.

It may be worthwhile to update your video driver and see if that improves the situation. You mentioned you have the 91.85 drivers, it looks like there is a newer 94.24 version available here: http://www.nvidia.com/object/winxp_2k_94.24.html


> <...> but presents the Unexpected condition (crash) dialog instead of hanging.

There should be a crash dump file generated - can you please check in the MoI folder in c:\Program Files? It should be a file named moi_report1.zip . If there is one or more of those there, can you please e-mail them to me at moi@moi3d.com ? I may be able to determine the actual line of crashing code from that.

Thanks,

- Michael

> But then MoI crashed XP entirely to a black screen reboot,

I'd definitely recommend updating your video drivers... The full XP crash is a sign that something is going wrong at the video driver level. It's still possible that MoI is sending bad data to the video card or something, but I'm somewhat more suspicious of the driver itself right now. If you update your driver to the latest version you can take that part out of the equation.

I seem to remember that there was a problem at one point with nVidia and dual-proc machines.

- Michael

>I'd definitely recommend updating your video drivers...

Man, I'm gettin' tired of hearing that. No offense (and I am NOT trying to be belligerent, here, and I sure don't want to alienate you, because this app shows real promise and I'm here to help), but that's what everbody says as the first default response; coders, users, you name it. "Update your video drivers." It's become a throwaway cliche anymore. Continually trying out new video drivers gets to be a pain after a short while and certainly tends to break other apps that are working. One of these boxes has a Quadro and the drivers I'm using are the latest for it. 91.85 is what NT is using on their new Quadros and it works great for all of my other OGL apps. Once I find a good set of drivers that work across the board for my mainstream apps, it will take a lot to get me to take a flyer and experiment.

>The full XP crash is a sign that something is going wrong at the video driver level.

Might be *a* sign, but not the only one. Note that this only happens when the (crash) dialog shows, not when MoI slows the machine to a crawl. This time, I had to kill MoI while sitting at the (crash) dialog after hitting the Close button and waiting 10 minutes for it to do something before doing so. That's when it crashed to black screen. The dialog box had focus.

>It's still possible that MoI is sending bad data to the video card or something, but I'm somewhat more suspicious of the driver itself right now. If you update your driver to the latest version you can take that part out of the equation.

Can't buy that absolute conclusion. The latest video drivers can't fix all things all of the time and some definitely go in the other direction. Rhino2 opens and translates the file just fine with these drivers, as do a couple of other apps, so I'm more suspicous of MoI. Again, I don't want to make you angry by any means but this hasn't been my experience and I'd like to help find a solution.

Something caused a really *nice* wireframe with all edges and curves displayed, and I mean REALLY nice! Zooming was smooth at larger factors, translation and tumbling was responsive. Perhaps I have found the wireframe mode that you are looking for. Creating a new cylinder sure looked weird; circle with a vertical line at tangent with another circle above tangent to it but, hey, if a wireframe can be developed and a complex model will open and be worked on, I'm all for it 'cuz it was nice. ...If I only could figure out what triggered it.

Hi Speed, I can understand that you don't like hearing "update your drivers" all the time, but the fact is that buggy video drivers are a constant problem.

When I worked at Microsoft, I learned that the single biggest cause of Blue Screens of Death were buggy video drivers.

Normally it isn't feasible for a regular "user-mode" program like MoI to crash the entire operating system. For the whole operating system to crash requires a driver to do something bad since they run at a privileged level and can access protected kernel memory that a regular user-mode program cannot.

Your full system crash is a very big indicator that something is going wrong at the driver level. It may be due to MoI poking the driver in some improper way that it doesn't expect, or it may be due to bugs in the driver itself.


> Can't buy that absolute conclusion.

Certainly nothing is absolute in debugging. Until you know the problem, you don't know it...

But the clues are very strong that you've got a driver problem, particularly because this is an unusual problem, you are the first person to describe these particular symptoms. If I was constantly getting reports like this (or even just more than one), I would be less likely to blame the driver at first.

One of the best approaches for successfully debugging is to rule out different problems to narrow down the issue. That's why updating your drivers would be helpful because it would help to either validate that it was a driver issue, or rule out that it was a driver issue. As it stands right now it is completely possible that it is a driver issue.

If you can send me the data, or at least try it on a different machine with a different video card that would also be helpful. If the same problem can be reproduced under 2 different hardware environments, that really helps to narrow it down to a MoI issue instead of a driver issue. Crossing things off the list of potential problems is progress in debugging!


> The latest video drivers can't fix all things all of the time and
> some definitely go in the other direction.

Well, here's the thing - if you don't think that buggy drivers are the problem, then why are you worried about updating to new drivers that might be buggy? I mean this itself is a sign that you know that drivers have problems in them!

I've never seen a driver update that is permanent and irrevocable, you should be able to roll back to your current driver (or just re-install the older one) if the newest ones cause new problems.


> Rhino2 opens and translates the file just fine with these drivers, as do a couple
> of other apps, so I'm more suspicous of MoI.

If I remember right, Rhino2 in wireframe mode does not by default use hardware acceleration, I think it draws your wireframe with my old rendering code which avoids talking to the video driver (one thing that is nice about that is that it avoids driver issues, but it does not leverage the power of modern video cards though). And even if you have it set to use hardware acceleration, it and probably your other apps are using the OpenGL system which is a completely different driver system from the Direct3D one that MoI uses...


Don't get me wrong, I really appreciate your bug report and your good description of the symptoms.... But I'm not sure what you expect for me to do about it right now. It is very difficult for me to make progress without any narrowing down or any way to reproduce the problem over here, or even any additional similar reports to look for common factors..

Did you find out if you can send me the data or not?

What about crash dump files (moi_report1.zip), if you can find those and e-mail them to me it would be something I could look at.

- Michael

>Certainly nothing is absolute in debugging. Until you know the problem, you don't know it...

>But the clues are very strong that you've got a driver problem, particularly because this is an unusual problem, you are the first person to describe these particular symptoms. If I was constantly getting reports like this (or even just more than one), I would be less likely to blame the driver at first.

This is certainly not the first time that I have been the first to have discovered something. Infact, I have been increasingly retiscent to even report stuff I find until someone else happens upon it. Trouble is, not a lot gets done to fix esoteric problems.

>One of the best approaches for successfully debugging is to rule out different problems to narrow down the issue. That's why updating your drivers would be helpful because it would help to either validate that it was a driver issue, or rule out that it was a driver issue. As it stands right now it is completely possible that it is a driver issue.

>If you can send me the data, or at least try it on a different machine with a different video card that would also be helpful. If the same problem can be reproduced under 2 different hardware environments, that really helps to narrow it down to a MoI issue instead of a driver issue. Crossing things off the list of potential problems is progress in debugging!

Perhaps it might help to read my bios so that you can understand the level that I come from when examining scientific data:

http://imperialearth.com/bio.html

Then perhaps we can talk on even ground. Talking down to me isn't appreciated.

>and probably your other apps are using the OpenGL system which is a completely different driver system from the Direct3D one that MoI uses...

Now we're getting down to it. Yes, it is. Sorry for the noise and bother.

Hi Speed, sorry if it felt like that. I wasn't trying to talk down to you, just trying to give a complete outline of what the situation is and what different ways could possibly work to make progress on solving the problem.

In general there is no way for me to know the skill level or experience of any particular person that I'm talking to in this online manner, so I will often times err more on the side of trying to give very complete information.

- Michael