( Man, .. I want to save this title for a lighting question. )
Anyhow, I'm currently trying my hand at some rendering at home for the first time, so I have to beg your pardon for the junior-ish question.
I'm building the tutorial from http://g3d-cpp.sourceforge.net - G3D's an OpenGL/SDL based Graphics Engine.
I got the tutorial working largely, however when I tried scaling out the ground plane (a quad) to near-infinity, it all looks fine until I move the camera. Then triangles start to flicker, and if I stop moving the camera, it's a random chance that the triangles will show up or not.
Anyhow, some of the things I've tried:
- Flipped Culling to none
- Played around with enable2DClip
That's about it, because that's all i know how to do.
Anyhow, I realize this is hard to visualize without screenshots - pardon me but I still have to rig that up. I'll post them in a follow up when I get the chance. I'm more interested if people have any idea what's going on?
All I've got is a skybox and this infinite ground plane... Could it be z-fighting? Not sure.
Anyhow, like I said, it's a shot in the dark: I'll see if I can illuminate with some screenshots and additional research..
It's not good to have (near)-infinitely large polygons. Numerical precision issues make them jump around wildly as you move in the best case, and in the worst case they will randomly appear and disappear as you are experiencing.
Just use a ground plane that's as big as you need for your scene.
Interesting. I wonder if that's what's occurring.
So, pardon what's bound to be a very *very* elementary question (feel free to give me google search terms as an answer): but how do I render something that looks like an infinite plane but isn't then?
For my first cut here, I'm hoping to basically look like I'm staring down the horizon of a prairie ("You can see your dog run away for miles..."), and then build my game on top of that.
It sounds like stretching out my plane to near infinity is bad then, how can I get the 'look' I want then? Is there some formula to determine at what point it looks similar to what I'm hoping to achieve?
Please save me from binary searching on the appropriate size; as previously mentioned, search terms or a web page so I can RTFM is appreciated.
I'm sorry, but there is no specific answer I can give you that will be correct for all situations
You could consider using fog to hide the far distances, or constructing your game world so that there are always mountains or hills blocking visibility in the distance. If it absolutely must be an infinite flat world, make it big enough that you can't tell the difference (e.g a hundred times larger than the distance of the camera from the plane, or a thousand), and move the plane with the camera (changing texture coordinates appropriately, so it doesn't look like the ground is flying along with you).
Just out of curiosity, how big were you scaling it?
I suppose that makes sense. I figured there would be a point where it wouldn't be perceptible, but I suppose there must be one eventually. Sorry for my 'green-ness' showing through.
I'll probably just settle for something arbitrary and make it not 'move' when the people move for now. I just want to get things up and running. @Reedbeta
Just out of curiosity, how big were you scaling it?
Promise not to laugh?
pRenderDevice->sendVertex(Vector3(-1e30, 0, 1e30));
pRenderDevice->sendVertex(Vector3( 1e30, 0, 1e30));
pRenderDevice->sendVertex(Vector3( 1e30, 0, -1e30));
pRenderDevice->sendVertex(Vector3(-1e30, 0, -1e30));
*cuts off at eddie's evil stare*
Yeah. Remember, 32-bit floats have only 23 bits of mantissa precision (2\\^23 = 10\\^7 approx), so if your vertices are 10\\^30 units away, your plane is only positioned to within 10\\^23 of where it should be. You probably saw it disappearing because it was randomly shifting between where it ought to be and 10\\^23 units away
Go for simplicity.
Since you can only see what's inside the view frustum, why not using a finite quad that stretches exactly as the frustum does?
As you move the camera, the quad adapts itself to the new frustum. Final result is the illusion of an infinite plane.
Texturing will just require some extra work, but it's nothing you can't do.
You probably know this, but you can only see about 13 miles on Earth because of the curvature. =)
I'm going to mess around with G3D as soon as I get VC8 Express downloaded on my laptop. I'll kill to birds with one stone and try them out at the same time.
Heh. I actually had the suggestion to put the quad that size by a friend of mine. I was mostly curious to see why things are happening the way they are. I never knew that bit about Mantissa Precision... Good to know!
I've been busy toiling with my linux build, so I haven't had a chance to try this out (built a Gentoo ebuild for G3D however.... Reminds me, I should post it on http://bugs.gentoo.org. If anyone's interested, I'll link to it from here). But thanks for only laughing mildly. I'll have more stupid questions to come.
I'll post sometime tomorrow as to whether this problem goes away. I'll probably do Nautilus' suggesiton, as that's what I had in my head anyways: I was mostly just curious as to what's happening.
Scaled things down just for fun to 1000x1000, and everything's merry in my world.
Is there any reason why floats have severed precision? This is probably something elementary that I should know, so please let me know if I'm falling victim to ignorance, and where I can cure this (name the google search!).
(BTW: if you're interested in G3D for Gentoo, see here: http://bugs.gentoo.org/show\_bug.cgi?id=113811)
Well, all numbers in computers can only have finite precision. A floating point number consists of a sign bit (positive or negative), a mantissa, and an exponent. For instance in 1.5e30, the mantissa is 1.5, and the exponent is 30. The "float" and "double" types are just the same, but in binary In float, it's a 23-bit mantissa, 8-bit exponent; and in double, it's a 52-bit mantissa with an 11-bit exponent. If you're interested in learning more, google for "IEEE floating point" (IEEE is the standard organization that created the floating-point format used on most computers).
Ah. OK, here I was drawing a blank about mantissa's and the like.
I wasn't sure if had something to do with the z-buffer being 24 bit or the like.
New stuff to learn! Fun.
Guess this isn't much use, but when you have huge surfaces it's probably best to tesselate them a bit. Your perspective is then less likely to be screwy and having low precision in the distance doesn't wreck things up close.
Right, that makes sense. Chop the quad up into tiny little bits and it'll render cleaner at the near plane, and it might do some z-fighting in the distance, but at least it won't look like crap up close.
Cool. Well currently I've got a nice Saskatchewan simulator going on. Thanks all.
Have your horizon in the skybox, and make the fog blend the ground in to that color. Tada! And you have "athmospheric scattering" for free.
Pardon my ignorance. "Horizon in the skybox"? Do you mean bake into the texture that is the skybox, the actual horizon?
Hrmm. Gotta go run and learn about atmospheric scattering. \
how about using projective geometry and actually putting stuff at infinity?
You lost me kusma... :surrender
Are you refering to this stuff? http://www.anth.org.uk/NCT/ Seems like very intereting overkill! I personally think that fog is the best answer, but it's eddie's game. :yes:
What he means is using a projection matrix with an infinite far plane (as used for depth-fail stencil shadows), and actually drawing the polygons at homogeneous infinity, i.e. by setting their w coordinate to
Well... That lost me too, but I'm a big graphics newbie. =) It should all make sense when I catch up on the lingo.
Will that fix eddie's problem? Is it not easier to make the quad just big enough to look like it's infinite (much less than +/-1e30 of course).
next page →