With the strange output you are getting, does it look like one of the texture is applied and not the other one? I would think that you could use PIX to inspect that state of each of the textures and vertex/index data before and after rendering. Just take a single frame grab and inspect all of the draw calls. (I'm pretty sure you can use PIX even if your rendering code is in a dll...)
Perhaps that will give you a clue about what is wrong, then if you still can't figure it out you could post the PIX file here to see if anyone can help.
Weird overall problems when using D3D9 in plugin... [SOLVED]
Author
That's a good thought there. I'm now using this:
And when I run the host app, it now shows a messagebox 5 or 6 times (numMaterials) with twice just "bihull.bmp" and then "wings.bmp" and also twice it's empty, I suppose that these are subsets of the model without texture. In these two empty cases I get the two "invalid filename" errors in DebugView. So it does find the textures fine and it can't be a pathing problem. Also, it finds the model just fine and everywhere where there's the model, there's also the two textures, I double checked that. Additionally, I'm pretty sure I see the shading of the wood even in my weird version, that couldn't be a standard material?
JasonZ, I have uploaded the PIX file here, I can't quite make much out of it but I see the two textures in there, I think, so it does load them.
Thanks a ton so far, I hope we can crack this nut! :)
for(DWORD i = 0; i < numMaterials; i++) // for each material... { MessageBox ( NULL, tempMaterials.pTextureFilename, "Texture filename", NULL ); material = tempMaterials.MatD3D; // get the material info material.Ambient = material.Diffuse; // make ambient the same as diffuse // if there is a texture to load, load it if(FAILED(D3DXCreateTextureFromFileA(d3ddev, tempMaterials.pTextureFilename, &texture))) texture = NULL; // if there is no texture, set the texture to NULL }And when I run the host app, it now shows a messagebox 5 or 6 times (numMaterials) with twice just "bihull.bmp" and then "wings.bmp" and also twice it's empty, I suppose that these are subsets of the model without texture. In these two empty cases I get the two "invalid filename" errors in DebugView. So it does find the textures fine and it can't be a pathing problem. Also, it finds the model just fine and everywhere where there's the model, there's also the two textures, I double checked that. Additionally, I'm pretty sure I see the shading of the wood even in my weird version, that couldn't be a standard material?
JasonZ, I have uploaded the PIX file here, I can't quite make much out of it but I see the two textures in there, I think, so it does load them.
Thanks a ton so far, I hope we can crack this nut! :)
Author
Okay, again a final bump, if nothing new comes in I'm gonna leave it at that.
BUT, new insight, I'm now loading a test texture, discarding the textures loaded from the .x and instead loading a debug texture that looks like this:
And check how the model renders now:
So it seems my initial impression of it only taking the top portion of the texture was correct.
Now the question is pretty much: any ideas as to what a user could possibly do to a d3d device/environment for it to do this to textures? What can I do against that?
As I said, I'm not sure as to how much you guys can help me with this (of course I also tried contacting the author of the host app etc., no answers yet tho) but maybe somebody here has had a similar experience or is able to read something out of the PIX report or whatever.
Thanks.
EDIT: Okay, the texture seems solved now, must've been something with the model that I can't explain. I'm now testing with the tiny.x sample from the SDK and its single .dds texture and it's working just fine. What's left is zbuffering though...
[Edited by - d h k on July 24, 2009 4:56:57 PM]
BUT, new insight, I'm now loading a test texture, discarding the textures loaded from the .x and instead loading a debug texture that looks like this:
And check how the model renders now:
So it seems my initial impression of it only taking the top portion of the texture was correct.
Now the question is pretty much: any ideas as to what a user could possibly do to a d3d device/environment for it to do this to textures? What can I do against that?
As I said, I'm not sure as to how much you guys can help me with this (of course I also tried contacting the author of the host app etc., no answers yet tho) but maybe somebody here has had a similar experience or is able to read something out of the PIX report or whatever.
Thanks.
EDIT: Okay, the texture seems solved now, must've been something with the model that I can't explain. I'm now testing with the tiny.x sample from the SDK and its single .dds texture and it's working just fine. What's left is zbuffering though...
[Edited by - d h k on July 24, 2009 4:56:57 PM]
Ack! I checked out the PIX file, and it is using fixed function texture stage states! Unfortunately I haven't touched those in many years, so I can't offer help. However, from my memory it is pretty easy to mess up the states and get a completely different result than you are expecting. One possibility is that someone enables alpha blending, making the object seem like it is rendered in the wrong order? I see both diffuse and alpha stage states being set in there...
Perhaps someone more recently versed in the fixed function could chime in?
Perhaps someone more recently versed in the fixed function could chime in?
If I understand correctly, you're using a D3D9 devices handed to you from another app. In this case you can't rely on default settings, which my guess is that you do.
For example, it's possible that your model is using texture coords outside the [0,1] range (perhaps by mistake), and since the default texture addressing mode is WRAP, it works, but the device you're getting might have set them to CLAMP. Similarly, the device might have disabled Z (or, worse, not created one, in which case you might have to do it yourself).
I haven't looked at the PIX file, but you can check the state of the device there. Open the device object and look at it on the relevant drawing call. Compare to a capture of your program with a device you created yourself.
For example, it's possible that your model is using texture coords outside the [0,1] range (perhaps by mistake), and since the default texture addressing mode is WRAP, it works, but the device you're getting might have set them to CLAMP. Similarly, the device might have disabled Z (or, worse, not created one, in which case you might have to do it yourself).
I haven't looked at the PIX file, but you can check the state of the device there. Open the device object and look at it on the relevant drawing call. Compare to a capture of your program with a device you created yourself.
Author
Ah, okay, that makes perfect sense. Let's forget about the textures now as they work and I guess if I plugged that other airplane model in and checked all the settings (such as whether WRAP is enabled or not), I'd get it to work too. As I said, I now have a model that's textured perfectly fine.
The last thing that I need to work is the z buffer. You are right, ET3D, the host app does definitely NOT create a z buffer, I need to do that in my plugin. The problem is: I thought I'm doing that, I modify the present parameters (EnableAutoDepthStencil to TRUE and set AutoDepthStencilFormat), use the SetRenderState function to enable z buffering and clear it at the beginning of every frame. That's all I can find for z buffers in D3D9, is there more to it?
This is probably a really easy question now, so if this is easy to do and solve then I finally have everything in there I need, already you've all been really helpful, thanks!!
The last thing that I need to work is the z buffer. You are right, ET3D, the host app does definitely NOT create a z buffer, I need to do that in my plugin. The problem is: I thought I'm doing that, I modify the present parameters (EnableAutoDepthStencil to TRUE and set AutoDepthStencilFormat), use the SetRenderState function to enable z buffering and clear it at the beginning of every frame. That's all I can find for z buffers in D3D9, is there more to it?
This is probably a really easy question now, so if this is easy to do and solve then I finally have everything in there I need, already you've all been really helpful, thanks!!
Are you actually setting the depth buffer in the device:
IDirect3DDevice9::SetDepthStencilSurface
You would need to do this prior to enabling the depth buffering, but should only have to do it once (unless the remainder of your application sets NULL in its spot instead...).
IDirect3DDevice9::SetDepthStencilSurface
You would need to do this prior to enabling the depth buffering, but should only have to do it once (unless the remainder of your application sets NULL in its spot instead...).
Author
And that did the trick. Wow, major thanks to everybody for helping me out a lot and not getting frustrating with me and my D3D noobieness... :)
Quote:Original post by d h k
And that did the trick. Wow, major thanks to everybody for helping me out a lot and not getting frustrating with me and my D3D noobieness... :)
Everyone starts somewhere - welcome to the club!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement