Deus Siddis wrote:chuck_starchaser wrote:What part of it, Turbo? I thought using mesher was alredy in the wiki.
Maybe he means your avoiding overdraw comments, the wiki doesn't have anything on that. I mean I think everyone knows it's something to avoid, but when they do need to cut some corners, they are not sure where exactly to cut them.
I see; maybe I should write a wiki on mesh optimizations. Thing is, this is in the public knowledge, like here:
http://www.ericchadwick.com/examples/provost/byf1.html
http://www.ericchadwick.com/examples/provost/byf2.html
But I guess it wouldn't hurt writing a practical summary of do's and dont's.
Like before I didn't know that it was rendered surface area or pixel count of the occluded area on screen that determines how much extra work it is for the gpu. I might have guessed it was the number of occluded vertices.
Occluded vertices are yet another waste, but the thing is: There are two pipelines in a gpu: The vertex pipeline at the front, and the pixel pipeline at the back. The output of the vertex pipeline feeds into a small, hidden pipeline called the "triangle set-up" pipeline, whose output feeds into the input of the pixel pipeline; but we don't care too much about triangle setup here. The point is, whichever of the two pipelines runs slowly, it slows down the other. But as the years rolled by, the vertex pipeline got more and more powerful. Well, the pixel pipeline too; but not as much, because the pixel pipeline is hitting against a hard wall: memory latencies and bandwidth. So, it's very unusual for a mesh to be slow on the display due to too many vertices; most of the time it's the number and sizes of the textures, and pixel overdraw, that are the speed-bumps. This is not to say you can have a million vertices in every mesh, of course; but I'd worry much less about hidden vertices than about hidden texels.
EDIT:
A caveat: If the user turns on FSAA, then pixels crossed by edges have to be split into sub-pixels, so heavy meshes CAN increase (or rather DO increase) the pixel pipeline's workload, when anti-aliasing is turned on.
For a rough estimate, if you set FSAA at 4x4, that's 16 sub-pixels per each pixel split, so if your mesh splits 1/16th of the pixels on the screen, you've basically doubled the number of pixels to process. Unfortunately, I can't think of a simple rule of thumb to say how heavy a mesh would cause 1/16th of all screen pixels to be split, but avoiding excessive geometry is, of course, a good thing. Just not nearly as big a concern as overdraw.
Also clarifing the comparitive inefficiencies of two separate meshes within the same model that are not intersecting versus those that are. Are they both considered overdraw, is the intersecting situation alot worse?
No; intersecting is nothing special to a gpu; it gets resolved by z-buffering/testing (albeit z-fighting artifacts) during draw. The problem is that, unless you remove hidden surfaces in code (some engines do this, but it's hard), the gpu has no way of doing it for you. It draws ALL surfaces, hidden or not, and which surface covers which is decided by z-buffer comparisons, on a pixel by pixel basis, during frame draw. If you have many overlapping surfaces, the gpu will have to paint, or try to paint, every pixel on the screen where those surfaces overlap, multiple times.
Just to clarify, the gpu does cull about 50% of surfaces: those that face away from the camera. But this is easy to test (normal dot eye being positive or negative (well, it actually decides by clockwiseness of the vertices, but nevermind); so you don't need to worry about overdraw versus back-facing surfaces. But culling of front-facing surfaces based on coverage is something the gpu cannot do at the geometry level; it has to do it by z-testing pixel by pixel, while drawing to the screen.
This sort of detail could be really useful, maybe in your how to weld howto.
Ok, I'll try to put together a mesh optimization wiki.
(And that it looks like someone already added your info on creating diffuse, specular and shinniness maps on fendorin's archimedes thread to the wiki.)
Cool; that was probably Pyramid.
EDIT:
Thinking about the ideal tool for artists, rather than a gui for mesher, what would really rock is a ship visualization tool that integrates bfxm AND units.csv production.
First of all, using just ANY test scene is not right. There should be ONE test scene for all artists to use. Your ship should appear in a fixed location, near a station that in turn orbits a planet, and a few stationary ships nearby, so that one can tell, at a glance, how one's ship compares to other ships in terms of materials used and overall diffuse brightness and specularity.
Secondly, there should be a gui window in a corner that allows you to add .obj meshes and textures, choose blending mode and technique, add LOD's, etceteras.
All changes of parameters and reloadings of obj's or textures should have immediate effect on the ship viewed.
Thirdly, it should allow you to position weapons, subunits, engine exhausts and pilot.
Fourthly, it should allow you to move forward, to see if the ship's mesh orientation is right, and to change it otherwise (90 degree rotations).
And there should be a Save button which:
a) produces a folder under units
b) saves the bfxm and textures to it
c) saves the modified units.csv
e) saves a diff to apply to units.csv, to submit with the package
Am I dreaming in 64-bit color?