Gamebryo engine was good for performance. Daoc used it. War had good performance about 6 months in when they fixed the engine (i put the earlier bad performance down to ea rushing release, they probably did the same with swtor, I don't think hero itself is at fault) Rift uses gamebryo also.
It's not a simple matter of, this game engine performs well and that one doesn't. Performance of the final game depends very, very heavily on what you do with it. More models on the screen at once, more vertices in each model, and higher resolution textures all bring a performance hit.
It's the horrible netcode. As has been discussed before, BW bought a Beta engine. IDK if Hero has bad netcode intrinsically since I can't say I've played any other Hero engine games, nor have I coded with it. Did anyone play Faxion? AFAIK that's the only other game that used it.
TOR's netcode is awful. Hence the insane lag when more than 10-15 people are in the same place.
It would take extraordinarily bad networking code for its effect on frame rates to amount to anything more than a rounding error. The video card isn't aware of what is going on with networking code, or for that matter, whether there even is networking code as opposed to an offline, single-player game.
Network activity does put a slight load on the processor and system memory, but for online games, it's very slight. It's also in its own thread(s), so other threads aren't tripping over it. We've had gigabit ethernet since 1999, and even that offers perhaps four orders of magnitude more bandwidth than games will use during normal gameplay. Internet bottlenecks that aren't on the client computer won't affect your frame rates.
Whether network code is good or bad is not a property of a game engine. The game engine can have some placeholder network stuff, but the game designers will have to write their own networking code to a large extent. Making network code efficient depends very strongly on how fast characters move and accelerate, how long of range attacks have, how many characters are in the area at once, whether the characters are NPCs or players, and especially how much can be safely computed client-side as opposed to needing to be computed on the server.
It doesnt have any of dx10 and dx11 bells and whistles, its all DX9 and 2007, it should run on any newer hardware. THATS what makes a bad engine.
If it were DirectX 11, would that make poor performance more acceptable? New APIs don't make any effects possible that weren't possible before. Rather, new APIs give you more efficient ways to do things that you could have done before but with a larger performance hit. That dosen't make new effects possible, but it does make new effects practical. Something you could have done before at 2 frames per second, you can now do at 40 frames per second, so you can finally implement it into your game.
I would BECAUSE IT WOULD AT LEAST LOOK GREAT AND RUN POOR, compared to now when it looks like crap and runs very poor.
And yes, DX9 (2007) game SHOULD RUN PERFECTLY ON ANY COMPUTER TODAY even with only integrated video card.
Did you even read and understand the thing you quoted?
The API version is just a tool. If you upgrade from a toolbox with 10 tools in it to one with 15 tools in it, but don't use any of the new tools that weren't also in the old toolbox, would you expect things you build with it to suddenly be better? To the contrary, if you're not going to use the new tools, you might as well just stay with the old toolbox. That also gives you broader compatibility, and no chance for new bugs to crop up in the process of trying to port things back from DirectX 11 to DirectX 9.0c.
There's nothing intrinsic to DirectX 11 that makes it look better than DirectX 9.0c. The newer version does make some new things practical, but how good the graphics look is still up to the game developers.
It doesnt have any of dx10 and dx11 bells and whistles, its all DX9 and 2007, it should run on any newer hardware. THATS what makes a bad engine.
If it were DirectX 11, would that make poor performance more acceptable? New APIs don't make any effects possible that weren't possible before. Rather, new APIs give you more efficient ways to do things that you could have done before but with a larger performance hit. That dosen't make new effects possible, but it does make new effects practical. Something you could have done before at 2 frames per second, you can now do at 40 frames per second, so you can finally implement it into your game.
I would BECAUSE IT WOULD AT LEAST LOOK GREAT AND RUN POOR, compared to now when it looks like crap and runs very poor.
And yes, DX9 (2007) game SHOULD RUN PERFECTLY ON ANY COMPUTER TODAY even with only integrated video card.
Did you even read and understand the thing you quoted?
The API version is just a tool. If you upgrade from a toolbox with 10 tools in it to one with 15 tools in it, but don't use any of the new tools that weren't also in the old toolbox, would you expect things you build with it to suddenly be better? To the contrary, if you're not going to use the new tools, you might as well just stay with the old toolbox. That also gives you broader compatibility, and no chance for new bugs to crop up in the process of trying to port things back from DirectX 11 to DirectX 9.0c.
There's nothing intrinsic to DirectX 11 that makes it look better than DirectX 9.0c. The newer version does make some new things practical, but how good the graphics look is still up to the game developers.
Which comes back to compatibility. Hero does not support SWTOR's version of it's graphics engine, as part of their deal with EA, since EA bought what was available and would "fill in the rest" later (ie alpha versions of Hero).
I would encourage you to try out SWTOR's "F2P" Freemium model , since you are very interested in this subject. At first it will seem very nice, or at least when nobody else is near you, but you will notice the major defects people are talking about once you get to the fleet, level 10'ish.
EA did do a major workaround somewhere between patch 1.1 and 1.2, called "sectioning", in which a map (specifically the fleet) is broken up into smaller regions, each instanced, or in some way separate from adjacent sections. It isn't clear if this was done anywhere else other than the fleet. You can see this feature if you lose connection with the server (forcibly or via game bugs). You will be able to move around while not connected (everyone else stays still of course), and you will observe you are trapped in a square type area with invisible walls. Another workaround EA had was to limit the players on-screen at one time, according to your graphics settings. This is a more recent "fix". There might be 50 people at the mailbox, but a player will see far less.
EA came out with these ideas to make the game more playable, but it's really just tucking all the internal graphics engine issues under the rug. World PVP, for instance, still won't be very enjoyable (low fps) with this engine. If EA could fix the issues, they would have. It's likely they can't because it's way over their head, and/or the people who knew how to make miracles happen have been layed off / forced into retirement / or fired.
But still, if you are interested in furthering your studies and analysis, download and play it.
The API version is just a tool. If you upgrade from a toolbox with 10 tools in it to one with 15 tools in it, but don't use any of the new tools that weren't also in the old toolbox, would you expect things you build with it to suddenly be better? To the contrary, if you're not going to use the new tools, you might as well just stay with the old toolbox. That also gives you broader compatibility, and no chance for new bugs to crop up in the process of trying to port things back from DirectX 11 to DirectX 9.0c.
There's nothing intrinsic to DirectX 11 that makes it look better than DirectX 9.0c. The newer version does make some new things practical, but how good the graphics look is still up to the game developers.
I give up, yeah yeah, youre right, thers absolutely no difference between dx9 and dx11, its all just fluff and some general conspiracy by MS.
It doesnt have any of dx10 and dx11 bells and whistles, its all DX9 and 2007, it should run on any newer hardware. THATS what makes a bad engine.
If it were DirectX 11, would that make poor performance more acceptable? New APIs don't make any effects possible that weren't possible before. Rather, new APIs give you more efficient ways to do things that you could have done before but with a larger performance hit. That dosen't make new effects possible, but it does make new effects practical. Something you could have done before at 2 frames per second, you can now do at 40 frames per second, so you can finally implement it into your game.
I would BECAUSE IT WOULD AT LEAST LOOK GREAT AND RUN POOR, compared to now when it looks like crap and runs very poor.
And yes, DX9 (2007) game SHOULD RUN PERFECTLY ON ANY COMPUTER TODAY even with only integrated video card.
Did you even read and understand the thing you quoted?
The API version is just a tool. If you upgrade from a toolbox with 10 tools in it to one with 15 tools in it, but don't use any of the new tools that weren't also in the old toolbox, would you expect things you build with it to suddenly be better? To the contrary, if you're not going to use the new tools, you might as well just stay with the old toolbox. That also gives you broader compatibility, and no chance for new bugs to crop up in the process of trying to port things back from DirectX 11 to DirectX 9.0c.
There's nothing intrinsic to DirectX 11 that makes it look better than DirectX 9.0c. The newer version does make some new things practical, but how good the graphics look is still up to the game developers.
Which comes back to compatibility. Hero does not support SWTOR's version of it's graphics engine, as part of their deal with EA, since EA bought what was available and would "fill in the rest" later (ie alpha versions of Hero).
I would encourage you to try out SWTOR's "F2P" Freemium model , since you are very interested in this subject. At first it will seem very nice, or at least when nobody else is near you, but you will notice the major defects people are talking about once you get to the fleet, level 10'ish.
EA did do a major workaround somewhere between patch 1.1 and 1.2, called "sectioning", in which a map (specifically the fleet) is broken up into smaller regions, each instanced, or in some way separate from adjacent sections. It isn't clear if this was done anywhere else other than the fleet. You can see this feature if you lose connection with the server (forcibly or via game bugs). You will be able to move around while not connected (everyone else stays still of course), and you will observe you are trapped in a square type area with invisible walls. Another workaround EA had was to limit the players on-screen at one time, according to your graphics settings. This is a more recent "fix". There might be 50 people at the mailbox, but a player will see far less.
EA came out with these ideas to make the game more playable, but it's really just tucking all the internal graphics engine issues under the rug. World PVP, for instance, still won't be very enjoyable (low fps) with this engine. If EA could fix the issues, they would have. It's likely they can't because it's way over their head, and/or the people who knew how to make miracles happen have been layed off / forced into retirement / or fired.
But still, if you are interested in furthering your studies and analysis, download and play it.
You may not realize this, but you're basically saying that EA is using all of the graphics optimization methods that are available. They may or may not be using them well, but there aren't any obvious fixes that they're ignoring. Let's break it down.
1) Not drawing some things on the screen. Every game engine has to do a hefty dose of this unless it's a very, very small game world. Think "Asteroids" small, not "only one zone" small. Probably the simplest is "that's too far away, so we're not going to draw it"--or perhaps rather, not even going to load it into memory until it gets closer.
Sometimes saying, "we're not going to draw that" is more problematic than others. The best time to do it is for things that wouldn't have appeared on the screen anyway. If you can determine that a particular object isn't going to be on the screen that particular frame, then you can just ignore it and move on to the next, rather than passing it on to the rendering thread, which would have to switch to the right program (actually, you can usually get around this one by collating objects that use the same program), texture(s), and vertex data, upload the uniforms, run the vertex shaders, clip each triangle separately, observe that one of the six clipping planes completely killed the entire triangle so that nothing makes it to the pixel shader, and then not draw anything. It's impractical to always determine whether an object will appear on the screen without trying to draw it and see what happens. But if something is way off to the side or behind the camera or whatever, you can detect that and skip it.
But sometimes, there's still too much to draw in a single frame, and that's going to kill your performance. Trying to draw 50 characters at once, each of which is animated and has customized his looks (different textures for all, and likely different vertex data, too) is necessarily a ton of work, and that means a huge performance hit. You can sort and say, we're going to cap the number we draw in a given frame and only draw the closest ones, and sometimes you have to do that in order to get acceptable performance. Yes, it does look bad when nearby characters are disappearing and reappearing, but when there's too much to draw, there aren't always good alternatives.
2) Customizing the game engine. You're making a big deal about how EA started with a beta version of the Hero Engine, then changed it so that it's not the officially supported version anymore. But if they had started with the latest version, they'd still have had to change it so that it's not the officially supported version anymore. Off-the-shelf graphics engines are built to do certain things, and to do them in certain ways. It never exactly coincides with what you want to do in your game.
For that matter, even if the graphics engine was built for your particular game (Hero's Journey, in this case), as you actually build the game, you'll inevitably discover that you need some things you hadn't planned for, and that you're not using some things that you had built in. And if the graphics engine wasn't built specifically for your particular game, you'll probably come up with even more examples of both.
So what do you do about it? You modify the game engine, of course. If you discover that you need the capability to do something that the engine doesn't already support, the best option is to modify the engine to support it. At that point, it's no longer the standard, officially-supported version of the Hero Engine, but that's okay--and necessary, even.
One alternative is to try to cram what you want into the way the engine wants to do things, but this is highly inefficient. It's something akin to eating soup with a fork. The other alternative is to simply not do what you need to do for your game, i.e., chop out features that you were planning on adding. You'll sometimes need to do this anyway as things turn out to be impractical to implement, but you'll have to do a lot more of it if you're not going to customize the game engine.
On the other side, if the game engine supports things that you're not going to use, then you want to cut them out. On the processor side, it's often not that big of a deal if some code goes unused. But pixel shaders need to run hundreds of millions of times per second. If your pixel shader takes a microsecond longer to run than it "should", then you have a big, big problem. (I'm glossing over details of how a graphics card will have many copies of the same pixel shader running simultaneously on different data, but you get the point.) You have to go through it operation by operation (line by line is too coarse here) and make sure that it's as efficient as you can possibly make it. If there's functionality that you're not using and not going to use, then chop it out.
3) Breaking things into zones. This is really just a more efficient way of structuring your data. This doesn't only mean different planets in SWTOR, but also different zones within planets. It's highly probable that the game world is broken into zones in several different ways that are mostly invisible to players--and not necessarily that one subdivision is a refinement of another.
For example, in order to load the entire game into video memory all at once would surely take at least tens of gigabytes of video memory, and likely hundreds of gigabytes. So how does the game engine decide what to load? Well, it loads the stuff that is near you, of course. But how does it decide what is near you? It could check every single object in the game, determine how close you are to it, and then load it if you're close enough. But that would take too long.
Instead, the data is broken into zones that are never drawn on your screen. You're in some particular zone, and several other zones are near enough that the game might conceivably need to load stuff from them. It checks everything in those few zones, but skips the other hundreds or thousands of zones that are too far away. It's much quicker to check a zone once and determine that it's too far away than to loop through every single object in the zone and determine that each particular object is too far away to be loaded.
Or for another example, let's suppose that a mob somewhere in the game world attacks. The server has to determine which players will be informed of this. Informing every player every single time anything in the game world moves is impractical for bandwidth reasons. For the server to cycle through every single player online and check whether they're near enough would work, but would bring an unnecessary performance hit. So it breaks the game world into zones and only checks players in the zone that the mob is in and a few other zones nearby. Some players who are in such zones may still not be notified of the attack, but the idea of zones is that you can very quickly eliminate 99%+ of the players from needing to know, and only do more detailed processing on a few.
And more to the point, the zones for checking what texture and vertex data to load into video memory probably aren't the same zones as for checking which players need to be notified that a mob has attacked. There can be a number of other purposes for which players are divided into zones, too.
4) Drawing objects faster. Ideally, if you can find a way to compute exactly the same finished screen in less time, you do. But there's only so much of this available. Sometimes, you have to ease the load by making it simpler for the video card to draw a given object. This can mean lower resolution textures, and SWTOR famously had a big dust-up over this. It can mean fewer vertices in your models. It can mean reusing programs and textures and vertex data more, so that you can collate things and have to switch data less often. It can mean chopping out some graphical effects entirely, especially computationally expensive things such as shadows.
Ideally, you give players some graphical options to allow them to turn settings up or down themselves. That way, people with the hardware to handle it can get the full graphical effects, while people who don't have it can turn settings down and still make the game playable. But it does sometimes take some additional work to make sure that your code is optimized both for having settings on and having them off, as it doesn't do any good if turning graphical settings off doesn't ease the load on hardware. And, by the way, that's optimization work that you may not be able to do if you're using the standard game engine and not customizing things yourself.
-----
So what's the point of this? Most of the claims of "SWTOR has a bad graphics engine because of X" on this thread are completely spurious. It's like claiming that it's cold today because the sun rises in the east. Maybe it is cold today, and maybe the sun does rise in the east, but it's not cold today because the sun rises in the east.
In particular, that EA customized the game engine rather than using the bog-standard Hero Engine is a good thing, not a bad thing. If they hadn't, then you could claim--correctly--that it was a bad graphics engine for the game because it wasn't customized for the game in question.
Furthermore, optimizations of the sort that you describe aren't "tucking all the internal graphics engine issues under the rug". They're the stuff that graphical improvements are made of.
The thing that you need to understand about 3D graphics is that it's all completely fake. The way that the graphics work internally does not correspond to anything in the real world. It's really just a quest to make something that looks nice and lets the player feel like he can control what is going on, while drawing it as fast as possible. Any movement in that direction constitutes making the graphics engine better, not "tucking things under the rug".
The graphics engine is alright, it's about on par with a game from 2008 or so. The backend engine on the other hand is terrible, HeroEngine wasn't finished when Bioware bought it and shortly after Bioware obtained it, the engine was stated to be designed for free2play games. Things like this makes you go "hmmm....", almost as if Bioware planned this game to go F2P on purpose.
Comments
It would take extraordinarily bad networking code for its effect on frame rates to amount to anything more than a rounding error. The video card isn't aware of what is going on with networking code, or for that matter, whether there even is networking code as opposed to an offline, single-player game.
Network activity does put a slight load on the processor and system memory, but for online games, it's very slight. It's also in its own thread(s), so other threads aren't tripping over it. We've had gigabit ethernet since 1999, and even that offers perhaps four orders of magnitude more bandwidth than games will use during normal gameplay. Internet bottlenecks that aren't on the client computer won't affect your frame rates.
Whether network code is good or bad is not a property of a game engine. The game engine can have some placeholder network stuff, but the game designers will have to write their own networking code to a large extent. Making network code efficient depends very strongly on how fast characters move and accelerate, how long of range attacks have, how many characters are in the area at once, whether the characters are NPCs or players, and especially how much can be safely computed client-side as opposed to needing to be computed on the server.
The API version is just a tool. If you upgrade from a toolbox with 10 tools in it to one with 15 tools in it, but don't use any of the new tools that weren't also in the old toolbox, would you expect things you build with it to suddenly be better? To the contrary, if you're not going to use the new tools, you might as well just stay with the old toolbox. That also gives you broader compatibility, and no chance for new bugs to crop up in the process of trying to port things back from DirectX 11 to DirectX 9.0c.
There's nothing intrinsic to DirectX 11 that makes it look better than DirectX 9.0c. The newer version does make some new things practical, but how good the graphics look is still up to the game developers.
Which comes back to compatibility. Hero does not support SWTOR's version of it's graphics engine, as part of their deal with EA, since EA bought what was available and would "fill in the rest" later (ie alpha versions of Hero).
I would encourage you to try out SWTOR's "F2P" Freemium model , since you are very interested in this subject. At first it will seem very nice, or at least when nobody else is near you, but you will notice the major defects people are talking about once you get to the fleet, level 10'ish.
EA did do a major workaround somewhere between patch 1.1 and 1.2, called "sectioning", in which a map (specifically the fleet) is broken up into smaller regions, each instanced, or in some way separate from adjacent sections. It isn't clear if this was done anywhere else other than the fleet. You can see this feature if you lose connection with the server (forcibly or via game bugs). You will be able to move around while not connected (everyone else stays still of course), and you will observe you are trapped in a square type area with invisible walls. Another workaround EA had was to limit the players on-screen at one time, according to your graphics settings. This is a more recent "fix". There might be 50 people at the mailbox, but a player will see far less.
EA came out with these ideas to make the game more playable, but it's really just tucking all the internal graphics engine issues under the rug. World PVP, for instance, still won't be very enjoyable (low fps) with this engine. If EA could fix the issues, they would have. It's likely they can't because it's way over their head, and/or the people who knew how to make miracles happen have been layed off / forced into retirement / or fired.
But still, if you are interested in furthering your studies and analysis, download and play it.
Want a nice understanding of life? Try Spirit Science: "The Human History"
http://www.youtube.com/watch?v=U8NNHmV3QPw&feature=plcp
Recognize the voice? Yep sounds like Penny Arcade's Extra Credits.
I give up, yeah yeah, youre right, thers absolutely no difference between dx9 and dx11, its all just fluff and some general conspiracy by MS.
You may not realize this, but you're basically saying that EA is using all of the graphics optimization methods that are available. They may or may not be using them well, but there aren't any obvious fixes that they're ignoring. Let's break it down.
1) Not drawing some things on the screen. Every game engine has to do a hefty dose of this unless it's a very, very small game world. Think "Asteroids" small, not "only one zone" small. Probably the simplest is "that's too far away, so we're not going to draw it"--or perhaps rather, not even going to load it into memory until it gets closer.
Sometimes saying, "we're not going to draw that" is more problematic than others. The best time to do it is for things that wouldn't have appeared on the screen anyway. If you can determine that a particular object isn't going to be on the screen that particular frame, then you can just ignore it and move on to the next, rather than passing it on to the rendering thread, which would have to switch to the right program (actually, you can usually get around this one by collating objects that use the same program), texture(s), and vertex data, upload the uniforms, run the vertex shaders, clip each triangle separately, observe that one of the six clipping planes completely killed the entire triangle so that nothing makes it to the pixel shader, and then not draw anything. It's impractical to always determine whether an object will appear on the screen without trying to draw it and see what happens. But if something is way off to the side or behind the camera or whatever, you can detect that and skip it.
But sometimes, there's still too much to draw in a single frame, and that's going to kill your performance. Trying to draw 50 characters at once, each of which is animated and has customized his looks (different textures for all, and likely different vertex data, too) is necessarily a ton of work, and that means a huge performance hit. You can sort and say, we're going to cap the number we draw in a given frame and only draw the closest ones, and sometimes you have to do that in order to get acceptable performance. Yes, it does look bad when nearby characters are disappearing and reappearing, but when there's too much to draw, there aren't always good alternatives.
2) Customizing the game engine. You're making a big deal about how EA started with a beta version of the Hero Engine, then changed it so that it's not the officially supported version anymore. But if they had started with the latest version, they'd still have had to change it so that it's not the officially supported version anymore. Off-the-shelf graphics engines are built to do certain things, and to do them in certain ways. It never exactly coincides with what you want to do in your game.
For that matter, even if the graphics engine was built for your particular game (Hero's Journey, in this case), as you actually build the game, you'll inevitably discover that you need some things you hadn't planned for, and that you're not using some things that you had built in. And if the graphics engine wasn't built specifically for your particular game, you'll probably come up with even more examples of both.
So what do you do about it? You modify the game engine, of course. If you discover that you need the capability to do something that the engine doesn't already support, the best option is to modify the engine to support it. At that point, it's no longer the standard, officially-supported version of the Hero Engine, but that's okay--and necessary, even.
One alternative is to try to cram what you want into the way the engine wants to do things, but this is highly inefficient. It's something akin to eating soup with a fork. The other alternative is to simply not do what you need to do for your game, i.e., chop out features that you were planning on adding. You'll sometimes need to do this anyway as things turn out to be impractical to implement, but you'll have to do a lot more of it if you're not going to customize the game engine.
On the other side, if the game engine supports things that you're not going to use, then you want to cut them out. On the processor side, it's often not that big of a deal if some code goes unused. But pixel shaders need to run hundreds of millions of times per second. If your pixel shader takes a microsecond longer to run than it "should", then you have a big, big problem. (I'm glossing over details of how a graphics card will have many copies of the same pixel shader running simultaneously on different data, but you get the point.) You have to go through it operation by operation (line by line is too coarse here) and make sure that it's as efficient as you can possibly make it. If there's functionality that you're not using and not going to use, then chop it out.
3) Breaking things into zones. This is really just a more efficient way of structuring your data. This doesn't only mean different planets in SWTOR, but also different zones within planets. It's highly probable that the game world is broken into zones in several different ways that are mostly invisible to players--and not necessarily that one subdivision is a refinement of another.
For example, in order to load the entire game into video memory all at once would surely take at least tens of gigabytes of video memory, and likely hundreds of gigabytes. So how does the game engine decide what to load? Well, it loads the stuff that is near you, of course. But how does it decide what is near you? It could check every single object in the game, determine how close you are to it, and then load it if you're close enough. But that would take too long.
Instead, the data is broken into zones that are never drawn on your screen. You're in some particular zone, and several other zones are near enough that the game might conceivably need to load stuff from them. It checks everything in those few zones, but skips the other hundreds or thousands of zones that are too far away. It's much quicker to check a zone once and determine that it's too far away than to loop through every single object in the zone and determine that each particular object is too far away to be loaded.
Or for another example, let's suppose that a mob somewhere in the game world attacks. The server has to determine which players will be informed of this. Informing every player every single time anything in the game world moves is impractical for bandwidth reasons. For the server to cycle through every single player online and check whether they're near enough would work, but would bring an unnecessary performance hit. So it breaks the game world into zones and only checks players in the zone that the mob is in and a few other zones nearby. Some players who are in such zones may still not be notified of the attack, but the idea of zones is that you can very quickly eliminate 99%+ of the players from needing to know, and only do more detailed processing on a few.
And more to the point, the zones for checking what texture and vertex data to load into video memory probably aren't the same zones as for checking which players need to be notified that a mob has attacked. There can be a number of other purposes for which players are divided into zones, too.
4) Drawing objects faster. Ideally, if you can find a way to compute exactly the same finished screen in less time, you do. But there's only so much of this available. Sometimes, you have to ease the load by making it simpler for the video card to draw a given object. This can mean lower resolution textures, and SWTOR famously had a big dust-up over this. It can mean fewer vertices in your models. It can mean reusing programs and textures and vertex data more, so that you can collate things and have to switch data less often. It can mean chopping out some graphical effects entirely, especially computationally expensive things such as shadows.
Ideally, you give players some graphical options to allow them to turn settings up or down themselves. That way, people with the hardware to handle it can get the full graphical effects, while people who don't have it can turn settings down and still make the game playable. But it does sometimes take some additional work to make sure that your code is optimized both for having settings on and having them off, as it doesn't do any good if turning graphical settings off doesn't ease the load on hardware. And, by the way, that's optimization work that you may not be able to do if you're using the standard game engine and not customizing things yourself.
-----
So what's the point of this? Most of the claims of "SWTOR has a bad graphics engine because of X" on this thread are completely spurious. It's like claiming that it's cold today because the sun rises in the east. Maybe it is cold today, and maybe the sun does rise in the east, but it's not cold today because the sun rises in the east.
In particular, that EA customized the game engine rather than using the bog-standard Hero Engine is a good thing, not a bad thing. If they hadn't, then you could claim--correctly--that it was a bad graphics engine for the game because it wasn't customized for the game in question.
Furthermore, optimizations of the sort that you describe aren't "tucking all the internal graphics engine issues under the rug". They're the stuff that graphical improvements are made of.
The thing that you need to understand about 3D graphics is that it's all completely fake. The way that the graphics work internally does not correspond to anything in the real world. It's really just a quest to make something that looks nice and lets the player feel like he can control what is going on, while drawing it as fast as possible. Any movement in that direction constitutes making the graphics engine better, not "tucking things under the rug".
The graphics engine is alright, it's about on par with a game from 2008 or so. The backend engine on the other hand is terrible, HeroEngine wasn't finished when Bioware bought it and shortly after Bioware obtained it, the engine was stated to be designed for free2play games. Things like this makes you go "hmmm....", almost as if Bioware planned this game to go F2P on purpose.