Architecture - Sketchup workflow

Forums SketchUp Plugin Architecture - Sketchup workflow

  • This topic has 8 replies, 4 voices, and was last updated 1 year ago by loftalofta.
Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
  • #2131

    Thnx Jeremy for creating this section.. It’s a pleasure to try to be of help regarding what could be a future BellaRender ( BR) sketchup (SU) plugin.

    Just few words regarding our practice: Small studio based in Lyon, France, using Maxwellrender (MR) with SU plugins since the alpha version (2005?), and having updated till the last version with more or less success, having to workaround limitations often in order to use it in a easy way.
    This leads my thoughts to what we as architects doing construction projects would need as an ideal renderer, implies for me a few considerations

    1. Light quality: in architecture rendering: all that matters is that the lights look natural and unbiased. This is why we used MR at the first place because even a white model looked good with only glass / AGS as only other material. It also is how we usually model in SU: model geometry using groups, sometimes components, then add AGS, then add other material if time permits or is required for more realistic rendering. We use mostly physical sky without any modification besides geolocalisation, and sometimes skydome render for a more model like mood. HDRi is used also at times, but it needs so much guesses and trial/error work to find out where the sun is and how to set height that is not really simple.

    2. Materials: Materials in 3D software have come a long way since Zoom or early softwares, and why it is still so complex has only one explaination > they did not exist, so everyone has to create them from scratch, using available or homemade textures that add to the complexity of the material editors and the infinite layers systems etc…As architects we need materials that exist in real life and for this reason we have been using arroway textures because they are as close as it gets to real world without having to guess scale or if the woods/concrete etc is real etc… Basically what we do is when we set a material, it is almost never touched or modified besides reflections ( shiny or not) or color material ( more yellow planks, blue concrete etc…and that is very long and complex to do because in MR you need to edit the reflectance image in photoshop, change its colors, save as, replace in a new material etc…not very user friendly.

    Materials integration in Sketchup needs to be automated so each time a high res library material is created/imported in BR, it gets automatically created in a material folder in SU with the ability to choose the weight of the SU jpg: SU interface gets very laggy when you use materials that have a weight over 200 kb.
    The ideal workflow would be to be able to import / convert an existing .mxm material or arroway folder and automatically create the corresponding BR material, as well as a SU .skm material in the SU library.. It is important that people with existing library are able to convert them into BR because sometimes days of work have been put in them material libraries!

    3. Workflow:
    – Model in SU
    – Add materials to model ( either SU basic lowrez materials or BR materials), create new materials from import existing material file (.mxm?) / arroway layers / from scratch
    – Set light ( physical / skydome / hdri or all ) . Multilight beeing a real plus for architecture.
    – Render

    This is all for now, keep in mind architects are dumb, non 3D render professionals, that require simple tools that they can learn fast and use for production. If we require pro 3D renders it is usually output to people that have full libraries of vegetation, objects etc and they will require all the fine sophisticated options. Having to minimize the use of post processing in the image is also a plus! 🙂

    studio website High quality 3D’s are often outsourced, but you can see many were done within the office with sufficient result, but with lots of walkaround solutions due to the limitations of MR / SU combination.

    Jeremy HillJeremy Hill

    Welcome Nils, and thank you very much for taking the time to write all this! Very nice works on your site — I am very eager to see what people like you are going to be able to do with bella.

    It is interesting what you say about the need for light quality, even (or especially) in preliminary pre-viz. We had debated internally whether it was really worth the time for us to add a physical sky model, since our perception has been that while quick & easy, sky simulation has often been one of the more identifiably-CG aspects of renderings, and that production has moved toward heavier reliance on HDRI in most cases. So your use case is interesting — and thankfully we do not need to choose, as we have indeed been working (are working, presently) on adding a nice physical sky & sun environment.

    On materials, that is a much deeper question. It almost sounds to me like there would be a place in your workflow for a dedicated tool for translating materials, in an automated way, and not necessarily using functions actually inside the plugin.

    Of course a plugin must provide integrated ways of working directly with bella materials, and for translating native materials to bella, but plugin-based functions for dealing with external materials can often be obscure, fiddly, out-of-the-way types of affairs (i.e. click button X in toolbar Y to bring up the weird interface for this seldom-used function), when given what you say, it may be more interesting to look into having a dedicated and efficient standalone tool for converting or generating entire libraries of materials, which are subsequently used as-is from within the actual modeling environment.

    Regarding mxm specifically, since it is a proprietary binary format, the best we could do would be a python script that a licensed maxwell user would be able to run in their copy of pymaxwell. However, something like that could be integrated into a standalone tool like I mention above.

    All that said, though I am still designing the way that we will reference external bella materials (i.e. there is not currently support for it), we start from a good place with the bella .bsz format, which bundles a bella file with any resources it uses. Furthermore, a bella “material” file will really just be a bella file, so it will also be possible to support having more than one material in a file, or have a file that contains some geometry along with its materials, and so forth.

    Oscar CanoOscar Cano

    Hi Nils. Welcome! Nothing to add to Jeremy words, I just wanted to say thank you for the detailed explanation. Love the renders on your site.


    Hi guys, thank you for taking the time to answer! I know u must have busy hours!

    As for materials:
    Yes a script or plug-in able to convert existing MR library of course would be a tremendous plus, for so many hours have been invested in getting all arroway + mods + own materials that it is difficult for me to envision switching to another engine if I cannot recover that work… It is however as Jeremy stated not needed in the SU plugin or for embeded use in the worflow.

    The idea with our conception of 3D work is > output an image that requires almost no photoshop, appart maybe for landscape tailoring ( grass, flowers, plants…)
    This means all the materials are supposed to be already set in our library and require only texture positionning in SU depending on the project, with sometimes a need to modify a texture base color ( aka orange concrete from arroway base color). Having a workflow that would make it easy to just identify the d layer ( in the example of arroway again), open it in any image editor ( affinity, pshop…) and save it as new image and automatically create the new Bella material as well as its SU counterpart ( the auto mxm feature is a good idea…)
    Not sure my explainations make sense, but the most time consuming part of the worflow in SU / MR production is the materials creation / modifications. The second beeing the HDRI positionning which is such a pita that you often end up doing it in pshop in postprod..

    On how to apply materials >I was very disturbed with the move to MR (2.0) when the materials changed and any given SU material ( name) would benefit from a MR material characteristic, meaning one name > one type of material whatever the object is..this proved long to understand and has limitations, for examples emitters.
    In our simple dummies workflow, we would use SU light yellows ( yellow01 – yellow02 etc…) from SU materials and apply them to each different lights ( simple faces on the ceiling or in recessed objects) and then with MR plug in say this 01 color = that emitter color/ power etc…( has anyone used IES files? I doubt it appart from crazy rocket science geeks).. this combined with multilight offers great simple result. Maybe Bella will come out with another way of dealing with how materials are applied / control to SU materials..?

    Anyway this is very exciting! Can’t wait!
    As I said, our images are not “world class renders” because in the everyday workflow we do not need such artistic real life images and we outsource those when needed…
    Simple images we use for clients / internal decision making can be seen in those simple projects
    here town house/garage
    small school restaurant ( images at bottom ) winning project in a competition
    metal house: simple images at bottom showing that just light and small reflects create architecture
    bottom images that were used for convincing client ( worked :))

    Jeremy HillJeremy Hill

    In general, you should find materials in bella to be simpler to create and use. The core material types are simpler and more elegant to begin with; however, they are abstract, so we are also adding various “semantic” material types, which encapsulate high-level concepts (plastic, glass, etc) with the minimum number of parameters exposed to provide necessary control.

    This will help a great deal with conversion, since it becomes possible for you to express that a given collection of third-party materials should be interpreted as a certain type — that is to say, where it is remarkably difficult to take an arbitrary collection of parameters from a given material, and analyze them to find whether they should represent a plastic/glass/etc, it becomes a much more dependable process, when you are able to say “I consider these to be plastic, so see what you can do.”

    Regarding assignment, though it is a given that a plugin must integrate with the host-application’s approach for managing material assignment, I think that your desired workflow can easily be accommodated using a spreadsheet approach. Just thinking out loud, but this could be something quite interesting to support in the bella scene itself (i.e. a node containing associations between materials, and either other materials, or external files), since it would allow swapping material setups without reassigning anything.


    ok…well haven’t really understood how this is gonna work 🙂 as for the materials but for sure architecture needs preset real life materials that usually need no tweaking after they are created for good, those materials are most of the time materials requiring a texture and a bump at least. For all plastics and metals that are used in architecture, plastic is often used with a variety of layer effects ( aka ral color gallery for metal use ( panels, windows frames etc..)

    Regarding assignement, I was refering to the existing workflow that is currently a workaround that finds limits pretty quick > one of the easy way for us to work was to write freehand on a sheet the list of all Su bare colors that were given MR materials properties, and once we know which group of objects are using it, you simply reasign a material characteristic to that SU color for it to change everywhere on objects that would use it. Not very transparent process ( if you forget to write down where is which, you loose count and after a while have no more clue on what object is Su color XY…) There surely has to be easier ways :).

    Jeremy HillJeremy Hill

    Well, I am going to carefully read what you’ve written a few more times and do some thinking; I’m sure we can come up with something that works slick 🙂

    Albert MartinezAlbert Martinez

    Hi Nils! Thanks for your valuable information, we will be improving Bella with the experience that you all share in our mind to make Bella fitting to the workflow and user productivity as much as we can.


    Thnx Jeremy and Albert and Oscar!
    Indeed the difficulty for you is that you have different type of users..some that spend lot of time creating or refining materials for their images that are so realistic that u can not know if it is a 3D or a photography..Those are not likely to use Sketchup…
    Sketchup users are like the software > they look for simple workflow, not rocketscience material settings (unless they need /want to) and require almost and click and compute kind of 3D process. This is why architects will likely use arroway materials that are almost ready to go and plug in like skatter / laubwerk for plants and a few HDRI from Peter Guthrie 🙂

Viewing 9 posts - 1 through 9 (of 9 total)
  • You must be logged in to reply to this topic.