Assign normal map per material - Sketchup

Please note: Should you experience issues with Enscape or your subscription, and in case of any urgent inquiries/questions (e.g. regarding our upcoming licensing changes) please reach out to our dedicated support team via the Help Center or Support button as detailed here.
  • I'm wishing for a simple tool in the toolbar, perhaps just a letter "N" that will call an eye dropper. That eye dropper will let you sample a material and open a browser to link a normal map to that material. An additional slider to control the normal intensity would be a plus. Even if this is an intermediary solution until the material tools are further refined.....I find it necessary to accurately show things like stone in Enscape.

  • That would be incredibly beneficial to my workflow as well! I'm used to having full control over materials since I use V-Ray mainly, but having the ability to grab a normal map would be awesome! Or if possible, having the ability to use Substance materials would be great too.

  • scottofazphx You don't have this ability in the Revit plug-in, Revit materials just have more details including mentioned maps and Enscape is capable of reading and displaying these information.

    SketchUp unfortunately does not deliver any of these material information.

  • Yes Sketchup. I say normal maps for now, because at least we can control the reflectivity somewhat with naming conventions, whereas we have zero bump / height displayed in Sketchup at all. Obviously specular / reflection map support to mask the gloss would be a plus, but not having it doesn't detract from selling materials in a job...just detracts from selling realism. Having super flat stone or brick materials does detract from selling their role in a project.

    I understand that you are relying on the host software to have a material system in place. Hopefully there is a workaround for Sketchup as it will never have a material system that deals with more than just the diffuse.

  • When we had to develop the 3.4 material Editor, it was brutal. It's like re-inventing the wheel, especially with a legacy product like V-Ray that has all the bells and whistles since its a "high end" rendering solution, and to be honest, you don't need 80% of it. I'm still trying to sell my partner on using it for some new projects as a fast way to VR, but with out at least some material control, its tough. That's why I think if you guys supported a substance material, it wouuld be Ideal. Then as a high end user I can create custom materials, and as an entry level user, I can get pre-made materials or use something like Substance B2M to put together quick materials to load into my scene.

  • Substance support would be phenomenal. The subscription is reasonable for designer, painter and b2m. However, it's taken me quite a while to learn, especially designer which I'm still chipping away at. I'm not sure your average user would want to make that leap from the "hands off" material control currently in Enscape to something that is quite complicated. A simplified PBR approach would be great though.

    The best solution, IMO, is something that falls in line with the ease of use already in Enscape, but yet gives a little more control for the high end users.

    I wouldn't be opposed to a built in B2M type tech which would convert diffuse maps behind the scenes, automatically generating render maps and just allowing users to control the intensity on the surface. 99% of the normal maps I create for realtime software are created in one click (I use ShaderMap) with only the intensity adjusted. Vray has VRBumpMtl which automatically converts diffuse to bump and the Corona daily build also has an automatic bump generator. Both are very useful for pre-viz.

    I'm just frustrated with the presentation of stone materials. For instance the scene below. The stone texture doesn't look awful in daylight, but when you throw the lighting in the mix, it looks terrible.

  • i really, really miss some control over materials as well. as i have said before, Enscape has potential to create some stunning renders! but without control over bump/normal and Specular (for starters), it will never be realistic enough to use as final images.
    When a better material system is in place, I expect it to replace Maxwell/vray for most of the work i do daily. I think You could tap in to a really big costumer group when it is done...

  • i really, really miss some control over materials as well. as i have said before, Enscape has potential to create some stunning renders! but without control over bump/normal and Specular (for starters), it will never be realistic enough to use as final images.
    When a better material system is in place, I expect it to replace Maxwell/vray for most of the work i do daily. I think You could tap in to a really big costumer group when it is done...

    I agree, it's so close to being my all around renderer but without the maps I'm stuck in the revit version to get them and in revit I can't get the content. Figure out the maps for sketchup and thea, Maxwell, vray, and corona would not be needed.

  • While I love the idea of a super easy, quick and intuitive material system, there is a finite time to code such a thing. I would be more than happy with the ability to hack together something based on the tools that sketchup does allow.


    Since enscape is pulling material and texture data directly from the sketchup scene, we could embed multiple sub-materials containing the maps we are looking to use, such as brick, brick-bump, brick-normal, brick-displacement, brick-reflection, brick-glossiness, each as a separate material. If Enscape finds one of the sub-materials provided, it would use these to add these additional parameters to the master material it builds. Would probably be best to choose a very unique identifier for the naming structure.


    A sub-material's name can also indicate the strength of whatever map or parameter we are supplying. For example, the name"brick-bump-25"would mean 25% strength bump. If we want to supply only a value, we create a material with a name such as "brick-reflection-25", or "brick-glossiness-33"


    The other cool thing about breaking it down like this is it could theoretically give Sketchup/Enscape the ability to do separate scaling for each texture . Not sure if Enscape can handled this info, but this method would provide it. For example, "brick-glossiness-33" material could have a texture with a size of 10' x 10', whereas the main "brick" material texture might be sized at 5'x5'. There are many times when the ability to add a different sized submap can help to disguise tiling.

  • besides what you are requesting the texture is low resolution and it's not seamless.

    Check https://www.poliigon.com/home

    I am aware. It's a specific cultured veneer product which needs to be shown. Unfortunately the manufacturer doesn't provide seamless textures so I had to hack the texture together from 3 or 4 small section photos sent by the client. It is seamless and tiles well from a distance at 2K res. You are just seeing some clone stamp errors from my running out of patience.

  • I'm trying to learn Substance designer for those cases where you need a specific texture and nothing meets your needs.

    I am also. It depends on the job, the turn around time and the budget.....which dictates a lot of the end product. High budget projects aren't typically done in Enscape unless it's previz. At least for me. Manufactured stone products are big here in the US. It's tough as they vary greatly by region. If it's a local product, I can go out with my dslr and take the photos I need to make a good high res texture, but if it's a remote job on the other side of the country, I end up relying on my clients...and they have not concept of texture making.

  • There are lots of technical solutions for supporting bump maps, but all have their drawbacks. Believe me, I did spend a lot of thoughts on this feature request, but could not come up with a simple solution. Here are some of the problems:

    1. You don't want your material names to contain too much technical data. There is always the possiblilty to misinterpret something.
    2. You don't want the bump-maps to be bound by name to the rest of the material. This does not allow a simple renaming of materials.
    3. You have to be resistent against purging. (Model Info / Purge Unused) On the other hand the bumps should be cleared if they really are unused.
    4. You might want to share a bump map between several materials without needing the disk space several times.
    5. SketchUp users are accustomed to have their textures embedded in the skp file. This makes sharing the model so much easier. Only pointing to some file on the disk is not optimal. You send the file to your colleague and they see the normal material, but without the bump map.
    6. SketchUp materials do not have a persistent ID and can only be referenced by name - which can change.

    These are just the problems coming to my mind right now. I'm sure there are more. For a good solution we would have to provide a fully featured material editor - and that is a lot of work. And also a bit against our philisophy to have a good render with a single click. This does not mean that we will never do it, but it will take it's time.

  • What if you control it with group (or component) names instead of material names? The user would draw out faces to support the maps and keep them in scene, off camera somewhere. This would prevent them from being purged. You could have a main outer group with the material name and some suffix to signal that it contains the render maps. You could then have 2 or 3 subgroups which contain a single face supporting the applicable texture maps.

    It would be easy enough to build a quick template to plug the maps into. The user could organize the "map groups" off camera as they wish. Taking further, they could then be saved as components and quickly loaded for future projects.

  • What if you control it with group (or component) names instead of material names? The user would draw out faces to support the maps and keep them in scene, off camera somewhere. This would prevent them from being purged. You could have a main outer group with the material name and some suffix to signal that it contains the render maps. You could then have 2 or 3 subgroups which contain a single face supporting the applicable texture maps.

    It would be easy enough to build a quick template to plug the maps into. The user could organize the "map groups" off camera as they wish. Taking further, they could then be saved as components and quickly loaded for future projects.

    This actually feels overly complex on the user side.

  • This actually feels overly complex on the user side.

    From what I gathered from Simon's post, the biggest issue was the texture maps somehow being present in the scene and the naming convention issues. If the user creating the texture swatches is too complicated, then it could be easily automated. Perhaps sampling a material and having the texture input component (swatches) created automatically with the name of the material or whatever other variables Enscape would need to read the maps.

  • Simon,


    Totally get that you guys have obviously gone over this at length. I am hoping to make sure that a possible path of least resistance toward better material adjustments is not overlooked as unacceptable to users.


    I believe toward that goal it would be helpful to break down what material adjustments we consider essential and what minimum interface that would be acceptable.


    Essential would be basic adjustments to reflection, specularity, transparency, ior. These are essential because right now there are certain scenes which are simply not usable without them. They are also essential because +90% of materials make use and benefit from these settings.


    Next would be additional maps such as Bump, Normal, Specular, etc. These are lower in my opinion because a much smaller percent of users even take advantage of thes. Also for most materials in a typical archviz scene they are not required to make a good image.


    As it relates to interface, the naming convention does pose issues with naming conflicts. Another possible solution with even more potential would be an external xml file. The xml approach could rely on creating each material entry with the name of one material in our scene. Within that entry we add all the parameters needed. You guys would provide us with the template we need to follow for the xml.


    Assuming you can make this type of system adjust in realtime (enscape refreshes the settings upon save of the xml file) this could actually be far more productive than requiring setting be input within the sketchup interface. For example we could simply copy and paste entire material setups, quickly swap out material / filenames, swap out material versions just by replacing renaming the xml file, etc, etc.


    To make it approachable for newbies, you could implement all your prebuilt material such as copper, plastic, etc within the xml file, and users could use this as a jumping off point in beginning their adjustments.


    Also, if going a route like this would indeed be faster for development, it does not need to be looked at as the only solution... if you implemented something like this prior to, or even alongside an integrated material editor I believe many users would find it useful.


    For an example of how two approaches would be useful..... you mention preferring to have textures embedded in a file. I am of the opposite mindset. This leads to bloat when saving incrementally and needing to update multiple files if a texture changes. It would be ideal to be able to choose either method.


    Chris