If you haven't checked out Autenil's blog yet, and you like this type of behind-the-scenes information, I encourage you to check out his latest blog post.
Infinite Loops Are Bad
Thursday, March 27, 2008
Thursday, March 20, 2008
WYWSITUN Volume 1: Adjacency System Changes
U R probably wondering WTF does WYWSITUN mean.
It means "What You Won't See In The Update Notes".
We actually do a lot of work here at SOE, contrary to popular belief. :) Sometimes the things we work on aren't really worthy of the update notes. Although, I think it would be cool if we started including more detailed info in the update notes. Many people would probably be interested to read some of the technical details.
Until then, I'll just blog about some of these things. So without further ado, welcome to Volume 1 of WYWSITUN.
Something I've worked on a little bit recently is tweaking our adjacency system. What is an adjacency system? Well, its a small part of the server that determines which objects are near you. I guess you could more accurately refer to it as a "sub-system" of the server. Why do we need an Adjacency Sub-System (A.S.S. for short)? Without our ASS, we would have to send you updates for every object in a zone.
When Kunark was in development, we needed a faster and more efficient ASS because the zones were so much larger than previous expansions. One of the things the new system does is cap out when a maximum number of objects are sent to a client. This keeps a player from being bombarded with too many updates in really crowded areas. Instead, you just don't see as many objects as you would normally see. However, with the new system, I've noticed a couple of different issues.
Issue #1: Sometimes doors that are really far away don't render and you see black holes beyond the door. The reason you see a black hole is because the client determines that the door is shut, so it doesn't need to render whats inside the building. But since the door isn't rendering either, it just looks really bad. This is noticeable in Neriak when you stand before the bridge heading to the docks. At the other end of the docks is a building with a door, and sometimes this door doesn't render. I've made a change that increases the priority of doors and other important objects so they should render now from much further away, even if you're in a crowded area like Neriak.
Issue #2: Inanimate objects were causing you to hit the cap of max objects, thus cutting down the number of objects you'd see in an area. Inanimate objects are very lightweight to send to the client because they don't move or do anything to cause constant updates. So basically once we inform the client they are there, there's not a lot of overhead in keeping them relevant to you. An example of where you could see this problem in action is the Village of Somborn in Loping Plains. If you stood outside the church facing the guy that sells Wargs in the corner, most of the time you won't see him or the wargs render if you have your graphics settings somewhat low. This is because the tents behind you have a lot of static objects in them like bottles, papers, etc. Static objects like these will no longer cause you to hit the max cap of adjacent objects.
When GU44 goes live you should now see objects rendering from further away without impacting performance much. There's one other thing to keep in mind. The first step in getting an object rendered is for the server to notify your client that it's there. The second step is for your client to determine if it should be drawn or not. If your graphics settings are set to favor performance over quality, some objects may not be drawn even though the client knows about them. Another change I made is to increase the default rendering distance for some of the lower graphics settings. But if you still see objects not rendering when you think they should be, all you need to do is adjust the value of "cl_lod_scale". Set this value to 1 and you should be fine. You can also find this setting under Options -> Display -> Model Detail -> Level of detail bias.
Bonus: What does Level of detail bias do?
Level of Detail (LOD) describes how an object is rendered. An object rendered at the highest level of detail will show every detail of the model with the highest quality texture. As the LOD goes down, the model gets less detailed. So objects that are far away render at a lower LOD. After all, you won't notice the intricate detail in something when its far away. Once it gets far enough away, it will stop rendering altogether.
Each object determines the LOD it should be rendered at a given distance. So for example, a chair might render at its highest LOD up to 10 meters away. Between 10 and 20 meters it might render at its lowest LOD. And beyond 20 meters it may not render at all.
So back to the original question, what does Level of detail bias do? The distance of an object is multiplied by this value to determine what LOD should be used. So if your cl_lod_scale value is set to 2, a chair at 8 meters away would render as if it were 16 meters away. This would cause the chair to render at the lower LOD instead of the higher LOD. So basically putting this value to "1" tells the client to render objects from the distances in which they were intended to render. A higher number renders them as if they were further away.
So if objects are disappearing sooner than you would like, just decrease this value until you're happy with the results. Tweaking this value in combination with the adjacency changes that go live in GU44 should help in making objects appear when they would normally be gone.
Stay tuned for WYWSITUN Volume 2: Nerfing Rangers
(just kidding)
It means "What You Won't See In The Update Notes".
We actually do a lot of work here at SOE, contrary to popular belief. :) Sometimes the things we work on aren't really worthy of the update notes. Although, I think it would be cool if we started including more detailed info in the update notes. Many people would probably be interested to read some of the technical details.
Until then, I'll just blog about some of these things. So without further ado, welcome to Volume 1 of WYWSITUN.
Something I've worked on a little bit recently is tweaking our adjacency system. What is an adjacency system? Well, its a small part of the server that determines which objects are near you. I guess you could more accurately refer to it as a "sub-system" of the server. Why do we need an Adjacency Sub-System (A.S.S. for short)? Without our ASS, we would have to send you updates for every object in a zone.
When Kunark was in development, we needed a faster and more efficient ASS because the zones were so much larger than previous expansions. One of the things the new system does is cap out when a maximum number of objects are sent to a client. This keeps a player from being bombarded with too many updates in really crowded areas. Instead, you just don't see as many objects as you would normally see. However, with the new system, I've noticed a couple of different issues.
Issue #1: Sometimes doors that are really far away don't render and you see black holes beyond the door. The reason you see a black hole is because the client determines that the door is shut, so it doesn't need to render whats inside the building. But since the door isn't rendering either, it just looks really bad. This is noticeable in Neriak when you stand before the bridge heading to the docks. At the other end of the docks is a building with a door, and sometimes this door doesn't render. I've made a change that increases the priority of doors and other important objects so they should render now from much further away, even if you're in a crowded area like Neriak.
Issue #2: Inanimate objects were causing you to hit the cap of max objects, thus cutting down the number of objects you'd see in an area. Inanimate objects are very lightweight to send to the client because they don't move or do anything to cause constant updates. So basically once we inform the client they are there, there's not a lot of overhead in keeping them relevant to you. An example of where you could see this problem in action is the Village of Somborn in Loping Plains. If you stood outside the church facing the guy that sells Wargs in the corner, most of the time you won't see him or the wargs render if you have your graphics settings somewhat low. This is because the tents behind you have a lot of static objects in them like bottles, papers, etc. Static objects like these will no longer cause you to hit the max cap of adjacent objects.
When GU44 goes live you should now see objects rendering from further away without impacting performance much. There's one other thing to keep in mind. The first step in getting an object rendered is for the server to notify your client that it's there. The second step is for your client to determine if it should be drawn or not. If your graphics settings are set to favor performance over quality, some objects may not be drawn even though the client knows about them. Another change I made is to increase the default rendering distance for some of the lower graphics settings. But if you still see objects not rendering when you think they should be, all you need to do is adjust the value of "cl_lod_scale". Set this value to 1 and you should be fine. You can also find this setting under Options -> Display -> Model Detail -> Level of detail bias.
Bonus: What does Level of detail bias do?
Level of Detail (LOD) describes how an object is rendered. An object rendered at the highest level of detail will show every detail of the model with the highest quality texture. As the LOD goes down, the model gets less detailed. So objects that are far away render at a lower LOD. After all, you won't notice the intricate detail in something when its far away. Once it gets far enough away, it will stop rendering altogether.
Each object determines the LOD it should be rendered at a given distance. So for example, a chair might render at its highest LOD up to 10 meters away. Between 10 and 20 meters it might render at its lowest LOD. And beyond 20 meters it may not render at all.
So back to the original question, what does Level of detail bias do? The distance of an object is multiplied by this value to determine what LOD should be used. So if your cl_lod_scale value is set to 2, a chair at 8 meters away would render as if it were 16 meters away. This would cause the chair to render at the lower LOD instead of the higher LOD. So basically putting this value to "1" tells the client to render objects from the distances in which they were intended to render. A higher number renders them as if they were further away.
So if objects are disappearing sooner than you would like, just decrease this value until you're happy with the results. Tweaking this value in combination with the adjacency changes that go live in GU44 should help in making objects appear when they would normally be gone.
Stay tuned for WYWSITUN Volume 2: Nerfing Rangers
(just kidding)
Tuesday, March 11, 2008
EQ2Flames vs SOE
There is so much I'd love to say about this issue right now, but most of it will have to wait.
The drama thats happening on eq2flames is ridiculous. Of course the entire argument is one-sided over there because none of the devs dare get in the middle of it.
LFG was simply removed from the Influencers program for lack of involvement and communication. SOE was in no way severing ties with the entire eq2flames community. But because of his public post of Grimwell's email, and declaring "FFA" on SOE, the dev information was posted, and now SOE has no choice but steer clear of eq2flames.
I'm very angry and upset over this whole thing because it hurts the entire community and may ultimately hurt EQ2. If you don't care for the game, you should move on and play something else, but to try to ruin a community for those that do love it is just wrong.
The drama thats happening on eq2flames is ridiculous. Of course the entire argument is one-sided over there because none of the devs dare get in the middle of it.
LFG was simply removed from the Influencers program for lack of involvement and communication. SOE was in no way severing ties with the entire eq2flames community. But because of his public post of Grimwell's email, and declaring "FFA" on SOE, the dev information was posted, and now SOE has no choice but steer clear of eq2flames.
I'm very angry and upset over this whole thing because it hurts the entire community and may ultimately hurt EQ2. If you don't care for the game, you should move on and play something else, but to try to ruin a community for those that do love it is just wrong.
Wednesday, March 05, 2008
Armchair Programmers 4TW!
My hat is off to other developers whether you work on games, websites, business apps or whatever. Programming takes a certain kind of mindset but its both fun and challenging.
However, comments like this make me want to slap someone with a trout.
I'm a programmer and if their code is so poorly written they can't segregate and thread that logic then... well... that's just piss poor programming. Object design mehodology has been around for a lot of years now. It's only the terms that have changed the last few years. And given the other SOE titles out there it's crazy to think they don't have the code already and simply need to plug and play -- once again if they can't -- it's piss poor programming.
First off, Object Oriented Programming has NOTHING to do with multi-threading. Also, whether or not an application is a good candidate for multiple processes/threads/cores has nothing to do with how well it is written. So making a statement that EQ2 is made up of piss poor programming because it doesn't fully make use of multiple processors kind of makes me angry.
I'll be the first person to stand up and tell you that the EQ2 code-base isn't perfect. Find me an application that *IS* perfect, with over a million lines of source code, is over 6 years old and has been worked on by countless people who have come and gone, and I will gladly hand in my resignation. Especially an application like an MMO that is constantly growing and changing as new features are added.
All that aside, we are working very hard to improve the performance of the EQ2 client. It might not be in the form of multiple-cores, but we are looking into all possibilities.
Any programmer that thinks you can flip a switch or "plug and play" some code from another application and you magically have a high performing multi-threaded application seriously needs to find another line of work.
However, comments like this make me want to slap someone with a trout.
I'm a programmer and if their code is so poorly written they can't segregate and thread that logic then... well... that's just piss poor programming. Object design mehodology has been around for a lot of years now. It's only the terms that have changed the last few years. And given the other SOE titles out there it's crazy to think they don't have the code already and simply need to plug and play -- once again if they can't -- it's piss poor programming.
First off, Object Oriented Programming has NOTHING to do with multi-threading. Also, whether or not an application is a good candidate for multiple processes/threads/cores has nothing to do with how well it is written. So making a statement that EQ2 is made up of piss poor programming because it doesn't fully make use of multiple processors kind of makes me angry.
I'll be the first person to stand up and tell you that the EQ2 code-base isn't perfect. Find me an application that *IS* perfect, with over a million lines of source code, is over 6 years old and has been worked on by countless people who have come and gone, and I will gladly hand in my resignation. Especially an application like an MMO that is constantly growing and changing as new features are added.
All that aside, we are working very hard to improve the performance of the EQ2 client. It might not be in the form of multiple-cores, but we are looking into all possibilities.
Any programmer that thinks you can flip a switch or "plug and play" some code from another application and you magically have a high performing multi-threaded application seriously needs to find another line of work.
Subscribe to:
Posts (Atom)