Bella Render

jenujacob

Paul Russam's famous church model rendered in Bella....

one word : Bellisima!

juju

Paul Russam's famous church model rendered in Bella....
[attachment=0:1ab9zu6z]PaulRussamChurch_BR.jpg[/attachment:1ab9zu6z]
one word : Bellisima!

I tried looking for the model at the link provided, but it seems to have been removed?

jenujacob

@juju said:

@jenujacob said:

Paul Russam's famous church model rendered in Bella....
[attachment=0:388rlf7s]PaulRussamChurch_BR.jpg[/attachment:388rlf7s]
one word : Bellisima!

I tried looking for the model at the link provided, but it seems to have been removed?

Yes.. Paul had removed it a couple of years ago... Maybe he can upload it again somewhere? Or if he's OK with it, I could upload the model and share it here.

ntxdave

Continuing to learn. Here is an image rendered where the focus was using the Image Dome setting for the background. Yes, there are several things that could be improved but again, the emphasis was on the Image Dome and some of its settings.....
Car Wash Testing Image Dome.png

JD Hill

I hope you don't mind if I volunteer a tip -- I think this could benefit from use of a higher-quality HDRI, which would be capable of generating nice illumination & shadows:

However, since it is clear you want to use this image as a backplate, you could override illumination with a sky dome (or with another image dome using a different HDRI):

Either option would allow you to keep your city background just as you have set it up, while getting more natural light in the foreground of the scene.

ntxdave

Thanks for the feedback. Will do some more test/learning. Would like to have an HDRI that would fit well with my model. At the rate I am going the documentation is a long way off.

JD Hill

I hear you, it can be difficult to find the right thing; not sure if there are any precisely like what you have, but there are lots of nice ones here: https://hdrihaven.com/hdris/?c=urban

ntxdave

OK - Latest test render. However, it turned out what had the most effect was resetting the date and time. Changing the illumination to skyDome did not changed it. But once again, something to learn.

Yes, if I were really trying to produce something for a client, a better image would be needed. But for now, I was just trying to give the scene some context.

Here is the latest render (did not let it go as long as previous one)........
Car Wash Testing.png

Alright, I have to get a way from the car wash stuff so thought I would try another one.......
Room v9c .png
Now I have to figure out how to turn the lamp on.

JD Hill

Making good progress!

Regarding the lamp, to make a light bulb/source I would probably draw an octagon and extrude it, maybe delete the top & bottom faces, group it, and assign (to the group, not individual faces inside it -- they should have no material) a material set to the emitter type in bella. It is generally best to keep emitter geometry as low-poly as possible, for rendering speed.

ntxdave

OK - that seemed to work but I need to make it bigger and stronger. At least it is something for me to continue to explore/learn.
Room - Lit Lamp.png

JD Hill

On that, I'll mention that just like with real photography, it will not be possible to find an exposure that lets you see much influence from the lamp, without also causing the exterior visible through the window to be blown out. We don't usually notice this with our eyes because they have a high dynamic range, and adjust quickly as we scan across a room.

This hints at another rule, that the physicality of bella's camera/lights/etc requires models to be constructed using correct scale. Since for example, it will mean little to say an emitter puts out 100W, when the scene has been constructed at say 1/10 its real size.

Not saying you are doing that -- rather your impulse to want to crank up the power of the lamp suggests to me that you have chosen a not-unrealistic output value for the lamp, and that your scene is indeed modeled at correct scale.

I have often seen where people neglect these things, and end up cranking emitter output values, or camera values, to unrealistic ranges to try and compensate, and this puts things out of balance and generally yields subpar results, and loss of performance.

ntxdave

Thank you.....

On the positive side, if you look at the bottom of the lampshade, at the body of the lamp itself, and to some extent the wall above the lamp, you can tell that the lamp is on. I might remove the window or make some changes to the external lighting (that is blasting through the window) I think we would see a much more convincing image that the lamp is turned on. JMO

JD Hill

Sure, just mentioning that since I've seen people try to fight with it.

numerobis

WOW! How could i miss this one? Nice to see you back in the game JD! And thank you once more for your outstanding support in all the years regarding the SketchUp plugin!
This looks VERY interesting, especially the caustics solver!!! If this is really working... finally... I have to try it...
So there are several developers working on this, who used to work for NL? What happened? Is this related to the leaving of Juan Canada? The GUI and features surely have some similarities with Maxwell at first sight.
I was scrolling through the forums and noticed some familiar names like Thomas An., Tim Ellis, Magnus and Hervé... reminds me of the good old days of Maxwell Alpha/Beta. Would be really great to get this spirit back after NL doesn't seem to be interested anymore in developing renderers.
Do you have a road map?

Impressive!

JD Hill

Hey Numerobis, nice to hear from you.

Yes, Bella is created by myself, and Oscar Cano & Albert Martinez, the guys who originally created mw before bringing it to NL (I'll comment on some of the more political parts of your question via pm if you don't mind). So, the similarity naturally arises from that -- this is just what we love to do. Bella is in early days, since you can imagine it is a lot of work to start from scratch, but that has also been a great benefit, to be able to start from a clean sheet, with years of experience to guide us. We are building on a very clean node-based system which took some time to design and build, but it was an investment which is already paying us back now, and will continue to do so even more in the future.

It has been on my list to make an official roadmap, but we don't have one, as such .. just working like mad to implement all the expected stuff, and finish one plugin in order to move to the next (currently deep into the Rhino one). As I've mentioned earlier in this thread, this Sketchup plugin is a very bare-bones thing, really only made available because some people asked, but it provides an on-ramp anyway (as opposed to exporting/importing DAE or such). If you are interested, I'm sure you'll have some valuable input once we come to building the real thing.

numerobis

Do you have a timeframe for the SU plugin? And for the planned 3dsmax plugin?

And some more questions/suggestions regarding the development...
I suppose you're aware of the general market and technology situation and what features renderers need to have today, but i will try to write down my personal opinion regarding some points. My first question would be, how you want to position your renderer... for big scenes (archviz, film) or only for small stuff (product shots, etc.). In my opinion or for my needs, GPU or hybrid CPU-GPU would be great IF it is feature complete and the memory problem can be solved (out of core, or memory optimization like in Fstorm). If this is a problem i think it would be better to focus on CPU, especially with the increase in CPU power we've seen in the last time.

I don't know what your plans are, but for me it would be great if the development and communication would be organized similar to what they do with the Corona Renderer development. Open communication regarding potential features with the community, maybe incl. daily builds and a public roadmap (they are using Trello). The Fstorm development would be another one to name - not regarding communication, but more regarding features and the general interpretation of the workflow. I don't know if you're aware of the recent discussions about tonemapping? (FStorm, ACES and all the stuff). But I think this is a point that can have a tremendous effect on realism and usability that is still overlooked/ignored be many companies (i.e. NL)

And thanks for staying away from the subscription model and having one license for all plugins and incl. five render nodes (like it used to be in the good old Maxwell days). I think the nodes are also reasonably priced at 50€. Maybe you could add bundle prices with 10 or 20 nodes.

JD Hill

Thanks for taking the time, Numerobis.

I cannot give a definite timeframe on either the full SketchUp or 3dsmax plugins; I can tell you that SketchUp has been planned to come after Rhino, which I think I've mentioned is the plugin I am currently working on, but that I may slip a simple Blender exporter (like the current SketchUp plugin) in-between due to requests. 3dsmax has been tentatively planned for after Cinema 4D, both because there have been fewer requests for it, and because I have experience with Cinema, so should be able to do it quicker.

We have planned for GPU from the start, but of course CPU is a must, and is a cleaner environment for creating complicated new things like the Apollo solver, so it was natural that we would start there. It will indeed be a challenge to have things be 1:1 on GPU, just for example, since all Bella textures are procedural (of course file textures are not "procedural" as such, but they are just a special case of our general texture node), and since it will be possible for third-parties to author their own texture (and other) nodes. One benefit, though, is that much of the work required for GPU will also be able to be used to improve the CPU side, and I understand from Oscar that we are pretty close to seeing some of that.

Also from the start we chose to use industry-standard libraries where possible, so we have used OpenImageIO for textures, and OpenColorIO for color management. By default we provide built-in linear, sRGB, and Rec709 spaces, but you can use the standard OCIO environment variable to make Bella work with your desired OCIO config (e.g. ACES) -- its transforms will show up in your display & output choices, and in the file texture node. We also have available either Reinhard or Filmic tonemapping in the camera sensor node, at this point.

I will work on the roadmap aspect, I have been intending that for some time, but seem to end up working on code instead. Daily builds will not be likely at least for the time being, partially because I still personally download & install every package (after it's gone through Apple's notarization in the case of macos) to ensure they work and are not corrupted, and because being a small team, we each often end up getting pretty deep into some piece of code, so there are not enough changes to justify a daily build. Weekly will likely be a more useful target for us, with bug-fix builds being done quickly on an as-reported & as-needed basis. In any case, we are always available on our forum, and try to respond quickly.

On the node bundle idea, we have deliberately tried to keep Bella's product offerings and licensing very simple, but node bundles definitely make sense, so we'll be sure to discuss it.

Thanks again for your feedback, and I hope I have not missed anything.

numerobis

Thanks for your answers - even if it sounds like a max plugin is still far away

Just to be clear... "daily build" was just referring to the term that is used by the corona team for their frequent unofficial releases. In fact they are more weekly or even monthly releases as you suggest. So, yes, weekly or monthly builds are surely enough (like in maxwell alpha/beta days )

JD Hill

Ah, I see, well in case it is of interest, I do post all builds & release notes here: https://bellarender.com/builds. From time to time I then promote a build there to the regular download page.

numerobis

Ah, ok... so it's already there. Nice.