Home > other >  Directx 11 Drawindexed model drawing is not complete
Directx 11 Drawindexed model drawing is not complete

Time:09-18

I recently in learning, its in the drawing of the cube program joined assimp read obj model based on function (read a model of a human body), but when according to the problem of the display is not all,

By drawing the model using the Windows built-in viewer open effect as shown in figure


Directly call Drawindexed function can only draw the part of the lower body and head, torso part among painting not to come out,
Reference code:
D3dContext_ - & gt; DrawIndexed (numOfPs, 0, 0);
Mapping results:


Cycle if the draw, and each draw a number of vertices (multiple of 3), you can display completely (integrity associated with each draw points, the less overall were drawn each point is more complete, but sometimes it does not necessarily)
Reference code:
int i=0;
Int DPTime=156;
While (I & lt; NumOfPs) {
If (I + DPTime & lt; NumOfPs) {
D3dContext_ - & gt; DrawIndexed (DPTime, 0, I);
I=I + DPTime;
}
The else {
D3dContext_ - & gt; DrawIndexed (numOfPs - I, zero, I);
I=I + DPTime;
}
}
Mapping results:


The same code reading other obj files also appears the same problem, map without careful processing, parts with a corresponding unity, not good-looking but should not affect the model shows that the complete, inquire of exactly what went wrong,
Program using ASDWQEJK keys can move the camera and rotating object
Vs complete engineering on baidu network backup
https://pan.baidu.com/s/1Ixl96ZN1VNgjFg1-Uaqt9w

CodePudding user response:

Have you set up the index?

CodePudding user response:

The Index also read from the obj file, the same data map can draw completely I points a few times, I don't think the Index itself should be read wrong

CodePudding user response:

refer to the second floor Etiennely response:
Index is read from the obj file, the same data map can draw completely I points a few times, I don't think the Index itself should be misread


Don't know, I will only dx12

CodePudding user response:

reference WJN92 reply: 3/f
Quote: refer to the second floor Etiennely response:

Index also read from the obj file, the same data map can draw completely I points a few times, I don't think the Index itself should be misread


Don't know, I will only dx12

Ok, still thank you for your enthusiastic help

CodePudding user response:

What is numOfPs?

The appearance of the picture seems to be two possible
Is a model with multiple submesh, you just drew one, also is a shown in the figure, other fundamental picture
Another possibility is that you give the drawing of the triangle number is not the whole model number

I suggest you can check the model itself how much is the number of vertices and triangles, and then compare the parameters of the drawing you give

CodePudding user response:

Quote: refer to the fifth floor P_hantom reply:

NumOfPs is all need to draw by the number of index points, is through the traversal assimp model read out after the transformation, the number I verified there is no problem, I make a direct output to a text of statistical, and the total number of partial draws both one-off drawing and drawing is the same),
I remember model has seven submesh, I later according to the submesh after drawing some submesh quoted the wrong
at the bottom of theD3D11 WARNING: ID3D11DeviceContext: : DrawIndexed: Vertex Buffer at the input Vertex slot 0 is not big enough for what the Draw * () call expects to traverse by. This is OK, as reading off the end of the Buffer is defined to return 0. Or the developer probably did not intend to make use of This behaviors. [EXECUTION WARNING # 356: DEVICE_DRAW_VERTEX_BUFFER_TOO_SMALL]
Literally is a vertex buffer is not large enough, I go to the search on the net, not solve the problem, I checked again the description of the cache and no found the problem, and I just changed the drawing method, does not change the other code, if it is really a cache is not enough so I every few vertices a group should draw not to come out, but the truth is every couple of a group of basic drawing can be completely, directly paint only about half together, can draw 7, 8 points submesh drawing into,
Model reading should be a full, on the one hand, after I have read the print model and original model contrast, though assimp the model structure changed, but I made a contrast, the total number of vertices and indexes are right, but now that I have a couple of a group can be drawn that no missing data itself, should be the problem of various configurations of DESC,

CodePudding user response:

NumOfPs is the sum of all the submesh is a submesh
And I looked at it and if it is in accordance with a submesh draw your DrawCall the second and the third parameter to not ah, especially the second StartIndexLocation

CodePudding user response:

Dx12 can use PIX debugging, you can see this problem a debugging problems, but its don't know can't debugging

CodePudding user response:

View this thread is heavy, the latest progress to me that make a reference to the future generations, the problem currently have a temporary solution, after tests found that the problem seems to be out in the D3DCONTEXT DrawIndexed function, a began to use this function to map model according to the index, but the later found ASSIMP when read the model to the model's structure has carried on the reorganization, all vertices according to the drawing order arrangement of the road to a (for example, if we have four vertices V1, V2, V3 and V4, and then I want in the order 123234 to draw two triangles, normally we will store four points in the vertex, and then save 1,2,3,2,3,4 as index in the index, with ASSIMP after read, becomes in the vertex directly in order to store the V1, V2, V3, V2, V3 and V4 six points, then the index change to 6) therefore under this structure using DrawIndexed and the draw had no difference, so I change the drawing function, the result is can draw out, also won't complain, but as to why DrawIndexed will go wrong, I didn't find out why,

P.S. when drawindexed commissioning a new progress, if the mesh points a few paint, can be in one piece of drawing to quote the following error
D3D11 WARNING: ID3D11DeviceContext: : DrawIndexed: Vertex Buffer at the input Vertex slot 0 is not big enough for what the Draw * () call expects to traverse by. This is OK, as reading off the end of the Buffer is defined to return 0. Or the developer probably did not intend to make use of This behaviors. [EXECUTION WARNING # 356: DEVICE_DRAW_VERTEX_BUFFER_TOO_SMALL]
The misstatement is obvious, that is to say the vertex Buffer is not large enough, I go to the search on the net also cleared the code again, failed to discover problems, and if really Buffer is not large enough, why use the draw or paint every few when there is no problem, comprehensive consideration on the content of index related still feeling out of the question,

CodePudding user response:

In 3 ds Max SDK has a very good sample, as long as a slight modification can make their own export plug-in,
Make the export plug-in can well understand the index of vertex and the structure of the subset, is recommended

CodePudding user response:

I also think you had better use PIX debugged, look at each DrawCall parameters, and draw out what, this is bad to get light

CodePudding user response:

Thank P_hantom WJN92 and enthusiastic help, at present has found a solution more damage of the mistakes after screening suspected drawindexed functions to draw a not too big all points within the vertex Buffer (although the feeling is unlikely, a tens of thousands of points should not draw not to come out but not found other wrong, think so can only temporarily, welcome to point out mistakes), Obj model is mesh is the module to store (such as a leg is a, both hands is a, is a body), tried to read before stage record each mesh corresponding index index range and then in the rendering phase points mesh multiple calls drawindexed draw results failed, then see such a blog https://blog.csdn.net/X_Jun96/article/details/82633363#ObjReaderobjmbo_157
nullnullnullnullnullnullnullnullnullnullnullnullnullnull
  • Related