is Bella still developed?

Forums General is Bella still developed?

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
  • #4863

    or abandoned ?

    Jeremy Hill

    Yes it is developed, about 16 hours a day. 🙂


    cool! bumped into a post about it in some CG forum, wandered what happened…so tried it again. I can say that it’s better but if I can suggest some advice…. I’m a maya user, you know. And the Bella toolbar looks a bit poor with it’s 5 icons – and not really usable. I think that if you wanna see people using Bella more seriously it must be better and full of icons helping out to apply all Bella functions, or at least a button to assign Bella materials to selection, show emitter materials, focus camera (is it availabe?) …. let the users find the good stuff easily and make your engine also look Bella …

    Jeremy Hill

    I have been busy integrating Bella materials & textures into Rhino; very close to releasing a version with them:

    Albert has been (among other things), working on a new SSS model:

    And Oscar’s work on GPU begins to bear fruit, even looking very good for helping to improve the CPU side; here is a test of the current Atlas engine, rendering with 1 thread for 10 minutes (on a quite old machine):

    And here is the CPU version of his new “jupiter” engine, also rendering with 1 thread for 10 minutes, on the same machine:

    Regarding this comparison, I must make very clear that this is the (very recent) result of internal, heavily under-development code, and there is always the possibility that a show-stopping limitation pops up as the development continues.

    But that said, it is looking very promising.

    Jeremy Hill

    Ah sorry, we were posting at the same time.

    Regarding maya, if you have suggestions I am open. The way I approached it is to try to work along with maya’s native ways, so you create/apply a bella material the same as you do a maya one. Ditto with the camera, you have the bella rollout in the maya camera attributes, and tools like “frame selection”, or using a camera target, should all work as expected.

    But we can definitely add more convenience features, just let me know what you would like.


    cool, I’d try bella soon on one of my older scenes and tell you what I think. I know that as a pro I shouldn’t look too much at the toolbar but today people like presets and 1-click solutions and if you’re the new kid on the block you must look good!

    Jeremy Hill

    I am very open to suggestions, because I do not pretend to be a maya pro. 🙂

    As I say, I tried to expose bella things in a very native maya way, so we have access to all bella node attributes the same as any other type of node, and can write python or mel scripts to create custom tools.


    Your renderer is great feature-wise but some boost in speed is needed for sure. Let’s not forget that Maxwell lost its position when faster gpu render engines appeared. Speed is super important when setting/manipulating the scene, so a less sophisticated GPU render for IPR and for draft renders is the only option for me. The perfect combination of quality/speed right now  is Indigo but you seem more keep developing guys


    Jeremy Hill

    Thanks for the input, we are indeed thinking along those lines, simply based on the reasoning that there is no sense in waiting for a full GPU implementation to be finished, before using a more preliminary implementation for IPR. 🙂


    I have to say that to me, scene setup is less important when thinking about speed. as a long time maxwell user I can tell that having a very-predictable render engine saves tons of time in scene setup as usually I know what I’m gonna get. I do test the scenes a few times but it’s only like 10-15 mins render to view forums etc. while waiting… end result is what important, that’s why I’m looking into Bella, hoping to find maxwell+ quality and less time for final renders.

    Jeremy Hill

    We completely agree about predictability; clearly you understand how important this is, and how/why a strict physics-based approach produces it, but that is not something that is obvious to many, until they have actually experienced it. I attended siggraph and various other conventions for NL, and this was always one of the first things I’d try to explain to people.

    As far as quality goes, even maxwell will not be able to compete with bella. Everything in bella is brand new, designed with the benefit of so many years of hindsight, and without the baggage that you end up with in a codebase that’s been maintained for nearly two decades. Our scene model, material model, sky model, camera model — everything — is simply superior. Not in a bragging way, but just factually. An architect can easily understand this — just imagine you had worked on a single skyscraper for 15 years, and how you would wish you could go back and start over; there would be entire methods of construction that had not even existed when you started, but it would be too late to make use of them.

    Our disadvantage is simply that bella is still young, and therefore still lacks various features (e.g. hair/grass, volumetrics, etc). But those are just a matter of time, not capability. Luckily, being all brand new & modern, we are able to implement such things much quicker and better than would otherwise be possible. We invested a good deal of time & effort to design our foundation, and it has been paying off already, and will continue to do so.

    Unfortunately though, our gallery does not yet reflect what bella can really do, since it is still the case that most of the images have been made by me, and besides not being a great visualizer, it is difficult to stop coding long enough to spend the time necessary (as you well know — i’ve seen your outstanding work) to produce really great imagery.


    well that’s great news, Bella superior to Maxwell ?! I’m exited now. Let me just suggest that if you want an important (and maybe relatively simple to code ?) feature, it should be something like the MXS references and scatter in maxwell. not grass, not displacement, not hair… all are important but with instances of a reference you can really increase a scene to include many details yet stay simple, and with scatter you can replicate anything – you can create a plane of grass made of a very simple instance, etc. To me, at least…I hope to have some time during weekend as it’s a holiday here so I can try and render something decent.

    Jeremy Hill

    Thanks for your input, indeed referencing scenes (bella, or OBJ/etc) is something high on the list of priorities. Bella’s nodal nature and pervasive instancing will come into play here — in bella everything is an instance, so you are able to instance geometry, or other instances, or entire hierarchies of instances.

    I also have plans for another kind of instancing, where each instance is extremely lightweight; each one will have fewer options (a real instance can have a name, its own material, its own per-triangle materials, it can even use its own set of UVs, on a per-texture basis), with the benefit being that you can scatter thousands and thousands of them.

    Not that bella can’t handle lots of traditional instances already .. I recently implemented a very effective optimization, when I inadvertently tested with a scene that had 75,000 instances, and it was taking some time to deal with them all. I was able to reduce render startup time by 10x in that case, and the code for that will be in the next build.


    made some tests today, I have to say it looked real promising, only hold back is the time to create materials, for me at least still not easy enough: selecting from nodes with names like “bellaceramic” and trying to figure out each one…. think a wizard system and a small (for start …) library with a typical car paints, walls, fabrics, textured  and glass/ags would help any user.

    Jeremy Hill

    Thanks, that sounds logical. We have some things in the oven on the material front, one is a PBR type, another is “larger” more all-purpose material more like arnold’s standard surface. So those will basically (and of course optionally) take the place of what can now require several different nodes & connections. And second, it has already been requested by both users and Oscar and Albert, for me to make a function that “switches” a node to another type, translating over any matching attributes — and what you suggest above falls under that general category.

    Just for reference, there are currently two broad “types” of materials: core materials, and “smart” materials. The core ones are the base conductor, dielectric, and such, and you can build anything using these. The smart materials are the higher-level ones like glass, metal, etc, and these build a material internally, using a small number of the most relevant parameters.


Viewing 15 posts - 1 through 15 (of 15 total)
  • You must be logged in to reply to this topic.