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.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/showt...=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]
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.
[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.
[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.
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?
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...]
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.
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.