From BlenderWiki
100.0%Abstract
Tex Face is part of Blender original design 15 years ago. The functionality it brought to the Blender Game Engine is still useful nowadays. However its design hasn't changed and it lacks integration with other parts of Blender.
This proposal is centered on moving the working functionalities as sub-options for the Material and remove deprecated ones.
Disadvantages
or why users may complain There are two arguments against this proposal that I expose here for the sake of an open dialog:
- The TexFace Shading mode will be working as before (eventually renamed SingleTexture mode?). The difference is that now you will need to create a material if you want to set any option from the old TexFace.
** old del** There is no possible way to handle backward compatibility.The implementation of backward compatibility can be too cumbersome. See details. it may be better to drop it. In other words any old file that was relying on TexFace options different than the default ones would have to be manually updated. This would include making copy of your materials to set different options for different parts of your Mesh.- update: Backward compatibilty has to done in two steps sometimes See details.
General Design
TexFace Options
Tex, Tiles, Light, Invisible, Collision, Shared, Twoside, ObColor, Halo, Billboard, Shadow, Text, Sort, Opaque, Add, Alpha, Clip Alpha
|
Obsolete options
ObColor - it's not been used in the BGE drawing code. If you have any sample that uses it please send me. Looking at the code and testing with files revealed to me that it's obsolete.
Shared - it's not been used in the BGE drawing code. It's been used for Vertex Painting instead. The check is:
if(shared_color or not in paintmask mode) ...
I would like to hear from people that uses it, but it seems to me that simply checking for the paintmask mode will be fine. This feature was used to blend vertex colors across connected faces. If we get rid of Shared we will have to include the faces we want to "share" in the paintmask. For there will be no way to have them shared automatically (as one could with the TexFace option)
for the records, the actual code for that is in pain_vertex.c:
if ((tface && tface->mode & TF_SHAREDCOL) || (me->editflag & ME_EDIT_PAINT_MASK)==0) {
New User Interface
Material Panel
New Game Option sub-panel only available in the Game Engine render mode
|
Game Options
New Panel
|
Game Options
Blend Mode
old: Transp (Opaque, Add, Alpha, Clip Alpha), Sort
new: Blend Mode (enum: Add, Alpha Blend, Alpha Clip, Alpha Sort, Opaque)
Opaque is the default
Face Orientation
old: Halo, Billboard, Shadow
new: Face Orientation (enum: Billboard, Halo, Normal, Shadow)
Normal is the default
Isolated Options
old: Two-sided, Text
new: individual booleans as before
Physics
Existent Panel - adding a new boolean
|
Physics
old: Collision
new: boolean in the Panel header to whether use or not use the Physics options (friction, force, ...)
Shading
Existent Panel - not changing anything
|
Shading
old: Light
new: to use the Shadeless option already existent as the only factor to determine whether a face gets lid.
Related topics
Tiles - currently available in the UV-Editor this option may stay for good, to be moved to Image Layer in the future (see next topic).
UV Layer - the current TexFace options are a subset of a UV Layer struct. It's organized like:
UV | Image Layer | Game
With this proposal the game part will become obsolete. It can also be a good time to remove ImageLayer from there. Keep in mind that this is a separated discussion and doesn't affect this proposal in any way. It was brought to me by Campbell Barton while discussing those ideas.
Implementation Design
As a way to avoid code-refactoring (which can be welcomed eventually but not now) the idea is to move the options to the Object Material and use the same internal code in the BGE render. Ideally that would mean to change only the UI, the DNA, RNA and the Converter. However in some places in the Converter the whole mesh is passed along with the old options on it.
That will require more attention, in a case-per case basis. Nevertheless I stand that the less we change it the better.
If an object needs different settings for the same Mesh (as one can achieve with TexFace) you can set multiple materials for it.
The Blender Game Engine already splits Blender Material into their own materials - more details here.
That means that internally BGE always dealt with faces with different TexFace settings as if they had independent materials. Now we will be exposing this to the user.
Backward Compatibility Implementation
Whenever a new file is open we try to convert all the materials following the rules: 1) not change the render result (options such as shadeless is not touched, nor new materials are created). 2) the material has no conflict (all the meshes/faces assigned to it share the same texface flags).
If there are still materials (or faces with no materials) that require further conversion a warning in the console will indicate to use the Convert Option in the Help menu. If the user access it it then will convert all the materials, including creating new materials when needed.
Backward Compatibility Issue/Solution
I originally thought that Blender had a limit in the number of material slots of an object. Apparently it doesn't so I reconsidered the original statement. Backward compatible is possible indeed. However it may make your file hard to manage. How I see this being implemented:
Case 1: Mesh has no material and no UV was ever created
This is what one would expect from a file ready to render. In this case there is nothing to be done. No new material will be created. Perfect scenario. But why do you have a mesh with no material and no UV? :)
Case 2: Mesh has no material and TFace options are the default
Similar with the Case 1 we don't have to create a material here. We do have to loop over the Mesh to make sure of that, but well that's life.
Case 3: Mesh has no material and different combinations of TFace options
In this case we would have to create the materials: no_material_collision, no_material_collision_text, no_material_collision_add, ... (or let's say no_material_1, no_material_2, no_material_3, ...)
In the worse scenario that would produce around 319 combinations! I may be wrong in the math here, but I'm afraid I'm correct. {{Note|320 = (2 ^ 4 * 5 * 4 - 1) |(2^4=16 means 4 boolean options, 5 the options of the first enum and 4 of the second one. -1 is to discount the default option which falls into Case 2)}
Is it possible? Yes. Desirable? I'm not so sure. It seems that it can easily get out of hand here. Let's see the next case.
Case 4: Mesh has a material and no UV was ever created or using default options
Same thing as Case 1 and Case 2, no need to do anything. Render files may falls into that category so we are good to go.
Case 5: Mesh has a material and one single TexFace != default is being used
Now things start to get complicated. If there is another Mesh using the same Material we need to make sure they both share the same TexFace settings. If they do we have to take this material and convert it (add on its panel the old TexFace option). Otherwise we have to similiar with Case 3 and create my_material_collision, my_material_text, ... again we are talking about more than 300 combinations here so we may want to go with numbers?
Case 6: Mesh has a material and different combinations of TFace options
Same as the Case 5.
Conclusion
It seems doable for sure, but I'm not sure is something we want to do automatically. One alternative I thought would be to keep the structs in the Blender DNA, the old TexFace properties in the RNA and create a Python script that can handle that for the user (as an addon On by default). Or maybe one option in the FileManager to open/append old files and convert the properties the TexFace. For Linking I think it should be handle on each file individually.
How you can help
How it's been done so far
The original design for this changes was made by Mike Pan and me (Dalai Felinto) in some informal rantings over lunch with a sketchbook and a screenshot of the 2.49 TexFace panel. After that artist and developer Vitor Balbio decided to give this a try and helped rethinking some of the UI options.
Now that the UI is done he is trying to implement the new options while I'm coaching him in some BGE specifies and general help.
UI Design
The design and ideas here are not set in stone. Feedback and discussions (here or in the bf-committers mailing list) are necessary.
Support the Idea, or Not :)
As any core change in workflow bringing backward compatibilities issues I expect to see some adverse opinions on those ideas. I would like to hear sincere opinions on whether or not this change is worth. Take in mind that this is not something I'm proposing as a coder only, but specially as a BGE user. The design and presented ideas tries to address both perspectives.
Get your Hands Dirty
That said, I'm currently pretty busy with other projects, therefore I have no plans to actually do hardcore coding on this. If you think you have the time and energy to help on this and want to join Vitor to work on this together that would be great. I'm committed to code design, code review and general assistance.
If you are a code developer really willing to take over this feature please let me know. It would be nice to coordinate efforts together.
Contact and Further Discussions
I would rather if the ideas could be discussed in the bf-committers mailing list.
With the code structured and the design in the right foot I will likely post on BlenderArtists to gather fresh users opinion on that as well (a pole maybe).
February 2011 Dalai Felinto
