Re: [android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
It's exactly what I was getting, except the guy had red pants. I was using the Milestone which is basiclly a Droid. Like you I was fillrate limited so I didn't see any drop in framerate. Really the only performance issues I had/have are with particle overdraw. IMHO you're wasting time trying to solve this. If anything notify Motorola. Leigh Leigh, thanks for the reply. I actually found your thread on the subject and was dismayed at the solution :-) I think I will live in denial for awhile before switching to that. How much of a performance hit do you feel you took with all the extra verts to be transformed? And I guess that would vary a lot with the hardware. Currently, on the Droid at least, I seem to be fill-rate limited, more so than vert limited. Though changing my MIN filter actually made a pretty nice improvement. Mario, I'm pretty sure it's not z-fighting as, aside from there being nothing to fight with, you can see the background color through the hole. But here are a couple (old) screen shots (I've had this issue since inception). Please ignore the placeholder graphics, the game looks SO much better ALREADY :-) HONEST :-) This is the same hole from two slightly different camera angles Of the triangular opening, the two distant verts are (I believe) 'real verts') but the bottom tip of the triangle is not. The real vert would be off screen behind the camera (the triangle is 8meters on a side, with the little man being a 2 meter ruler). It's as if the third vert is being mis-transformed to a spot which causes the triangle to intersect the near clip plane, and it is that clip region which we see as 'the hole' and which varies with camera angle. Again, the adjacent triangles share the same verts and render fine, and if I move an inch this triangle will render fine, as well. Let's see if these links work: http://www.synthetic-reality.com/hole1.jpg http://www.synthetic-reality.com/hole2.jpg Again, don't be shocked by the art :-) It's a little creepy. - Dan On Jun 14, 7:40 am, Leigh McRae wrote: Been there done that. When I ported Tank Recon 3D from BlackBerry to Android I had this problem. Lucky for me I was pretty sure it wasn't my code since it worked on BlackBerry. I tried fixed and float. Did interleaved and non-interleaved and it didn't fix anything. Went through shutting off all states like texture, depth buffer, alpha, stencil etc and still nothing. Are you ready for the fix? I switched from indexed buffers to straight arrays (glDrawArrays). It's really sad but it made the problem go away. Also if you search around there are problems with buffers other than ByteBuffer. Leigh and no, it's not 'the last triangle in the mesh' Seems fairly evenly distributed in that way, so I no longer blame my ShortBuffer (at least not in that way). It does maybe have a sweet spot though. the last few failures I have seen have all occured when looking just shy of due east (88 degrees from north, where north in my coord system is (0, 0, -1); so the failure is when looking about (.9, 0, 0 ). But now I have a cool texture diagnostic mode to more easily identify exactly which triangle I am looking at, so that's nice :-) I know, I will just prevent the camera from looking in that direction! turn turn SNAP turn turn SNAP. I can have a little on- shoulder-conscience-pet that hits you in the head when you get close to looking in the bad direction. The actual visual defect looks more like a triangle that is intersecting the near plane, more so than simply gone. But there is no way this triangle would be intersecting the near plane. It's like one of the verts is suddenly mis-placed "behind the camera" (again, static vertex buffer, the vert has not really moved, only the camera has moved). Well, only the transform has changed. Definitely a bug, just only 99% sure it's not mine :-) ON another note, I think this game just started to be fun today. Which is to say, it's now possible to get killed if you're not careful. Plus the code is still young enough that's it's all pretty and organized and easy to understand. On Jun 13, 1:34 pm, Samsynwrote: Well, with that special hubris that comes just before you realize you did something super stupid: "no, the code is PERFECT!" :-) For some reason, I found some other threads talking about this (sort of) AFTER making my post (I looked first, honest!), but I guess those were sort of off-topic comments, so maybe a new post just for this is not a huge sin. I should mention I do not have the issue in the emulator (when I can stomach running at 4 fps), just on my Droid. (and maybe not on the Eris, the only other test phone I have), so this might be a Droid- specific issue. So far, I have only noticed it on my terrain, th
[android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
Leigh, thanks for the reply. I actually found your thread on the subject and was dismayed at the solution :-) I think I will live in denial for awhile before switching to that. How much of a performance hit do you feel you took with all the extra verts to be transformed? And I guess that would vary a lot with the hardware. Currently, on the Droid at least, I seem to be fill-rate limited, more so than vert limited. Though changing my MIN filter actually made a pretty nice improvement. Mario, I'm pretty sure it's not z-fighting as, aside from there being nothing to fight with, you can see the background color through the hole. But here are a couple (old) screen shots (I've had this issue since inception). Please ignore the placeholder graphics, the game looks SO much better ALREADY :-) HONEST :-) This is the same hole from two slightly different camera angles Of the triangular opening, the two distant verts are (I believe) 'real verts') but the bottom tip of the triangle is not. The real vert would be off screen behind the camera (the triangle is 8meters on a side, with the little man being a 2 meter ruler). It's as if the third vert is being mis-transformed to a spot which causes the triangle to intersect the near clip plane, and it is that clip region which we see as 'the hole' and which varies with camera angle. Again, the adjacent triangles share the same verts and render fine, and if I move an inch this triangle will render fine, as well. Let's see if these links work: http://www.synthetic-reality.com/hole1.jpg http://www.synthetic-reality.com/hole2.jpg Again, don't be shocked by the art :-) It's a little creepy. - Dan On Jun 14, 7:40 am, Leigh McRae wrote: > Been there done that. When I ported Tank Recon 3D from BlackBerry to > Android I had this problem. Lucky for me I was pretty sure it wasn't my > code since it worked on BlackBerry. I tried fixed and float. Did > interleaved and non-interleaved and it didn't fix anything. Went > through shutting off all states like texture, depth buffer, alpha, > stencil etc and still nothing. > > Are you ready for the fix? I switched from indexed buffers to straight > arrays (glDrawArrays). It's really sad but it made the problem go away. > Also if you search around there are problems with buffers other than > ByteBuffer. > > Leigh > > > > > > > and no, it's not 'the last triangle in the mesh' Seems fairly evenly > > distributed in that way, so I no longer blame my ShortBuffer (at least > > not in that way). > > > It does maybe have a sweet spot though. the last few failures I have > > seen have all occured when looking just shy of due east (88 degrees > > from north, where north in my coord system is (0, 0, -1); so the > > failure is when looking about (.9, 0, 0 ). > > > But now I have a cool texture diagnostic mode to more easily identify > > exactly which triangle I am looking at, so that's nice :-) > > > I know, I will just prevent the camera from looking in that > > direction! turn turn SNAP turn turn SNAP. I can have a little on- > > shoulder-conscience-pet that hits you in the head when you get close > > to looking in the bad direction. > > > The actual visual defect looks more like a triangle that is > > intersecting the near plane, more so than simply gone. But there is > > no way this triangle would be intersecting the near plane. It's like > > one of the verts is suddenly mis-placed "behind the camera" (again, > > static vertex buffer, the vert has not really moved, only the camera > > has moved). Well, only the transform has changed. > > > Definitely a bug, just only 99% sure it's not mine :-) > > > ON another note, I think this game just started to be fun today. > > Which is to say, it's now possible to get killed if you're not > > careful. Plus the code is still young enough that's it's all pretty > > and organized and easy to understand. > > > On Jun 13, 1:34 pm, Samsyn wrote: > > >> Well, with that special hubris that comes just before you realize you > >> did something super stupid: > > >> "no, the code is PERFECT!" > > >> :-) > > >> For some reason, I found some other threads talking about this (sort > >> of) AFTER making my post (I looked first, honest!), but I guess those > >> were sort of off-topic comments, so maybe a new post just for this is > >> not a huge sin. > > >> I should mention I do not have the issue in the emulator (when I can > >> stomach running at 4 fps), just on my Droid. (and maybe not on the > >> Eris, the only other test phone I have), so this might be a Droid- > >> specific issue. > > >> So far, I have only noticed it on my terrain, though the same code is > >> used to render other meshes in the game (the poseable-skeleton > >> characters, for example). It's possible it happens there as well and > >> I just haven't noticed yet (I mean, if it's a Droid bug, I would think > >> it would have some probability of happening on any of my meshes). But > >> the terrain mesh has fairly larg
Re: [android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
Been there done that. When I ported Tank Recon 3D from BlackBerry to Android I had this problem. Lucky for me I was pretty sure it wasn't my code since it worked on BlackBerry. I tried fixed and float. Did interleaved and non-interleaved and it didn't fix anything. Went through shutting off all states like texture, depth buffer, alpha, stencil etc and still nothing. Are you ready for the fix? I switched from indexed buffers to straight arrays (glDrawArrays). It's really sad but it made the problem go away. Also if you search around there are problems with buffers other than ByteBuffer. Leigh and no, it's not 'the last triangle in the mesh' Seems fairly evenly distributed in that way, so I no longer blame my ShortBuffer (at least not in that way). It does maybe have a sweet spot though. the last few failures I have seen have all occured when looking just shy of due east (88 degrees from north, where north in my coord system is (0, 0, -1); so the failure is when looking about (.9, 0, 0 ). But now I have a cool texture diagnostic mode to more easily identify exactly which triangle I am looking at, so that's nice :-) I know, I will just prevent the camera from looking in that direction! turn turn SNAP turn turn SNAP. I can have a little on- shoulder-conscience-pet that hits you in the head when you get close to looking in the bad direction. The actual visual defect looks more like a triangle that is intersecting the near plane, more so than simply gone. But there is no way this triangle would be intersecting the near plane. It's like one of the verts is suddenly mis-placed "behind the camera" (again, static vertex buffer, the vert has not really moved, only the camera has moved). Well, only the transform has changed. Definitely a bug, just only 99% sure it's not mine :-) ON another note, I think this game just started to be fun today. Which is to say, it's now possible to get killed if you're not careful. Plus the code is still young enough that's it's all pretty and organized and easy to understand. On Jun 13, 1:34 pm, Samsyn wrote: Well, with that special hubris that comes just before you realize you did something super stupid: "no, the code is PERFECT!" :-) For some reason, I found some other threads talking about this (sort of) AFTER making my post (I looked first, honest!), but I guess those were sort of off-topic comments, so maybe a new post just for this is not a huge sin. I should mention I do not have the issue in the emulator (when I can stomach running at 4 fps), just on my Droid. (and maybe not on the Eris, the only other test phone I have), so this might be a Droid- specific issue. So far, I have only noticed it on my terrain, though the same code is used to render other meshes in the game (the poseable-skeleton characters, for example). It's possible it happens there as well and I just haven't noticed yet (I mean, if it's a Droid bug, I would think it would have some probability of happening on any of my meshes). But the terrain mesh has fairly large triangles, which is why I am willing to suspect a math overflow issue. Still, lots of nearby triangles, sharing the same verts, will be non-problematic. I guess the most LIKELY explanation would be the short index buffer. something like the first or last entry in the list, maybe. I lied a little implying there was just one terrain mesh, when really the full terrain is tiled with multiple meshes, and I haven't tried using goofy texturing to help identify if this is always a particular corner of such a mesh (i.e. first/last triangle). I guess I will try that now. But to answer your question, I pass the gl check stuff when I turn it on. And again, all the buffers are completely static, so their content should not be flakily changing. If I had bad numbers in the buffers, I would expect the problem to be pretty constant. - Dan On Jun 13, 1:21 pm, Frank Weiss wrote: I'm no GL expert by far, but is there possibly a debug or logging mode which might expose a calculation or data error?- Hide quoted text - - Show quoted text - -- Leigh McRae www.lonedwarfgames.com -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
A screenshot of the error would help a lot. I suspect z-fighting of some sort given the information you gave us so far. On 13 Jun., 23:30, Samsyn wrote: > and no, it's not 'the last triangle in the mesh' Seems fairly evenly > distributed in that way, so I no longer blame my ShortBuffer (at least > not in that way). > > It does maybe have a sweet spot though. the last few failures I have > seen have all occured when looking just shy of due east (88 degrees > from north, where north in my coord system is (0, 0, -1); so the > failure is when looking about (.9, 0, 0 ). > > But now I have a cool texture diagnostic mode to more easily identify > exactly which triangle I am looking at, so that's nice :-) > > I know, I will just prevent the camera from looking in that > direction! turn turn SNAP turn turn SNAP. I can have a little on- > shoulder-conscience-pet that hits you in the head when you get close > to looking in the bad direction. > > The actual visual defect looks more like a triangle that is > intersecting the near plane, more so than simply gone. But there is > no way this triangle would be intersecting the near plane. It's like > one of the verts is suddenly mis-placed "behind the camera" (again, > static vertex buffer, the vert has not really moved, only the camera > has moved). Well, only the transform has changed. > > Definitely a bug, just only 99% sure it's not mine :-) > > ON another note, I think this game just started to be fun today. > Which is to say, it's now possible to get killed if you're not > careful. Plus the code is still young enough that's it's all pretty > and organized and easy to understand. > > On Jun 13, 1:34 pm, Samsyn wrote: > > > Well, with that special hubris that comes just before you realize you > > did something super stupid: > > > "no, the code is PERFECT!" > > > :-) > > > For some reason, I found some other threads talking about this (sort > > of) AFTER making my post (I looked first, honest!), but I guess those > > were sort of off-topic comments, so maybe a new post just for this is > > not a huge sin. > > > I should mention I do not have the issue in the emulator (when I can > > stomach running at 4 fps), just on my Droid. (and maybe not on the > > Eris, the only other test phone I have), so this might be a Droid- > > specific issue. > > > So far, I have only noticed it on my terrain, though the same code is > > used to render other meshes in the game (the poseable-skeleton > > characters, for example). It's possible it happens there as well and > > I just haven't noticed yet (I mean, if it's a Droid bug, I would think > > it would have some probability of happening on any of my meshes). But > > the terrain mesh has fairly large triangles, which is why I am willing > > to suspect a math overflow issue. Still, lots of nearby triangles, > > sharing the same verts, will be non-problematic. > > > I guess the most LIKELY explanation would be the short index buffer. > > something like the first or last entry in the list, maybe. > > > I lied a little implying there was just one terrain mesh, when really > > the full terrain is tiled with multiple meshes, and I haven't tried > > using goofy texturing to help identify if this is always a particular > > corner of such a mesh (i.e. first/last triangle). I guess I will try > > that now. > > > But to answer your question, I pass the gl check stuff when I turn it > > on. > > > And again, all the buffers are completely static, so their content > > should not be flakily changing. If I had bad numbers in the buffers, > > I would expect the problem to be pretty constant. > > > - Dan > > > On Jun 13, 1:21 pm, Frank Weiss wrote: > > > > I'm no GL expert by far, but is there possibly a debug or logging mode > > > which might expose a calculation or data error?- Hide quoted text - > > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
and no, it's not 'the last triangle in the mesh' Seems fairly evenly distributed in that way, so I no longer blame my ShortBuffer (at least not in that way). It does maybe have a sweet spot though. the last few failures I have seen have all occured when looking just shy of due east (88 degrees from north, where north in my coord system is (0, 0, -1); so the failure is when looking about (.9, 0, 0 ). But now I have a cool texture diagnostic mode to more easily identify exactly which triangle I am looking at, so that's nice :-) I know, I will just prevent the camera from looking in that direction! turn turn SNAP turn turn SNAP. I can have a little on- shoulder-conscience-pet that hits you in the head when you get close to looking in the bad direction. The actual visual defect looks more like a triangle that is intersecting the near plane, more so than simply gone. But there is no way this triangle would be intersecting the near plane. It's like one of the verts is suddenly mis-placed "behind the camera" (again, static vertex buffer, the vert has not really moved, only the camera has moved). Well, only the transform has changed. Definitely a bug, just only 99% sure it's not mine :-) ON another note, I think this game just started to be fun today. Which is to say, it's now possible to get killed if you're not careful. Plus the code is still young enough that's it's all pretty and organized and easy to understand. On Jun 13, 1:34 pm, Samsyn wrote: > Well, with that special hubris that comes just before you realize you > did something super stupid: > > "no, the code is PERFECT!" > > :-) > > For some reason, I found some other threads talking about this (sort > of) AFTER making my post (I looked first, honest!), but I guess those > were sort of off-topic comments, so maybe a new post just for this is > not a huge sin. > > I should mention I do not have the issue in the emulator (when I can > stomach running at 4 fps), just on my Droid. (and maybe not on the > Eris, the only other test phone I have), so this might be a Droid- > specific issue. > > So far, I have only noticed it on my terrain, though the same code is > used to render other meshes in the game (the poseable-skeleton > characters, for example). It's possible it happens there as well and > I just haven't noticed yet (I mean, if it's a Droid bug, I would think > it would have some probability of happening on any of my meshes). But > the terrain mesh has fairly large triangles, which is why I am willing > to suspect a math overflow issue. Still, lots of nearby triangles, > sharing the same verts, will be non-problematic. > > I guess the most LIKELY explanation would be the short index buffer. > something like the first or last entry in the list, maybe. > > I lied a little implying there was just one terrain mesh, when really > the full terrain is tiled with multiple meshes, and I haven't tried > using goofy texturing to help identify if this is always a particular > corner of such a mesh (i.e. first/last triangle). I guess I will try > that now. > > But to answer your question, I pass the gl check stuff when I turn it > on. > > And again, all the buffers are completely static, so their content > should not be flakily changing. If I had bad numbers in the buffers, > I would expect the problem to be pretty constant. > > - Dan > > On Jun 13, 1:21 pm, Frank Weiss wrote: > > > > > I'm no GL expert by far, but is there possibly a debug or logging mode > > which might expose a calculation or data error?- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
[android-developers] Re: GLES/IntBuffer/?? Mis-placed verts?
Well, with that special hubris that comes just before you realize you did something super stupid: "no, the code is PERFECT!" :-) For some reason, I found some other threads talking about this (sort of) AFTER making my post (I looked first, honest!), but I guess those were sort of off-topic comments, so maybe a new post just for this is not a huge sin. I should mention I do not have the issue in the emulator (when I can stomach running at 4 fps), just on my Droid. (and maybe not on the Eris, the only other test phone I have), so this might be a Droid- specific issue. So far, I have only noticed it on my terrain, though the same code is used to render other meshes in the game (the poseable-skeleton characters, for example). It's possible it happens there as well and I just haven't noticed yet (I mean, if it's a Droid bug, I would think it would have some probability of happening on any of my meshes). But the terrain mesh has fairly large triangles, which is why I am willing to suspect a math overflow issue. Still, lots of nearby triangles, sharing the same verts, will be non-problematic. I guess the most LIKELY explanation would be the short index buffer. something like the first or last entry in the list, maybe. I lied a little implying there was just one terrain mesh, when really the full terrain is tiled with multiple meshes, and I haven't tried using goofy texturing to help identify if this is always a particular corner of such a mesh (i.e. first/last triangle). I guess I will try that now. But to answer your question, I pass the gl check stuff when I turn it on. And again, all the buffers are completely static, so their content should not be flakily changing. If I had bad numbers in the buffers, I would expect the problem to be pretty constant. - Dan On Jun 13, 1:21 pm, Frank Weiss wrote: > I'm no GL expert by far, but is there possibly a debug or logging mode > which might expose a calculation or data error? -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en