Rainmaker

Members
  • Content count

    126
  • Joined

  • Last visited

Community Reputation

122 Neutral

About Rainmaker

  • Rank
    Member
  1. Hud blitting

    Thanks. I had a feeling that was the case, but I had to ask first. Good thing the original code is still around. Also, the DX font interface runs like molasses. Is there a way to bitmap it or something with a function call to get a speed boost? I suspect it would be wiser to write my own...
  2. Hud blitting

    I am working on a 3d project which uses DX9, and the team leader wants me to do the GUI/HUD rendering via blitting to the back-buffer (instead of in ortho mode). He thinks that should be at least just as fast as ortho mode. Is that true? One of the main issues that I can't seem to figure out is alpha testing or blending. Are either of those possible with blitting? How do most of you do HUDs and GUIs? Thanks.
  3. Slow rendering

    Hot damn, 522k+ polygons at 60 frames per second, including culling algorithms. That is all. Thanks ~ Paul Frazee.
  4. Slow rendering

    Thanks for the help. I actually knew most of what you guys are telling me, I just needed a few refreshers. With a test load of 130k polygons I get 40 fps without VBOs and 130 with. I ended up instituting a polygon range builder for each state change. Unfortunately, it has to work by polygon because my triangles are unsorted right now. Since my octree doesn't share triangles, I will sort the triangles (just indices) by node, which will make for faster culling. If I am really crafty, I may be able to use it to impose the range restrictions in RangeElements, but that is iffy. Then I will interleave my data, which will set my fetch right at 32 bytes. Silvermace, it rendered 300,000 triangles per second, or 300,000 triangles per hundredth of a second? You put tri/s, but then said 100fpsish, so that is why I ask. ~ Paul Frazee
  5. Slow rendering

    ok, thanks for the tips.
  6. Slow rendering

    Well if I want to render in chunks, then I am going to have to do something like build a listing of triangles to be rendered every frame to take advantage of culling. I could create a listing of ranges I guess... any better ideas on that? And just in case, is there _any_ way to salvage my indexed vertex mesh? Is that just a bad idea? Should I just go ahead and start crying over the lost time? ~ Paul Frazee
  7. Slow rendering

    Age old problem - rendering is too slow. My system has two limitations on the way polygons are rendered: 1) I use an octree to do frustum culling, and 2) polygons have different rendering states (texture, etc). As a result, I can not render in chunks - unless, of course, I ordered the triangles by render state within each octree node. I could try that, but I don't think the speed increase would warrant the work. So as it is, I use glArrayElements with vertex pointers to specify the rendering data (GL_TRIANGLES). Even if I remove the render state code and octree code, just rendering all of the polygons, I get 13 FPS rendering ~130k polygons on a Dell Inspiron XPS notebook (3ghz HT, 1ghz ram, ati radeon mobility). If I draw it all at once with glDrawArrays, I get about 55 fps, so I know that it can be done. I tried switching to indexed vertices (I had a question thread on that earlier, but by spatially partitioning the polygons, I got it down to a suitable speed), but I found no speed increase at all, which seems odd to me. The idea is to lower the amount of data transfered to the card (and stored on the card). What am I doing wrong with that? Also keep in mind that I cannot draw in clumps if I use indexed vertices. Also, do VBOs work with glArrayElement? It works fine with glDrawArrays, but my app just kinda hangs if I use glArrayElement. Thanks ~ Paul Frazee
  8. I am writing an algorithm to convert uncompressed triangles (3*trianglecount vertices) to indexed triangles (no duplicate vertices, triangles consist of 3 indices), and need to optimize a bit. My existing algorithm is pretty simple: for i=0 to PolyCount-1 for j=0 to i-1 if vertex[i] == vertex[j] isaduplicate() endif endfor endfor It works, but it is slow. O(nlogn), right? Any ideas as to a better algorithm? I considered some kind of spatial partition alg... but I can't be sure how much faster that would be. Any better ideas? ~Paul Frazee
  9. I am working on a level editor, and need some help with the texture coordinate transforming. The only level editor I have ever really familiarized myself with is Worldcraft, so a lot of my designs are borrowed from it. It works in modes - first is the primitives mode, in which you create the major level geometry using combinations of cuboids, spheres, and cylinders. Then you go to material editing mode, which combines the primitives with CSG and allows you to set textures and align them. The problem is getting good texture coordinates, regardless of the vertices. Here is a picture of what I am talking about: As you can see, the texture is distorting. Right now, I am using the texture matrix to do it. I have tried different orders, but that screenshot was rotate, translate, and scale. Thanks in advance for any help.
  10. Octree woes

    Thanks for your help, and sorry I didn't respond - I set this thing to email me on responses, and it never did. I ended up realizing the solution while in bed, heh. Thank you very much for your help.
  11. Octree woes

    I have a little bug in my frustum culling. I am sure this is addressed somewhere, but I can't find it. I made some purty pictures to illustrate my issue: Thoughts?