[Official High Resolution Textures Post] Can we get a clarification on this?

[jadel]

Yeah, he can't understand that.

 

I also am disappointed that TOR is currently so poorly optimized and that they failed to at least provide a simple and quick [temporary] fix:

 

1) Let us turn on high-res for our characters and party members

or

2) Let us turn on high-res textures, but it only works for the first 20-ish or so models to be rendered.

If they did the above, they would placate the vast majority of people complaining while they do a more permanent fix.

 

 

Which reminds me: OP, please add the above suggestion to the first page.

 

This=Win. Come on BW.

[Your_dominus]

go play crysis, then come back to this game and make an objective comparison of in game graphics.

 

lolwut?

Did you not realize i was being sarcastic? aimed at the trolls that are arguing with me?

Edited January 12, 2012 by Your_dominus

[Harower]

The war between gaming graphics and video cards is what keeps the industry advancing at the rate it does.

 

 

The simple option to click a few settings and have your computer system ****ed in the *** is standard for just about every "new" release.

 

Ubersampling in witcher 2 anyone?

 

Honestly what company removes features and settings because they dont think we can handle it? That is detrimental to the gaming industry itself! A lot of people went out and spent a lot of money to use ubersampling etc. To experience the potential.

 

 

What if witcher 2 disabled AA, disabled high rez textures(then told us they never intended them to be part of normal use) as well as disabling ubersampling ( or in tor's case uniform colouring on gear )

 

 

Its.... so wierd and not industry standard I can't help but think they are not telling us something.

[shakunetsu]

Lol, you were comparing high rez RE to newer games with low rez, then you posted videos of high and low rez RE. Where's the 'newer games with low rez'?

 

If I were to compare the two videos you posted, then I would conclude, contrary to the spirit of your argument, that high rez is clearly superior!

 

Thanks for the videos.

 

You know for the game not having a hi res texture option it still lags as if it did. So I believe bioware will now hence forth be called bioware

[Your_dominus]

Lol, you were comparing high rez RE to newer games with low rez, then you posted videos of high and low rez RE. Where's the 'newer games with low rez'?

 

If I were to compare the two videos you posted, then I would conclude, contrary to the spirit of your argument, that high rez is clearly superior!

 

Thanks for the videos.

 

He doesnt even grasp that the game was upscaled for 720p/1080p, and that the source textures are the freeking same.

On top of that he thinks literally higher resolution textures ( mathematically, LARGER textures), are not better than TOR's

 

I;m still trying to figure out how he managed to get a couple people to gang up on me,lmao.

[United_Strafes]

Really if I think about it with Mass Effect 3, Hawken and MechWarrior with Cryengine 3 coming soon don't know really why I care, maybe cause I did want the game to be good and it's pretty lukewarm, and the textures are flat out bad along with some other graphics fubars. Maybe because I have an initial investment of $100 in a single game idk.

 

Still oh well if they want to feed us some BS that's ok the game will fail, I'd like it no to cause I believe it can be good and I love Bioware and Star Wars but I won't stand by and get spoon fed BS that I know is BS. Anyway for me as far as gameing there are much greener pastures than this, still I do hope they fix it and keep the PR bull that anyone with any sense can see through to a minimum.

[wildknight]

lolwut?

 

the crysis engine is pretty dated, note how i did not say crysis 2. or you could just use my sig for reference on what "high fidelity" should look like in this game, and actually did back in beta when the picture was taken.

[Your_dominus]

the crysis engine is pretty dated, note how i did not say crysis 2. or you could just use my sig for reference on what "high fidelity" should look like in this game, and actually did back in beta when the picture was taken.

 

......I was being sarcastic.

Aimed at the troll who keeps using the word " opinion" when I say mathematically larger resolution textures in 3 listed games are better, and that dx10 is better than dx9.

 

It was originaly meant as a offhand remark about how poor the graphics in TOR is, and I actually got someone who thinks other wise,lol.

Edited January 12, 2012 by Your_dominus

[shakunetsu]

the crysis engine is pretty dated, note how i did not say crysis 2. or you could just use my sig for reference on what "high fidelity" should look like in this game, and actually did back in beta when the picture was taken.

 

It feels like I'm playing a high res game tho it takes a lot of my memory, I want to run videos while I play

[Piddletrenthyde]

Nevermind. He was being sarcastic. thank god. Edited January 12, 2012 by Piddletrenthyde

[wildknight]

It feels like I'm playing a high res game tho it takes a lot of my memory, I want to run videos while I play

 

then buy and add more memory to your computer :boggle:

 

wait, another troll perhaps? i am not good at spotting them right away.

Edited January 12, 2012 by wildknight

[Ommm]

 

Its.... so wierd and not industry standard I can't help but think they are not telling us something.

 

 

Indeed.

Edited January 12, 2012 by Ommm

[DiscordDecorum]

Quite frankly, I am insulted at the explanation Stephen has given the community about the Texture resolution issue. As such let me take some time to truly explain the completely inadequate farce that is the SWTOR texture LOD System.

 

First, a quick background of myself. I am a student at Full Sail University studying Game Development, which focuses on 3D graphics programming, primarily in C++, however we dabble in a few other things and learn to optimize in Assembly as well. I have already taken several engine development courses, the most recent of which focuses on texture management, deferred rendering, transparency sorting, and post process chains (With a focus on HLSL Shader programming).

 

Now, Stephen mentions something called a Texture Atlas in his post. For the un-initiated, this can be simply considered a 2D Sprite sheet meant for use on 3D models by scaling and positioning (offsetting) UV texture coordinates. A low end atlas could store textures for multiple objects, where as a high end one might only be able to store 1 object's textures.

 

UV Texture coordinates are Jargon that simply means that each vertex, or point, on a 3D model also have 2 values that represent a position on a 2D picture. UV is used because X, Y and Z are used for the position of the vertex. When saving the data from whatever editor was used to make the models, Bioware either saved data for how to alter the UV coordinates, or what seems more likely from Stephen's explanation, They saved out multiple sets of UV coordinates that correspond to the different Textures used to skin (UV map) the object (The former is more efficient).

 

The key element in the entire process is what is called a state change, or a context switch, in the graphics hardware when rendering (drawing) the 3D objects to the screen. When a state change needs to occur, information must be sent to the graphics card informing it that new settings are in place, and for it to use the new information for future rendering instructions. State changes are considered slow because they are limited by the speed of the connection from the motherboard to the graphics card (this is called the "Bus" of the graphics card) which is several orders of magnitude slower than normal operations, and the changes cannot benefit from multiple processors because of this.

 

The most common state change is a change in texture binding. The way the graphics card uses textures is that it has a limited number of slots available for it to refer to on the fly to retrieve color information from an image at any given time. Many of these slots are taken up by information used to calculate lighting behind the scenes, such as Normal maps, ambient occlusion maps, specular maps, displacement or parallax maps, ect. This means that a state change must occur whenever an object needs to use a texture that is not already slotted into one of the available references the graphics card has access to quickly. Keep in mind that a texture can be loaded onto a graphics cards without being in one of these slots.

 

There is a way to speed up the process however, and that is to batch similar objects together that all need the same state, and render them back to back so that a state change does not need to occur when rendering that batch. Any engine worth it's salt does this. The texture atlasing solution Stephen has posted about is meant to further alleviate state changes by making it easier for more objects to share the same states needed for rendering.

 

The picture I have painted above may seem like a complete disaster zone of a coding nightmare (It is), however, the actual expense in performing a state change can be drastically reduced by also batching by state changes as well, something it seems the SWTOR engine is not doing efficiently, or at the least the dev team is overreacting about the performance hit. Furthermore, already having the textures present on the graphics card will further reduce the time cost drastically. Hence why cards with more RAM tend to perform much faster.

 

Batching by state changes entails a few things. First, you will want to have the next batch have as many similar states as the one before it... to a degree. Signals across the bus are sent in bursts and thus it is important to calculate just how many state changes can be sent at a time, and try to maximize this without going over. Furthermore, it is also of extreme importance that you keep track of what texture information is loaded onto the graphics card at any given time, and try to only make calls to draw objects in which the texture information is already present on the card. Otherwise the card will wait for it to load before doing any drawing, which murders your framerate. Death From Above style. It won't move on and come back; it just sits there and does nothing.

 

Now, on to the topic of more draw calls that Stephen mentions... I have no idea what he is talking about. Drawing an object requires a call to tell it to draw. all objects must do this, there are not any more or less calls made to do this with different textures unless someone faceplanted on their keyboard while coding the engine. The only increase is the number of state changes.

 

Texture atlases are almost mandatory for high counts of character models, all with different gear on, however, as seen in most every MMO released for a while, there is an option for a maximum number of high detail characters before reverting to using the atlas for the rest. The player character is ALWAYS one of them, and the rest are allocated to party members first, and then just the closest characters to the camera for any remaining characters. This option limits the number of additional state changes that can happen due to high quality textures so that a variety of cards can keep up with the demands of the game. This option is unfortunately sorely lacking (read: unavailable) in SWTOR. Instead, the textures are uniformly downsampled, or in essence, shrunk by a certain ratio (usually 2 or 4) and tacked on to an atlas to save memory and state change costs.

 

It is in my opinion that the Dev team either has a critical design flaw in their engine that prevents them from fixing a severe performance degradation due to additional switching between textures without a large amount of code re-write, or there is a bug with their option for limiting high quality character textures, with no know eta to fixing, and in the mean time they figured they could just completely disable the feature and pass it off as working as intended until they can either fix it or everyone stops caring. There are a number of other things that can be causing the issue, however the point to be made, and that has been made, is that far worse games have pulled off far better texture quality and SWTOR's player base expects no less from you Bioware, and we will not accept the "No" you have given to us as an answer.

 

Kilran Out.

[Your_dominus]

Ok I'm just gonna pop in here real quick to point out that obvious Dominus troll is obvious.

 

You jumped the shark there buddy. NOBODY can honestly say that TOR's "textures" are of the highest quality. That is patently ridiculous. The armor "textures" are poor at best by ANY standard. This is not to be debated. This IS a fact.

 

You kinda missed the memo ya?

Here I 'll help you out.

I was being sarcastic. Scroll on back a few pages as to why.

 

" fact" is my 3 listed examples have superior texture size,and hence quality. As well as superior lighting, and shaders.

But I got trolled

Apparently lower size textures. ( literally lower resolution textures) are better? and dx9 is better than 10. it's a wacky world so I started trollin too.

If you can't beat em join em I guess.

Edited January 12, 2012 by Your_dominus

[Mormack]

In all honesty, I would rather see this:

 

 

http://i.imgur.com/vRI0J.jpg

 

 

Than this:

 

 

http://i.imgur.com/6Qo5g.jpg

 

At least the textures are Crisp, the shadows are smooth, and the Company isn't trying to tell me what I can and can't accomplish on my computer.

[Kashaan]

not the case. also if you are as avid a gamer as you claim, you should know that that isn't a finite definition. saying that since the machines they put together crashed, everyones would is a blanket falsehood. all the beta users that had the high settings before they took them out would also have to disagree, especially that they also had server stress testing even when high settings were still enabled, and the majority didn't have problems. it has been posted by those people in the previously maxxed threads.

 

If professionals who are familiar with the code used computers with top-end components and they crashed under high pop circumstances... then yes, it is a true statement, not a falsehood at all.

 

An no, you cannot use beta as evidence that people wouldn't crash, since even during the Thanksgiving stress test they never got to the level of high population that occurred during launch.

 

 

once again you are assuming that everyone would run the max settings even if their machine couldn't handle it and they knew that. just because the option is there. another blanket falsehood. i will say it one more time since you dodge it continuously. let me choose whether or not to limit my graphics, don't push something on me that i didn't choose to have just because you think i don't know what i am doing or am incapable of choosing for myself.

 

This is EXACTLY the point. People who thought they could run it on max would have, and they would have crashed. Then they would have *****ed that they are forced to run on low (just like now). Those who knew they couldn't run on max are irrelevant.

 

In either situation (having the choice or not), people will *****. The only difference being that in addition to the ***** ing, people would have ALSO been ***** ing about crashing as well. The problems would have compounded.

 

 

what did happen was bioware took out an option during beta that some people were having issue with, but not all, and never put it back in after assuring us in beta it would be. and now claiming that they never intended to have that option for anything other than their "cinematics" aka cutscenes.

 

This is where you're not understanding the situation. The problem didn't occur during beta, because there was never a high enough population to cause it.

Edited January 12, 2012 by Kashaan

[Yselik]

Quite frankly, I am insulted at the explanation Stephen has given the community about the Texture resolution issue. As such let me take some time to truly explain the completely inadequate farce that is the SWTOR texture LOD System.

 

First, a quick background of myself. I am a student at Full Sail University studying Game Development, which focuses on 3D graphics programming, primarily in C++, however we dabble in a few other things and learn to optimize in Assembly as well. I have already taken several engine development courses, the most recent of which focuses on texture management, deferred rendering, transparency sorting, and post process chains (With a focus on HLSL Shader programming).

 

Now, Stephen mentions something called a Texture Atlas in his post. For the un-initiated, this can be simply considered a 2D Sprite sheet meant for use on 3D models by scaling and positioning (offsetting) UV texture coordinates. A low end atlas could store textures for multiple objects, where as a high end one might only be able to store 1 object's textures.

 

UV Texture coordinates are Jargon that simply means that each vertex, or point, on a 3D model also have 2 values that represent a position on a 2D picture. UV is used because X, Y and Z are used for the position of the vertex. When saving the data from whatever editor was used to make the models, Bioware either saved data for how to alter the UV coordinates, or what seems more likely from Stephen's explanation, They saved out multiple sets of UV coordinates that correspond to the different Textures used to skin (UV map) the object (The former is more efficient).

 

The key element in the entire process is what is called a state change, or a context switch, in the graphics hardware when rendering (drawing) the 3D objects to the screen. When a state change needs to occur, information must be sent to the graphics card informing it that new settings are in place, and for it to use the new information for future rendering instructions. State changes are considered slow because they are limited by the speed of the connection from the motherboard to the graphics card (this is called the "Bus" of the graphics card) which is several orders of magnitude slower than normal operations, and the changes cannot benefit from multiple processors because of this.

 

The most common state change is a change in texture binding. The way the graphics card uses textures is that it has a limited number of slots available for it to refer to on the fly to retrieve color information from an image at any given time. Many of these slots are taken up by information used to calculate lighting behind the scenes, such as Normal maps, ambient occlusion maps, specular maps, displacement or parallax maps, ect. This means that a state change must occur whenever an object needs to use a texture that is not already slotted into one of the available references the graphics card has access to quickly. Keep in mind that a texture can be loaded onto a graphics cards without being in one of these slots.

 

There is a way to speed up the process however, and that is to batch similar objects together that all need the same state, and render them back to back so that a state change does not need to occur when rendering that batch. Any engine worth it's salt does this. The texture atlasing solution Stephen has posted about is meant to further alleviate state changes by making it easier for more objects to share the same states needed for rendering.

 

The picture I have painted above may seem like a complete disaster zone of a coding nightmare (It is), however, the actual expense in performing a state change can be drastically reduced by also batching by state changes as well, something it seems the SWTOR engine is not doing efficiently, or at the least the dev team is overreacting about the performance hit. Furthermore, already having the textures present on the graphics card will further reduce the time cost drastically. Hence why cards with more RAM tend to perform much faster.

 

Batching by state changes entails a few things. First, you will want to have the next batch have as many similar states as the one before it... to a degree. Signals across the bus are sent in bursts and thus it is important to calculate just how many state changes can be sent at a time, and try to maximize this without going over. Furthermore, it is also of extreme importance that you keep track of what texture information is loaded onto the graphics card at any given time, and try to only make calls to draw objects in which the texture information is already present on the card. Otherwise the card will wait for it to load before doing any drawing, which murders your framerate. Death From Above style. It won't move on and come back; it just sits there and does nothing.

 

Now, on to the topic of more draw calls that Stephen mentions... I have no idea what he is talking about. Drawing an object requires a call to tell it to draw. all objects must do this, there are not any more or less calls made to do this with different textures unless someone faceplanted on their keyboard while coding the engine. The only increase is the number of state changes.

 

Texture atlases are almost mandatory for high counts of character models, all with different gear on, however, as seen in most every MMO released for a while, there is an option for a maximum number of high detail characters before reverting to using the atlas for the rest. The player character is ALWAYS one of them, and the rest are allocated to party members first, and then just the closest characters to the camera for any remaining characters. This option limits the number of additional state changes that can happen due to high quality textures so that a variety of cards can keep up with the demands of the game. This option is unfortunately sorely lacking (read: unavailable) in SWTOR. Instead, the textures are uniformly downsampled, or in essence, shrunk by a certain ratio (usually 2 or 4) and tacked on to an atlas to save memory and state change costs.

 

It is in my opinion that the Dev team either has a critical design flaw in their engine that prevents them from fixing a severe performance degradation due to additional switching between textures without a large amount of code re-write, or there is a bug with their option for limiting high quality character textures, with no know eta to fixing, and in the mean time they figured they could just completely disable the feature and pass it off as working as intended until they can either fix it or everyone stops caring. There are a number of other things that can be causing the issue, however the point to be made, and that has been made, is that far worse games have pulled off far better texture quality and SWTOR's player base expects no less from you Bioware, and we will not accept the "No" you have given to us as an answer.

 

Kilran Out.

 

 

 

 

This, this, a million times this.

 

OP should absolutely be adding this to his original post.

[Dosblade]

Not sure what to say. I think maybe they have no clue how to fix it... enable it so ..working as intended..

 

You know I am getting 70+ all the time so .. what ever.. fix it.. let us TURN IT ON OR OFF..

[PjPablo]

Quite frankly, I am insulted at the explanation Stephen has given the community about the Texture resolution issue. As such let me take some time to truly explain the completely inadequate farce that is the SWTOR texture LOD System.

 

First, a quick background of myself. I am a student at Full Sail University studying Game Development, which focuses on 3D graphics programming, primarily in C++, however we dabble in a few other things and learn to optimize in Assembly as well. I have already taken several engine development courses, the most recent of which focuses on texture management, deferred rendering, transparency sorting, and post process chains (With a focus on HLSL Shader programming).

 

Now, Stephen mentions something called a Texture Atlas in his post. For the un-initiated, this can be simply considered a 2D Sprite sheet meant for use on 3D models by scaling and positioning (offsetting) UV texture coordinates. A low end atlas could store textures for multiple objects, where as a high end one might only be able to store 1 object's textures.

 

UV Texture coordinates are Jargon that simply means that each vertex, or point, on a 3D model also have 2 values that represent a position on a 2D picture. UV is used because X, Y and Z are used for the position of the vertex. When saving the data from whatever editor was used to make the models, Bioware either saved data for how to alter the UV coordinates, or what seems more likely from Stephen's explanation, They saved out multiple sets of UV coordinates that correspond to the different Textures used to skin (UV map) the object (The former is more efficient).

 

The key element in the entire process is what is called a state change, or a context switch, in the graphics hardware when rendering (drawing) the 3D objects to the screen. When a state change needs to occur, information must be sent to the graphics card informing it that new settings are in place, and for it to use the new information for future rendering instructions. State changes are considered slow because they are limited by the speed of the connection from the motherboard to the graphics card (this is called the "Bus" of the graphics card) which is several orders of magnitude slower than normal operations, and the changes cannot benefit from multiple processors because of this.

 

The most common state change is a change in texture binding. The way the graphics card uses textures is that it has a limited number of slots available for it to refer to on the fly to retrieve color information from an image at any given time. Many of these slots are taken up by information used to calculate lighting behind the scenes, such as Normal maps, ambient occlusion maps, specular maps, displacement or parallax maps, ect. This means that a state change must occur whenever an object needs to use a texture that is not already slotted into one of the available references the graphics card has access to quickly. Keep in mind that a texture can be loaded onto a graphics cards without being in one of these slots.

 

There is a way to speed up the process however, and that is to batch similar objects together that all need the same state, and render them back to back so that a state change does not need to occur when rendering that batch. Any engine worth it's salt does this. The texture atlasing solution Stephen has posted about is meant to further alleviate state changes by making it easier for more objects to share the same states needed for rendering.

 

The picture I have painted above may seem like a complete disaster zone of a coding nightmare (It is), however, the actual expense in performing a state change can be drastically reduced by also batching by state changes as well, something it seems the SWTOR engine is not doing efficiently, or at the least the dev team is overreacting about the performance hit. Furthermore, already having the textures present on the graphics card will further reduce the time cost drastically. Hence why cards with more RAM tend to perform much faster.

 

Batching by state changes entails a few things. First, you will want to have the next batch have as many similar states as the one before it... to a degree. Signals across the bus are sent in bursts and thus it is important to calculate just how many state changes can be sent at a time, and try to maximize this without going over. Furthermore, it is also of extreme importance that you keep track of what texture information is loaded onto the graphics card at any given time, and try to only make calls to draw objects in which the texture information is already present on the card. Otherwise the card will wait for it to load before doing any drawing, which murders your framerate. Death From Above style. It won't move on and come back; it just sits there and does nothing.

 

Now, on to the topic of more draw calls that Stephen mentions... I have no idea what he is talking about. Drawing an object requires a call to tell it to draw. all objects must do this, there are not any more or less calls made to do this with different textures unless someone faceplanted on their keyboard while coding the engine. The only increase is the number of state changes.

 

Texture atlases are almost mandatory for high counts of character models, all with different gear on, however, as seen in most every MMO released for a while, there is an option for a maximum number of high detail characters before reverting to using the atlas for the rest. The player character is ALWAYS one of them, and the rest are allocated to party members first, and then just the closest characters to the camera for any remaining characters. This option limits the number of additional state changes that can happen due to high quality textures so that a variety of cards can keep up with the demands of the game. This option is unfortunately sorely lacking (read: unavailable) in SWTOR. Instead, the textures are uniformly downsampled, or in essence, shrunk by a certain ratio (usually 2 or 4) and tacked on to an atlas to save memory and state change costs.

 

It is in my opinion that the Dev team either has a critical design flaw in their engine that prevents them from fixing a severe performance degradation due to additional switching between textures without a large amount of code re-write, or there is a bug with their option for limiting high quality character textures, with no know eta to fixing, and in the mean time they figured they could just completely disable the feature and pass it off as working as intended until they can either fix it or everyone stops caring. There are a number of other things that can be causing the issue, however the point to be made, and that has been made, is that far worse games have pulled off far better texture quality and SWTOR's player base expects no less from you Bioware, and we will not accept the "No" you have given to us as an answer.

 

Kilran Out.

 

"Look at the big brain on Brad!"

 

Seriously though. Thx for the info.

[Piddletrenthyde]

You kinda missed the memo ya?

Here I 'll help you out.

I was being sarcastic. Scroll on back a few pages as to why.

 

Yes I apologize. I have been following this beast of a thread since it started. I saw your post and just about barfed all over myself.

 

Someone really needs to make a sarcasm font.

[Ogitrev]

Quite frankly, I am insulted at the explanation Stephen has given the community about the Texture resolution issue. As such let me take some time to truly explain the completely inadequate farce that is the SWTOR texture LOD System.

 

First, a quick background of myself. I am a student at Full Sail University studying Game Development, which focuses on 3D graphics programming, primarily in C++, however we dabble in a few other things and learn to optimize in Assembly as well. I have already taken several engine development courses, the most recent of which focuses on texture management, deferred rendering, transparency sorting, and post process chains (With a focus on HLSL Shader programming).

 

Now, Stephen mentions something called a Texture Atlas in his post. For the un-initiated, this can be simply considered a 2D Sprite sheet meant for use on 3D models by scaling and positioning (offsetting) UV texture coordinates. A low end atlas could store textures for multiple objects, where as a high end one might only be able to store 1 object's textures.

 

UV Texture coordinates are Jargon that simply means that each vertex, or point, on a 3D model also have 2 values that represent a position on a 2D picture. UV is used because X, Y and Z are used for the position of the vertex. When saving the data from whatever editor was used to make the models, Bioware either saved data for how to alter the UV coordinates, or what seems more likely from Stephen's explanation, They saved out multiple sets of UV coordinates that correspond to the different Textures used to skin (UV map) the object (The former is more efficient).

 

The key element in the entire process is what is called a state change, or a context switch, in the graphics hardware when rendering (drawing) the 3D objects to the screen. When a state change needs to occur, information must be sent to the graphics card informing it that new settings are in place, and for it to use the new information for future rendering instructions. State changes are considered slow because they are limited by the speed of the connection from the motherboard to the graphics card (this is called the "Bus" of the graphics card) which is several orders of magnitude slower than normal operations, and the changes cannot benefit from multiple processors because of this.

 

The most common state change is a change in texture binding. The way the graphics card uses textures is that it has a limited number of slots available for it to refer to on the fly to retrieve color information from an image at any given time. Many of these slots are taken up by information used to calculate lighting behind the scenes, such as Normal maps, ambient occlusion maps, specular maps, displacement or parallax maps, ect. This means that a state change must occur whenever an object needs to use a texture that is not already slotted into one of the available references the graphics card has access to quickly. Keep in mind that a texture can be loaded onto a graphics cards without being in one of these slots.

 

There is a way to speed up the process however, and that is to batch similar objects together that all need the same state, and render them back to back so that a state change does not need to occur when rendering that batch. Any engine worth it's salt does this. The texture atlasing solution Stephen has posted about is meant to further alleviate state changes by making it easier for more objects to share the same states needed for rendering.

 

The picture I have painted above may seem like a complete disaster zone of a coding nightmare (It is), however, the actual expense in performing a state change can be drastically reduced by also batching by state changes as well, something it seems the SWTOR engine is not doing efficiently, or at the least the dev team is overreacting about the performance hit. Furthermore, already having the textures present on the graphics card will further reduce the time cost drastically. Hence why cards with more RAM tend to perform much faster.

 

Batching by state changes entails a few things. First, you will want to have the next batch have as many similar states as the one before it... to a degree. Signals across the bus are sent in bursts and thus it is important to calculate just how many state changes can be sent at a time, and try to maximize this without going over. Furthermore, it is also of extreme importance that you keep track of what texture information is loaded onto the graphics card at any given time, and try to only make calls to draw objects in which the texture information is already present on the card. Otherwise the card will wait for it to load before doing any drawing, which murders your framerate. Death From Above style. It won't move on and come back; it just sits there and does nothing.

 

Now, on to the topic of more draw calls that Stephen mentions... I have no idea what he is talking about. Drawing an object requires a call to tell it to draw. all objects must do this, there are not any more or less calls made to do this with different textures unless someone faceplanted on their keyboard while coding the engine. The only increase is the number of state changes.

 

Texture atlases are almost mandatory for high counts of character models, all with different gear on, however, as seen in most every MMO released for a while, there is an option for a maximum number of high detail characters before reverting to using the atlas for the rest. The player character is ALWAYS one of them, and the rest are allocated to party members first, and then just the closest characters to the camera for any remaining characters. This option limits the number of additional state changes that can happen due to high quality textures so that a variety of cards can keep up with the demands of the game. This option is unfortunately sorely lacking (read: unavailable) in SWTOR. Instead, the textures are uniformly downsampled, or in essence, shrunk by a certain ratio (usually 2 or 4) and tacked on to an atlas to save memory and state change costs.

 

It is in my opinion that the Dev team either has a critical design flaw in their engine that prevents them from fixing a severe performance degradation due to additional switching between textures without a large amount of code re-write, or there is a bug with their option for limiting high quality character textures, with no know eta to fixing, and in the mean time they figured they could just completely disable the feature and pass it off as working as intended until they can either fix it or everyone stops caring. There are a number of other things that can be causing the issue, however the point to be made, and that has been made, is that far worse games have pulled off far better texture quality and SWTOR's player base expects no less from you Bioware, and we will not accept the "No" you have given to us as an answer.

 

Kilran Out.

 

Good post and read man. I am not a techie person, but someone mentioned that the game is running in 32bit mode and therefore can only access 2gb of Ram. Can this be one of hte reasons for the performance hit. Hi res textures on players characters and companions would eat up memory, add in other characters and you could run into memory issues due to the game only using 32bit. Again, not a techie person, just retyping what I read in an earlier post in this thread.

[United_Strafes]

the crysis engine is pretty dated, note how i did not say crysis 2. or you could just use my sig for reference on what "high fidelity" should look like in this game, and actually did back in beta when the picture was taken.

 

Hurts me eyes to look at those back to back.

[shakunetsu]

This is the 4th post about this issue:

 

1st post (117 pages long): http://www.swtor.com/community/showthread.php?t=140954

2nd post (112 pages long): http://www.swtor.com/community/showthread.php?t=151787

3rd post (125 pages long): http://www.swtor.com/community/showthread.php?t=162569

 

*New Update 11/01/2012*

 

So here we go. The answer we wanted, and also probably the answer nobody wanted:

 

 

 

So no, we won't have high resolution textures in a 2012 AAA game anytime soon.

 

Thanks all for the support on this subject guys.

 

New Update 09/01/2012

 

We finally got a first response by Stephen Reid. I'll just quote it:

 

 

 

I'll update this post as soon as we get that info.

 

 

Original 1st post with 117 pages: http://www.swtor.com/community/showthread.php?t=140954

 

I want to thank EVERYBODY for the support we are all giving to this post. Many good opinions here. More than 50 pages in 1 day clearly shows one thing: as customers paying for a 50$ product and worth 15$ a month, we deserve an answer.

 

//Update

 

Ok, since this has become the "official" post for the High Resolution Textures issue, I'm going to update this post for newcomers with the information we have at the moment. So, here are the facts we know:

 

1- The game had high resolution textures during beta. But they disappeared before releasing the live client.

 

2- You are NOT playing in high settings, no matter what your preferences window says. At this moment, medium=high, and there is no high, so you are all playing viewing your char's textures in medium quality.

 

3- This was expected to be fixed in the PTS. However, at this moment the issue hasn't been fixed for 1.1. What is more, they deleted the "MediPum" quality option, and now there are only two options. Low and High. And yes, you are right: High is just the new Medium, as you can see in this screenshot:

 

http://img651.imageshack.us/img651/9238/swtor3.png

 

More info on this, by MaxWham:

 

 

 

4- Somehow, the high resolution textures are already in the game. But they are not being used while playing with your character. You can see em during dialog cutscenes. You can see them on your companions wardrobe preview window. And you can see them for 0,5 secs after clicking on your holo terminal in your ship. Here are some examples:

 

Medium: http://imageshack.us/photo/my-images/59/screenshot2012010419385.jpg/

High: http://imageshack.us/photo/my-images/851/screenshot2012010419390.jpg/

 

Medium: http://img32.imageshack.us/img32/8974/screenshot2012010710454.jpg

High: http://img38.imageshack.us/img38/553/hirez.png

 

Medium: http://imgur.com/NqI7j

High: http://imgur.com/M7Geg

 

ToonPhil shared with us this one: http://img12.imageshack.us/img12/3646/swtorhightextures1.png

 

Another one from Adamant:

 

Medium: http://i.imgur.com/PsqBo.jpg

High: http://i.imgur.com/U1RMk.jpg

 

And yet another one: http://i146.photobucket.com/albums/r277/UnruheEndlos/The%20Old%20Republic/TORTextureComparison.jpg

 

One of the best high/med comparison photosets I've seen in this forum, by Rhykker: http://img51.imageshack.us/img51/5493/hirez.jpg

 

Gif showing the difference between both: http://m.uploadedit.com/bac/1325903803236.gif

 

and another gif: http://i40.tinypic.com/ip8wmb.gif

 

And a video:

 

And a WoW vs SWTOR comparison: http://i146.photobucket.com/albums/r277/UnruheEndlos/TORWOWComparison.jpg

 

Also, I'm getting this technical information from the user Lemon_King. It's really impressive what some users like him are finding inside the code:

 

 

 

It is important to note that after 200+ pages, Bioware still hasn't said anything about this.

 

I'm also quoting this very well written post:

 

 

 

//Update.

 

So, this is what the official known bugs forums says:

 

If you installed prior to 5:00AM CST on January 4th, 2012, your graphics will display as "Low" even if actual in-game settings are higher due to automatic preference detection.

Workaround: Your graphics setting will display properly once modified and saved.

 

Workaround: Individual preferences will display properly once modified and saved.

 

Also, it was stated on 1.0.2 patch that:

 

Upon a new installation and first launch of the game, settings files and in-game graphics preferences are now consistent with each other.

 

So, please Bioware, can we get a clarification on this? Does this mean that if we reinstall the game using the online installer, we will get high resolution textures everytime and not only during dialog cutscenes?

 

If not, any ETA on when the high resolution textures bug will be fixed?

 

Thanks in advance for answering this confusive situation.

 

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.

 

A lot of people aren't going to like this. I bought the CE. Now I regret it. I'm going to destroy my box. And that art book will be burned. I'll rip the soundtrack and import it to iTunes. Then I'll just leave it outside the case so it can get scratches. And that statue? You don't want to know what I'm going to do to that statue.

[Allmightyprom]

That sir is an opinion.

Theres nothing wrong with TOR it's otimized perfectly, and the textures are of the highest fidelity I have ever seen.

 

I require proof in your statment that it's optimized poorly.

 

You are really joking yeh?

[Your_dominus]

Good post and read man. I am not a techie person, but someone mentioned that the game is running in 32bit mode and therefore can only access 2gb of Ram. Can this be one of hte reasons for the performance hit. Hi res textures on players characters and companions would eat up memory, add in other characters and you could run into memory issues due to the game only using 32bit. Again, not a techie person, just retyping what I read in an earlier post in this thread.

 

No this is not the reason.

Most games are 32 bit.

Whats more is, TOR is large address aware. It can use 4gb.

 

It's poorly optimized. Period.

You are really joking yeh?

 

No! Didn't you hear? Low res textures are better than higher res ones, and dx9 is better than dx10!

Poor rendering distance on foliage is also better than far distance, and blocky shadows are better than smooth and dynamic.

Edited January 12, 2012 by Your_dominus