MoI discussion forum
MoI discussion forum

Full Version: V5 Wish List

Show messages:  1-16  …  317-336  337-356  357-376  377-396  397-416  417-436  437-456  …  597-602

From: James (JFH)
30 Apr 2022   [#377] In reply to [#374]
Michael

I know it is very early days yet with development of V5, and I'm unaware the your plans for GUI improvements. Although the view window buttons on the bottom nav bar function well, I wonder if there is a more elegant solution that doesn't hog so much screen realestate.
Although the colours are a bit garish, I think the navigation cube in this online SD modeller could serve as an example:
https://stephaneginier.com/archive/nomad_demo/

The navCube is immediately comprehensible on initial encounter with the interface and the labelling of faces greatly assists with orientation.
It also includes screen reset facility: clicking a second time on the cube face selection zooms to selected object extents.

Now, I know that there is no option for split screen, but perhaps a small adjacent 4 pane window icon could solve this requirement.
Please disregard this suggestion if it does not meld with your vision of Moi3d

James
https://www.instagram.com/nodeology/

Image Attachments:
navCube.jpg 


From: Michael Gibson
30 Apr 2022   [#378] In reply to [#377]
Hi James,

re:
> Although the view window buttons on the bottom nav bar function well, I wonder if there is a more
> elegant solution that doesn't hog so much screen realestate. Although the colours are a bit garish,
> I think the navigation cube in this online SD modeller could serve as an example:
> https://stephaneginier.com/archive/nomad_demo/

It looks like it performs a somewhat different function than the Split / 3D / Top / Front / Right view tabs in MoI.

When you click on Top on that view cube, it's navigating a perspective view camera position. When you click on
the Top view tab in MoI it switches the orthographic 2D Top viewport to be maximized.

The 2D ortho views in MoI help to give more of a 2D drawing workflow when you're working in them, it would
be a problem to eliminate them and only navigate the 3D perspective view like the view cube navigation
is doing.

- Michael
From: James (JFH)
30 Apr 2022   [#379] In reply to [#378]
Michael

quote:
The 2D ortho views in MoI help to give more of a 2D drawing workflow when you're working in them, it would
be a problem to eliminate them and only navigate the 3D perspective view like the view cube navigation
is doing.


Of course, I wasn't advocating abandoning 2D orthographic projections, but rather suggesting the possibility of adapting this type of navigational device to operate within MoI3d similarly to how the button row works now (perhaps with animated transitions).
And as for the 4up split view, this could be handled by additional adjacent icon.

Anyway it was only a thought, not even a request.
Have a great weekend,
James
https://www.instagram.com/nodeology/
From: Michael Gibson
30 Apr 2022   [#380] In reply to [#379]
Hi James, I think it might be difficult to animate a transition between perspective and orthographic. I'm not sure though.

The way that particular view cube navigation works it isn't an issue because it stays in a perspective view the whole time. That's why it's a somewhat different type of function than MoI's view tabs.

Another issue is that in MoI when you switch to a 2D ortho view you don't do any view orbiting. With the view cube you need to be able to orbit the camera to expose different views that you might want to switch to. All the different views are not always exposed and ready to click on immediately, like if you go to Top it's kind of problematic that the view cube now just shows Top where you're already at and you have to do some camera orbiting movement to be able to go somewhere else.

It doesn't really fit in with MoI's 2D viewports being separate from the 3D view. That's why I mentioned getting rid of the 2D ortho views, because it seems like that would probably be a precondition for making it work.

- Michael
From: Michael Gibson
30 Apr 2022   [#381] In reply to [#375]
@Larry,

re :
> Assembling the individual PDFs into a multi-page document isn't a problem for me (just a small hassle),
> but the thought occurred that if it was relatively easy to append to an existing PDF it would be quite
> handy. I'll look forward to whatever you come up with & appreciate as always your willingness to help!

I put a plug-in for doing this over here:
http://moi3d.com/forum/index.php?webtag=MOI&msg=10679.1

- Michael
From: Death
1 May 2022   [#382] In reply to [#378]
Am I am not even sure why one would need the cube. Got all of it already in the tabs ...

Message 10114.383 was deleted


From: Grendel
1 May 2022   [#384]
A circular selection mode would be helpful
From: Larry Fahnoe (FAHNOE)
2 May 2022   [#385] In reply to [#381]
Hi Michael,

AddPageToPDF.js with podofomerge works great with V5 beta, thanks!!

A little odd though as it appears to work with V4 (script functions as it does in V5, with no errors), but the output file is not changed.

I'm on a MacBook Pro with M1.

--Larry
From: Michael Gibson
2 May 2022   [#386] In reply to [#385]
Hi Larry,

re:
> A little odd though as it appears to work with V4 (script functions as it does in V5, with no errors),
> but the output file is not changed.

I've updated AddPageToPDF.js so it should work ok now on v4 Mac now as well.

It was an issue with spaces in filenames that v5 automatically compensates for.

- Michael
From: Larry Fahnoe (FAHNOE)
2 May 2022   [#387] In reply to [#386]
> I've updated AddPageToPDF.js so it should work ok now on v4 Mac now as well.

Confirmed working, thanks again!

--Larry
From: scott
7 May 2022   [#388]
Feature request for V5... add dimension field to POLYGON data entry fields

I would to be able to:
1. select POLYGON
2. select the desired option (Center, Edge, Star)
3. enter the desired number of SIDES (sidebar question... can the default number of sides by set in the .ini file?)
4. tab to a new 'dimension' field (below the SIDES field?) to enter the desired polygon dimension (eg, the CIRCUMSCRIBED dimension if selected). I'd also prefer to have the entered dimension match my USER PREFERENCES for DIAMETER vs RADIUS or vice versa, eg, use DIAMETER if CIRCLES is set to use DIAMETER (or provide an .ini option to set the preferred default).

For example, if I'm using the current implementation correctly(?) for a CENTER drawn polygon, the TAB button cycles between SIDES and CIRCUMSCRIBED. To enter the desired CIRCUMSCRIBED dimension, I have to move the cursor to the XYZ data entry box to enter the desired dimension. Or create the polygon and then edit the dimensions.

Obviously not a significant change functionally but would potentially improve my workflow when creating polygons.

Thanks as always for this great CAD program!

Scott
From: Michael Gibson
7 May 2022   [#389] In reply to [#388]
Hi Scott,

re:
> (sidebar question... can the default number of sides by set in the .ini file?)

The default comes from this line in the Polygon.htm file inside the commands install folder:

<td><moi:UnsignedIntegerInput id="numsidesinput" default="5"/></td>

You could change that to default="8" for example.

Another thing you can do is set up a shortcut key which will set it to a particular value. For
that you would put in this for the shortcut key:

Polygon numsidesinput=9


re:
> For example, if I'm using the current implementation correctly(?) for a CENTER drawn polygon,
> the TAB button cycles between SIDES and CIRCUMSCRIBED. To enter the desired CIRCUMSCRIBED
> dimension, I have to move the cursor to the XYZ data entry box to enter the desired dimension.

Yes you need to set distance constraint to control it currently, by entering the distance value in
the XYZ (or "d") input control like you describe.

The main reason why the polygon command doesn't have a radius input field is that it's not fully
defined by a radius value alone, it still needs a point to be placed to control the orientation of
the polygon.

I guess it could be possible to have a radius/diameter field there which would do the same thing
as setting distance constraint. One thing that's potentially problematic with that though would
be that there would effectively be 2 different spots where you would be setting distance
constraint and what should I do if you enter in a different value in one control vs another.

Another thing I've been meaning to set up for some time is a shortcut that would put focus in the
XYZ control always and not in the command option fields like Tab does. Like maybe Ctrl+Tab.

- Michael
From: BurrMan
7 May 2022   [#390] In reply to [#389]
Hi Michael,
So with regards to modifying the polygon.htm file....

MoI's structure is that the htm and js files have the same name to address each other.

I just wanted to be sure. Or possibky suggest a pointer in an htm file to a js file.

So why i ask, is "i" would make a polygon3-polygon5 and polygon8 htm file etc. As many as i like, though they all only really need polygon.js

Not more js files just for the name match.

But really, its not overly intrusive. Just wanted to ask about if it worked that way now, and i didn't know it
From: Michael Gibson
7 May 2022   [#391] In reply to [#390]
Hi Burr, so the way that commands in MoI work is when you enter in a command name to run, MoI will look in the commands folders (both install and appdata and any additional ones listed in moi.ini) for a .js script file with that name.

There can optionally be an .htm file with the same name as well. If there is then it will start up loading the .htm file into the command options area and let that finish loading first before loading and executing the .js file's script code.


re:
> Not more js files just for the name match.

It won't work like that because the .js file is the main thing associated with a command, it's the .htm file that is optional. If you have a command that does something and exits without showing any UI then only the .js file is needed.


re:
> So why i ask, is "i" would make a polygon3-polygon5 and polygon8 htm file etc. As many as i like, though they all only really need polygon.js

Instead of doing that you could give a command line parameter and have the script pay attention to that to parameterize it.

There is also a mechanism where if you give a command line parameter using the id values of one of the controls in the .htm file it will set the control to that value. So for example instead of having polygon3.htm, polygon5.htm, polygon8.htm you could do:

Polygon numsidesinput=3
Polygon numsidesinput=5
Polygon numsidesinput=8

- Michael

From: BurrMan
7 May 2022   [#392] In reply to [#391]

"Why that's IMPOSSIBLE"

No no no. "I was inverted"!!!

Thanks Ice!


From: Michael Gibson
7 May 2022   [#393] In reply to [#392]
:) It's kind of crazy there's going to be a new movie after so many years.

- Michael
From: BurrMan
7 May 2022   [#394] In reply to [#393]
It will have been 11 years since i have been to one. Gonna take my son, who is 16 now!!! Can't wait!
From: scott
9 May 2022   [#395] In reply to [#389]
Hi Michael

Thank you for the solution to my sidebar question.

After reading your explanation re my request for a polygon 'dimension' field, I did find a workaround solution that streamlines my workflow to some extent. I discovered that after selecting the desired polygon shape, I can enter the desired polygon dimension (radius) in the 'd' field as my first entry. This 'd' value then remains active until I finalize the polygon orientation. So with this workflow I'm able to 'preset' the polygon radius which works fine for my purposes.

Would adding a redundant 'd' field in the polygon settings section (under SIDES?) possibly make this workflow simpler without causing the conflicts you mentioned earlier? Or would a redundant 'd' field be potentially confusing/inconsistent with the MoI UI?

Again, not a big issue for me and especially given the workaround I mentioned above. Just highlighting in case you thought this one might be a possible MoI workflow improvement.

Cheers

Scott
From: Michael Gibson
9 May 2022   [#396] In reply to [#395]
Hi Scott,

re:
> Would adding a redundant 'd' field in the polygon settings section (under SIDES?) possibly
> make this workflow simpler without causing the conflicts you mentioned earlier? Or would
> a redundant 'd' field be potentially confusing/inconsistent with the MoI UI?

Well the problem is I'm not sure about the answers to these questions so that makes me
hesitate.

One thing that I have done though is I've made Ctrl+Tab work to always put keyboard focus into
the XYZ input control and not into the command specific options area like plain Tab does.

So you'll be able to use Ctrl+Tab and then type a number into the XYZ input to set distance
constraint without any clicks needed.

- Michael

Show messages:  1-16  …  317-336  337-356  357-376  377-396  397-416  417-436  437-456  …  597-602