Hi PaQ - that particular area for displaying edges of polygon meshes at mesh export time is a kind of special case area of the drawing engine, before the stuff I was talking about was more for the general case area of the regular working display where there are actual curves being displayed.

Currently MoI does treat those mesh-export polygon edges with basically the same process as curves, so it handles projecting the vertices onto the screen and forming polygons and then sending those polygons to the graphics card. That whole projection process is pretty fundamental for curve drawing since curves need to be broken down into individual separate lines, but for polygon edges it's not really quite the same thing so yeah for that particular area it could be possible to get a speed increase if I were to send 3D lines to the video card rather than textured polygons with the downside being that they won't get any antialiasing on them.

I can probably do an experiment in that one particular area - basically it's not an area that I've focused on a whole lot for performance tuning since it's only something that happens at one particular time (during mesh export) rather than all the time through regular work.

- Michael

Hi Michael,

Ok I get it.
I finally understand the difference between the way you draw curves on nurbs models, and polygones wireframe.

and I agree, boosting performance only during the export time is not really important.

Thanks for your time.

Hi PaQ,

> and I agree, boosting performance only during the export time is not really important.

Well at the same time I guess it's also not so bad to have the display look worse (with no antialiasing) at that time either...

Probably what I could do is use a different polygon-edge display method once you got over a certain number of polygons.

This is a lot less tricky area to experiment with than stuff involving the curve display engine so that's something that I'll take a look at.

But yeah for curve display there is certainly a lot more work being done than with a polygon display - surely you've noticed that curves are displayed in MoI very precisely, and when you zoom in they never become jagged? That's because there is a lot of work being done right "on demand" directly in the display engine to refine a curve to make it look smooth right at the current view of it.

That kind of quality makes it so with curves you're always seeing more of what the "true curve" really looks like and not only looking at some rough jagged approximation of it, and in a lot of cases that's like a kind of an always-on built in analysis tool where if you really want to know what the geometry of the curve looks like you can zoom in and see what's happening with it and not have to worry about "is it just a display artifact" ...

So anyway I've tried to focus my optimization efforts on improving speed while still maintaining that same quality level, and I haven't been all that excited about doing things that would degrade quality very much, at least not yet when there was still stuff on the table for improving the full quality speed like the multi-core use which is now in v3. But for mesh export on heavy meshes I probably don't need to worry about that high-quality aspect so much at that particular time.

- Michael

Hi PaQ, also there are a lot of CAD engines that draw NURBS curves all jaggedy looking, there are many for example that draw edges just by drawing the polygon edges of the shaded surface display mesh instead of doing the "show the true curve" way that MoI is focused on.

If you were to try one of those you would probably be surprised at how gross that would appear to you now after being used to MoI's display though... ;)

And not just gross from an aesthetic view only, but it also removes an important visualization and analysis method of being able to see more detail on what a curve is really like when you zoom into it more.

It wouldn't necessarily be bad to have a kind of hybrid mode where at certain times like when orbiting the view it would switch to a low-quality-but-faster mode and switch back again when you're actually drawing... But again it often comes down to "where to put in the effort", and so far I've decided that it's better to put more effort into making the regular full display mode to get speed improvements as more of a priority. With the multi-core work being done now I think I may have just about ran out of things that were potential things to do for that though.

- Michael

A little test of MoI's new DXF import/export functions.

This file was originally done in the '80s to exhibit the precision capabilities of AutoCAD, I think.

The text doesn't show up, but I suppose that's expected because MoI is still growing, but bear in mind this drawing is to scale...

...Try to find the Lunar Lander with its plaque (text is gone, but the frame's there).

Very nice Michael, how circles don't degenerate into very low-count polygons.



Martin (2).

Hi Martin, thanks for testing the DXF import!

Yeah that is normal currently that text will not come in - MoI does not currently have anything set up for "annotation" type entities like dimensions or annotation text so it does not attempt to read those kinds of entities in yet.

MoI's DXF importer will currently read any of these AutoCAD entities: LINE, CIRCLE, ARC, POINT, LWPOLYLINE, POLYLINE, ELLIPSE, SPLINE. Also blocks ("INSERT" elements) and nested blocks are supported and their contents automatically converted into regular geometry.

The text that you are asking about is in the file as a "TEXT" entity and not any of those above geometric entities, so that's why it does not show up.

I think you can use Explode in AutoCAD to convert from "logical text" into just plain line geometry though, if you did that then it should come through.

- Michael

Hi Michael.

I'm posting this file because I'm not sure about the outcome of the fillets around the handle to body intersections.

The main body is a network surface and the handle is a sweep, each made as a solid, unioned, filleted and the whole lot scaled up x 10.

I wondered if there is an continuity issue, as fillets (which had to be done by clicking several times, due I think to the surface seams) don't flow smoothly from one to the next, i.e. there's a distinct join between them.


**Actually, I think it might be a manifestation of this problem http://moi3d.com/forum/index.php?webtag=MOI&msg=5376.1 **



Martin (2).

Hi Martin, it's a similar problem as that previous one but a fairly different case inside the filleter itself as the fillet in your case here is made up of multiple different segments and not all one single closed fillet surface.

Do you have this in its pre-filleted state?

Also it looks like this may have been done with the "constant distance" option in filleting? That particular filleting method seems to have some various more problems than some of the other methods, I've sometimes thought that maybe I should remove the option for it since it doesn't work all that well.

- Michael

Hi Michael.

File attached, pre-scaled and pre-filleted.

My vote would be for you to retain the Constant Distance fillet if possible, as it makes a nice compact blend (in this file), which is of a fundamentally different shape to all the other options and I find, suits some situations better.

*TWEAK REQUEST*

I've been using MoI's text tool and it's very nice thank you - could you consider allowing the scroll wheel to adjust font and size? Little video of the feature in CamBam included of what I mean. http://screencast.com/t/RV7Bsen2


Thanks for the constant work you put in.

Martin (2).

Hi Martin,

> File attached, pre-scaled and pre-filleted.

Thanks for the example! There's definitely a bug there, but yeah it is a different case then the "closed single fillet surface" area that I worked on for the past release.

Unfortunately the fillet engine in general is a very complex area of the geometry library and it is very time consuming and difficult to investigate these kinds of problems. So this one will probably have to go on a list of stuff to look into longer range and I will not likely be able to address it right now.


> I've been using MoI's text tool and it's very nice thank you - could you consider allowing the scroll wheel to
> adjust font and size? Little video of the feature in CamBam included of what I mean. http://screencast.com/t/RV7Bsen2

It's difficult for MoI to do that for size, because MoI's size control for there is not bounded to some small list of predefined choices like the CamBam sample that you show there that seems to only include typical "point sizes" like you'd see in a word processing font control.

MoI's one generates 3D geometry and is not oriented around printed point sizes like that.


For the font style, right now that's not working because of a separate feature which is that the scroll wheel controls zooming in and out of the viewport rather than scrolling a select control. That might be possible to adjust though when the mouse is located directly over a select.

- Michael

Ok, I understand the situation about the fillet bug, Michael.

As for the font size, well nothing's simple is it :)

Whizzing through the available fonts whilst they update the text is quite a nice thing to use in CamBam, so if it can be had in MoI, that would be brill.


Thanks.
Martin (2).

Hi Martin, so there is actually a way for you to whiz through the fonts currently - to do it click on the font dropdown once which will open up the dropdown, and then click on it a second time which will close the dropdown but maintain keyboard focus on the control itself.

Then at that point you can push the up or down arrow keys on your keyboard to rapidly whiz through different fonts and see it update continuously.


Also another method you can use without any clicking is that after you launch the Text command push the Tab key twice which will put keyboard focus on the font dropdown also and then you can use up/down arrows after that.


I did a quick experiment with trying to get the scroll wheel to work, but that particular behavior with the scroll wheel on those kinds of controls does not seem to be enabled in the WebKit infrastructure that MoI uses for all that UI, so it would likely be a fairly involved matter to enable it.


I hope though that the up/down arrow key action that works currently might be a good substitute since it's quite similar.

- Michael

Michael.

Thanks for checking this out.

The up/down arrows keys method is absolutely fine by me!
I wasn't particulary looking for a mouse solution, just some way of whipping though the fonts and seeing how they look on the fly :)

Lurvely!



Martin (2).

Hi Michael, I like the way MoI is improving but there are still two little big issues with the mac version that the windows one doesn't have. First, the offset command has improved its launch time but still it isn't as fast as on windows. Did you particularly worked on some area to make it better? Offset is a very common command for me and The other very annoying thing (discussed a little time ago) is that some times when you launch a command that needs some numeric input it doesn't highlight the input field automatically as it should when you type something. Those things feel really bad because the plus of MoI has always been the closest to perfect interface.

Aside from that I just started working on an architectural firm they are starting to like MoI, I'll see what happens!

Hi ed,

> First, the offset command has improved its launch time but still it isn't as fast as on windows. Did you
> particularly worked on some area to make it better?

No, nothing has been worked on in this area recently. But I think I have a fix now, I just investigated it and it turns out that the setup for the Offset command was making the command processing system mistakenly think that the command had failed initially and when that happens the command processor worker process will get flagged to get recreated on the next use, and that command processor spin up time seems to be a bit slower on Mac and so that creates a kind of lag.

I've attached an updated version of the offset command file which should fix the problem, to install the fix download the attached Offset.js file and then right-click on the MoI app and choose "Show package contents", and inside there go into the directory drive_c/moi/commands and copy Offset.js there overwriting the old version. After that repeated offsets should be speedier.


> The other very annoying thing (discussed a little time ago) is that some times when you launch a
> command that needs some numeric input it doesn't highlight the input field automatically as it should
> when you type something.

I remember the offset one being discussed before, but I don't remember this other one and I can't seem to repeat the misbehavior over here.

I'll need to be able to repeat this problem in order to look into a fix for it. Is it with one specific command that the auto-focus behavior doesn't work? Does it stop working at one certain point in a session with things that it used to work with before? Is there any pattern you can see for when you run into the problem like you see it after showing a certain dialog or opening a new file or something like that? Over here I did a quick test with basic things like drawing a line, drawing a rectangle and a circle, etc... and I could not see any problems.

I'll need more information and hopefully repro steps for this second one in order to have any chance at fixing it.

Thanks,
- Michael

Perhaps this is asked before but,

Is it not an idea to have (more) buttons in the panels? There are so many nice and cool scripts and so many shortcuts to remember.... I have setup shortcuts for a lot of scripts but the ones I do not use often I forget that I installed those...
It would be nice to use buttons instead of all those key combo's.
Or am I the only one?? I'm used to Cinema4D and there I can move any script or any command on a panel.


Peace,
Rich_Art., ;-)

Seems a customised UI was asked from numerous users from a long time :)

No..you're not the only one..i think Michael keeps to mantain a clean "zen" interface(this is one of the best features of this software)
but the scripts are growing very fast,so a choice to add a button somewhere in the UI just for your favourite scripts could be a good compromise
you know..press CTRL+A or ALT+X etc...and remember all them..it's not exactly a clean and fast workflow..

Hi Rich_Art, I definitely want to make the UI more easily customizable in the future. It involves a lot of work though, and currently I've placed a higher priority on other areas of work like bug fixes and new modeling functions.

I expect in the future it will come in some stages, like probably some kind of plug-ins menu where you would be able to see a list of installed plug-ins will probably be first at some point before some kind of more extensive UI customization mechanism.

Those things do not really block you from doing actual modeling though, so things like new modeling functions are just more important to focus on before that though.

The keyboard shortcut mechanism is also pretty primitive, and I'm definitely aware that it will need some attention too, like it should be possible to assign shortcut keys more easily by just pressing the key that you want to assign rather than typing in a label like the current method. Again, that's just a matter of priorities.

- Michael

Hi Mauro,

> but the scripts are growing very fast,so a choice to add a button somewhere in the UI just
> for your favourite scripts could be a good compromise you know..press CTRL+A or ALT+X
> etc...and remember all them..it's not exactly a clean and fast workflow..

Really the main solution right now for this is to just not install so many scripts, especially ones that you don't regularly use.

If you don't install things you don't need, then you don't need to worry about keeping track of them either... ;)

But actually though, it is certainly true that MoI is just not currently optimized for this kind of "lots and lots of scripts installed" kind of case. But it's all a matter of priorities, do you really want me to focus on a big overhaul of making an elegant UI for managing all your scripts or would you rather that I work on improving Blend so that you can actually construct surfaces better than you can right now?

Basically the existing keyboard shortcuts and scripts mechanism even though not ideal works well enough that it's hard for me to justify putting an overhaul in that area as a high priority.

If you're having problems remembering things you can always do something like write yourself a text document that helps keep track of things for you.

I do expect that it will get overhauled eventually, but I'm not sure exactly when.

- Michael