Converting DX8 to DX9 a work in progress

So... What? Nobody uses the meshloader functions because they're too slow when polygon counts rise?
But what about skinned meshes? How the crap will I help my friend who started 20 years ago trying to do
his 3D game fix it to work with raw polys and custom vertexes?
Someone tell me there's a way to optimize all of this reasonably...
I note the type library from DX9 hasn't got higher functions and I went back to DX7 and discovered both it
and DX6 didn't have meshloader functions either, nor do they have a helper library.
---WELL THAT WAS SOME HELP---
They messed him up real good.
Can anybody help us???

Hi!
As I wrote - I was very busy, so long did not answer.
Today I had time and I reviewed your example.

1. Slow loading model because the model is saved in text format, if you save in binary, then will be much faster.
2. Render the model slowly because it contains 436 subsets, it very much. Render each subset - is an implicit:
SetFVF
SetIndices
SetStreamSource
SetMaterial
DrawIndexedPrimitives
And other functions. As well as a clear call to SetTexture. All these functions are heavy. But is likely to have possible to reduce the number of their calls. Each subset contains different material. Is it realistic to require different materials, or is it just the rubble upon conversion of the .3ds format? Can materials are different, but their number is not great?
The model uses about 100 textures, combining the subsets just a texture - it will be 100 cycles instead of 436.
If the texture coordinates are not out of range 0 .. 1, the texture can be combined into a texture atlas. In your model they come out of this range is the range coordinate tv 2 .. 3, perhaps it is also the result conversion from .3ds, but it is possible to compensate for this to 0 .. 1! I can do this, then all the textures merge into one, and the performance will be higher than in my example HighPoly.

But I'm busy, I'll be done slowly. How to make the first demo - give EXE, then there is going to talk about the payment and the transfer of source.
I ask that you use your messages as a competent and simple English - I speak it badly, and even Google translator can not handle. :)

Oh- Mikle! I didn't mean that you were not doing your job, I was asking everyone else about DirectX 8 and meant no insult to your speed of work.
I am pleased to hear that you are still working on this project, and yes, you can expect some payments when you feel the time is ready to begin. The method of payment you must decide.

About the sample mesh:
This represents worst case mesh sample. It pulls 7 FPS here in DX8.
I cannot test in DX9 without a mesh loader in the type library.
I appreciated your suggestions about optimization, but it has also been my frustration that people with newer machines and C++/'Doom3' seem able to use as many textures and polygons in a scene as they want to.
I thought it was about as optimized as I could, since instead of textures, I used only materials for color change.
I have only recently learned about 'sprite sheets' and 'texture packing', but I haven't addressed the sheer magnitude of readdressing the texture coordinates to the packed sheet.
I noticed only a moderate improvement when I reduced the texture/material maps to 1 on 'mapunmoving', and after all, the objects have to get their colors somehow.
I have a handwritten macro to export to .x file from 3DS Max.
The speed at which a level loads is not an issue at present, since I also include bounding box information in the comments at the bottom of the file.
Max uses decimals on the material color values and sometimes maybe the close ones are the same one.
I suppose that grouping the meshes by material might work, but the frames for the individual objects represent objects that move seperately in the scene.
And we have not addressed transparency... These objects have to be sorted by farthest distance from the camera otherwise they look totally wrong.

If you are able to reach even 27 frames/second with stock .x as it is, you will beat Microsoft's meshview (written in C I guess...)

I also have 12 detailed actors of 8400 polys with 184 joints and 6 textures/materials, when all 12 are displayed, we slow to a crawl also.
How do we get modern video game speeds, or is VB6 just not capable of this? I've seen many monsters together overwhelming the player.
What about Progressive meshes - probably vital
What are the frame rates on your modern machine with modern OS?

---

Update:
Scale of texture coordinates was for tiling textures multiple times across a surface.
I now understand the need for attribute sort of the triangles by material number used.
I cannot understand how to reduce vertex (point) count using vertexduplicationindexes
I do not have a .x file optimization tool. The .x file exporters written for 3ds max 5 are all poorly written.
I hope my english is more easy to read now for you in the translation tool Google.

Quote:

---

I hope my english is more easy to read now for you in the translation tool Google.

---

Yes!
I sent example to your mail, but the reply I will write here because it might be interesting to someone else.
Little performance over DOOM3 :) not caused by application VB6, D3DX8Mesh makes a lot of excess on each call.
This is not a universal tool, ready to convert models, this is an example, which converts this particular model.
On my computer, my example shows 1300 fps, the video card - GF260GTX, screen - 1680 * 1050, the rest is not important.
I did not import the materials from your model, if you combine all the textures in the atlas of 1024 * 1024, and designate each material point of the corresponding color, the performance still grow up.
Not necessarily use the Progressive meshes, you can do several LODs (Level of Detail) with 3DS Max and each level convert separately.
Transparent polygons do require sorting, there may be different types of optimization according to the scene.
For example, on the tables in the room are 50 aquariums, each of 50 polygons. Instead of sorting the 2,500 polygons, you can sort only 50 aquariums and aquarium store for Model 3 .. 4 pre-sorted index buffer, and choose the buffer, which is more suitable.
The games use clipping the geometry that is not visible, this is different methods - frustum culling, portals. Game space is divided by quadtree or octree.
For a set of small objects, such as bullets and fragments can be unnecessary after the separation with octree collect the required one vertex buffer. To do it in every frame, and it will increase the speed.
That is a lot of techniques, to experiment, to choose suitable.
The performance in VB6 is quite high, in a pinch you can make the slowest fragments in DLL for C++. This may be procedure sorted or passage octree.

We have figured out the mesh optimizations used in .x files now and will test this again with DirectX8. File size fell to 1/3 (ASCII)
You say that the DirectX8 meshloader has some overhead and I understand this now as you said:
SetFVF
SetIndices -- not sure, but represents the 'drawsubset' part of D3DX8 with drawindexedprimitives below.
SetStreamSource -- to the vertex buffer
SetMaterial
DrawIndexedPrimitives -- so I was right to pack as many triangles as possible into my single 'mapunmoving' object, yes? Just use as few material/textures as possible...
And this is performed for each mesh.
We presently render separately in order by:
mapunmoving (no texture coordinates)
mapunmovingTV (texture mapped)
mapunmovingA (alpha parts of stationary scene)
looping twice here in order by distance (super quicksort used~ 2 milliseconds)
normal separate moving objects with 2 subsets each, loop1 material/texture, then loop2 alpha

Further categorization of meshes by FVF would reduce 1 level. We could do that. Curious- what about using maximum FVF with xyz, normal, diffuse, tex1 (position, normal, vertex colors, and 1 texture coordinate) waste of space? It would depend on how many triangles in the mesh, but is the speed the same with hardware?
The only other type of mesh would be skinned mesh weights -- xyzb1, normal, diffuse, text1 my mesh bone weights are never any number but 0 (no effect) and 1.0 (full bone effect).
So a maximum of 3 or 4 types (skin mesh with vertex colors in far future, like robot or something, not used yet)

We are now working on a way to tile textures, but our problem now is that we are having to write our own tool for this and to find a way to re-map all of the .max source files manually (a lot of work)
It is fortunate that we kept our texture sizes small however, and wonder what advise you can offer regarding a sprite sheet tool and texture coordinate re-mapper?
We hope for a big increase in frame rate, but are conservative if it will give much improvement since similar tests involving removal of texture maps did not seem to help much here.
It may be our hardware - Pentium 4 3.6Ghz NVidia FX5500 AGP (Anyone?)

So drawprimitives I have used in the distant past and am somewhat familiar with it - not indexed primitives
This would be suitable for 60 to 90 percent of the scenes, but the skinned meshes without D3DX8 style manipulation of bones would be an absolute nightmare to us.
So if you simplify meshloader to restrict mesh types in some way so that we know how to best feed it with .x file data of sequential meshes, heirarchy for skinned meshes.
Restricting to 1 to 10 materials with texture map would require few changes to the scenes, but mapunmoving will then require automatic sprite sheet generator...
Tossing out the .x file format loading capability would waste many years of work we have done. A simple loader would be better than no loader at all.
But skinned meshes are not very simple...

I finally was able to get to the sample you sent me (I was gone a while and they had done some server maintenance).
WOW, optimization, conversion, AND a loader.
We pulled 45 frames per second here with no changes to your demo.
I will now turn my attention to texture optimization instead, using a sprite sheet for the arcade games.

It looks like all that we need is:
1. skinned meshes loading
2. simple alpha transparency by entire object, pre-process object parts with .tga texture and/or object part with diffuse material
we could pre-process and split pieces off the mesh and put new mesh together with a different name prefix, but the same center of rotation?
sorted and render separately.
3. materials
4. texture transformations
5. access for switching textures for animation by our program
We do not use standard collision checking and so we do not need per-face collision checking, only in very special case...D3DX.Intersect for target shooting.
(2D with altitude bounding boxes in array already finished a long time ago)

Are most of the other common features supported in the dll such as lights, fog, etc? I haven't really studied it yet, but I will do so now.
I don't know how similar dx9 is to dx8, but I am assuming you are converting the API call names to be similar to their C names that would be used?

Thanks again for all your efforts on our behalf.
Joe

About the mesh: You'll note the abbreviated material faces and the dummy skin joint 'table' (not the mesh, the bone) used as placeholders for geometry to rotate around.
The dummy joints are very common in the more complex models we use.

I have included a very small and simple skinned mesh. I have also included the 'Ascending Radix American Flag Sort' by Ralph Eastwood 18/07/2006 - supposed to be fastest in the world (in VB6)