Guild of Writers

Nalatez wrote:If poor performance was not on the server side, not in Plazma, not in PhysX, and not in DirectX/OpenGL then where was it coming from?

If you read the chatlog that I posted from chip on my blog and on the UL forums, he says that the main source of lag is the physics engine. However, I will repeat it here, since you seem to have not seen it.

chip wrote:<chip> oh man, can we please start arguing about plasma again
<chip> the problemm isn’t plasma2.0 or the plNetCore
<chip> its the physics crap
<chip> it was sloooow
<chip> you put like 30 people on the same screen
<chip> it just goes to all shit
<chip> * same area
<chip> I learned lots at cyan. mostly that you can optimize the backend servers all you want
<chip> but in the end
<chip> a shitty client (in this case in c++ and python)
<chip> can still make the whole thing suck

I will repeat again for the benefit of everyone THE SERVERS ARE NOT THE MAIN SOURCE OF LAG.

Mod Edit: The log contained a not so nice word, it was deleted.

Nadnerb wrote:Well, theoretically, it would be a new clothing item, rather than a completely new avatar. The avatar used by the engine is determined by your gender. Your gender is either Male, Female, Kodama, Engberg, DrWatson, Sutherland, Victor, Yeesha, Zandi, RandMiller, Cate, or Bahro. >.> But all of the above use only the Male or Female (or possibly Bahro) animations depending on which size of armature they use.

One of the requests most favored by ladies, is to have more hair styles, more emotes, and to have real time cloth physics, for hair and clothing.

Nalates wrote:If poor performance was not on the server side, not in Plazma, not in PhysX, and not in DirectX/OpenGL then where was it coming from?

From the only place you haven't yet mentioned. Not the third party pieces that were plugged into it. Those were optimized by the relevant third parties. Not the renderer (DX), not the server (plServer), not the physics plugin (PX), the client itself. (I'm ignoring the word "Plazma" because it doesn't mean anything) Specifically, the way it handled it's communication with the physics API, which was designed for Havok and then was retrofitted to have PhysX unceremoniously stuffed into it.

Nalates wrote:@ Nad… I did not respond to what I thought you were thinking… I responded to what you wrote, which was my point in the PM you are plagiarizing. Since there are no emotes or clues and I don’t really know you… and I try to avoid projecting my interpretations, I am not ashamed to have missed it.

The point of the PM I was plagiarizing seems to have been that the recipient wasn't correctly interpreting your words, which were completely open to interpretation. My words were as well. Words do not have an intrinsic meaning, their meaning is the result of the interpretation provided by the reader. So yes, you did respond to what you thought I was thinking. Unfortunately, it wasn't what I was thinking, so I provided a clarification, (admittedly a rather snarky one) after it became evident that you had settled on the wrong interpretation.

Paradox wrote:Nalatez wrote:

But Nadnerb, if people will only upgrade to a modern GPPU (nVidia), physics will be virtually a non existant problem

Nalates wrote:If poor performance was not on the server side, not in Plazma, not in PhysX, and not in DirectX/OpenGL then where was it coming from?

Plasma doesn't use OpenGL (yet).


@Grogyan
Also, about cloth sim... please no. The physics is already causing a slowdown as it is. Adding this would make the problem 100x worse.

I can't see why adding cloth physics would make much difference, 8800GT and higher can process it all quite well, using various nVidia programs as benchmarks
It sure doesn't make any difference in SL

Because as chip says the physics are what makes everything run like crap. I can say from experience actually programming a physics engine into my gameengine that it really is a huge performance-hit.

Also, the number of people currently using new hardware is small. I'm sure with the computer and graphics you have, lag doesn't seem as big of an issue as it does to others.

Client framerate is bad. Physics is slow. Let's not add completely needed physics function-calls until the game becomes playable with more than 20 people one spot in an age.

It was just a suggestion, as I have no experience in programming physics to anything.

So then I guess the real question is, whether there is enough people here in the fan community that know enough about the DirectX API, that can refine the physics in a more supportive way?

PhysX and its implementation into Plasma is what I think the we should do wrangling with to increase framerate. Also, making the plPipeline shorter.

Currently there is a lot of processing before sending an object to the graphics card. If this could be shortened, even if the graphics take a hit when there are lots of avatars/objects at least your CPU and system memory (assuming you're not using shared video memory) won't have to work so hard.

Here's a plan for making the pipeline shorter (just really popped into my head):

Back in the days when the plPipeline was first written (1999 maybe, I'd have to check my Headspin history) graphics cards had a lot fewer extensions (read, hard-wired stuff including some fairly high-level goodies). In most cases you can do similar stuff using your CPU.

If you have a certain extension depends on your card (very new cards are able to do quite amazing things all onboard--some can do physics calculations). Most modern cards have piles of extensions.

Antialiasing for instance, can be done two ways in a 3d application: The first way is to use the CPU (software), the second is to use the GPU extension (hardware). The GPU way is much faster.

I'm thinking that there are some things in the pipeline code that could be switched from software to hardware, leading to less CPU and system-memory grunt-work during the rendering process.

Cyan _has_ updated the pipeline over the years. But I'm thinking there's at least something that could be made to use GPU rather than CPU.