# StakFallT

Member

84

308 Neutral

• Rank
Member

2. ## Shadow Volumes - Edge finding

Woah. The man himself! :)   Thanks!
3. ## Shadow Volumes - Edge finding

Well I think what I've just experienced was a serious herp-derp moment. Furthering my previous reply: of course the "solution sets" MUST be the same! If you compared vertex index 100, 200, and 300 against vertex indices 50, 150, and 250 it wouldn't make sense because the vertices aren't even in the same position in space and if they were and they were just redundant vertex entries, technically it'd be a hole (despite overlapping) in the model! i.e. you don't check an edge shared by two triangles by checking two completely different sets of vertices otherwise it's no longer a shared edge lol! ::doh:: So the assumption made is the 3 points checked two of them must be in another triangle for the edge to be shared and it's quicker to check the index value rather than the float values. I kinda figured my brain was being dense lol   I think building the extra indices would actually cause a problem, because if vertex 1 is 0, 0, 0 (making it easy) and vertex (say) 53 is 0, 0, 0. Sure the values are the same, but the indexes are different. Sure you can check the value to see if they're the same, but not only is that slower, but you've introduced the implicit problem that the points aren't actually technically the same.They merely just overlap exactly. Like drawing a line on a piece of paper overtop of the same line, sure it looks like one line, but technically there are two lines there and I imagine that might cause some issues with the algorithm.   EDIT 1: (Rather than create a 2nd follow up post in a row, I figured I'd do this in the form of an edit) And what is the deal with Edge **edgeArray? The function definition is: long BuildEdges(long vertexCount, long trianglecount, const Triangle *trianglearray, Edge **edgeArray)   and further in the function it does: Edge *edge = &edgeArray[edgeCount; edge->vertexIndex[0] = unsigned short) i1; ...   according to the book, edgeArray: "A pointer to a location in which a pointer to the edge array is returned (Lengyel; p.296).", the parameters, and the fact that edgeequal an element in edgeArray (Which appears to be already allocated), this variable is supposed to already be allocated, yet the book says "The return value is the number of edges written to the array edgeArray (Lengyel; p.296)." How can it write to memory without it already being allocated? How do I know it's not allocated yet? Because the function returns how many edges were written to it... If it's not allocated then the above code is going to create an access violation.
4. ## Shadow Volumes - Edge finding

hmm ok so if I understand this correctly, it's true that the actual index number has no real meaning;but it's also true that the function doesn't pretend it to be and that the only reason the function really actually works is because the index comparisons being made are the same set, only in opposite directions. If i'm understanding this correctly, it's like saying we're comparing A, B, and C -- we don't really care what A, B, and C are equal to or what vertex in the list A, B, and C's values are referring to, just as long as the two triangles are using AB, BC, or CA (and BA, CB, or AC). I guess maybe a better way of putting it would be to say, so long as Edge 1 and Edge 2 of Triangle 1 and Triangle 2 use the same solution set a comparison can be made, and whether one is less than or greater than has more to do with winding than actually caring about the value itself.   I think what I wasn't getting was that I kept thinking if Triangle 1 has indices: 100, 200, and 300 and Triangle 2 has indices: 50, 150 and 250 how does comparing the two sets of indices help? In that case, it doesn't. The indices of any edge comparisons made must be the same (Obviously in different directions -- hence > or < helps here for that, but the same nonetheless).   Something else that doesn't help is he's using "long a" to refer to the outer loop of all the triangles, yet just below he uses b to refer to the points of the triangle, making them seem related in purpose. He should've renamed a to something like TriangleNum or something, then when he does: edge->faceIndex[0] = (unsigned short) a; edge->faceIndex[1] = (unsigned short) a;   it would read: edge->faceIndex[0] = (unsigned short) TriangleNum; edge->faceIndex[1] = (unsigned short) TriangleNum;   and "long b" to something like "long PointNum"   much easier to understand and separates a's purpose from b. Which is obvious on the surface but when someone think's they're missing something and that's why they don't understand something, they start looking harder and trying to pull things out from the material.
5. ## Shadow Volumes - Edge finding

Ok I think I follow that a little bit better, because even if you have two triangles that share an edge, if the normals to both faces are different, then it means you're at the edge of the model where it starts "wrapping" around toward the back; basically you're leveraging the property of normals being inverse of each other combined with the shared edge so as to determine which edges in the entire model are at that "wrap-around" part. Ok that makes sense, but what about the actual indices? In the function Eric basically checks the index numbers. Here's a short blurb of what I'm referring to... Hope this is ok... for (long a = 0; a < triangleCount; a++) { long i1 = triangle->index[2]; for (long b =0; b < 3 b++) { long i2 = triangle->index[b]; if (i1 < i2) { ... If you simulate an example, let's say that triangle->index[2] = 103 and b = 0 (following it further ->  long i2 = triangle->index[0] = 204)   What difference does it matter if i1 = 103 (for example) and i2 = 204 (again, for example) 103 and 204 only refer to entry numbers in a vertex list not the actual contents, how is checking 103 vs 204 really helpful? I could see if checking the vector at entry 103 vs the vector at entry 204 would be helpful, but the actual index numbers? Is this implicitly assuming that the order of vectors in the global-vector-list (that are referred to by the model's faces) are in some kind of special order? (NOTE: I'm not referring to the point order that make up a face, obviously that does matter, what I'm referring to are the actual index numbers themselves) If that's the case, then yeah I could see 103 and 204 actually having some sort of implicit yet significant meaning. Sorry if I'm being dense. I feel like this is something so simple, just I'm not there yet...Thanks so far btw!   P.S. Yeah that article is almost an exact copy out of his book, only main difference it seems is he left the function code and the GL shader code out of the article. EDIT: Various edits in an attempt to articulate my point more clearly, also a couple of spelling mistakes
6. ## Shadow Volumes - Edge finding

Hoping someone could help me understand the algorithm to finding edges. I've been reading and re-reading about shadow volumes and having a really tough go of it for some reason. Namely in the edge finding algorithm. The latest material I'm looking over comes from the book "Mathematics for 3D Game Programming and Computer Graphics" (3rd Edition) by Eric Lengyel. In it he displays the code behind a BuildEdges function. But he does what I've seen done so many other times with Shadow Volumes. He seems to base some stuff of the vertex-index of the points on a triangle and he furthers this even further by checking if the index number is greater than or less than the previous one. Um... what?. The index number, from my personal experience, is just a rudimentary number that correlates to a 3-float-value (x, y, z) in a vertex-table list that only lists vertex values once -- that is, a unique vertex list. But even if the actual vertex-list was not one of uniqueness of it's entries, what good would checking an index number's ordinal value be? From what I can tell, the indices (The order of the vertices in that list) has no rhyme or reason they're just in there in the order the 3D modeling program sees as it's looping through the geometry to export. I don't really understand how the index's number is helpful...If someone could shed some light on this, I'd really appreciate it; thanks!   P.S. I'd post the function, but I'm not sure if that's something the publisher would mind. I can't see why they wouldn't given it's only one function is a fairly thick book, but I'll defer that to the board mods.   -- StakFallT
7. ## Bizarre D3D9 hResult error: "The drive cannot find the sector requested."

Even though it's not for the XBox and isn't written using XNA?
8. ## Bizarre D3D9 hResult error: "The drive cannot find the sector requested."

Anyone ever get this error: "hr = 0x0000001b The drive cannot find the sector requested." when calling something as simple as the DrawPrimitive function? I'm getting this error in my engine's worldbuilder being written in C#. The engine is written in C++ and so I used SWIG to create the wrapper interface to bridge betwen native C++ and C#. I kept noticing the call stack errored in nvd3dum.dll (nVidia card for anyone that couldn't tell) -- was getting an unhandled exception to be more specific. But when I went poking around in the various threads, I noticed my engine's thread was sitting at a DrawPrimitive call, so I bp'ed on it and spammed the f5 key a bunch; low and behold I eventually found it to be yielding that error upon checking the result of call. My first instinct was to run scandisk which I did and it gave me a clean bill of health with no errors discovered. Not that I think it matters but I'm running Windows 8.1 just incase anyone was wondering. The weird thing is, all myviewports for the various view windows render at least once just fine but then all of a sudden the app just hits a brick wall on this draw call... Any thoughts on how to dig deeper on this? Thanks!   -- StakFallT
9. ## OpenGL Light Positions to D3D

@C0lumbo: Yup, that's exactly what it's doing. Just I saw the w in there, for lighting, and wasn't sure what to do with it.the setting w to 1 or 0 though was the info I was after :)  Btw, what about if it's a spotlight? I'm guessing I'd set w to 0 like I would a directional? Shadow Mapping is being favored over volumes? I thought the volume technique came out after mapping?   @Hodgman: Well there's some optimization stuff in that first paper and it does mention using some hardware here and there throughout and if it's available; I'm not really sure where the code in that first paper matches and/or differs with the Doom 3 source. My guess is, it's some sort of hybrid -- that is, use hardware if available, otherwise do it on the cpu.   Btw, thanks guys for the quick replies!

11. ## Creating volumetric mesh data from polygonal vertex set

Sorry to bother, but I've had to some time to work with the algorithm a bit, and I have a couple of last min. questions...   1) This would NOT be suitable for animated meshes -- at least without some kind of trick right? (There's just too much math for each test-point during voxel generation) -- as the naive (sp?) approach would be to regenerate the voxels every frame. I can't really picture a need to do this, but was just something that dawned on me. I guess, not to use a morbid example -- and I definitely apologize for doing so, but like if you took a rag-doll skeleton and wanted to like shoot an arm off off or something, but that's really the only example of an animated mesh I could think of where voxels could be used. Most destructable things are solid non-living objects (buildings, tanks, etc.) and even though some non-living things "animate" (like tanks), generally speaking, they either move, rotate, or scale as a collective whole of triangles. I suppose, also, anything non-living that might move on it's own... something flexible that might animate on their own (maybe by wind or something) would also be a candidate for on-the-fly voxels -- only thing that comes to mind would be a flagpole or a tree swaying in the wind.   2) What about scaling of meshes? When I scale my models, it's merely visual-only (since scaling all vertices and re-updating the vertex buffers on-demand would kinda be out of the question). I say this because, if the mesh gets bigger, the vertex data doesn't reflect this, only the model matrix does which is eventually passed to D3D; what this means is the voxels are calculated off the original vertices and as such if the mesh gets bigger, there won't be enough voxels to fill the inside of the model since the voxels being generated are calculated off the original smaller triangles... Would I create a second set of vertex/face data that scale when voxels are generated to counter that problem or is there a method that entails less overhead? I've heard of a method that some people make sophisticated usage of billboards to achieve voxels in general, but I'm not sure how that would really work -- but for any kind of deformation would definitely require some spaghetti code I'm thinking (As you'd then have to convert the billboards into cubes otherwise at certain camera angles the voxels, being billboards, would "disappear").
12. ## Creating volumetric mesh data from polygonal vertex set

Been looking over the implementation, thanks!  The code is soooo clean...  I follow it, just wish I could visualize the formulas in my head better -- though, that usually comes overtime through working with them. Thanks again! I think I'm on my way now! :)
13. ## Creating volumetric mesh data from polygonal vertex set

well I was saying a vertex because a vertex represents the very end of triangle, it's impossible for something on a face to be passed all of the encompassing 3 vertices (one of those 3 will be the furthest point), but I see what you're saying about an edge -- if 1 vertex is dismissed and you're down to two, and those two happen to be equidistant (side the side)  from said point, then the mid point of that edge would be closer. Thanks btw!     EDIT 1: It's taking some time to go through the algorithm; been a while since I read through a math paper but I think I'm starting to understand parts of it. Currently, my question on it is, what is "B"?   here's the text I'm referring to: "where a = E0 * E0, b = E0 * E1, c = E1 * E1, d = E0 * (B - P), e = E1 * (B - P), and f = (B - P) * (B - P)."   I get that the Es are the edges, and P is the arbitrary point you're testing, but what is B? The paper doesn't seem to explain that. Also, s and t I'm guessing are the 2d coords of the triangle? So how do I flatten a 3d tri into 2d? Would I use barycentric coords?
14. ## Creating volumetric mesh data from polygonal vertex set

By the sounds of it, the gist is: 1) Create a bounding box 2) Select an arbitrary point that is inside that box 3) Take that arbitrary point and locate the closest triangle (By checking the distance of it's vertices) to said arbitrary point 4) Take that triangle's normal and test it against the arbitrary point and if - it's inside, if + it's outside, if 0 it's on the surface. 5) If -, or 0 create a cube at that arbitrary point   repeat steps 2 through 5