Page 7 of 7 FirstFirst ... 567
Results 91 to 95 of 95

Thread: Network data changes

  1. #91
    Registered User
    Join Date
    Nov 2002
    Posts
    48
    Actually it's the engine that has a hard time - I'm not sure how they draw the world - but I can tell ya it's the suck :P

    Ever wonder why the lag in the bazaar is bad? It's not the number of people - look at the ground and everything is fine - data packets are not dragging your comp down.

    The problem is when you look at a wall not only the wall is rendered - but everything behind the wall also.

    Every *new* model also has separate models for the teeth, eyes and such - all the armor is *over* the skin of the model that is drawn every time you look at someone even though you can't see it.

    *That* is why you need such a good system to run new models on.

    The old models used skins that actually changed the skin of the model when you wore armor - that's why they were alot less laggy.

    If they added the code - or fixed it - so when you *can't* see something it isn't drawn - everyone in EQ could play with all new models in the bazaar and never lag - even with an old geforce1.

    The actuall polygons are not *that* detailed - it's the layer upon layer with the stuff drawn behind the walls that causes such grief.

    Currently the only way to stop drawing stuff behind a wall is to narrow your clip plane down to where everything is in a fog.
    Quothe the raven, "Nevermore!" - Poe

  2. #92
    Registered User
    Join Date
    Feb 2002
    Posts
    62
    If I'm not mistaken, isn't that what the 3D graphics cards do for you, that is do all the drawing of objects for you? I don't believe that EQ program has to take into account your position relative to all the other objects and draw what is appropriate. My understanding is that the EQ program simply tells the graphics card the position of all the "objects" and your current position, and the driver and firmware for the card take care of the rest, including knowing which objects are behind other objects and therefore shouldn't be rendered on the screen.

  3. #93
    Registered User
    Join Date
    Dec 2001
    Posts
    1,262
    If I'm not mistaken, isn't that what the 3D graphics cards do for you, that is do all the drawing of objects for you? I don't believe that EQ program has to take into account your position relative to all the other objects and draw what is appropriate. My understanding is that the EQ program simply tells the graphics card the position of all the "objects" and your current position, and the driver and firmware for the card take care of the rest, including knowing which objects are behind other objects and therefore shouldn't be rendered on the screen.
    You are mistaken... read any book on 3D graphics.. when graphics cards can do realtime object occlusion, the world will be a wonderful place... For now, they do z-buffering to decide what objects are in front, but in order to do that, they still have to render (atleast partially) all of the triangles in the scene...

    --Jeeves
    "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Albert Einstein

  4. #94
    Registered User
    Join Date
    Nov 2002
    Posts
    48
    there is a process called bliting (spelling - heck it's been a few years)...

    This is where the software determines if a pixel is behind another pixel and if so doesn't draw the stuff behind - this is the basic premise behind a ray-engine such as Doom and Quake use.

    it would be more processor intensive to check the position of objects for obstruction - but I think that the overhead would be minimal compared to the processor time spent sending the data/textures/etc to the graphics card to draw - not to mention the drain that your graphics card takes...
    Quothe the raven, "Nevermore!" - Poe

  5. #95
    Registered User
    Join Date
    Dec 2001
    Posts
    1,262
    I do quite a bit of DirectX development in my spare time, here is the way it generally works:

    Object culling is done (maybe, maybe not in EQ.. no idea). This checks for OBJECTS (not polygons) that are obstructed by other OBJECTS, note: in EQ, the entire zone is an object.

    Backface culling is done (so polygons facing the wrong direction arent transformed, lit, or rendered)

    view frustum clipping is done, so objects outside of the view frustum arent rendered (think clipping plane)

    polygons are sorted by distance from the eye point (not strictly necessary on anything except for transparent polygons, but can save alot of time on the graphics card).

    rendering pass 1:

    Render all opaque polygons from closest to farthest from the eye point.. the video card (or software driver, if vid card doesnt support hardware z-buffering, which i think all do these days) figures out which polygon each pixel should take its color from... and does texturing, etc..

    rendering pass 2:
    Render all transparent polygons from farther to closest to the eye (so that multi-transparency works correctly)..

    this is the basic premise behind a ray-engine such as Doom and Quake use.
    EQ and any modern 3D games are NOT ray-cast rendered, that is an old technology used in games like wolfenstien, doom, quake 1, etc...

    This is where the software determines if a pixel is behind another pixel and if so doesn't draw the stuff behind
    This is called z-buffering, and it is done on the graphics card... and note, z-buffering works on a PIXEL level, not a POLYGON level...

    To see an example of what the z-buffer does, drop down to 16-bit color in EQ... if you have a card that decreases your z-buffer to 16-bit (instead of 32-bit), you will start to see jagged, moving, sawtooth edges where polygons intersect, particularly when the polygons are large... (go to Plane of Tranquility, and look at the water's edge..)

    If people are interested in these topics, there are some excellent books out there... here is one I liked in particular:

    http://www.amazon.com/exec/obidos/AS...651110-9650202

    Oh, and blitting is moving image data from one area of memory (video or otherwise) to another area of memory, with some action going during the copy (could be ANDing the source memory by destination, ORing, XORing, alpha blending, etc, etc, etc..)

    --Jeeves
    Last edited by high_jeeves; 02-15-2003 at 05:50 PM.
    "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former." --Albert Einstein

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Posting Permissions

You may post new threads
You may post replies
You may post attachments
You may edit your posts
HTML code is Off
vB code is On
Smilies are On
[IMG] code is On