Kavan

Your code seems a bit strange. How can you store multiple keys in m_ProcessResult? You need a separate flag for each of the keys.

I doubt tests like this could have such an impact on performance. There must be something else that's wrong. What's the difference in speed between debug and retail build?

I can't spot anything out of order. Have you tried profiling?

[C++] IDirect3DDevice9 *dev = (IDirect3DDevice9*)device->GetObjectByValue(-759872593).ToPointer(); [/C++] Don't change the number! I'm not sure if you can do the same in C#. You can get the IntPtr, but I'm not sure how you'll call functions on it.

If you'd like to know what skinned meshes are about you can check this article: http://www.3dlevel.com/forum/viewtopic.php?p=1250#1250 It has some theory explained and setting up skinned meshes in VB.NET (rendering is not explained, but is in the attached project; it's for original DirectX9 (not Summer Update 2003)).

First the architecture of Mesh class. It basically has a vertex and index buffer and the attribute ranges define what is rendered in a single call to DrawSubset. The best way as I see it if you want something along this lines would be to define each node in octtree to have a unique attribute. You would probably want to group it in a way that neighbouring nodes have neighbouring attribute indices. You would do this for each original attribute in the mesh (it's even better to just assume there's only one material/texture and if there are more just treat them separately). Then you'd call optimize to do attribute sort. That way vertices get rearranged to minimize cache misses. Then in the rendering phase you wouldn't call DrawSubset but directly calling DrawIndexedPrimitive in a way that if more consecutive attributes are to be rendered you render them in a single call. All this makes sense only in very big buffers and you'd probably run out of buffer size before you get any benefit. Reason behind this is that this increases the number of DrawPrimitive calls which is the biggest factor determining the speed of your app. So as far as I know the way to go around this is to stream the data that should be rendered into a dynamic vertex buffer. Again, this makes sense only if you have huge scene graphs where vertex fill rate is of real concern. In most cases when geometry is not that intensive it's best to do simple frustrum tests and just brute force the whole mesh.

There's a lot of things that are bad in here performance-wise but I'll just point to the main problem you have. When you're using attributes to gain performance it is not meant to be used with DrawSubset. If you want to get any benefit at all then you have to use attribute data to derive parameters for DrawIndexedPrimitive call. Another thing to have in mind is that vertex range defined in attribute is not the thing to check while computing boundaries, you should check the face range and get the vertices in attribute from the faces. If anything needs clarification (and I guess it does) just say so.

Yes you can use managed DX in C++. But to clarify some more things. The only reason I see why one would want to use C++ (besides bugs in MDX) is that you want to optimize some parts of your code. Out of experience I have found out that less than 1% of code needs optimizations and most of them can be achieved with unsafe code in C#. I would never start with C++ as you'll have tons of problems debugging your program. The right approach as I see it is to first write the code in pure managed code (C#, VB.NET) and only after profiling makes it clear which code is slowing your program, port it to unsafe code in C# and only then to native C++. The reason for this is that production is much faster in managed lanuages and it's easier to track obscure bugs like memory leaks as there aren't any. Another point is that once you've written the managed code it's already working. And porting working code is way less error prone than coding it from start. I hope this will give you something to think about.

I've taken the time to test your code. It works ok for me. Where do you get an exception. Do you use HAL device? The most common mistake is that your device does not support that many bone weights as are required by the mesh.

Managed DirectX is written in c++ I guess. I doubt you'd do a better job at it (although there are quite big holes somewhere and I was forced to write my own wrapper for some of the broken functionality). If documentation is your problem wait for SDK 2004. It's quite possible to help yourself with c++ documentation however as most things are 1 to 1 mapping. To answer your question. Yes it's possible to create a wrapper in c++ and use it from vb. But you can't leave it completely open. Meaning that you can't expose the raw objects but have to provide wrappers for all of the methods. Reason for this is that vb cannot use unsafe code (no pointers in vb).

Don't worry too much. That's just how it is in c world. Everything there is by value, you have no reference types. So in this case it's the equivalent of passing an array byref. They have to cast to void since that's the declaration of the function and it's an upward cast and that must be explicit in c.

What kind of textures do you use? Perhaps it would be easier to track the problem if you'd post a simple project that reproduces what you're trying to do.

Do you set the texture states? Something like: device.TextureState(1).ColorArgument1 = TextureArgument.Current device.TextureState(1).ColorArgument2 = TextureArgument.TextureColor device.TextureState(1).ColorOperation = TextureOperation.Modulate device.SamplerState(1).MagFilter = TextureFilter.Linear device.SamplerState(1).MinFilter = TextureFilter.Linear Maybe you'll also have to set AlphaOperation.

I usually use a picture format that already has an alpha layer like tga or png. If you need colorkeying just do as ThePentiumGuy suggested.

device.SetTexture(0,texture1); device.SetTexture(1,texture2); PieceMesh.mesh.DrawSubset(i);

You have to first set both textures and then only call DrawSubset once.

Try setting VS to break into debugger when any exception is thrown (Debug->Exceptions). I hope this helps, I haven't had the time to check your code.

If you're only concerned with device lost, then you only have to take care of objects in default memory pool. Objects like Sprite have their own methods that you should call when device is lost or reset (you'll find the right methods by their name).

With device.TextureState(0) .ColorOperation = TextureOperation.Modulate .ColorArgument1 = TextureArgument.TextureColor .ColorArgument2 = TextureArgument.Diffuse .AlphaOperation = TextureOperation.Modulate .AlphaArgument1 = TextureArgument.TextureColor .AlphaArgument2 = TextureArgument.Diffuse End With With device.RenderState .AlphaBlendEnable = True .SourceBlend = Blend.SourceAlpha .DestinationBlend = Blend.InvSourceAlpha .AlphaTestEnable = True .ReferenceAlpha = &H8 .AlphaFunction = Compare.GreaterEqual End With If you set the states like this then if the texture has an alpha value stored in it, you'll get transparency. Sorry it's in VB.NET, but I guess you can manage.

Here's a solution for you: Frame.RegisterNamedMatrices(RootFrame, AnimationController) Bones are matched by their name.

What you need is to use transformed vertices. Or just use Sprite class as it does that for you in the background.

Yes I'm the same guy. Where have you heard about Artificial Heart?

This is a known bug in MDX that will probably be solved for the next SDK update. Use the following workaround for the time being: Try mAnimationController.ResetTime() Catch mAnimationController = Nothing End Try

You have to provide it ray in the model space. This means that you need a point in space and a direction. If you have this data in world space then you'll have to transform it to model space by multiplying by inverse of world matrix. It'll return true or false telling you if the ray hit the model. Some overloads also give you further information about which face exactly was hit and so on...

You call Dispose on them.