Wow, thank you so much for taking the time to write all of this, and I see some very nice images on your photobucket! I am very eager to get artists like you working in bella, so I can stop pretending to be an archviz guy in order to make pictures for our twitter. 🙂
i quite like the renders you have put up in the gallery! Don’t think I can do any better! 🙂
I completely agree about having a fully-integrated plugin, and that (use via plugin) is bella’s prime intended use case. Our GUI’s main intended purpose is just to allow getting the actual rendering process out of the host application, once you are done tweaking things, both because rendering performance can suffer by some percent if you render in the context of the host application, and because it is convenient to be able to keep working as rendering is done.
You must forgive me, but I need to keep taking examples from the current render engine I use. In Thea, there is an option where one can toggle on and off the interactive rendering. So, if I want to work on the model, while rendering out some test shots, it can be done and there is very minimal loss of performance (since Thea is able to utilize GPU). Maybe that is an option you could consider?
I do have some experience with this (integrating a renderer in sketchup), since I wrote and maintained maxwell’s sketchup plugin for many years, and while I am still fairly proud of what was able to be done there, you should expect a superior experience from bella when the time comes, since where maxwell bolted its (fairly revolutionary, at the time) FIRE realtime capability onto an already existing exporter-based plugin model, bella has been built from the ground-up with realtime usage in mind. I am in the midst of working on our rhino plugin, and have been very pleased so far with how much easier it is to accomplish things — we could have had more plugins by now, but chose instead to invest time in design of the programming interface that is used to implement them, and I am not regretting that decision — and I do not currently foresee a reason why anything you can do in sketchup, cannot be made interactive in bella.
When you say “realtime usage” do you mean raytraced real time like the game engines or IPR? I am assuming it is the latter. Though, I firmly believe the real time renderers (like U-render for C4D and Enscape for SU or Lumion) is the future. Hopefully Bella will be able to provide such an option in the future as well!
It is interesting what you point out about making first impressions; our approach there is basically just to never promote bella as being a product for people other than users of plugins we already offer. I have created this sub-forum here, and the similar rhino one, for discussing plugins we definitely plan, in order to get input such as you have provided, but you will not see us post anything about bella on an external forum, unless/until there is at least a stable alpha plugin build, and we wish to find more testers than we already have here.
Here, I will say it has been considered, that while the current plugin (rhino at this time) is in process of development, I might elect to supply a rudimentary export-type script, for people who absolutely wish to use bella, before their plugin is available. This has been discussed especially in the case of blender, since it will be quite a project (due to opensource) to provide an integrated experience, and in the case of sketchup, mainly because I have already written such a script, early on, in order to allow the other developers to have something with which to generate models, for development. However, providing such a script may risk exactly the type of problem you point out, so I’d be interested to hear your opinion about it.
Such a script would be good in a very closed pre beta testing stage, where artists can get a feel of the quality of the render engine and to get a taste of the features and count me in as I am really eager to see what Bella can do. Hopefully down the line, all the options would be able to make it into the plugin itself!
Regarding most of the features you have mentioned above, with the exception of a material swap, I think that so far, either we have them, or they are on our internal to-do list. We have been discussing here the best way of exposing a roadmap — it is something we want, but I think we must do it carefully, because while we wish to give a view into our thinking, we also always want to avoid the situation where someone purchases the software based on a roadmap “promise”, since plans can change due to unforeseen conditions. Probably it will take the form of another page on this site, where you can see a grid of things that are currently in-process, things that are definitely planned, and so forth, along with our comments & notes on each one.
This is a very sensitive topic indeed and I would say it all boils down to how the developers interact with the community of users. Earlier, when Thea was a small company, the developers were more forthcoming with the customers and they even shared with the users a rough outline of the upcoming features. In case there was something that was promoted as an upcoming feature, but couldn’t make it to a release, they would state the reasons and provide the users with an alternate time frame and that would have been enough and the users were more understanding. However from the time Thea was acquired by Altair, all that changed and unfortunately, not many of the users are happy. But that’s your decision to make as developers and you know best! 🙂