Jump to content
AutoDesSys Forums

Recommended Posts

ASONE, Poco,

 

ADS had a well working scripting SDK with 6.x, that for the most part carried through v7.   Not exactly sure if it broke with v8 or v8.5  as I really only moved up to 8.5 from 6.7.

 

IMHO, the only issues with the old scripting method had nothing to do with data access, but that it was more of a proprietary "language"  Essentially C, but with some oddities, and not really typical of a scripting language.

 

The advantage of the new SDK being Python, is that it is common, which will bring more people to the idea of scripting fZ.  Too, FSL (old scripting language), was that it had limited GUI access, Pretty sure you did not have the ability to have sliding GUI components (could be wrong).

 

I do however strongly disagree, that it is for either professional programmers or bored hobbyists with a lot of time.   I am neither, it just becomes well worth my time to do, as it can save me easily 10x the amount of time it takes learning it and developing a script.

 

ADS, provides a full SDK that requires C or C++ for the professional coder.   The Scripting environment is more for us who have a different job to do, but can do it faster with a few tweaks.  No company can fully anticipate a users needs or uses or methods of use.  Scripting provides the non-professional programmer the ability to modify the behavior and not have to depend on (ADS) to do something they may never get to, just because there isn't enough demand for it.

 

in the past, I released most of my scripts and were well received by architects (I am an industrial designer, but none of the scripts were unique to ID)

 

A robust scripting environment also bodes well for growing a user base. Giving that the program gets expanded into all sorts of directions that once again, ADS either can't or won't provide merely because they need to focus on a primary user base.

 

I have not had any chance to experience Grasshopper,  but would welcome something like that as well, as long as it can integrate into the Python scripting as well  (as long as it can call python scripts, would be good enough)

 

I am itching real hard for this, I am bloody!!!!

 

cheers!

 

¢£

Edited by Chris lund

Share this post


Link to post
Share on other sites

Chris

 

You seem to be anticipating that the new Python script will just be a duplicate of the present proprietary script. I did not intend to imply that but rather was warning it would be a mistake to do that for the sake of time and hope that AutoDesSys will avoid that trap. Thus my original questions.   I believe, from the couple of hints dropped, that AutoDesSys is also aware of the limitations of their own and other scripting systems -- which is good enough for me.

 

 As to the new systems usage I stand by my experience that tying to duplicate the existing capabilities of Formz just to draw a new item or produce a  novelty in a new form is a fruitless usage. I am hoping that the new scripting will be designed to extend the program not just duplicate it. Not expecting anything different just maintains the present in a different form but I doubt if it will attract new uses and users. For this reason, POF, no scripting system (a bunch of them) has been all that useful or significant other than for the commercial developers that I am aware of -- including FormZ.  Hope this will be different.

 

 

Share this post


Link to post
Share on other sites

There is no reason to anticipate a duplicate.  formZ is quite different after all, so no I don't.  I suspect however, there is no need to go backwards regarding data access functionality.

That being said, the scripting before did not actually have access to everything, for example, it did not have the ability to make new types of Data Objects.  Due to the complexity of this, I doubt that this will be added to the new scripting environment either.  Scripting does, and probably always will have limitations compared to actual under the hood coding.  Too, there is no reason to expect that having access to scripts or the full SDK will allow formZ to perform something it just was not meant to.  The SDK in either form is really just access to the callbacks and data and methods of the platform.  Sorry, no turning formZ into Photoshop, nor is there any expectations for such.

 

That being said, the easier it is to make adjustments to a platform, the more usable said platform is to a wider audience. I stand by my experience, that nothing is perfectly built for me, but if I can modify it to work, then it is more useful than the designers original intent.

 

Telling me "in your experience" tells me nothing without knowing your experience, so means nothing.  Care to elaborate?

 

We both appear to agree on the desire for the SDK to allow us to do what we want, within limitations of the platform of course.

As before, I will have no problem distributing my scripts to the wider audience if I think it can help them.  Should it be something more profound, I wouldn't mind charging a minimal fee for it.

Admittedly however, most of my stuff won't fall into that category, but rather nuances that neither require a full SDK or a professional developer.

 

Cheers!

Share this post


Link to post
Share on other sites

I am very happy to see Python upcoming in formZ.

 

To leverage all these concerns: I am an Industrial Designer and 20 years formZ user. I am also a "semiprofessional" workflow maniac that is lazy and tries to be smart. I dived into Python and the whole Open Source ecosystem in 2002 during the use of Plone, a very secure object oriented Web CMS with over 15 years of success.

 

Hope the following lines are not to boring and open the mind of even "no nerd" users to empbrace python.

 

I have done a lot of communication work around Python and Plone. One is the official Python Brochure by the Python Software Foundation that can be downloaded here.

http://brochure.getpython.info/media/releases/psf-python-brochure-vol.-i-final-download.pdf

 

We researched a lot of stories around the usage of Python in the Industry (Including Industrial Light and Magic, Houdini, Blender). Some stories did not make it into the brochure (including the one from Disney) due to some legal permissions missing. We know that companies like Electronic Arts, McNeel (Rhino), Maxon (Cinema4D), GOM (3D-Scanning) and much more use Python as a glue language to connect everything to productive environments.

 

You find nearly unlimited solutions to solve almost every problem you can imagine. Microsoft offers more than 10h of training videos on Python and you find excellent books and trainings everywhere. You can bridge from Python to almost every database, spreadsheeds and even scrape webservers. You can process xml and JSON. You can easily document your work using clear and modular programming patterns if you know that, but also save your life with simple few liners working with the OS clipboard.

 

Python is very succesful especially with non full time programmers like scientists and technicians. The easy readable code and the interpreted execution as script boosts your productivity even if you just read and modify existing code.

 

Plone is still using Python 2.7.x but on the way to Python 3.x. 

Why they are so late? Lazyness? Dumbness? Are there similarities to formZ?

 

The Python Standard Library has a very big and proven ecosystem around it. You can do almost everything in either Web Programming, Embedded Controlling, Scientific Computing (including AI and Big Data) in a more efficient way than using Java or C and with lesser code. There are reasons to use C if the code needs to be executed fast very often. But if you just need get things done several times, short development time beats minor execution time improvements. This is one story behind the success of Python.

 

So why Python 2.7 (e.g. in MacOSX)? (Background why 2.7 is still in use and is supported)

 

There are some rare critical Libraries that were only ported to Python 3 recently and they are not interpreted code (which runs almost fine in Python 3 with some easy tweaks) but compiled into C to run fast) So if you do not have the power to port the code to Python 3 compatibility yourself (what you could do theoretically with Open Source) you have to wait for the maintainer to do it. I fact Python 2.7 is supported until 2020 and everybody knows this. It works as reliable (or better) than Python 3.

 

You can already write code that runs fine under both major releases Python 2 and 3 and you can "Test" that! There are converters to do that automatically as well. Unicode is already supported in Python 2.7 but is treated different. Since formZ scripting is not exposed to the web (even it could do so!) there are no security concerns / reasons against to extend that deadline for some time if you know what you do.

 

Are PyQT etc relevant?

 

If formZ offers nice access to manipulate the native GUI the productivity will be much better because you are in the same object namespace to query the state of everything in formZ directly. If necessary you can use PyQT or WXPython if you have strong needs. There will be no limit as far as I can guess after what I read here.

 

Get a grip now?

 

The only bad story is, that every 3 mails I sended to the ADS crew in the last year to grant access to the SDK were not answered. I suggested the use of Python or/and to implement a bridge from the old SDK myself. Inspiration? – I think they catched it themselves before... but still a bit poor...

 

I will start to work with Python in formZ it as soon I get a grip on a beta. This was the last reason to switch to Rhino, now gone.

 

Share this post


Link to post
Share on other sites

tl;dr for the above post:

 

Python is a welcomed addition to formZ as it is a widely used scripting language.  But do not worry, version 2.7 is still very relevant AND you can convert it to Python 3 for later use, if necessary.  I hope I'm close... 

Share this post


Link to post
Share on other sites

So, I'm reading lots about the addition of Python to FZ 9... is there anything else we can look forward to?

 

In particular, I'm hoping to see an upgrade to the interface to make it a bit more streamlined. Currently, I use 2 screens to deal with all the palettes and tools... it's cumbersome and worst of all if I ever turn off one of my screens all the palettes get scattered over my work on the remaining screen.

 

 

Share this post


Link to post
Share on other sites

David, 

 

We are working on giving formZ a more "unified" interface.  One such change is to make a single "List Palette" that will house... well, list palettes (layers, objects, lights, etc..).  We have tested it in some VERY early Alpha builds in the office, and we think it's a great solution to the "scattered palette" problem  :)

 

 

So, I'm reading lots about the addition of Python to FZ 9... is there anything else we can look forward to?

 

In particular, I'm hoping to see an upgrade to the interface to make it a bit more streamlined. Currently, I use 2 screens to deal with all the palettes and tools... it's cumbersome and worst of all if I ever turn off one of my screens all the palettes get scattered over my work on the remaining screen.

 

Share this post


Link to post
Share on other sites

David, 

 

We are working on giving formZ a more "unified" interface.  One such change is to make a single "List Palette" that will house... well, list palettes (layers, objects, lights, etc..).  We have tested it in some VERY early Alpha builds in the office, and we think it's a great solution to the "scattered palette" problem  :)

 

This is great news!

 

Thinking about how this is done in other clean UI's, it is obvious to me now that we need TABS.  Tabs in the palettes would make everything fit in a much more cohesive and streamlined manner.  And could be easy to implement without a complete overhaul.

 

But getting back to basics, we need to remove the superfluous wastes of space.  For example, there is absolutely no need for the Workspaces Palette, and it takes up a ton of space, and is a mostly useless feature, in an overly prominent location in the default UI.   I would much rather see an Ultimate Workspace offered that has all of the tools and palettes exposed in nicely organized and thought through layout, instead of hidden away, confusing newer users.  As is, the jokingly huge default tool icon size makes FormZ look like a children's toy, instead of a professional tool.  I suspect the UI developer is not using a similar dpi monitor as the rest of us, for their development, and therefore cannot see the same oversizing of the tool icons and menus.  I know much of this is user adjustable, but it shouldn't need to be adjusted as much to get the same clean and fluid look and feel that pre v7 FormZ offered.  The newer interface certainly has some improvements, but they are incredibly overshadowed by large wastes of valuable screen space.  Palettes now take up considerable more screen space which means less room for a nice large modeling window.

 

I think the only reason users like myself keep bringing this up is because we want FormZ to succeed.   We want it to have a much higher adoption rate.  We want students to fall in love with FormZ in school, and carry that into their professional careers.  In order for this to happen, we need to have a serious change in the way FormZ is presented when opened for the first time.  It needs to be streamlined, and cohesively connected.  Gone are the wastes of UI space.  Increase the size of the modeling window.  Reduce the default tool sizes.  Bring back the classic white workspace, or develop a better light grey version for default.  The beige has to go!  I'll never forget my old boss, who was a longtime FormZ user from the days of OS 8 and OS 9, said "Why would FormZ make the background color 'shit' brown, instead of the clean white it has always been?  It's incredibly unprofessional, especially when saving and sharing plan views on a grid of our models."   I think that speaks for itself.   :/

Share this post


Link to post
Share on other sites

This is great news!

 

Thinking about how this is done in other clean UI's, it is obvious to me now that we need TABS.  Tabs in the palettes would make everything fit in a much more cohesive and streamlined manner.  And could be easy to implement without a complete overhaul.

 

But getting back to basics, we need to remove the superfluous wastes of space.  For example, there is absolutely no need for the Workspaces Palette, and it takes up a ton of space, and is a mostly useless feature, in an overly prominent location in the default UI.   I would much rather see an Ultimate Workspace offered that has all of the tools and palettes exposed in nicely organized and thought through layout, instead of hidden away, confusing newer users.  As is, the jokingly huge default tool icon size makes FormZ look like a children's toy, instead of a professional tool.  I suspect the UI developer is not using a similar dpi monitor as the rest of us, for their development, and therefore cannot see the same oversizing of the tool icons and menus.  I know much of this is user adjustable, but it shouldn't need to be adjusted as much to get the same clean and fluid look and feel that pre v7 FormZ offered.  The newer interface certainly has some improvements, but they are incredibly overshadowed by large wastes of valuable screen space.  Palettes now take up considerable more screen space which means less room for a nice large modeling window.

 

I think the only reason users like myself keep bringing this up is because we want FormZ to succeed.   We want it to have a much higher adoption rate.  We want students to fall in love with FormZ in school, and carry that into their professional careers.  In order for this to happen, we need to have a serious change in the way FormZ is presented when opened for the first time.  It needs to be streamlined, and cohesively connected.  Gone are the wastes of UI space.  Increase the size of the modeling window.  Reduce the default tool sizes.  Bring back the classic white workspace, or develop a better light grey version for default.  The beige has to go!  I'll never forget my old boss, who was a longtime FormZ user from the days of OS 8 and OS 9, said "Why would FormZ make the background color 'shit' brown, instead of the clean white it has always been?  It's incredibly unprofessional, especially when saving and sharing plan views on a grid of our models."   I think that speaks for itself.   :/

 

Oversized icons are disturbing and one icon is especially hilarious: the component man! There should be more abstract picture in that icon. Usually my components are building blocks. And the bright "Pan" hand is also interesting. Perhaps that hand belongs to the component man!

 

Generate Tool palette has sphere icon activated at start. It should be cube definitely. Little, almost comic details but they do matter.

Share this post


Link to post
Share on other sites

Could not work-colors incorporate dynamic colors, that is, very slightly brightening-dimming- intensity for selected objects...changing at a subtler rate than Photoshop-selections,  (perhaps with gradual peaks and valleys of one change per second). Hence we could extend the range of one limited octave of coloring to more states of clarity.  

Share this post


Link to post
Share on other sites

I would like to see a better snapping and align system much like MOI has. So easy in MOI to align groups or single objects to other object or within the scene. Snapping in MOI is very aggressive so you know if you are on target where as FZ seems to not snap consistently or easily especially when you start having complex shapes and scenes.

 

In MOI you can have a single selected object and align it to non selected shapes.

 

FZ also lacks overall dimension of a selected object or group forcing you to use the measure tools. This can be really cumbersome when fitting shapes.

 

Lastly.... can we have math input for the input fields? Much easier to toss in a diameter/2 and hit enter when modeling something and want to reverse engineer a direct measure to radius or be able to extrude with a draft such as length*tan#°.

Share this post


Link to post
Share on other sites

+1 Math input.   Lowest form of it would still be helpful, if the Python Terminal is available where we could type in what we wish to figure out.   But true, in field would be best!

Share this post


Link to post
Share on other sites

This is great news!

 

Thinking about how this is done in other clean UI's, it is obvious to me now that we need TABS.  < CUT-DOWN>

 

I concur with that, I was discussing this very topic the other day on another forum I'm on with respect to an Architectural CAD software I use (SPIRIT) & thought TABS seemed a cleaner way to deal with tool icons that sometimes looked unorganised on the top UI, as a future UI upgrade. This would also cater for future software tools & a user custom tab. I used RHINO as a TAB example (sorry FZ-users). I also discussed Ribbons like AUTOCAD uses, but this type of UI didn't get a thumbs up, So was wondering what the consensus is with FZ-users.

 

NO CHANGE =

RIBBONS =

TABS = 2

 

Over & out,

CJT52 

post-12026-0-47559600-1496593568_thumb.png

post-12026-0-75598100-1496593587_thumb.png

post-12026-0-74944300-1496593891_thumb.jpg

Share this post


Link to post
Share on other sites

Note that in the spirit and rhino UIs that the actual working space in your examples appears to be about 50% of screen area. My current working space in FZ is around 85%. Any modifications should focus on maximizing working area and include flexibility to minimize the interface.

Share this post


Link to post
Share on other sites

I concur with that, I was discussing this very topic the other day on another forum I'm on with respect to an Architectural CAD software I use (SPIRIT) & thought TABS seemed a cleaner way to deal with tool icons that sometimes looked unorganised on the top UI, as a future UI upgrade. This would also cater for future software tools & a user custom tab. I used RHINO as a TAB example (sorry FZ-users). I also discussed Ribbons like AUTOCAD uses, but this type of UI didn't get a thumbs up, So was wondering what the consensus is with FZ-users.

 

NO CHANGE =

RIBBONS =

TABS = 2

 

Over & out,

CJT52 

 

I would like to prefer tabs over ribbons, but only if they are done well and don't clutter the UI. For me, Blender is a good example of a contemporary UI that is adaptable, uniform, and leaves the most space to the modelling window. The tabs are small, appealing icons whereby you can fit a lot of tabs on a very narrow frame and quickly navigate to the right tab (compare it with Rhino's tabs).

 

post-10709-0-64987700-1496601605_thumb.png

 

More advanced tools can be accessed in three ways: (1) the menu on the bottom (exploring), (2) hitting the space bar to display a hierarchical menu where you can search for a tool or use a sequence of characters as a shortcut (asn => Add Surface Nurbs). This is quite handy for more experienced users.

 

post-10709-0-20046300-1496602454_thumb.png

 

You can also access tools and object and scene settings by opening the sidebars (press n or p). I think that the key here is that Blender's UI responds to its context: When I am editing an object the toolbars change. When I am painting it or sculpting it the toolbars will change again.

 

post-10709-0-01435400-1496601665_thumb.png

 

post-10709-0-80626700-1496601683_thumb.png

 

post-10709-0-19651400-1496602666_thumb.png

 

Another thing I also like very much is that one can split the window in as many frames as I like by dragging the little hatch in the upper right corner. Joining them is as simple as splitting them. No need for opening up a dialogue.

 

post-10709-0-03474700-1496601627_thumb.png

 

 

If I want to give the model more space I can maximise a frame temporarily by hitting shift and the space bar:

 

post-10709-0-99775900-1496603271_thumb.png

 

I highly recommend the UI team to have a look at Blender's approach. The software is open source and large parts of it are based on python.

Share this post


Link to post
Share on other sites

Note that in the spirit and rhino UIs that the actual working space in your examples appears to be about 50% of screen area. My current working space in FZ is around 85%. Any modifications should focus on maximizing working area and include flexibility to minimize the interface.

 

That's true, but the side vertical menus in SPIRIT have a handy pop-out slider when one ghosts your mouse pointer far right or left, they can also stay fixed, as in the example, as they also have a pin or un-pin to screen icon.

 

Over & out,

CJT52

Share this post


Link to post
Share on other sites

I like the blender look - but it is really text intensive. I understand the icon based approach have issues , but it can be fixed. For me Photoshop remains the best example of a modern and clean UI with the right balance between icons and text.

 

I agree with PS as being a great example for o contemporary UI. I wasn't aware of Blender's text intensive UI because the text elements of the interface are hidden most of the time  ^_^

Share this post


Link to post
Share on other sites

How do you think about a formula field for the Measure Quantities tool? When doing conceptual mass models I like to compare their floor area on-the-go by using a very simple formula: A = V / storey height. It would make conceptualising much more fluently if I could just enter a formula in the Measure Quantities tool that uses the information it derives from the clicked object (see figure below).

 

post-10709-0-04212700-1497638357_thumb.png

Share this post


Link to post
Share on other sites

Ok, my contribution to this discussion.

 

I do not care that much about the UI FormZ uses at this moment, but I do care about consistency of it. The palettes should always stay in place, like in many other programs I use. For instance Maxwell, Photoshop and Affinity Photo + Affinity Designer (https://affinity.serif.com/en-gb/) are good examples. I love Affinity to work with.

 

Another thing I really like to see is that many issues about version 8 are solved in the next version, to many to mention here. All those little errors gives me the feeling as if it is programmed just to quickly, not accurate. Instead of adding major new features in the next version (nice anyway, but...) make that new version rock solid. For me Affinity is the example of a small software company who develop software from scratch and it just works, no little annoying issues at all, and with a nice clean interface.

 

then...

 

Could we get best in class printing output options? Let's say, print frame setup in the 3D model and save as a scene. Text always printed on 300 dpi, easy to create layered PDF, etc. 

 

I am looking forward to the all new version, just because I still hope it will be better...

 

Succes with development.

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×