- This topic has 14 replies, 3 voices, and was last updated 1 year ago by Jeremy Hill.
May 25, 2020 at 5:16 am #4863yossi
or abandoned ?May 25, 2020 at 12:42 pm #4868Jeremy Hill
Yes it is developed, about 16 hours a day. 🙂May 25, 2020 at 12:54 pm #4871yossi
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 …May 25, 2020 at 1:10 pm #4872Jeremy 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.May 25, 2020 at 1:13 pm #4874Jeremy 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.May 25, 2020 at 1:24 pm #4876yossi
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!May 25, 2020 at 1:30 pm #4877Jeremy 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.May 25, 2020 at 2:33 pm #4879visitor
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 enthusiastic..so keep developing guys
🙂May 25, 2020 at 3:10 pm #4881Jeremy 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. 🙂May 26, 2020 at 3:02 pm #4887yossi
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.May 26, 2020 at 3:38 pm #4888Jeremy 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.May 26, 2020 at 3:59 pm #4890yossi
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.May 26, 2020 at 4:11 pm #4891Jeremy 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.June 8, 2020 at 5:10 pm #4981yossi
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.June 8, 2020 at 5:55 pm #4985Jeremy 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.
- You must be logged in to reply to this topic.