Bella Render
-
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
-
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)........
Alright, I have to get a way from the car wash stuff so thought I would try another one.......
Now I have to figure out how to turn the lamp on.
-
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.
-
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.
-
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.
-
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
-
Sure, just mentioning that since I've seen people try to fight with it.
-
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!
-
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.
-
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.
-
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.
-
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
) -
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.
-
Ah, ok... so it's already there. Nice.
-
I just started using bella render and I want to make one of my renders either 4k or 8k as I am using the rendering to make some graphics for my school project. How do I do this? How long will it take to make the resolution this good?
Thanks
-
It would depend on being licensed, in demo mode it is limited to 720p (1280x720) by area, while when licensed there is no resolution limitation. To change the resolution, since this rudimentary version of the plugin just exports using the Sketchup viewport size, you would stop the render in Bella GUI and go to the Camera panel, where you will fine the output resolution of the camera. As for how long it will take, that depends on many factors, such as the difficulty of the lighting scenario, as well as the speed and quantity of CPU cores on the machine.
-
About the Standalone (demo)
I have a DAE file from SKetchUp
All is well imported Volumes+ SU Material Textures...
But how to render all ? Seems path accept only one image texture...
(no problem in the Integrated BellaRender version inside SU)
We can't rotate the object inside BellaRender in the Integrate SU Version ?
Alt + Mouse ?
but in the Standalone...i must miss something!
(or Demo don't accept many materials ? File DAE + Images Textures linked)
-
I am not sure if the importer we use supports multi-materials in DAE, but I can check it out. I also notice that it is not picking up the textures unless I move them next to the DAE (instead of having them in a subdirectory), so I'll put it on my list to check that too.
That said, rather than use DAE, it will be much better to use our plugin to write a Bella file from SketchUp. It will produce a better file, support multi-materials, other settings (environment, etc), and so forth.
Regarding rotating (or scaling/moving) objects once the file is in Bella GUI, you can do that by selecting a parent transform (more info here), and changing its Position/Rotation/Scale in the Editor panel:
-
Thx for the infos i will see that...
-
For Standalone with an OBJ file, it's the same problem of path...
[WARN] Failed to find texture: belltwo_Textures/Dalle_effet_pierre_de_taille.PNG
[WARN] Failed to find texture: belltwo_Textures/Brique_antique_02.PNG
[WARN] Failed to find texture: belltwo_Textures/Pierre_de_maonnerie_multicolore.PNGbut I have found how to make!
You must put all in the same level! (JPG)
And so no problem of rotation!
Alas the same trick don't work for the DAE (PNG)
Another thing is the Scale from the SketchuP exported OBJ: maybe a factor 100* from the origine!
Here the Import OBJ
(with any regulates & rustic snapshot) but textures are now existing! 
Advertisement