   index buffer access violation (adv)
  hey alli am experimenting with resource/geometry handling, below is some contextual info that might be useful- i use a d3dxmesh for setting up & manipulating geometry(either regular or progressive mesh) into a lpd3dxmesh pSetupMesh, which is then converted to tristrips or trilists- after setup, the pSetupMesh is passed either to a STRIPIFY or TRILIST kind of function, which processes the pSetupMesh into tristrips or trilists.- converting the specified pSetupMesh into trilists work fine, without errors, for both regular and progressivemeshes as the original source of the pSetupMesh- stripifying a pSetupMesh with a d3dxmesh as the original source of the pSetupMesh works fine (!!)- stripifying a pSetupMesh with a d3dxPmesh (progressive) as the original source of the pSetupMesh... well, here is where all hell breaks loose:sometimes, reading data from a specific position in an index buffer leads to an access violation. I get an access violation in the debugger on specifically copying a dword out of the index buffer into a local unsigned int one (i'm using nvtristrip to stripify, so i am converting indices between dwords and ints)i read somewhere on the directxdev forums about resources (automatically) allocated in the d3dpool_default pool possibly could be paged out of memory by the os, even if the memory is locked (however i am not sure, since its hard to find info). This could be the case here but i am not sure, i could as well be passing some kind of unholy parameter during resource creation/allocation.One more thing, the access violation happens somewhat randomly- sometimes a PMeshes has been succesfully converted into a pSetupMesh and stripped say 2 or 3 times (each with a different vertex/face count), and the 4th one raises the access violation, in the middle of converting the dword indices into unsigned int indices. This seems to happen on arbitrary geometry.note that stripification of a pSetupMesh based on a d3dxmesh (regular mesh) works just fine. So if i stripify a rectangle consisting of two tris, it works ok. if i send the same geometry through the pmesh stripification code path, my system sometimes just reboots (this goes even beyond the access violation). After spending a couple of days experimenting with resource allocation parameters, i am left clueless as to the origin of the bug. the only difference in the stripify/trilist code path is in setting up a pSetupMesh based on a regular mesh or pmesh input variable, after that its passed into a uniform 'StripifyMesh(lpd3dxmesh mymesh)' functionsorry for my potentially bad explanation of the situation and its context :-) its a specific and detailed situation where the access violation occurs, and i dont know the exact terminology to explain what happens (it sure would make browsing for information a lot easier)currently i am looking into various flags for resource/mesh creation, looking at the dx debug output etc, but until now i havent got a clue what i might be doing wrong... there is no dx debug output error when a access violation occurs, it just occurs. oh well, at least i was able to narrow the problematic code down until the above (stripify d3dxpmesh) scenariothanks to gamedev.net in general - this place is invaluable when you're facing the graphics programming learning curve :-)[edit: rephrased some things for clarity and consistency][edited by - whatsinaname on February 17, 2004 12:10:56 PM][edited by - whatsinaname on February 17, 2004 12:13:46 PM][edited by - whatsinaname on February 17, 2004 12:18:34 PM]