Could be promising

Forums General Could be promising

Viewing 15 posts - 16 through 30 (of 37 total)
  • Author
  • #5791
    Jeremy Hill

    Great, thanks again for your thoughts. I think it’s pretty common that freelancers & small shops do not prefer to use referenced materials, but that larger offices often want to have a single person who can curate the materials they use, in order to enforce a consistent look across all their work.

    Ultimately what I want for bella is something in-between, where you are able to add a set of attributes (think color, shininess, whatever you like) to a special kind of material, and connect them to inputs of one of the standard bella materials. Then, when you reference this material, what you see is only that set of attributes, which you use to tweak a particular instance of the material.

    If you don’t expose any attributes, then you can’t change anything, and this is just a regular referenced material. But if you do expose some, then you have a flexible material that allows you to create many variations, easily decided in each place where you use it, with all the details remaining hidden.

    The simplest use case would be just to simplify the use of a standard bella material, however you see fit. But if you consider that the “internal” material may have connected textures, layers, etc, using color correction nodes, or vector multiplication of colors, and so forth, you can create something super powerful, but which still exposes only a minimum of attributes to control it.


    after a bit more playing I can also ask that bella emitter will include temperature-based parameters ?

    like a typical bulb with 4000 deg. Calvin, 100 Watt, 50 Efficacy etc. ?


    Jeremy Hill

    Definitely it will, it is just hidden for now since I still have some work to do before exposing it.


    A few more thoughts

    • In Europe and Asia, emitters are specified via their light output, lumens; and being able to use IES files that all LED and even retrofit “LED-bulb” manufacturers offer is essential
    • Industrial designers need common material presets and MOLD-TECH textures, a big plus for Keyshot. Few even in large studios are tweaker nerds; you drag materials from a library, maybe change a texture here and there. Whether VFX wizards like it or not, designers like it “easy” and if a company can offer “easy”, it has a chance of adoption in the marketplace
    • Vray, unlike Maxwell, allows camera projection of a backplate onto the shadow catcher plane, so one gets proper reflections on backplated renderings, a huge plus
    • No confusing nodes with spaghetti, which are oh-so-fashionable. One thing really good in Maxwell is the analogy to how materials are in the real world, a stack of layers, something any product, transport, industrial or car designer can understand
    • CPU speed, as the overwhelming majority of designers are laptop users without dedicated boxes holding a stack of GPUs

    It really is a matter of product positioning and market sector placement

    Jeremy Hill

    Thanks Andreas, IES has always been on our to-do list, I very much understand how important it is, but it just has not yet risen to the top. And of course you can already use lumens if you wish.

    It looks like mold-tech would be a no-go, as luxion claims to have an exclusive partnership with Standex, but I get the point about having easy to use ready-made materials, and I was touching on an aspect of that above, when talking about how I want a material that lets a pro build it, but rather than be set in stone, to also let the author expose just a few parameters for tweaking by the end user.

    Regarding the shadow-catcher, just so I understand this correctly, if we have this regular render:

    The problem you are pointing to is that when we catch shadows with the plane, we don’t have a shadow here, in the reflection:

    If so, then Albert can take a look and see what we can do.

    Regarding materials, Bella’s use a very physical layered model. We have the substrates you start with, conductor/dielectric mainly, and we then have a physical layer you can add, which is truly simulating reflection & refraction bounces within the virtual thickness (unlike mw which works more like photoshop layer blending, not like a true physical layer). With the Blend material, we also do have a photoshop type of layering, but you can layer an arbitrary number of entire materials, either by blending or by ordered stacking & masking.

    On cpu & gpu, we are indeed working on a gpu solver, but it is not just an add-on, it is a new core that will be implemented very similarly on both cpu & gpu, and will (to be precise, provided no showstoppers crop up — and things are looking very good so far) eventually replace all of our current production solvers. The cpu implementation will come first, and it is looking to be many times faster than what we have now.

    Oscar will probably shoot me for showing this, since it is in-process and not even optimized yet, but here is a test scene rendered for 2 minutes on my (pretty nice 4930mx, but around 7 years old) laptop with our current atlas solver:

    And here is 2 minutes on the new jupiter solver cpu implementation:

    And — this is with various optimizations disabled, and with some problems due to being under heavy development — which included using only half my cpu threads.

    We understand well the need to leverage advances in hardware, but at the same time, we do not forget that you cannot just sit around and wait for new hardware to give you improvements, and have to keep pushing forward on new algorithms, which can get you breakthroughs both on new, and existing hardware.


    Thanks, it all looks very exciting.

    What I meant (and, yes, the shadowing is another issue) was what is easily done in Vray, which also in oh-so-Blender you cannot get right as one can see here

    Vray example (kettles on backplate road markings correctly reflecting them) here “correct workflow if cg object integration onto backplate # post680958” (sorry, posting the chaosgroup link here always deletes the just written email).

    Jeremy Hill

    Thanks, I still have not figured out why this forum software sometimes screws up with links, but I was able to find it in the admin side, so I’ll try to link it too, so Albert can take a look.


    Hi Jeremy and company,

    Just my two cents to this thread – I also heavily rely on a pre-built library of materials developed over time. It is one of the largest barriers to switching to another render platform – so much time and energy has been spent in making and tuning these.

    My personal opinion is that a Bella material file format would make sense, but then that begs the question of a standalone material editor… which I think you have been trying to stay away from? I like the idea of a Bella material being a custom zipped folder with all required assets, and a manifest file.

    I remember in the old Maxwell/Rhino plugin days texture scaling was a big undertaking. Is that still the case? I just tried doing a deep dive into the mapping of textures, and am now terrified. It is very difficult to understand intuitively where Rhino stops and where Bella starts. Putting “Bella” before certainly helps! (I’m sure it will become more obvious as I spend more time using it…)

    I just installed the latest Bella (dev built), and I see the PBR option making an appearance, but I take it it is still in dev? Can’t seem to render any textures yet, although the Rhino PBR option seems to be working as it renders in Bella.




    Jeremy Hill

    Hi Tom, an external material format has always been planned, but as usual I like to wait until something has become quite necessary to implement, in order to have as clear a view as possible when approaching the design. The format can be made with or without an external editor, and I’m neither strongly for nor against building one of those — however it ends up, a plugin will be able to read & write the files, so an external editor would be optional to use, and my main argument against building one would just be that it would take time better spent elsewhere, without much of a payoff.

    Regarding PBR in Rhino, it should be working, but I have fixed (internally here) a few issues with identifying textures in some cases, so you might try a few different texture sets from to check whether it is just the naming used in the particular sets you have tried. And if so, and if it is convenient, I’d much appreciate getting a look at one of those failing ones, to confirm that my current code is handling them well.

    Regarding your comment about not seeing where Rhino ends and Bella starts, I think I’d like to hear more what you mean here. I suppose it may be things like wondering if you can use a Rhino texture in a Bella material?

    If so, you generally can, but you should usually prefer to use Bella textures, since the Rhino ones have to be baked to file to be used. I asked, and Andy open-sourced the logic for Rhino procedurals, so when I get time I will be implementing those directly in Bella, and this will mean we will no longer have to bake them to files.

    Aside from that, it is still generally possible to use Rhino materials in Bella, and there can be arguments for that (e.g. using a single setup for multiple renderers), but the Bella materials will give you more direct control without the need for us to make a generally-imperfect translation from Rhino to Bella.

    Not sure if this helps, so if you want to elaborate a bit, please do.


    Well, this is embarrassing… The material format I describe is pretty much a PBR folder… You can tell I’ve been a little out of the rendering business lately!



    Jeremy Hill

    Heh no worries, there’s a little mismatch between Rhino’s concept of PBR and ours — the Bella materials that correspond most closely to Rhino’s Physically-Based Material are the Uber & Principled types, where you get control over a whole bunch of parameters (Uber gives most control, Principled exposes just the most-commonly used).

    Then, you have our PBR material, which just accepts a single path — it can be one file in a matching texture set, or it can be a .zip file containing a texture set. In the former case, there is logic inside that scans to find the other the textures in the set, using the supplied path as a prototype. These types of PBR texture sets are intended to encode all the necessary information directly in the textures, so the PBR exposes very few parameters.

    Rhino’s Physically-Based Material also has a function you can use to set it up based on a set of textures, and at some point the Bella Uber & Principled materials will gain a similar function, though I consider it generally preferable to just use the Bella PBR material.

    I’ll mention that there is one thing with PBR that can potentially trip you up, and that is that I cannot yet support Arroway texture sets, because they use a peculiar naming convention for the textures. I am working on that, but in the meantime, if you wanted to use an Arroway set, it would be necessary to rename the textures to use the more standard file_color.jpg, file_normal.jpg, file_roughness.jpg (and so forth) naming.


    Thanks for the clarification – this is super helpful. I think conventions can be really powerful, and often overlooked, and I am glad that at least in the naming scheme PBRs are converging.

    What I found confusing when using the Bella PBR is that it doesn’t let you know it has sucked in the other files, at least in the Rhino plugin interface. I figured it out by rendering a few materials from (thanks for the pointer), and seeing that things were happening. I tried using the Rhino PBR, and the Bella PBR – Bella looks much nicer!




    Jeremy Hill

    Yes, this is a very young feature so I don’t yet have anything special for showing you the related textures (I do have that in my code here, in the Bella GUI). Barring bugs it is supposed to “just work”, and people are intended to think of their PBR .zip as “the material” when using Bella PBR.

    As far as Rhino PBR showing up nice in Bella, that will also take more work, since what you are seeing now is going through a Rhino PBR -> Rhino “Custom” -> Bella conversion path. The Rhino PBR will eventually be translated using the Bella Uber material, which should have sufficient parameters to represent it, but that involves some hackery to peek into the values of the Rhino material when I detect that it is of the PBR type.


    well to sum it up, I think there’s a need to step out of the programmer attitude that stuff like “uber-material” is a cool name 😉 and into the typical user that wants a simple “glass, plastic, stone, metal, default grey….” material names and presets. I never get the idea why should all the nodes start with “bella” (not only with bella but also with others), I know what I’m using (da…) and never seen a thing like “maya_phong_node” or “maya_super_lambert” stuff. guys keep it simple because no one wants to re-learn a whole new system.


    I could not agree more.

    Without total user/market focus, there is little chance of penetrating the targeted industry segments. While appeal to nerds is surely fun and makes for nice forum banter among “those in the know”, it is hardly a sustainable business case. An easy to use no-nonsense interface is paramount. It is all about the user experience. Particularly the novice user must experience “aha moments” right from the start to get hooked, and can then explore nerd-dom in-depth later. That is one reason why for example Keyshot, despite its many problems, became so popular, and the industrial design, packaging design and interior design market segment is huge. Lamenting the desire for “easy” and “out of the box” lighting, scene or material set-ups is understandable from the insider or nerd perspective, but one cannot ignore how the real world works (not saying that you guys are ignorant, just see too many product market failures because of that exact reason).

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