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 <d...@synthetic-reality.com> 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 <d...@synthetic-reality.com> 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 <fewe...@gmail.com> 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

Reply via email to