@pilou said:

@unknownuser said:

That's strange because it did work fine for me, with the DAE + textures you attached before.

That works but for only one texture for me!

Ah sorry, I misunderstood, yes it found the texture, but did not support per-face materials.

@pilou said:

but I have found how to make!
You must put all in the same level! (JPG)

Yes, this is what I noticed too when trying your file. We use a 3rd-party library for importing, so I have to take a look and see why it is failing.

@pilou said:

Alas the same trick don't work for the DAE (PNG)

That's strange because it did work fine for me, with the DAE + textures you attached before.

@pilou said:

Another thing is the Scale from the SketchuP exported OBJ: maybe a factor 100* from the origine!

Bella's native units are meters, so you generally need to scale the parent transform of an import, depending on what is contained in the imported file. Beyond this, it is generally necessary to rotate the import too, since it may not use the same coordinate system as Bella.

@pilou said:

About the Integrated SKetchUP BellaRender: we can't rotate the render or IPR with Alt + Mouse or other ? (i don't want enter values in some boards)

In the Bella GUI, you can rotate the camera when using IPR, but not during render. You can orbit/zoom/pan the camera using key combinations similar to the application chosen in Settings > IPR > Navigation. By default it is set to Maya when just opening GUI, but Bella files written from the SketchUp plugin set it to SketchUp mode.

@pilou said:

Any refresh when you rotate in SketchUp ?
We must re-press the Icon BellaRender inside SketchUp ?

There is no live connection, for this very simple plugin. When I make a full plugin, then you will have a Bella IPR inside of SketchUp, working in real time (along with materials, objects, etc), like we currently have in the Maya & Rhino plugins.

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:

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.

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.

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.

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.

Sure thing, good luck and stay safe.

It depends on the model; you know how you can distort textures, well sometimes you do that and it is important, while other times it is not, e.g. you import a tree or shrub, where each leaf has had its texture distorted just a very slight bit -- not enough to matter (sometimes it seems so slight as to have been produced by small numerical errors when the model was perhaps generated or processed by some software tool).

By telling the plugin to ignore distortion, it just uses the non-distorted texture, which means it doesn't have to ask sketchup to write a unique bitmap for each leaf.

Since attributes in that menu are applied hierarchically, you can enable them for just a single group (or component instance), or a group of groups, and so forth, all the way up to what we did here, by quickly grouping the whole model, and making everything ignore distortion, just to see if that was the cause of the slowdown.

It was my first guess because the exporter is generally pretty quick, so when there is an unreasonable slowdown, distorted textures are a prime suspect.

Shot in the dark -- group the whole model, right-click the group, and enable Maxwell > UV Coordinates > Ignore Distortion.

(I am not seeing any private message here btw)

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

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.

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.

When I wrote the plugin you could use File > Export > 3D Model to save an MXS, or if you have maxwell studio, you could export to studio. Not sure now, though, so it depends on your version. If it still uses much of the same code, there is also a temporary mxs written at <documents>/Maxwell/SketchUp/temp/temp.mxs when rendering in FIRE.

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

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.

Sounds like you should wait for a version that integrates everything inside sketchup. This one, I wrote basically because jenu and a few others asked.

Hey jenu nice to see you. That is really strange about the forum -- it's not just you, I can see that your post is listed as most recent, but the post doesn't appear in the thread .. I'll have to check if I need to update or fix the forum software somehow.

Nice to see some images, looks like you're getting the hang of it already. True it may not be the easiest thing to use once you get to the GUI (though, that is a bit of a fooler, since it is hiding a full nodal model underneath, while not forcing people to deal with big node graphs), but I made no secret that this is basically an internal script I wrote early on just so the other guys could generate their own geometry during Bella's early development. So it's a bit of a geek toy for sure at this point.

However, still worth noting that much of the code that's in there will remain even in the eventual full plugin, so it's good for it to see some use, so we catch any issues early, which will speed up development of the full plugin when the time comes.

And meanwhile, just keep in mind that we have here basically a blank slate for that development. I created the early SketchUp plugin forum, and then this plugin, mainly so that anyone who wishes, can get involved early, to help shape how the full plugin ends up looking.

I have now uploaded the example scenes I mentioned earlier, here and here.

They are made available in both SKP and BSZ format, which is a bella format that embeds resources along with the BSX file that uses them (BSX is the binary bella format, as opposed to the ascii BSA format written by this pure ruby plugin).

I'm in the minneapolis area, and the others are (and the company is set up) in barcelona, which is 7 hours ahead of me. On the help, it is actually most interesting to me to see how you are perceiving things, and how you are presenting them.

I am right in the middle of some things now so will not likely work on docs for this plugin for a week or so, so if you wish to continue I am sure it will be useful, and I can talk to the others about working something out, license-wise, to make sure you are not just donating your valuable time.