Jump to content

Why is there a copy protection system in the graphics, and is it crippling the game?


Tiron_Raptor

Recommended Posts

Stephen Reid response to thread added at bottom of post.

 

Stephen Reid response about the High Res Textures added at bottom of this post!

 

Edit: This is basically all speculation! Do not panic yet! More data needed before running about screaming and shouting!

 

During the discussion about the high-res texture problems( http://www.swtor.com/community/showthread.php?t=151787 ), someone discovered that a dll in the retailclient folder appeared to contain instructions to deliberately reduce the quality of textures. Further investigation revealed that the dll in question appeared to relate to a remote rendering system, specified as being for copy protection of 3D models. An honest to god research paper on the subject can be found here: http://graphics.stanford.edu/papers/protected/protected.pdf Another thread, on the subject of swtor needing administrator privileges, seems to indicate that the mysterious second swtor.exe process is not the launcher but in fact relates to the remote rendering system. ( http://www.swtor.com/community/showthread.php?t=143859&page=3 )

[Edit: it has been stated further on, but not confirmed, that the 'RemoteRenderer' is just part of the normal rendering system, and may be a renaming of or replacement for an original Hero Engine Component: The name may just be a coincidence. Hard data needed.]

 

The research paper lists a few methods for accomplishing remote rendering: several of them involve deliberately degrading the display to prevent an accurate reconstruction. All of them require that data be constantly sent from the server in order to display the model: some going so far as to transmit a pre-rendered image to be displayed.

 

It's entirely possible that the second process is the 'remote renderer', and is being used as a secure transmission and decryption method for the assets from the server. It's also possible that it's doing this using software rendering, due to it being considered more secure. [Edit: At least partially debunked by quote at bottom of this post, second process does not communicate directly with the internet at all.]

 

[EditAgain: Some examination of the activity of the processes so far hasn't show much of anything. The second process wasn't really seen to access game files in at least one case, though in another it was noted that there was a lot of cross-chatter between the two processes that was sometimes causing one to wait on the other. It's hard to judge for sure, but the results I've heard of so far don't really scream 'rendering stuff for the client']

 

If it is in fact the case that assets have been deliberately withheld from the client, and thus have to be transmitted to the client from the server in some form, it goes a VERY long way to explaining most of the performance problems SWTOR has been having.

 

Delayed animations? It's having to send what you're doing to the remote rendering server, and then wait for whichever box or process that is to render it, send it to the client, and integrate it with the locally rendered bits.

[Edit: The 'remote' rendered bits could only possibly be client side, confirmed by Mr. Reid that server rendering and transmission is as absurd as generally believed]

 

Queues?

 

[This section is defunct, due to new information.]

If the rendering is being done server-side, easily explained by the resource lost to the rendering.

[Edit: Confirmed by Mr. Reid to be as silly as was suspected]

Resources and bandwidth consumption from sending model assets to the clients could be a factor if it is present. If the whole thing is client side, there's no effect obviously.

 

 

[This section is defunct, due to new information.]

Disabled High Res Textures? The higher quality images would result in a tremendous increase in the memory load and bandwidth usage of the server, if anything is actually being rendered by the server; the bandwidth being due to the final rendered output being higher quality. They could also just be too much for the remote renderer server to handle, and had to be disabled to prevent performance degradation.

 

[Edit: Pretty well explained by Mr. Reid. The performance hit is indeed present, and apparently caused by difficulty getting the super high-res textures off the hard drive and into the memory. It becomes a problem particularly if there's a lot of characters in a given area. The high res textures are used in cutscenes still, because the number of characters etc in it at one time is completely controlled, preventing it from escalating into a problem.]

 

Performance drop in areas with a lot of characters? The DLL Referenced in the textures thread appears, from what I can tell, to be specifically related to character models in particular, so it's logical that the performance hit from the remote rendering would be worst when there are many characters on screen.

 

It makes so much sense, and potentially ties together a large number of the problems people have been reporting.

 

And for what? Copy protecting the models? Seriously?

 

Deliberately crippling the performance and appearance of the game for legitimate, paying customers in order to keep someone from being able to rebuild your 3D models? It has to be one of the most absurd things I've ever heard.

 

[This section is defunct, due to new information.]

And yet, I can't figure out why, when I'm on the republic fleet and have a large number of characters on screen at once, it causes a system with 8GB of RAM to act like it's paging.

[Edit: Appearance of paging due to thrashing when trying to pull large amounts of high-res texture data at once, per Mr. Reid]

 

This needs some serious, detailed, answers as to what exactly this 'remoterender' actually does, and what benefit it provides to us as customers. At the moment it sounds like it may be substantially degrading our experience and providing no benefits to us in return.

 

This may not at all be what is going on, but if it is, it'd be devastating.

 

Edited for clarity: Again, again, and again once more!

 

Edit5(or so): Changed paper link to official stanford website. Same paper, different host.

 

Addition:

 

One thing I've noted, is that the size of the beta client dropped by a tremendous amount, in excess of 10GB I believe it was, between the first and second beta weekends I participated in. At about this same time, the NDA was lifted. Things I've heard also seem to suggest it might've been about then when the high resolution textures were disabled.

 

This could suggest that the remote renderer was added at this time, a large portion of the assets were removed to the server, and the high res textures were disabled to aid the performance of the remote renderer. This would explain why people could run high quality textures no problem in beta, but have bioware disable them anyway.

Edit: It has been stated that the 'missing data' was in fact localization data, because the original beta client installed all possible localization files, whereas the retail version only installs at most a few specific ones. Can anyone verify?

 

Addition2:

 

go download netlimiter 3 and watch the second process ... it never access internet even during loading time so the only remote processing possible would be on 127.0.0.1 and that would be juts dumb... the amount of data able to pass trough the botttleneck that this create versus cpu--> gpu is astonishingly immense.

 

The game loading zone are eating twice as much bandwidth than even 8v8 pvp (i would check ilum but dead server is dead).

 

 

It's really odd during loading zone it stays at low download ( 5k/sec) then at the infamous30% mark ( where the small icon on the bottom right restart turning) it jump to 55k/sec for the reminder of the loading bar. This does seem to indicate transfer of texture in betwen the server and the client as there is absolutely nothing that require a 50k/sec bandwidth gameplay wise... Unless they reload the whole client database at EVERY loading zone... and even then.

 

This seems to suggest that the second process isn't in contact with Bioware, but the main process has a huge spike in bandwidth usage at the infamous hitch during loading.

[Edit: Speculated to be caused by information on the current local state being downloaded from the server: Presence or absence of NPCs, their locations, their movements, any objects, nodes or corpses present, etc...]

 

Addition3:

 

Hey everyone, thanks for bearing with us as we investigated the concerns raised here.

 

After investigation, it seems that the confusion here is a combination of a UI issue that's been resolved and a feature that's working as intended, but the reason why it's 'working as intended' needs explanation.

 

First, the UI issue. The preferences menu as it is seen on the Public Test Server for version 1.1 of the game is correct - there are only supposed to be two texture choices, 'Low' and 'High'. This replaces the original three-choice preference of Low/Medium/High because in reality, there was never supposed to be a 'Medium' choice - that was a bug.

 

Here's where we need to explain. As many of you have noted, your character in the game world is rendered using lower resolution textures than inside of cinematic conversation scenes. This was a deliberate decision by the development team. To understand why this was done, I have to briefly talk about MMOs and their engines.

 

In comparison to single player games and other genres of multiplayer online games, MMOs have much higher variability in the number of characters that can be potentially rendered on-screen at the same time. In MMOs, even though most of the time you'll see a relatively small number of characters on screen, there are certain situations in which many more characters will be seen. Some examples of these situations include popular gathering places in-game (in our case, the two fleets), Operations with large teams, and Warzones. In those scenarios the client (and your PC) has to work hard to show off a lot of characters on-screen.

 

During development and testing of The Old Republic, our priorities were to ensure the game looked great and performed well. In testing, we discovered that using our 'maximum resolution' textures on in-game characters during normal gameplay could cause severe performance issues, even on powerful PCs. There were a variety of possible options to help improve performance, but one that was explored and ultimately implemented used what is known as a 'texture atlas'.

 

To understand that I've got to get technical for a minute. When a character in the game is 'seen' by another character - ie, gets close to your field of view - the client has to 'draw' that character for you to see. As the character is 'drawn' for you there are a number of what are known as 'draw calls' where the client pulls information from the repository it has on your hard disk, including textures, and then renders the character. Every draw call that is made is a demand on your PC, so keeping that number of draw calls low per character is important. With our 'maximum resolution' textures a large number of draw calls are made per character, but that wasn't practical for normal gameplay, especially when a large number of characters were in one place; the number of draw calls made on your client would multiply very quickly. The solution was to 'texture atlas' - essentially to put a number of smaller textures together into one larger texture. This reduces the number of draw calls dramatically and allows the client to render characters quicker, which improves performance dramatically.

 

When it comes to cinematic scenes, however, characters are rendered using the higher number of draw calls and maximum resolution textures. This is because in those scenes, we have control over exactly how many characters are rendered and can ensure that the game performs well. The transition between 'atlas textured' characters (out of cinematics) and 'maximum resolution' textures (in cinematics) is mostly hidden by the transition between those two states (when the screen goes black), but obviously it's clear if you pay close attention.

 

In summary; yes, we had a small UI bug that unfortunately caused confusion over how the game is intended to work. The textures you're seeing in the course of normal gameplay are optimized for that mode of play. The textures you're seeing during cinematics are also optimized for that mode of play. They are higher resolution, but that's because we're able to control cinematic scenes to ensure good performance in a way we can't during normal gameplay.

 

We understand the passion and desire for people to see the same textures you see in our cinematic scenes in the main game. Because of the performance issues that would cause for the client, that's not an immediate and easy fix; we need to ensure we're making choices that the majority of our players will be able to benefit from. Having 'atlassed textures' helps performance overall, and that's a very important goal for us.

 

With that said, we've heard your feedback here loud and clear. The development team is exploring options to improve the fidelity of the game, particularly for those of you with high-spec PCs. It will be a significant piece of development work and it won't be an overnight change, but we're listening and we're committed to reacting to your feedback.

 

Addition4:

 

I'm going to ask the development team to look into this, but I'd ask you to pull back on some of the more extreme speculation. It doesn't help us to have rational informed discussions about the issues that we are facing.

 

There is, to my knowledge, no single DLL that's responsible for a multitude of problems across the game. For example, our 'ability delay' issue is being addressed by the development team right now, and I've been told there are dozens of fixes potentially being looked at to help improve things. There's no single magic fix (although some fixes may have more of an effect than others).

 

I'll also say right now that we're not 'remotely rendering' textures and sending to your client via your internet connection; that would be some impressive technology and if we were doing it, is likely something we'd have talked about before now.

 

I'll seek developer comment on this, but I just want to caution anyone from overreacting.

Edited by Tiron_Raptor
Link to comment
Share on other sites

  • Replies 699
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Keep in mind that 'remote rendering server' doesn't necessarily mean a server located at Bioware. In fact, it is highly unlikely that Bioware is rendering images in this manner. What may be happening is that the second swtor.exe process is the remote server itself. The game may be simply sending all render requests to the second process by way of 127.0.0.1, the localhost address.

 

On that note, next time I'm playing I'm going to toy with some packet inspection.

Edited by ironix
Link to comment
Share on other sites

This sounds like a complete joke to me. The only reason i can see for doing it like this is because Lucas Arts demanded that all assets are copy protected and EA/Bioware was forced to comply.

 

Or this is some kind of weird research project they are toying around with.

Link to comment
Share on other sites

Nice read. I'd like to get an answer, but maybe the issue is too technical...

 

The short version: it looks like instead of having all the models and textures on your hard drive, being rendered by your video card, at least some of them are exclusively on the servers, rendered at least in part by the servers, and then sent to your client.

 

There's a theory that the MASSIVE reduction in hard drive space used by the game (something like 17gb I think it was) in the last month before the game launched might be because the missing assets were put into this remote rendering system.

 

There are a few holes in this explanation thus far, but it could explain so much...

 

Keep in mind that 'remote rendering server' doesn't necessarily mean a server located at Bioware. In fact, it is highly unlikely that Bioware is rendering images in this manner. What may be happening is that the second swtor.exe process is the remote server itself. The game may be simply sending all render requests to the second process by way of 127.0.0.1, the localhost address.

 

On that note, next time I'm playing I'm going to toy with some packet inspection.

 

Entirely possible: that other thread indicates the second process is "swtor.exe @RemoteRendererServer.icb" I find it highly implausible myself that they'd render it on the server.

 

What they could be doing though, is storing the assets on the server, and using the second process to decrypt and/or render them, which could still introduce substantial performance hits.

Edited by Tiron_Raptor
Link to comment
Share on other sites

It makes so much sense, and potentially ties together a large number of the problems people have been reporting.

 

And for what? Copy protecting the models? Seriously?

 

Deliberately crippling the performance and appearance of the game for legitimate, paying customers in order to keep someone from being able to rebuild your 3D models? It has to be one of the most absurd things I've ever heard.

 

It would seem insanely absurd to me but sadly, it makes perfect sense in my opinion since EA is involved.

 

This is however very, very interesting. Can't wait to see how this plays out.

Link to comment
Share on other sites

See Stephen's response in the other post about this:

 

Hey all, I am here to apologize again... the good news is we have a draft of our response (you might be able to guess it's not a sentence or two) but I am circulating it internally to ensure my technical details are correct.

 

To give you an insight into our process here... as the Community team does with most big replies, I tracked down a variety of people on our client and art teams to get the facts on how the game works before putting the post together. As I'm representing those teams publicly, I want to ensure they're happy with what I'm saying on their behalf before I post it. They're busy people, so I'm just waiting on their sign-off right now.

 

I appreciate your patience and assuming we have sign-off this evening, you'll get our response tomorrow. If not, I accept the incoming rotten eggs.

 

Hopefully we will get a good, technical answer later today.

Link to comment
Share on other sites

See Stephen's response in the other post about this:

 

Hopefully we will get a good, technical answer later today.

 

Unfortunately that was just about the TEXTURES. The textures discussion brought the remote renderer to light, but it isn't purely a texture issue.

 

The forthcoming explanation may or may not address the remote rendering, since it's directly specifically at the fact that the high res textures have apparently been disabled, and the options being changed to disguise that.

 

I speculate that the remote rendering could be a factor, but I'm guessing it won't get a full treatment. and it needs a full treatment of its own.

Edited by Tiron_Raptor
Link to comment
Share on other sites

i am by deffinition not a pc tech guy...but doing this could actually ruin the game expierence and this cost them subs...

 

 

 

strange thing this thread is yes. the force be weak in them for doing this:csw_yoda:

Edited by DarthQube
Link to comment
Share on other sites

It's curious that they would resort to something like this for copy protection at all, if indeed that is what it is for.

 

Would need to know what is actually being done with this, but i'm very interested to see what its actually doing.

Link to comment
Share on other sites

it sure is , i myself dont have alot of problems with the performance issue's. i can understand ppl with lesser PC's are actually being held from playing by the makers of this game...wichis offcourse pretty stupid and absurd :/

Actually, by the sounds of it, this could actually go a long way to making the game MORE playable on lesser PCs, since the strain of rendering is on the internet connection, and not the local graphics card.

Edited by TheTurniipKing
Link to comment
Share on other sites

Do I need a tinfoil hat to participate? :csw_jabbapet:

 

No, but it helps.

 

Honestly, I would really prefer it if I was wrong... If it turns out to be true it could generate a ton of bad press and flat out kill the game. For the most part, it's a really good game.

 

Actually, by the sounds of it, this could actually go a long way to making the game MORE playable on lesser PCs, since the strain of rendering is on the internet connection, and not the local graphics card.

 

SOME of the rendering: what I've seen so far sounds like it's mostly or entirely the character models it's affecting. Your computer still has to splice the different bits together.

 

Additionally, it's possible that the remote renderer is in fact the second swtor.exe process that runs when the game is open: the assets could still be on the server, sent to the second process in what they consider to be a secure way, securely unpacked, rendered, and sent over to the other process (the actual client).

 

Several of the methods listed in the research paper outlining it admit to having substantial performance hits, and the first listed and also touted as the most secure is...software rendering. If the second process was software rendering parts of the gameworld and remoting it over to the client, that could explain some of the apparent CPU related problems as well.

Edited by Tiron_Raptor
Link to comment
Share on other sites

Very interesting read and if true seems like an awful design decision from the company. I have cancelled my subscription in light of the problems I have been having with textures, performance and character responsiveness, but still have 60 days left from a pre paid card so hopefully they can rectify these issues soon with updates and significant patches. Only then will I decide whether or not to continue playing the game.
Link to comment
Share on other sites

This would be incredible if true. A game company deliberately crippling their own game for the sake of protecting models. I noticed the problem with many players in an area but assumed it was my PC despite not having problems any other time.
Link to comment
Share on other sites

Hopefully they will figure out that such systems are crippling when even a mediocre amount of players are in the same area.

 

I wonder if this is also what causes the UI to completely stop my game for 1/2 a second every time I open a new window (very easy to see by simply spamming B).

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

×
×
  • Create New...