[Bf-committers] BGE: Removing Singletexture Mode
Brecht Van Lommel
brechtvanlommel at pandora.be
Wed Sep 11 21:04:49 CEST 2013
I'm happy to see old cruft removed, but automatic conversion is
unlikely to be totally smooth. So if we are going to put game engine
users through this compatibility breaking again, it may be good to
consider the bigger picture too?
What is the ideal material system that you would work towards? With
fixed function being deprecated in OpenGL, where does that leave
Multitexture? Currently all 3 modes have issues:
+ Visible in 3D viewport
- Too simple for good materials
+ More flexible than single texture
- Not visible in the 3D viewport when editing
- Strange interpretation of material options
- Fixed function is being deprecated in OpenGL
+ Most flexible
+ Visible in 3D viewport
o Designed to match blender render exactly
- Performance quite poor because of that
- Shaders not dynamic (limited parameter animation and number of lights)
Anyway, maybe no one has time to undertake a big redesign here, but it
may be interesting to think about.
My other question is, what does deprecating single texture in 2.69
mean? Does that involve any code changes, or just a mention in the
release notes that it will be removed in a future version?
On Wed, Sep 11, 2013 at 8:03 AM, Mitchell Stokes <mogurijin at gmail.com> wrote:
> Hello devs,
> Based on feedback from a BA thread, I would like to start working on
> removing the Singletexture material mode. By removing Singletexture, we can
> focus on making Multitexture a fixed-function material mode and GLSL a
> shader-only material mode. I would like to deprecate Singletexture in 2.69
> and remove it in 2.70. Ideally, we should be able to get blend files using
> Singletexture to convert smoothly over to Multitexture.
> The biggest benefit of removing Singletexture is we get to cleanup some
> code. For example, KX_PolygonMaterial can be completely removed since
> KX_BlenderMaterial handles both Mutlitexture and GLSL material modes. We
> can also remove some checks for if we're using KX_BlenderMaterial, since
> KX_BlenderMaterial will be the only remaining concrete implementation of
> RAS_IPolygonMaterial. Furthermore, we'd no longer need this
> IndexPrimatives/IndexPrimativesMulti mess in the rasterizer code.
> The feedback from BA was mostly users, so I'd like to get some devs'
> opinions on this as well. Any feedback would be appreciated.
> Mitchell Stokes
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers