Hi Lewis,

re:
> Is there way to set TEXT font size for dimension stool (i find ti too small by default)

You can set the text size by clicking on the Font value here:



That way (using the properties panel for the selected object's properties) will change just what is selected. To change the defaults for newly created dimensions go to the Options dialog Dimensions section and set the preset's Font value.

> and is there way to show UNITS also ? I'd like to see meters/centimeters or any other user picked unit (in preferences)
> visible on the dimension line also.

You can customize the text content by editing the "Text" value that is just above the Font.

Put in your units label after the <> , so have it like: <>cm for example. The <> will be replaced by the dimension value.

There is not currently a way to set a units label for the default text. At some point in the future I would like to support other types of variables but that won't be ready for v4.

Hope that helps!

- Michael

Yes that helps, I've set size for default/new dimensions and works great, for units it's OK for now and i can edit that number but yeah would be great if it could also be set in options for default/newly created ones also in future.

Thanks :).

Hi Michael,

Some keyboard shortcuts don't work in my MacBook pro (Japanese Keyboard).
I checked which keys are recognized in MoI v4 Beta in the shortcut key setting dialog.

[Key I press] → [Recognized as]
backspace → N/A
Enter → End
Tab → Home
English/Number → N/A
Kana → N/A
CapsLock → A

[Env]
Mac OS catalina

I hope this make some help.
Thank you!

nemuneko

Hi nemuneko, thanks for reporting this problem with Japanese keyboard shortcut keys.

It may be related to this Qt bug mentioned here:
https://codereview.qt-project.org/c/qt/qtbase/+/95050

There seem to be some fixes in the Qt Mac keymapper since the version that MoI currently uses. Probably the first thing to try is for me to update that and see if that helps.

Can you please try using the attached updated version? To apply it, right click on MoI v4 beta Jan-22-2020.app and choose "Show package contents". Then inside there go to Contents > Frameworks > qt > platforms. Rename the existing libqcocoa.dylib something like libqcocoa.dylib.bak and then put the attached one in place there.

Is there any change in behavior with that in place?

If not it may be difficult for me to fix this since I don't have a Japanese keyboard over here. Maybe I can make a couple of test builds to send to you that could gather more information about how those keys are being processed. I will be away on vacation for this next week so we could try that after I return.

I can reproduce the CapsLock making an "A" (on every 2nd keystroke it appears) so that's one I can dig into more easily. But I think the fix will be to just do nothing, CapsLock isn't meant to be used as a shortcut key.

Thanks,
- Michael

Hi Michael,

Thank you for your response.
I replaced the qt lib to your updated version and it work!

Backspace key work as 'Delete' shortcut.
Enter and Tab are recognized as UI shortcut (I think this is correct behavior).
Other keys show same behavior but they aren't meant to used as a shortcut key as you said.

It seems that the updated version of qt lib solved this problem.

Thanks a lot!

nemuneko

Hi nemuneko,

re:
> I replaced the qt lib to your updated version and it work!

Great! I'm glad that fixed it.


> Enter and Tab are recognized as UI shortcut (I think this is correct behavior).

Yes that's correct, since they are used by the UI as an alias for 'Done"/OK and for moving focus between controls they are not recognized as a target for shortcut keys.


> Other keys show same behavior but they aren't meant to used as a shortcut key as you said.

That was for English/Number, Kana, and CapsLock keys, is that correct?

I can reproduce the CapsLock one over here and I should be able to fix that up too.

The English/Number and Kana keys are modifier/mode type keys is that correct? I mean they don't produce a printable character if you press it just by itself?

- Michael

Hi Michael,

>That was for English/Number, Kana, and CapsLock keys, is that correct?

Yes.

>The English/Number and Kana keys are modifier/mode type keys is that correct? I mean they don't produce a printable character if you press it just by itself?
Yes, they are special mode keys which used to switch input methods (English <-> Japanese). They don't produce a printable character.
Also I think English/Number and Kana keys are not used for shortcut.
(I add them to the symptom list just to cover all physical key behaviors. I'm sorry if you recognize these keys are modifier key used for shortcut.)

Thanks.

nemuneko

Thanks nemuneko, I thought it was like that but I wanted to double check to make sure.

Thanks, - Michael

Hi,

I guess this has been mentioned, the fractional display on the dimensions does not work.

Otherwise I like the behaviour of dimensions, maybe the could be a stop on the resizing of the text when you zoom out at a certain point (perhaps when the text touches the arrows?).

Thanks,

Marc

Hi Marc,

re:
> I guess this has been mentioned, the fractional display on the dimensions does not work.

Fractional display should be working if you set Formatting > Distance display > Feet & Inches, but you also need the current unit system (under Options > General > Units) to something other than "No unit system" for it to take effect.

If you have "No unit system" then it isn't able to determine how long a foot is so "feet & inches" type fractional display isn't able to work there.


> Otherwise I like the behaviour of dimensions, maybe the could be a stop on the
> resizing of the text when you zoom out at a certain point (perhaps when the text
> touches the arrows?).

Well there isn't actually any resizing of text currently. Right now text is always drawn at the same on-screen point size regardless of zoom. This does have a kind of sense that it is sizing when you zoom out and objects become smaller but text size remains the same.

I do want to experiment in the future with some options to shrink the text down when you zoom out. But doing it when the text touches arrows would result in a variety of different text sizes on different dimensions if some have plenty of room between the arrows and others do not. The other problem is that text blocks only have a single reference point and so there is no "in between" measurement to use for them.

It will probably need to be a setting for "Max text size in model units" or something like that so you could say make stuff smaller than 5 model units to be shrunk down. That's probably not going to happen for the v4 timeframe. But there is one more related area that I have left to work on for v4 which is an option to make the text size entirely controlled by model size so it both shrinks and grows in size when zoomed same as geometry does. One part that's not good about that is that it then can cause really large sized text. But that way will have better compatibility with how other CAD programs handle text.

Thanks,
- Michael

Dear Michael,

I have some DXF file that can't be offsetted properly. I'm trying to generate roads from curves I imported. I'm using the offset tool using the Bidirectional and Trim settings with a distance of 0,15. The curves get disconnected.

I hope you can take a look at it. I've attached the .dxf as an attachment.

Hi Yanik, re: offset problem - I think the problem is that Offset in MoI is focused on working on a closed loop, not a branching structure like you have here.

It will try to join together segments that touch to try and make a closed loop but that is not good for your branching structure.

I don't think that MoI's offset will produce the kind of result you're looking for here, you've got not just branching but some pieces touching others in spots other than endpoints making "T" junctures. MoI's curve offset is not set up to handle those either.

Maybe a 2D CAD program that has an architectural type "wall" offset might do what you are looking for.

- Michael

Hi Yanik, you might be able to get somewhere with that with Max Smirnov's "Fatlines" script (http://moi.maxsm.net/files/), I think that script will thicken each curve individually instead of trying to join things together to make closed loops like MoI's regular offset function does.

- Michael

Funny that i adviced somewhere ;)

Seems you must trim in some parts before use Fat Lines
Don't know if there too many roads or if there are particular intersections or ...
red = trimming polylines

Hi Michael the lines are all individual lines. Each road is a polyline with multiple points. The concave points have issues when offsetting them. The FatLines script has the same issues.
Not sure what the problem is. It works fine on similar drawn polylines.

Having used FatLines script in complex senarios (recent one was a vitro window for a 3d scene) it helps to separate the project in portions. When I tried to apply it at once to all of the linework things froze up.

If I offset just 1 polyline I get the same issues. So it's not related to complexity. Try the dxf and you'll see.

Hi Yanik,

re:
> If I offset just 1 polyline I get the same issues. So it's not related to complexity. Try the dxf and you'll see.

I am seeing some issues with polylines that are at shallow angles to one another.

In general MoI is not expecting to work with polylines like that which have numerous line segments at shallow angles to one another, it's expecting for things shaped like that to be smooth curves and not polylines.

- Michael

Hi Michael,

I'm not sure I understand, shouldn't the dimension display units be independent of the model's?
Hobbit's foot are something else than 12 inches? :)

Marc

This curious thing of looping was due of an old version of Fatlines!



with the FatLines for v4 no more looping! : even with the DXF above post! ;)
Lignes Epaisses = FatLines