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 <leigh.mc...@lonedwarfgames.com>
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<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 -
>
> --
> Leigh McRaewww.lonedwarfgames.com- 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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
No comments:
Post a Comment