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 <[email protected]> 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 <[email protected]> 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
