Jump to content
  • Advertisement

fireking

Member
  • Content Count

    669
  • Joined

  • Last visited

Community Reputation

122 Neutral

About fireking

  • Rank
    Advanced Member
  1. fireking

    Toughest thing to program

    another program that would be hard to write is a program that fixes most computer problems *and im not talking no junk like windoctor*
  2. fireking

    Toughest thing to program

    hard to program a program that responds and reacts with emotion to a user's input, via voice/touch/sight/and smell although im not very specific, i do mean... emotion not just some static response that comes back everytime you do something and not just a random choice from a list of responses... either
  3. another example say you have a model in your game. he's a ninja and he has 3000 triangles. the ninja comes from behind you and jumps over your head, quickly appearing right in front of you at lightning fast speed! then he dodges to the left and escapes after landing. now, considering he is a lightning fast ninja, lets say he was only on the screen for 60 frames (a common time of about "1 second" in most 3d games). in that one second, do you think you would rather make 3000 calls (60 times in this one second, mind you) to your processor to find out if each triangle in his model was in the camera's view or not? or would you rather make one check/call on his bounding box? apply this same concept to terrains... which can easily be divided into 4/8/16/32/64 these chunks could save you thousands and thousands of cpu ticks, man. by checking only the chunks, instead of what the chunks contain.
  4. Quote:Original post by embpos Quote: if you try to process every single triangle, you have lots of cpu overhead... if you could divide whats in the world into little groups, then you could check if camera can see "group1", which might contain 300 triangles. thats one check compared to 300 checks (to find out if its in the camera's view) But this is no different from clipping out polygons that are not in the viewing frustrum. Number of polygons in frustrum is same regardless of rendering polygons per mesh, or whether you render polygons based on node grouping. I don't see why node grouping makes life easier for the rendering process. the reason why it makes it easier is because it reduces the amount of work the processor has to do to sort through all of your triangles to find out if they are in the FOV or not. in otherwords, the graphics api does not tell you, or have a way of letting you know that polygons are in the FOV. you have to mathematically figure it out for your self. all the graphics api does is DRAW things to the screen. a quad-tree system/oct-tree system is the art of grouping parts of your scene (polygons) into sections to decrease the amount of operations it takes to find out if something can be seen or not. in other words. you have to sort through every single polygon in your entire game world (or zone, map, whatever) and find out if its visible to the camera. if its not, dont draw it, if it is, draw it. if you were to group those polygons, logically (ie: "all of these polygons are next to each other, if the camera can't see me, then he can't see some of my neighbors"), its less work for the cpu because you just skipped 1500 triangles with one call (instead lf making 1500 calls for each polygon in the "group"). do you get it?
  5. Quote:Original post by Bliz23 Quote: Quote: if you try to process every single triangle, you have lots of cpu overhead... if you could divide whats in the world into little groups, then you could check if camera can see "group1", which might contain 300 triangles. thats one check compared to 300 checks (to find out if its in the camera's view) But this is no different from clipping out polygons that are not in the viewing frustrum. There is a differnce. Clipping is done after all the transformations to view space and after lighting. So all the triangles that YOU clip do not need to go through all those transformations. *nods*
  6. Quote:Original post by embpos Quote: if you try to process every single triangle, you have lots of cpu overhead... if you could divide whats in the world into little groups, then you could check if camera can see "group1", which might contain 300 triangles. thats one check compared to 300 checks (to find out if its in the camera's view) But this is no different from clipping out polygons that are not in the viewing frustrum. Number of polygons in frustrum is same regardless of rendering polygons per mesh, or whether you render polygons based on node grouping. I don't see why node grouping makes life easier for the rendering process. read what Oxyacetylene wrote
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!