Jump to content


Photo

formZ 9


  • Please log in to reply
91 replies to this topic

#41 Alan Cooper

Alan Cooper

    Advanced Member

  • Members
  • PipPipPip
  • 461 posts
  • LocationBuckinghamshire, UK

Posted 22 February 2017 - 12:19 AM

Yes, anything that takes us closer to creating a cost-list / price-list / more user controlled bill of materials as spreadsheet, which refers to selected parts and maybe parts even unselected if on a certain layer. Info management is an extremely useful tool but the .csv output is still a little limited regarding customisation.


  • etroxel, qapedkat, Robertquade and 8 others like this

FZ8.5 pro with Renderzone on Windows 7 64bit.

Family Plan.


#42 Chris lund

Chris lund

    Advanced Member

  • Members
  • PipPipPip
  • 567 posts
  • LocationWestcliffe Colorado

Posted 23 February 2017 - 01:39 PM

Tech,

 

Is there a technical reason we are going to use the 2.7 release of Python instead of 3.x?

Python Documentation notes that 3.x is the current and future, and 2.x will no longer be updated (which looks to be the case for quite some time)

 

Truth of it all, if it would delay getting it, let's stick with 2.7.

 

Thanks!


Christopher Lund

Neurascenic - Industrial Design


#43 Tech

Tech

    Moderator

  • Moderators
  • 4,090 posts

Posted 23 February 2017 - 02:01 PM

Chris,

 

There are a couple of reasons that we are using Python 2.7:

 

• There is a vast collection of Python 2.7 compatible resources (libraries, tutorials, debuggers, examples etc).

• Python 2.7 is built into MacOS X so no extra installation is required.

• A number of the features that were introduced in python 3 have been included in Python 2.7. In fact the latest version (2.7.13) was released on-12-17-2016 so its not so old.

 

It should be noted that most of the Python interface with form•Z is Python 3 compatible so we expect that the transition in the future will not be too difficult.



#44 poco2017

poco2017

    Member

  • Members
  • PipPip
  • 12 posts

Posted 23 February 2017 - 04:08 PM

Since it was mentioned -- I was wondering if the minor release version of Python will matter (compatible) with the new script feature. My Mac has a default version of 2.7.10. Since 2.7.13 was mentioned -- should I load it??



#45 Chris lund

Chris lund

    Advanced Member

  • Members
  • PipPipPip
  • 567 posts
  • LocationWestcliffe Colorado

Posted 24 February 2017 - 04:17 AM

Understood,   I do find it odd though, that the Mac is still using 2.7.    I have installed 3 in the past, but upgrades to the OS, must Downgrade Python.

 

Thanks!


Christopher Lund

Neurascenic - Industrial Design


#46 Tech

Tech

    Moderator

  • Moderators
  • 4,090 posts

Posted 24 February 2017 - 04:52 AM

Chris,

 

We are not yet aware of any limitations that would require a specific version of 2.7, we recommend keeping what you have installed if its working fine and only upgrade if you encounter a specific dependency or issue.



#47 ASONE

ASONE

    Advanced Member

  • Members
  • PipPipPip
  • 280 posts
  • LocationBoulder, Colorado, USA

Posted 01 March 2017 - 02:03 PM

Can someone explain what this development means to an architect without coding knowledge?  I can obviously see the benefit from the sample provided, but will there be a way to create these parametric type commands without coding?  Or I suppose one could hire someone with the knowledge to produce specific coding as needed.  Is this FormZ's answer to Grasshopper?


FormZ PRO v8.5.  2017 iMac 4.0 GHz quad core i7 24MB RAM and a 2015 Macbook Pro quad core i7 16MB RAM, Modern Architecture in Boulder and Denver Colorado www.ASONEarchitecture.com 


#48 poco2017

poco2017

    Member

  • Members
  • PipPip
  • 12 posts

Posted 01 March 2017 - 03:48 PM

IMNOHO -- Your asking questions that can't be answered right now. But my experience with other programs that have a scripting feature convinced me, that for the average architect, it will still be easier and faster to create 3D features/objects/designs directly and store them in a library even for repetitive tasks. The best use of scripts is for commercial users and hobbyist who have a lot of time to extend the program in areas to costly for Formz to consider. And that is totally dependent on how detailed AutoDesSys will make the script interface. If they extend it to the extend of say, Sketchup, then I can see some benefit. But remember, it took Sketchup years to get there. I doubt, that with the initial release, they can get that detailed. Maybe in the future if they decide to continue work -- but who knows?

 

Where I found a huge benefit is in the ability to configure custom annotations, Spreadsheets,  B/M's, notes and defining attributes. Again that is dependent on how much access is allowed to the object data. in this area it doesn't take much knowledge to generate the details needed to provide the info to manufacture/construct your designs and can be a great time saver. in these areas, AutoDesSys simply can't anticipate all the user's needs. Best left to the user to provide.

 

So the answer, it's too early to tell (IMO) as this is completely depended on how deep AutoDesSys is willing to go. We'll just have to wait and see.

 

As to Grasshopper I have both it and Archicad and found it to be not not worth the learning curve -- More Formz practice and skill is much more productive.


  • Alan Cooper likes this

#49 ASONE

ASONE

    Advanced Member

  • Members
  • PipPipPip
  • 280 posts
  • LocationBoulder, Colorado, USA

Posted 01 March 2017 - 05:26 PM

Ok it sounds more relevant to trade show and industrial design work, no?

 

 


FormZ PRO v8.5.  2017 iMac 4.0 GHz quad core i7 24MB RAM and a 2015 Macbook Pro quad core i7 16MB RAM, Modern Architecture in Boulder and Denver Colorado www.ASONEarchitecture.com 


#50 poco2017

poco2017

    Member

  • Members
  • PipPip
  • 12 posts

Posted 01 March 2017 - 06:44 PM

Ok it sounds more relevant to trade show and industrial design work, no?

 

Exactly!! -- For now, But if AutoDesSys does provide a comprehensive Script, i think you will be pleasantly  surprised as to to the innovative solutions users will be willing to share.



#51 Chris lund

Chris lund

    Advanced Member

  • Members
  • PipPipPip
  • 567 posts
  • LocationWestcliffe Colorado

Posted 02 March 2017 - 08:26 PM

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, 02 March 2017 - 08:28 PM.

Christopher Lund

Neurascenic - Industrial Design


#52 poco2017

poco2017

    Member

  • Members
  • PipPip
  • 12 posts

Posted 03 March 2017 - 12:02 AM

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.

 

 



#53 Chris lund

Chris lund

    Advanced Member

  • Members
  • PipPipPip
  • 567 posts
  • LocationWestcliffe Colorado

Posted 04 March 2017 - 03:43 AM

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!


Christopher Lund

Neurascenic - Industrial Design


#54 Armin Stroß-Radschinski

Armin Stroß-Radschinski

    Newbie

  • Members
  • Pip
  • 1 posts
  • LocationTroisdorf, Germany

Posted 07 April 2017 - 09:03 AM

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.getp...al-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.

 

  • Chris lund likes this

#55 darwin06

darwin06

    Member

  • Members
  • PipPip
  • 14 posts

Posted 07 April 2017 - 10:30 AM

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... 



#56 David Lemelin

David Lemelin

    Advanced Member

  • Members
  • PipPipPip
  • 82 posts

Posted 03 May 2017 - 01:33 PM

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.

 

 



#57 andrew

andrew

    Advanced Member

  • Members
  • PipPipPip
  • 77 posts
  • LocationMinneapolis

Posted 03 May 2017 - 10:21 PM

Please, please address the GUI and stability of the Imager.  Its such a great tool and unique to ADS, imho.


  • David Lemelin likes this

#58 Tech

Tech

    Moderator

  • Moderators
  • 4,090 posts

Posted 05 May 2017 - 01:15 PM

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.

 


  • 3dworks, Jaakko and David Lemelin like this

#59 Justin Montoya

Justin Montoya

    Advanced Member

  • Members
  • PipPipPip
  • 324 posts

Posted 18 May 2017 - 01:00 PM

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.   :/


  • Jaakko, David Lemelin and AC1000 like this

#60 Hugo

Hugo

    Advanced Member

  • Members
  • PipPipPip
  • 208 posts
  • LocationNetherlands

Posted 18 May 2017 - 06:28 PM

+2

VANDENBOOMEN-ARCHITECTen...

 

MACOS 10.12 SIERRA | Form Z 8.5.7 | Vectorworks 2017 SP | AutoCad 2017 LT | Maxwell Render 4.1.x.x | Thea Render | Renderzone | Affinity Photo and Designer

Mac Pro late 2013 8-core 3.0Ghz 32Gb RAM, 2x FirePro D500 3GB | MacBook Pro Retina 15" mid 2014 i7 2.8Ghz 16Gb RAM, Nvidia GeForce GT 750M 2Gb+Intel Iris

Mac Pro mid 2010 12-core 3,46Ghz 96Gb RAM, SSD | Mac Mini mid 2010 2,4Ghz 2-core 16Gb RAM, Nvidia GeForce 320M 256MB | Cinema Display 27" 2560x1440 | LG 31" 4K 4096x2160





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users