Feedback in new material options (replacement for texface) [committed]

Game Engine Game Engine Support and Discussion
21

Sorry to arrive this late, but I just learnt about this modification when reading the 2.60RC changelog. I have been afraid by the “Texture face properties moved to Material” annoucement, so I have checked the whole wiki.blender.org paper (as well as the bf-committers thread) to estimate if my concerns were justified. And unfortunately, they are…

[Warning: Long post…]

To expose my situation:
I’m working on an import/export Python add-on for a several external formats used in a game. Blender is just used here as a perfect all-purpose 3D editor, the goal is neither to render an image, nor to use the Blender Game Engine. The managed formats (which are beyond my control) are using several per-face settings (boolean properties and materials).
Here comes the trouble. As you know, Blender unfortunately doesn’t support per-face custom properties, and it doesn’t support either Face Groups, or anything like that… The only way to support some per-face settings was to re-use the Texture Face options. I only had to wrote my own panel to give these options another name (more suitable for the end user), and voila. Internally, the settings were saved as TexFace options, but it perfectly fitted the add-on needs when importing / creating from scratch / exporting.
I also have to mention that, as far as this addon is concerned, having ‘use_image’, ‘use_twoside’ and ‘hide’ available as per-face options was just as convenient as can be, since they behave in Blender exactly as they behave in the target game. Not to mention that the result was directly observable in the 3D view using the Blender internal rendering engine only.

The proposed solution of using materials is unfortunately not a decent option here: first, materials are already used by the addon as… materials (ie. steel , wood, etc.). Second, these settings just have to be per-face settings, not per-material settings. Creating a material for each possible combination is definitely out of the question (even though there is no limit in the number of material slots in Blender). For info, I have 28 available materials, and there is 10 per-face boolean options: it makes 28672 possibilities…

To be honest, as far as I’m concerned I don’t really understand the benefit of this modification (getting rid of the Texture Face panel, removing 2 Obsolete options ??), but it’s probably not that surprising as I’m not a BGE user. I also want to make clear that I am not directly questioning the point of your update, seing the others feedback it seems to be a positive modification, so I’m sure it is.

I’m perfectly aware that my complaint may not sound relevant, and that you may say I was using BGE options for a wrong purpose. But I have to point out that having eg. a per-face double-sided option was very convenient if we see Blender as an all-purpose 3D modeling software. Besides being used for the BGE, this option is also likely to be needed to easily add support for any external formats. And still from an all-purpose perspective, a per-material double-sided option doesn’t really make any sense IMO (actually, the tooltip of the ‘Backface Culling’ and the ‘Invisible’ options in the new ‘Game Settings’ panel are mentionning “the face”, not “the material”…).

To conclude about this:

  • It would have been really nice that this modification only occurs once Blender also support per face custom properties. I understand that it’s not really your concern, but at least TexFace was supplying several per face option slots that could be easily reused.
  • IMO, at least the ‘use_twoside/backface_culling’ option should remain available as a per-face setting (and not a per material setting) and rendered in Blender internal rendering engine.

And last, I respect your work and don’t want to sound harsh compared to the involved effort of yours, but at least in my case the loss of the per face settings sounds like a big regression, and I see no suitable workaround (except storing boolean props into the UV texture coordinates, talk about a solution…). I’m just afraid this modification is currently turning Blender 2.60 and subsequent into a dead end for the addon I’m working on (and any format that specifies per face culling).

22

If You create material on the fly when needed all 28672 combinations is probably rarely used. Materials support custom properties so You can save the settings there (even if a clever way to encode the options in the material name probably is more useful).

Per face custom properties would be nice but, still, I hope this change stays.

23

@ji hugen - Sorry to hear that you might lose your work - that’s never good. However, this is, to me, definitely a step in the right direction for the BGE. Just looking at it from a workflow approach - it’s far easier to copy settings between objects that you know share properties (i.e. several two-sided pieces of glass). It was easy to accidentally assign a face a wrong property, and copying settings between faces had to be done via the old Face Properties Copy add-on (it wasn’t built into Blender). Also, it’s more streamlined, and makes more sense - if each face can only have one material and can only have one set of texture face properties, why not combine the two? From the BGE side, it’s an improvement. However, from what you wish to do, it does sound like a step in the wrong direction, so I’m sorry that it might be an issue.

If you notice in the Help menu, there’s an option to convert Texture Face settings to Material Options, too, so be aware that there is some backwards compatibility there.

24

Hi ji hugen, thanks for your feedback.

A few points to help to find a proper solution:

  • I believe ‘use_image’ can be inferred from the face since the face can (1) have a texture assigned to it. (2) be part of a material that uses an image. I’m not sure if the (1) is exposed (I think it’s) but the (2) can already be done.

  • Right now there is no way to support different “3dview” renders based on a custom property. For example if an external engine extend the material panel to incorporate special features we don’t support custom glsl codes to go with it. So unfortunately this is a limitation of our current system as a whole.

  • I would like to understand a bit more how you are/were using ‘use_twoside’ and ‘hide’ in your workflow/engine. As in, why you are setting this per face and not per material/object.

  • “(actually, the tooltip of the ‘Backface Culling’ and the ‘Invisible’ options in the new ‘Game Settings’ panel are mentionning “the face”, not “the material”…).” >> thanks I’ll fix those.

Now I see two similar ways of solving this. Please let me know what you think:

  1. keep the tface flag option exposed in rna (as a short, no longer through the booleans)

  2. use the face flag for your hacks (currently used only for ‘hide’ and ‘smooth/flat’). It will likely require some changes in code to expose ala the old tface. But I can provide you with a test if you think this would solve your problem. In the long run that may not be the best solution if we start to have more options in the mesh …

25

Two other solutions:
(3) You could create a CustomDataLayer (as we have UVs, vertex colors, …) in python and use it for you your custom data. I’m not sure this is supported yet.

(4) We can create a new flag for the faces (not tface) exclusively for this kind of hacks. To re-use the one we had is not so good in my opinion because it’s dependent of “UV-Textures” instead of being directly stored in the mesh face.

26

Thanks for the answer and suggestions… And sorry for another long post.

That’s true, but the number of needed materials will quickly increase anyway, and it’s just inconceivable to let the end user selecting itself the proper material in the complete materials list. So it implies I’ll have to create my own material list and “Assign” button, etc. to hide the trick and keep it convenient for the user. Sounds quite complex, but doable.

Because several faces sharing the same material don’t necessarily share the same set of texture face properties. The proposed solution is to dupplicate the material for each set of properties. And what if we want to modify a setting of this material, like the diffuse color? We’ll also have to update each dupplicated material… It’s not really consistent either. IMO materials are one thing, face properties are another.

@dfelinto
About ‘use_image’, yep, it’s probably not the most important. I used it as it was already there and easy to add in the panel as an operator. But I think I should be able to use the simple ‘image’ property for the same need.

Ok. About ‘use_twoside’, it’s really used it for what it is, ie. most faces are rendered single sided in the game, but it’s still possible to force double sided on a per face basis. I can’t tell exactly how the game manages it internally, but the goal is just to keep the models/world as low poly as possible. When modelling in Blender 2.5x, this settings was only one click away, and the result was directly visible in the regular Blender Render engine (not need to use Blender Game Engine). It was just perfect…
About the ‘hide’ option, I’m only using it to indicate that the face should be included in the collision data but not in the rendered mesh. Once again it was very convenient because the face was actually not rendered in the 3D view (even in Object mode), and it was still independent of the Show/Hide feature in Edit mode.
About materials, there are a set of properties like friction, roughness, etc. that are used by the game physics engine. Most properties are hardcoded in the game, but there is still 4 per face custom properties. For these 4 properties I was simply using the same TexFace trick with another UV Texture.

About the second part of the question, if there was only the double-sided setting involved, I could have dupplicated the list of material and used a per material setting (though it would still be way less convenient than a per face checkbox). But I also have the other 9 per face properties (plus 4 others per face material properties). Here we’re coming down to point discussed with LaH above.

Oh, and about the tooltips, in fact I was rather suggesting that they prove these settings as naturally seen as per face instead of per material settings. :wink:

About your suggested solutions:

  1. I’m afraid I have not clearly understood that point (for example why it should be a short instead of a a boolean), but do you mean keeping the tface flag as dummies? that is to say not actually used for anything, but only as slots?

  2. I don’t know if I have looked at the proper part of the code (after a quick googling), but the flag seems to be a simple char, isn’t it? It wouldn’t allow for enough boolean flags, and as you said it may interfer with any eventual use of this flag.

  3. CustomDataLayer sounded like a perfect solution, as it seems to be a way to add per face custom properties, unfortunately I think it’s toasted (not available from Python). Quoted from this page:
    >> Note that this API does not make it possible for external plugins or python scripts to define their own layer types.

  4. That could be nice actually. We could have for example 32 slots of boolean options available per face for any use… Maybe it would looks a bit like an ill-defined and unfinished per face custom properties support, but I think that would be perfectly enough for me.

To resume a bit, there is in fact 2 clearly separate points here.
a) The loss of the per face slots (using the TexFace trick) while there is still no per face custom properties support in Blender.
b) Leaving the above point aside, the fact that IMO, the ‘use_twoside/backface_culling’ and ‘hide/invisible’ options should rather remains per face setting instead of per material setting. It’s not an issue if they become different options (ie. if TexFace is removed and these options are created elsewhere), as long as they remain available for the user when modeling, and not only bound to the BGE.

In fact, though point a) is currently the more obtrusive hindrance for my addon, thinking for the long run I find point b) to be the most important, since there is hope to see per face custom properties support coming eventually (which would definitely solve point a)), while point b) is directly affecting the potential Blender has of being used as an all-purpose 3D editor.
Now, I don’t know whether backface_culling has become a material setting because you think it’s actually makes more sense, or just because it was easier/cleaner to implement it this way…

27

For invisible faces we need only one material (or at least one per physics setting). So they should not be so much of a problem.

For back culling… If I understand correctly that is just how graphic hardware work - so double sided is really “copy face with inverse normal”. Giving that what’s really clean is to separately assign materials to the front and backside. Then we can get double sided without extra material by just assigning the same material to both sides, and have the useful possibility to assign different material to the different sides. This probably assume “no material” = invisible.

I’m a bit more worried by the physics settings (who been in the materials for ages). If I understand right again the graphic make a render pass for each mesh*material(possible *texture) combination. Allot of passes is expensive - so we really want to merge materials that only differ in physics. BGE created different materials for each texface setting internally before so this patch don’t make it worse. But it might be a clue for some optimization opportunities - that probably should be done at conversion time.

28

To resume a bit, there is in fact 2 clearly separate points here.

a) The loss of the per face slots (using the TexFace trick) while there is still no per face custom properties support in Blender.

The way to go will be CustomDataLayer. It’s already supported but not so straightforward to access.
Have you give it a try? It can be improved, but it’s important to see where this need a push to work for you.

b) Leaving the above point aside, the fact that IMO, the ‘use_twoside/backface_culling’ and ‘hide/invisible’ options should rather remains per face setting instead of per material setting. It’s not an issue if they become different options (ie. if TexFace is removed and these options are created elsewhere), as long as they remain available for the user when modeling, and not only bound to the BGE.

I still miss strong arguments to justify/support that. We have no decent way of manage per face options in Blender (copy, identify them) and that alone was a huge turn off of our previous system.

Aside, internally your gameengine likely deals with them as separated buckets/materials. So why not expose that to the user?
If you think you will often change a setting for all “connected” materials you can use Nodes for that and change the settings (e.g. diffuse color) in a Material Input node.

Now, I don’t know whether backface_culling has become a material setting because you think it’s actually makes more sense, or just because it was easier/cleaner to implement it this way…

The former. From the user perspective, what do you use backface_culling for? Can that be considered a new material? (in my mind the first example I come up with are tree billboards).

29

No, I just can’t, as it seems that custom layers creation is not supported from Python (or have I overlooked something?).

We have no decent way of manage per face options in Blender (copy, identify them).
For info, to remedy this shortcoming, I have added a batch editing feature (ie. a drop-down list for the property and 3 buttons: Select / Set / Unset) for each TexFace property in the Face Properties panel of my addon, so this was not really an issue anymore… Here is a preview:

I still miss strong arguments to justify/support that.
I see, but I’m afraid I can’t really find strong arguments here. It’s rather a matter of what the user is likely to need… For me the need of a per face culling sound pretty obvious for example, but I’m aware I see things mostly through the only game engine I know quite well (which is already a few yers old, btw).
The other users that gave feedback so far do not seem to complain about losing per face settings. I just have no idea though about how they use to employ settings like backface culling, or “hide”…
The other point is also that I think these per face settings are pertinent to keep Blender as versatile as possible (on the other side, I can’t testify that they are actually broadly needed).

Strictly from an end-user point of view, I still can’t see the connection between a material and the backface culling setting. To explain my POV, I mostly see the double-sided setting as a way to fine tune a low-poly mesh. For example, when the modeller decides that some parts don’t need thickness he can use double-sided polygons (eg. for the leaves of a tree, a metal plate, a glass window, etc.). But when he’s sure that the camera will never see the back side of a poly he can set it to single-sided (which is obviously done on a per case basis).
I agree that in some cases, eg. the leaves or the windows, we could bound the double-sided setting to a “leaf” or a “glass” material. But what if we’re sure that a few leaves or windows can only be seen from one side? If we can’t tune this setting on a per face basis anymore, we’ll have to create another material just for these faces. It’s not convenient, and from an end-user point of view it doesn’t really make sense, does it?
Even if that’s how the internal work, I see no real benefit to expose it to the user, it just makes more things to manage while the material split could be done automatically (and internally). It would not be less optimized, but it would be simpler for the user.

And last, if users appreciate to have these settings in Material panel mostly for the management features you mentionned (copy /select /etc.), that could probably also be done from a dedicated Python addon (as with the “Copy Attributes Menu” addon) without using the material panel. I would be ready to help for that if needed.

30

Hmm, 2 weeks and a new Blender release later, and no answer in this topic, I just have very few hopes to see this modification evolve now…

And as far as I can see, it seems to be here to stay. Unfortunately it’s preventing me (and the users of my addon) from upgrading to v2.6, but I can’t imagine sticking with v2.5 forever.
For info, I’ve already faced this dilemma with v2.49. By this time I have happily rewritten my addon from scratch for v2.5 as the evolution sounded promising. But when it was once again close to be done, this new modification arose without a really valid workaround (I’m talking about the 10 per-face slots - per UV texture layer - offered by TexFace, but I could also mention the loss of the very convenient “double-sided” and “hide” per-face settings).

I’d like not to give up this plugin development but my motivation is about to fly away now… With a bunch of extra Python codes to manage dummy materials I think it should be possible to circumvent the loss of the per-face “double-sided” and “hide” settings. But without per-face custom settings, it’s not possible to replace the lost face setting slots.
Now, I don’t think the per-face custom settings support is planned to be added in the near future, isn’t it?

BTW, I’m also surprised that this modification doesn’t bring more feedback (either negative or positive), particularly now that it’s part of the official Blender release. Does it mean that nobody but a few BGE users were using these settings? Or because everyone agree it’s only better now?

31

I personally agree that it’s better, but not everyone’s moved to 2.6 yet. Some people are still using 2.5x. I imagine it would be quite difficult to write a new plugin that would modify the material’s settings, as well as create variables that would need to be exported? It’s just simpler, to me, particularly when you consider that a lot of Texture Face settings were the same across an object, but perhaps with different UV values, or that several objects shared similar settings (e.g. glass in objects were the same). So, it’s more efficient to deal with this. The core functionality seems to still be there, though - perhaps there’s a way to ‘unhide’ the texture panel and run the BGE in a ‘compatibility mode’.

32

Hi Ji Huge, Yes this is here to stay. It’s a pity that the official workaround for your addon is still not supported. It’s approved design-wise though. It only takes a coder to expose the rna functions to create and access the CustomDataLayers.

Now, have you tried using material custom properties? Would that work for you? (I know it’s not optimal for you given that you would need unique materials per combination of ‘texface’ settings).

I was expecting more feedback as well. But honestly not a lot of people know about the texface options. Partially because of the original ‘hidden’ and not as intuitive interface I believe.

33

Is two sided not renamed to backface culling?

34

It’s not likely, as it’s probably better for everyone (ie. users and devs) to remove the old code from the Blender source when a feature is not supported anymore.

As you can imagine, material custom props can’t help me much. I could either use them or simply encode the properties directly in the material name, but in both case it’s not really convenient since what I need is really per-face properties.
The only way I can think of now is to create a new face properties panel and add my own functions in Python to edit the material setting internally each time the user modifies a face property. The Python code would check if the material / face option combination already exists, otherwise another material duplicate would be created using the new face options. But to keep it usable for the end user, I would probably also have to create my own materials list (and management buttons) as the regular Blender material list will likely be filled with hundreds of materials combinations…

I don’t know yet if I’ll ever do it. Anyway, thanks for the anwser.
And I can still hope to see custom face properties finally supported in Blender one day…

35

I noticed that in 2.6, there is no longer possible to change the properties for each face:
seem a good change

all things that are not sufficiently useful,
should be deleted, or at least hidden, or placed in a corner.
otherwise confusing (and slow down the engine)

my opinion, this thing was part of the long list of things “not useful”

I’m sorry for ji hugen , although I think you can work around the problem in some way

36

@Ji Hugen,
It’s already possible to create your own custom data layer:

mesh.layers_int.new(‘CustomLayerName’)
http://www.blender.org/documentation/blender_python_api_2_61_release/bpy.types.Mesh.html#bpy.types.Mesh.layers_int

That should make your exporter possible again.

37

@dfelinto
Yes, I noticed that already when looking at the Nov. 26 Testbuild changelog… It was just quickly mentionned (r41876) but it has directly caught my eye. :wink:
I played with it cursorily in the console to ensure it could actually be used for my need, and it looked very promising.

About my addon, I have already implemented a trick mentionned above, that is to say creating a new Blender material for each new combination of material and face properties supported by the target game. It works, but the code is a bit heavy and the result is slightly less convenient for the end user (who can’t modify anymore the face properties from checkboxes). At least it’s still possible to set per-face Backface Culling as well as Invisble property and see the outcome directly in the 3D view.

Now I could switch to using the new custom data layer for target propeties, it would likely be more efficient, but I’m a bit reluctant… To keep viewing the outcome of per-face Backface Culling and Invisible in the 3D view, I’d still have to use half the previous trick, which makes this solution less appealing.
I have to take a look at material nodes to see if it can be of any help, but I don’t think they can be used to modify eg. the Backface Culling on a per-face basis, based on the value in the custom data layer (without updating the material itself, which is shared among several faces).

Anyway, I appreciate you took time to keep me informed of this feature, thanks Dalai.