what about “quarantining” the old code, and having placeholders,
so “mutlitexture” is a small addon/patch?
In fact since version 2.0 OpenGL ES ( Android, Ouya and so on… ) don’t have anymore a fixed pipeline just a programmable pipeline with GLSL (OpenGL ES Shading Language).
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.
It’s not like “give up your 2 years hardware”, we are talking about 10 years hardware! We’re talking about Geforce 4 and Radeon HD 1.xxx before it was AMD… Again, we’re not talking about office work, it’s computer graphics.
Blender will drop WinXP support soon, so the oldest SO will be Vista that is native DX10 ( OpenGL 3.x similar )! Viewport FX GSoC is in the way to be OpenGL 3.3… There’s no arguments to keep it in BGE against the rest of the blender code. Mostly if it’s adding so many layers of complexity to improve and maintain the already messy BGE’s code. If you guys want a better Game Engine drop Multitexture would be a great start.
If we had more manpower, we could possibly keep it.
I think game engines, compared to other types of programs, are a bit different when it comes to development. There is the whole graphics versus gameplay debate, but the underlying driver remains - game engines generally aim to push the limits of graphical fidelity and bring us closer to reality. That is what most of the popular game engines do and brings them development (i.e. money).
What is the goal of the BGE? Do we envision it to be competitive with Unity and others? (Yes, the BGE is the underdog but it still offers something unique). In order to do that, the BGE has to become more visible and have commercial development/interest, more or less, so it can be developed further. Originally, the BGE was a prototyping tool but at some point its goal became a game engine platform (but Ton felt it failed at this and should now be recycled into an “interactive tool”).
I see two different BGE crowds - those that use it for gaming purposes in the sense of video games and those that use it for interactive purposes like in educational settings or for demonstrations. Most of the former want to deprecate multitexture mode and most of the latter want to keep it since their hardware is limited.
Dare I say, keeping the BGE as a niche game engine, aka interactive tool, will keep it mediocre. Another way of thinking about this is if schools can’t even afford to upgrade their hardware, how can they contribute any development back in the form of coding. Of course, bug reports are needed, but pointless without developers to fix them.
Perhaps, Ton is partly right. The BGE needs to be broken up into an interactive tool and a game platform. At this point, it simply cannot do both well without compromising on one or the other. I guess this is the downside of its genericness.
So, what about “ripping” out the game engine, as it’s own code block, and allowing the selection of game engines to import?
People could then add direct build and play for ue4, and Quake3 etc.
Core Bge- could continue development,
MultiTexture could even grab low hanging fruit from BGE -“Core”
I want the bge to be faster graphically, and if there are “if” forks in EVERY draw operation, it might slow down things a bit,
also if openGL 3.3 is required soon for the viewport does that not make this a no brain decision?
I wasn’t aware of the Windows XP crashes, but in the jump from 2.45 to 2.59, we got a lot too. All forms of GLSL shaders (built-in and custom), soft body physics (I think?), a revised Python API, spotlight shadows, orthographic sun shadows…
I feel like it was definitely worth it, looking over the differences. Of course, if you don’t use GLSL, then there hasn’t been many more additions (but there were still some, like collision groups and level-of-detail).
Yes, but game engines make games, which is one purpose. Graphics cards display graphics, which can be for both playing and creating games. And even if you did get a commercial game license, you still would probably have to update your graphics card. So basically, over time, making 3D games is becoming something that pretty much requires a GLSL-supporting graphics card.
I’m not sure myself about losing support for older platforms that require GLSL-compatible cards, either. I know that a lot of Blender users use GLSL-less cards to make games, or prefer the (what should be) faster MultiTexture mode to GLSL mode. If it results in a cleaner, easier to maintain codebase, though, then it’s a good thing, I think.
Maybe it could be merged, in a way? Drop the “MultiTexture” and “GLSL” differences and make a centralized face class that contains properties either mode could use (i.e. MultiTexture mode uses 50% of the face information, GLSL mode uses the full amount)? But that would be GSoC-level work to pull together, I’d think; it sounds pretty complex.
I think we can all agree that one of Moguri’s goals is to make the BGE source cleaner and more attractive to developers who might want to start writing patches for it, therefore getting a larger ecosystem of devs. and bringing with it regular development of the BGE.
The idea here is that the multitexture mode in its present state is getting in the way of that goal, and I think a lot of would-be developers would like to work with an engine that’s centered around a single modern graphics pipeline like GLSL.
I wasn’t aware of the Windows XP crashes, but in the jump from 2.45 to 2.59, we got a lot too. All forms of GLSL shaders (built-in and custom), soft body physics (I think?), a revised Python API, spotlight shadows, orthographic sun shadows…
Sorry, I should’ve clarified that it was only XP computers with integrated Intel cards that were crashing. We didn’t notice it for a while because all of our XP machines had basic dedicated cards. Unfortunately for us, 90% of our XP customers only had an integrated card because of budgeting issues.
We had similar crashing on Vista/Win7 until we found that the Microsoft Redistributable 2010 SP1 was needed. Maybe we need another redistributable to get XP to work… Can’t find any that work though.
It’s easy to say “tut tut stop using integrated” but I know people are still using them for mainstream games. I had to listen to a guy yesterday that wouldn’t shut up about how well his Surface Pro 2 (has Intel integrated graphics) was handling an MMO. It’s not just education that buys the cheapest they can get their hands on, but they do seem to suffer from it the most.
I will never buy integrated again,
my gpu failed, and it’s on the motherboard, so replace it right?
they don’t make them, and only made 2 years, and they fail consistently
so I could not EVEN buy a motherboard… FROM DELL…
Enough about integrated ranting, but I had to bite the bullet and get a dedicated,
the performance diff is immense,
How do I develop for machines that can’t run what I am doing? should I?
I have been developing looking at whats coming not what is, is this a bad idea?
if someone is making a game, and they are aiming for singletexture etc, does that limit the audience? not that they can’t run the game, but they don’t want a step back,
@BPR:
Consider your competitors. If Wrectified can’t run on todays mainstream computers, but something like Minecraft or World of Warcraft can, then your game needs to be pretty damn amazing. You should aim to be at least as compatible as the other games in your genre.
I think the GLSL implementation uses the same “in-the-way” design as Multitexture. That is the reason why this happens. With a clean separation, you would be able to add new GLSL features/upgrades without even touching multi-texture code.
So I vote for a consolidation of the render-pipeline first. You can focus on the GLSL-Mode, when both are running well, it is the proof the design is good. Just removing multitexture … I’m sure it will not make it more clean as it is now.
I had a short look at the sources. There is a package called RAS_OpenGLRasterizer, why not creating a clean interface to a RAS_GLSLRasterizer and RAS_MultiTextureRasterizer or even RAS_GLSL30Rasterizer? The managing logic would be just a little switch that activates the right package according to the users settings. To ease that there is no need to mix these modes or run them parallel. Getting the rasterizers as add-on would be the golden faucet.
Indeed I haven’t look in that detail, so I can’t tell if that is the right level to separate.
What do you think?
It’s easy to assume that no one uses “10 year old computers” and that any reasonable blender user can use GLSL.
But just read this article to get a sense of how wrong that assumption is:
“Many of the world’s cash machines are still believed to be running Windows XP”
As a private computer user you probably live in a western country and can afford to spend a lot of money on a modern computer and graphics card. Most schools, internet cafes and government offices, even in the western world can’t.
I live in South Korea and work as a teacher, I can tell you now that every computer in my school runs windows XP and has an integrated graphics card. If I was working as an architect or a designer and wanted to show my government customer a walkthrough or visualization, I’d have to go there and bring my expensive laptop (which by the way, had an ATI graphics card, so I had to download unofficial firmware to get GLSL working on it). I couldn’t e-mail it to them or upload it to a cloud storage system. It’d get an angry phone call from them saying that it just didn’t work. “everything is just white”. They’d say and I wouldn’t be invited to submit any more presentations.
South Korea is a reasonably developed country, and in many ways it is very modern, but like all countries, it doesn’t have cash to spare for advanced graphics cards. You say it’s only 50-100$ for a card that can handle GLSL? My expensive GeForce card burned out during the summer and I had to use one of those 50$ cards for a week while I waited for Geforce to replace it (It was less than 2 years old). It could run GLSL, but even a very basic scene was running at about 15 FPS. So the cheap cards are no use at all but even if we say that 15 FPS is OK and set a 50$ price tag, imagine paying that for every computer in a school (giving a very low estimate of 20 computers per school):
20*50 = 1000$
Now multiply that by the number of schools (about 10,000)
10,000 * 1000 = 10,000,000$
Can you see why schools and government institutions still don’t have GLSL compatible cards?
If blender is going to be only about making animations and rendering images for hobbyists in the USA and Europe, then I agree it doesn’t need any legacy rendering mode. If however, it’s going to be a useful tool for educators and other IT workers in the developing world then it absolutely needs to be able to run on “10 year old computers”. How many African schools can you think of that could afford to spend 50-100$ on a dedicated GLSL compatible graphics card?
They can just use blender 2.49 you say? That’s cool but I could also say “why not teach all my students how to use Microsoft Excel 3.0 (1993) in IT class?” (the spreadsheet program I learned in school) Or how about openFX, the program I used before blender? Almost none of the skills I learned using those programs were transferable to more modern systems. There’s almost no support for old versions of Blender, any bugs that exist are unfixable (several educational projects I worked on so far with 2.49 had to be started again from scratch after repeated crash to desktop type failures on the school computers, one the day before a big presentations where the kids parents would be watching). There’s also the question of translations for old versions of Blender. It’s much easier to get a translation done for an “in development” branch of a platform than it is for an old version. If someone started asking about help with making a translation for Blender 2.7 they’d get lots of help and support. If they did the same for Blender 2.49, they’d get ignored.
I was against removing single texture mode, and I’ll still be against removing multitexture. I’m sure it would be much easier to develop Blender if the developers (whom I’m very grateful to by the way, without them Blender would still be as it was back at 1.6 or whatever) could just focus on GLSL. But I’m also sure blender will be much the poorer without legacy support.
No matter how well the code is abstracted out, multitexture will always need maintenance and will have be kept in mind when implementing things, less code rot sets in. When programming a feature, multitexture mode might require a different implementation than GLSL mode.
For example, in the VideoTexture module, when applying a texture you have to check for whether GLSL mode is enabled or not, so you can determine which method to call to access the appropriate material of the object. Yes, the module could use some refactoring but it still provides a simple example.
I’m also curious to know. Whether this technique is used or some other, would it be so much more effort to separate in a way that all obstacles for development are removed? And would it even be possible? Maybe Moguri could answer that.
Edit: just read what Mahalin said, but it’s always good to get more opinions from developers.
I haven’t posted yet here, because I hadn’t decided yet. But now I have. Get rid of multitexture. Gone.
My decision was finally made when I thought about what the removal of Multitexture would do:
- Some hardware will be unsupported
- Performance Issues
The first is obvious, with GLSL requiring (more) modern graphics cards. So who is Blender marketed to: 3D graphics and in this case, Game developers. Both of these people will have updated their computers at least once in the past 5-6 years. So anyone using blender regularly will already have outgrown this issue. With XP support ended, there are very few PC’s around that don’t have GLSL to at least some extent.
The second is also obvious. Many people use multitexture because they can’t get GLSL games to run fast on their computers. This is not a flaw with the game engine at all. This is an issue with how their games are made. Many people do not realize just how much each game is optimized apart from the actual engine itself. When you wander through the latest game, take a minute to think about if the game renders all thousands of lights in the scene at the same time. The answer is of course that it doesn’t. So how can you expect blender to?
If you have rasterizer performance issues on blender, think about what you’re asking it do, and consider if there is a better way, such as using a script to manage which lights exist. Consider using LOD, consider Occluders. Blender is a lower level engine than Unity or Unreal version X. This means these sort of optimizations have to be made yourself. (Though I am not against auto-light-detail management being an engine level thing.
And hence my overall conclusion is that the removal of multitexture will only impact people with poor game design. And as soon as people discover performance issues and ask about them, we can give them some hints as to making them faster.
On a side note: blender is the lightest professional-level modeling program I have come across. Solidworks (which I use at Uni because I have to) is gigabytes and requires immensely powerful computers. Removal of GLSL will only increase these requirements very slightly.
So go for it.
That’s impossible without rewrite almost everything in BGE. First by definition we’re talking about two completely different pipelines. It’s not like we can easily abstract it in a down layer that separate GLSL from Multitexture. Everything is different for all the code, from the Converter until the “Begins/Ends”. If you go for Multitexture you have a completely different code than when you go for GLSL code. In part that is what turn BGE’s code messy cause we need to support both in the same files, in the same code in many cases with two separated functions or using “ifs” to do the same thing. I’m not saying it can’t be done, i’m saying it will not be done cause the work necessary is like rewrite BGE render code from the scratch.
Make applying textures to models in glsl mode easier (like click and drag, including from an external window), rather than having to go through creating a new material and texture, then uv unwrapping it etc. and multitexture will be irrelevant aside from incompatibility with older machines.
Is it possible to get GLSL to work on non-dedicated-GPU systems like Intel HD graphics? If so, go for it. If not… should probably keep multitexture somewhere.
if the processor is part of IvyBridge it will support OpenGL 4.0
if it is Sandy Bridge, it will feature OpenGL 3.1
And if it is Clarkdale it supports OpenGL 2.1
All these have GLSL Support
Yes, but changing GLSL code does not automatically require a change to the multitexture code -> independent implementations
Exactly, this is the purpose of such a separation.
Why does the VideoTexture need to care if the render unit is GLSL or not? It should interface with a render pipeline, not a specific one. With a clean interface this would not matter.
These arguments show that the design is not sufficient. Why are there “if glsl” and “if multitexture” somewhere in the code. Code against an interface. Let the BGE dynamically bind the configured implementation when starting (GLSL or Multitexture). The implementation code does not need to be in one file. It should be in separate files anyway.
This is “just” the render unit. Anything else in the BGE (logic, input, sound, physics etc.) does not care how you render anyway or if you do that at all. With a clean design you could add different render units later. E.g. a render unit that renders to a file rather than a GPU is possible.
Pretty sure using GLSL mode with no materials would be illogical, since you couldn’t take advantage of the material settings. You’d be using something that supports specularity / normal mapping / requires UV map settings and somehow bypassing all of that? I guess you could say that it would have a default, unseen fallback material, but that seems like it could cause problems and make it difficult to deal with in the future (i.e. you forget to apply a material, but things still look somewhat alright).
Maybe a dev could stop by and say their thoughts on this. Is it feasible or even possible to refactor it in Monster’s (good) idea, to have different interfaces for GLSL and MultiTexture? I’m sure nobody wants to lose MultiTexture mode, but only if it’s really unnecessary and dragging down the BGE.
Side effect: BGE user base may shrink further.
Users are ‘Capital’ in case we need to fork one day.