Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More ergonomic approach for material setups #56

Open
joepal1976 opened this issue Jul 3, 2019 · 5 comments
Open

More ergonomic approach for material setups #56

joepal1976 opened this issue Jul 3, 2019 · 5 comments
Assignees
Milestone

Comments

@joepal1976
Copy link
Contributor

As we add more features to the material setups, they will become increasingly complex.

Currently we define the entire material in code, with lots of if/else statements and calculations of coordinates and what not.

This is messy. It should be possible to outsource most of the definition to a JSON file and only modify those values in it which needs to be modified, based on the incoming material information.

This way, we should also be able to keep different material setups for different types of meshes, if we for example want to add an enhanced skin material with pores etc.

@joepal1976
Copy link
Contributor Author

There's a working draft in a feature branch https://github.com/makehumancommunity/makehuman-plugin-for-blender/tree/_feature_alternative_node_setup

I have left the old createMHMaterial intact (for now) and implemented a createMHMaterial2 function.

I haven't tested what happens if a material has a bump map yet, but it works as expected with a normal map.

@Cortu
Copy link

Cortu commented Jan 10, 2020

I believe that the biggest problem in sharing Make Human assets is distributing the materials. I wrote some quick code to facilitate this action. It stores a blender material in a .blend file, then loads that material based off a path in a .mhmat file. I've given it some thought and I think it is far superior to json. It allows the artist to easily store the entire material, including packaged texture masks, and should continue to be compatible even as blender develops. It could also potentially be used for the distribution of mesh data such as Edge Creases and Multiresolution Sculpts. The only issues I foresee are the possibility that someone may accidentally package a large unneeded file and the possibility that the Make Human community would not want to exchange files that are only useful to Blender.
Currently I am not familiar with the code. In particular, I might have difficulty passing the path to the material file from Make Human to Blender. If this is something that you are interested in, but don't want to personally integrate it, then let me know and I'll see if I can figure out the code.

def matSave():
    """
    Save the active material on the active object
    to a blend file in the current directory
    named after the objects name.
    """
    import bpy
    obj = bpy.context.active_object
    mat = obj.active_material
    path = '//'+obj.name+'.blend'
    # Probably should be more careful about over writes.
    bpy.data.libraries.write(path, {mat})



def matLoad(fake_user=False):
    """
    Set the active material on the active object
    to a material loaded from a blend file determined by the line
    'blendMaterial = someBlendName.blend/materials/someMaterialName'
    within the file '//Cube.mhmat'.
    """
    
    import bpy
    
    # Need to be able to find this dynamically.
    path = '//Cube.mhmat'
    path = bpy.path.abspath(path)

    with open(path) as text_file:
        for line in text_file:
            if line.startswith('blendMaterial'):
                # Horrible line.
                blendPath, dirName, matName = ( path.strip() for path in line.split('=')[-1].rsplit('/', 2) )
                break
    

    with bpy.data.libraries.load('//'+blendPath, fake_user=fake_user) as (inBasket, outBasket):
        # Weird syntax.
        setattr(outBasket, dirName, [matName])
    
    mat = getattr(outBasket, dirName)[0]
    mat.make_local()
    bpy.context.active_object.active_material = mat

@joepal1976
Copy link
Contributor Author

This isn't a bad idea. On the contrary, I've toyed with the idea of being able to attach an intact blender material somehow.

These approaches (MHMAT/JSON vs blender material) aren't mutually excluding each other though. There is currently no foreseeable scenario in which we could:

  • Display a blender material inside MH
  • Export a (new) blender material from MH

... so we'll obviously still need to work via MHMAT most of the time.

However, bundling an already existing blender material with (for example) clothing pieces, might be an interesting path to investigate.

I'm currently reworking the production of skins and materials via a new tool, MakeSkin, at https://github.com/makehumancommunity/community-plugins-makeskin. This is pre-alpha as of yet, but it might be a proper place to insert code for producing the blender material attachment. Once the library modules are finished there, MPFB will have to be adapted to understand these.

@Cortu
Copy link

Cortu commented Jan 11, 2020

I was thinking the best approach would be MHMAT/BLEND. They would work in parallel. The MHMAT would pass a path to the BLEND to Blender. MakeHuman would never read the BLEND. It would just pass it along without knowing any thing about it at all. MakeHuman would still use the MHMAT for its display.

I've read the code you linked, and I have some concerns as an artist. Were going to need more control. Specifically, at the very least, we will need to be able to provide a texture for the following Principled BSDF inputs;

  • Base Color
  • Subsurface
  • Subsurface Radius
  • Metallic
  • Secular
  • Roughness
  • Transmission
  • Transmission Roughness
  • Emission
  • Alpha
  • Normal

If MakeHuman cannot do at least this much, then there would be no point in making a material file that was meaning full to both MakeHuman and Blender. I at least, would not use it. Also this dose not address edge cases. For instance, I am currently working on an iridescent sequined dress that uses facing for the iridescent. A hard coded file format will never be able to handle unusual cases such as that.

At any rate, may main question was weather or not the MakeHuamn community would be hostile to the idea of passing BLEND files around. I don't particularly want to spend a lot of time working on something to have it rejected out of hand, so I thought I would check first. It sounds like you would least be willing to consider what I'm suggesting, so I'll see if I can figure out how to move forward. Me and the Git have never really gotten along well, but I seem to be able to read your code pretty easily, so I think I can probably make it happen.

@joepal1976
Copy link
Contributor Author

I have nothing against implementing support for attaching blender materials for those cases where the basic material setup won't suffice. Although the default and main track will remain being materials that can be represented visually in MakeHuman.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants