Removal of multitexture shouldn’t be an issue for like 95% (just a guess) of blender’s users. 10 year old PCs can already handle glsl. Also, being able to switch from per pixel shading to vertex shading in GLSL would make the 5% (again, that’s just a guess) satisfied.
Remember guys, just because multitexture would be gone, it doesn’t mean people can’t use it if they need to. 2.7.1 is going to be around forever, so people with older machines will still have options. I mean, there are still some people using 2.49 
Valid point. I ended up giving this proposition a YES answer. Yes, Multitexture should be removed from Blender.
I still recommend to implement a clean design that allows both.
You still can fork to a GLSL only version ;).
@ Moguri:
Would such a clean design (a design that clears all issues that now stand in the way of development) be possible? Is so, I would like to reconsider.
Don’t you think that creates a lot more work for the BGE developers? With relatively little gains I think, especially when some kind of Multitexture emulation mode could be devised in pure GLSL.
I agree with removal. Monster when you say fork to a glsl only version are you expecting the only bge dev with commit rights to fork to a separate blender version an then start making improvements outside of the main development line, cause that’s just a very poor idea.
Implementing a clean design that allows both render paths to be improved is easy to say, but who are we expecting to do this? which is clearly a large amount of developer resources to maintain? moguri who only until recently has worked on the bge in his own time for free and is only in a part time position now, which seemed like a position to solidify the plan that’s been set out for the bge moving into the 2.8 series.
+1 for Multitexture removal to facilitate BGE rasterizer clean up
+1 to remove multitexture.
It’s very hard to maintain two pipelines (Fixed and Programmable) for the same code. Example: Some time ago i try to code a way to control the animated texture in C++ core, a simple “setframe” in runtime for python access. I did it for GLSL but i can’t find any way to code it to Multitexture so as i knew this would never see the day light this way i give it up.
GLSL is suppose to work with any computer almost 10 years old, it’s more than a OS can support.If you want to make something for multitexture just stay in Blender 2.7
But i agree that remove multitexture affect all blender (BI) users so is necessary make a good design document to it. Cycles already have just one mode.
+1 For removal. Streamlining is never a bad thing when there are so few developers working on it. If this makes your task easier to optimize the BGE engine it is an easy decision for me.
Everything to make the UI more streamlined.
removal++;
You simply can’t use GLSL without the necessary hardware. Removing multi-texture will make the BGE unusable without GLSL hardware.
I know that it is a lot of work to establish clean design. That is the reason why we have this discussion. This problem will not stop just by limiting the BGE to GLSL. Yes, I know there is no developer who wants to spend his time to do do that.
I thought, that the glsl can do fixed functions if you code a shader to use multitexture?
I thought, that the glsl can do fixed functions if you code a shader to use multitexture?
GLSL is programmable pipeline you can’t use fixed pipeline with it. You can do a “per vertex” shading with GLSL but there’s no point on it. If you enable GLSL you need a hardware that support it ( every computer for the last 10 years support it ).
IMHO if you have such a hardware that don’t have GLSL it’s time to change, we’re talking about Computer Graphic work not Office work.
There are GPU’s available for 50 USD or less that support GLSL graphics, it seems like you’re trying to say we need to continue supporting machines that are from the turn of the 21st century, people with those machines by now are lucky that they can even run Blender and they are having to upgrade anyway because of Microsoft (and the majority of major app vendors) pulling WinXP support.
You can even perhaps get a GPU from Ebay or some secondhand shop that supports GLSL, there’s not really much argument to not switch everything to a purely shader-based pipeline as long as the two points I mentioned early on can be addressed.
I even find agreement with the person saying that multitexture mode may also be getting in the way of what could become some serious GLSL optimizations, so in a way we could inevitably see GLSL become as fast as multitexture (and who knows, perhaps there might even be a per-vertex option on a per-material basis for those who are still nostalgic for that sort of thing).
You can buy a licence for a commercial game engine too. So this - for me - is a very weak argument.
It seems sensible to separate the render code into a legacy rasterizer. It would be a good method for testing the purpose of having interfaces, and still ensure support for multitex. If the issue were with conversion code, that needs addressing anyway.
And a lot of those commercial game engines would either be used via subscription (to the tune of up to 200 USD a year) or by a professional license that costs a lot more. This <50 USD purchase would be a one-time thing and you would even be able to transfer the card to a new machine if you got one (and you wouldn’t need to get a new one very soon afterwards since it’s unlikely that the BGE will frequently pull support for older OpenGL versions). On top of that, a lot of machines mid-range and up nowadays have GLSL support out of the box through at least a low-end GPU.
I know you’re a gameplay over graphics guy, but that argument only goes so far, there’s a lot of people nowadays for example who will not play a lot of indie games because the graphics are nothing more than rectangles on a low resolution screen, and games these days are also using higher quality graphics that are then used to enhance…you guessed it, gameplay.
I just don’t get this strong sentiment against having a highly competent graphics engine, the fact that you mentioned an idea of making a GLSL only fork indicates that you almost seem to be offended by modern game engine concepts such as normal maps, lamp shadows, node materials, and per-pixel lighting. Why is that, because in theory, GLSL should give enough flexibility and power to have native shaders for texFace materials and per-vertex lighting, so it ultimately may mean there’s no real loss here since a lot of your old multitexture projects would not need a lot of graphical conversion work.
GLSL is programmable pipeline you can’t use fixed pipeline with it. You can do a “per vertex” shading with GLSL but there’s no point on it.
I see, thx.
So the Multitexture could be used for mobile or the mobiles(android, ouya…) are already using glsl shaders? If this was a commercial engine, then they would go for the latest development of the graphics api.
We were stung pretty hard when we updated from 2.45 to 2.59. We had to officially stop supporting Windows XP because scene changes are crashing the game.
In a perfect world, I’d love to say to our consumers that they should buy a whole new classroom of computers, but the harsh reality is that they don’t have the budget. They have to make do with that they’ve got, and we’ve got to do the best we can do support them.
We made the change because we needed better support for unicode. What we got was a slower starting game engine, a game engine that can’t be run from network shares anymore, and some weird problems with alpha transparency not ordering correctly. Removing MultiTexture is just another thing that puts me off updating to a higher version of BGE again.
I’m glad to see Monster standing up for supporting older hardware.