owen wrote:
Interesting you mention C4D Bricklyne .... VRayforC4D is NOT developed by Maxon - it is done by a very small team, yet it is totally integrated into the program. I see no reason why the same could not happen for ArchiCAD - I'm sure Graphisoft would not stand in the way. I believe more advanced rendering engines
.........
I know that VrayforC4D was developed by a third party developer - Ilab ; and frankly speaking all existing Vray bridges to other software and plugins have been developed by third party developers or enthusiasts rather than the developers of the host application or Vray itself. Whether it be VrayforSketchup or VrayforRhino3D (both developed by ASGVIZ and not Google or McNeel) or VrayforBlender (independant developer).
The exceptions to this being the 3DS Max, Maya and XSI versions which were developed by Chaosgroup themselves directly.
The point was that none of these third party developers would be able to developers these plugins without considerable support from the developers of the host application along with support from Chaosgroup - who themselves also get a decent amount of support from Autodesk for their MAX/Maya/XSI plugins. The kind of support I doubt GS would be capable of providing going by just how detached they are when it comes to customer support and client interaction. I mean, look at these forums for crying out loud - the inmates are running the asylum - so to speak.
I remember when the Nextlimit guys were developing the Maxwell plugin for AC, it was like a solo mission, considering the lack of enthusiasm and seeming or apparent lack of support they seemed to get from GS when they first broached the topic a couple of years back.
A lot of these render engines support a lot of features and require a lot of functionality that ArchiCAD doesn't either support or provide, and which it would be difficult to work around without significant support from the GS people.
At a basic level and as an example, you have the Material editing system in AC which is really archaic by modern standards and which, not surprisingly GS have refused or neglected to revamp for heaven knows how long. So much so that if you're the developer of a plugin for a Maxwell bridge from example and your users need to edit their materials and take advantage of Maxwell's full material editing features, it has to run a separate material editing sub-program or applet, outside of AC. That may not be such a big deal (mostly since the plugin developers have it running so efficiently and fluidly) But it becomes a problem when you need to or have to adjust your material mapping sizes, rotation and coordinates in real time and in your model and basically have to resort to guesswork and going back and forth between the editor and the program.
That's just one example.
There other things such as the fact that a lot of these render engines are able to handle considerably high geometry counts through tricks like displacement, and proxies, but then become limited by AC's notorious polycount limit.
And I wasn't suggesting that GS should develop the render engine themselves. Goodness no, they would utterly s uck at that; - they should stick to improving the program's core modeling and design tools and functions (or avoiding having to, by lopping those responsibilities to third-party peeps and developers while they chasing the business of corporate clients, but I digress).
I have always been a huge proponent of their outsourcing this particular task to more professional outfits (such as the ones above) - but it should be pro-active on their part (i.e. they should take the initiative rather than wait for these developers to make the plugins on their own when they don't see the incentive in it, thanks to GS's acerbic marketing, which leads people to believe that there are less AC users out there and therefore fewer potential customers for them), and it should also ideally be integrated - meaning that, rather than have someone go and develop a revamped high-end render engine or plugin for the program and then charge users extra for it ala Ecodesigner, MEP modeller, Virtual Explorer (some of which should really be integral to AC's functions to be honest), have the render engine built directly into AC or with the option of installing it as an integrated tool along with AC during first install and then either charge a premium per license which would then go to the plugin or render engine developers directly or allow them to download and install it later directly if they choose otherwise. This way, there would be no need for having to wait 4-6 months after an AC release for the plugins to be updated as well, if at all, like it currently is with certain plugins.
They already do it this way with Lightworks, except that with Lightworks sans-Radiosity (which I'm sure accrues an extra cost into the license you pay for AC whether you use it or not), the users are not exactly getting the most bang for their buck.
Unfortunately, for a lot of the improvements necessary in AC (including and not just limited to the rendering tools) to make it viable and competitive again (or to keep it so), requires not just a change in how GS relate with their third-party collaborators and indeed with their own customers. It also requires a drastic change in their collective corporate attitude and their outlook on the future of ArchiCAD and its place in the marketplace.
That's the bigger obstacle for them as far as I'm concerned - and one which could and very well will dictate the future, or lack thereof, of this program.
( Autodesk is even launching 2011 products !?) 
