| |
| |
| |
|
Page: 1 2
Comments:
<0> oh, this is strange.. my mirror doesn't work in wireframe mode... wtf
<0> oh, duh
<0> meh. How do I make this stupid mirror clip the world properly?
<0> oooh... that's interesting
<0> does glDepthMask(0) disable depth testing?
<0> wait, hrm.
<0> wtf. my quad is not occluding properly
<1> No, glDepthMask(0) disables writing to the depth buffer.
<1> Compares is still done.
<1> are*
<0> yeah, something else is going on here
<0> blah, how can I find out what the effective (x,y,z) of a vertex is after all the translations happen?
<1> Fetch the current matrix and to the transformation manually.
<1> s/to/do
<0> so be it.
<1> OpenGL only provides a hardware accelerated transform to speed up rendering.
<1> Use glGetDoublev with GL_MODELVIEW_MATRIX to fetch the modelview matrix currently on the stack.
<0> yeah
<1> The pointer should point to a double array of 16 in size.
<0> okay, which order are the columns in? 0 1 2 3, or 0 4 8 12 ?
<0> that is to say, is x[1] row 1, column 0, or is it row 0, column 1?
<0> ah, here we go. x[1] is row 1, column 0
<0> so... xt=arr[0]*x + arr[4] * y + arr[8]*z
<0> right?
<0> hrm, i'm not getting the right matrix here
<0> hrmmmmm
<0> this is interesting.
<0> oh, duh
<0> suddenly everything is so clear
<2> hello
<0> If there is a matrix that produces an affine transformation, and I have three before/after points, I should be able to determine that matrix, right?
<0> *noncolinear points
<2> if i have many polygons in front of each other, will they all get drawn?
<2> even if many of them are obstructing the others from view
<0> depends on the order they were drawn
<2> basically, like if i have 1000 simple planes with textures on them, but you can only see the front one because the others are behind it and obscured by perspective
<0> Polygons that entirely occluded by others don't get drawn
<2> ok, that just happens automatically without me having to worry about it?
<0> here's the catch (at least, as far as I understand things):
<0> if you draw polygon A, which is then subsequently occluded by polygon B, A's already been drawn
<2> 8-|
<2> so i draw from the front-first
<2> and opengl will just discard whatever's behind if its occluded ?
<0> It's even better if you can do your own sanity checking and avoid drawing some of the occluded stuff
<2> ok
<3> You can use depth testing to avoid rendering what's "behind" and occluded
<3> If you can do some calculations to skip whole batches of triangles that aren't visible anyway, do so
<2> just a simple vector calculation right?
<2> trigonometry
<2> from position of camera
<0> Maloeran: I think his question is, if you render polygon A, and then render polygon B, which is completely behind A, does GL bother doing the math to *try* rendering B
<3> I'm not following. Depth testing has little to do with trigonometry
<3> Oh sure, it tries rendering B and tests the depth for every pixel
<2> oh it does for every pixel? fantastic
<2> hmm alright
<2> now, another thing...
<2> would it make any sense
<0> yeah, Leper, you just do glEnable(GL_DEPTH_TEST);
<2> alright
<2> cool
<3> And create your context with a depth buffer, and clear it before rendering every frame
<0> ah, yeah.
<0> glClear(GL_COLOR_BUFFER_BIT|GL_DEPTH_BUFFER_BIT);
<2> is that all i have to do?
<2> for opengl to not draw occluded polys?
<3> The default settings for the rest should be fine, yes
<2> ok
<2> Maloeran
<2> you said that it checks per pixel
<2> lets say I have one poly with an alpha mask (black and white, no semi-transparency) and another one behind it with a full texture
<2> will it draw only what's appearing through the "holes" of the alpha mask?
<2> or will it draw both full textures?
<3> You will want alpha testing to discard pixels entirely, so the depth isn't updated for these pixels
<2> alpha testing
<2> oh
<2> yes
<2> for the alpha mask on the 'front' polygon
<3> Correct
<2> how about the polygon behind that
<0> for fun and excitement, glDepthFunc(GL_GREATER)
<2> will the parts obstructed by the front polygon's opaque pixels be drawn?
<3> Not if you used alpha testing, no
<2> thanks Stevie-O
<2> ok
<2> thanks a lot Maloeran
<0> glDepthFunc(GL_GREATER) causes stuff to be drawn... backwards
<2> oh
<2> 8-|
<2> sounds fun
<2> :D
<0> That's why I said 'fun and excitement' :)
<2> lmao
<2> hmm, do you think using alpha testing to avoid drawing many obscured polygons would actually improve performance?
<2> basically i want to have many layered polygons with high res textures on them
<0> keep in mind you need to account for perspective
<2> and 'holes' in them
<2> need to account for perspective?
<0> you could always render it and see how it looks
<0> yes
<3> What's the big picture, Leper?
<2> so alpha testing will have to be using vectors from the camera instead of straight down
<2> basically, my goal is
<3> Opengl never performs tests using "vectors", it's a raw per-fragment pipeline
<0> hey Maloeran
<0> I read somewhere that all matrix transformations are affine
<2> i want to draw terrain using a large number of layers of polygons slightly offset from each other
<0> in which case... how does a perspective transform work?
<2> they will use one height map and one texture
<2> all using the same texture
<2> the height map will clip a mask for each polygon
<2> depending on their height and the value in the heightmap
<2> so if the height is in the middle, around a 50% grey value in the heightmap
<2> it clips off everything higher than that value, turning it into the mask
<3> Stevie-O, multiplication of x,y,z followed by perspective divide ( /z ) ? I'm not sure I follow, the math is covered in the redbook and http://www.gamedev.net/reference/articles/article1691.asp
<3> That doesn't sound like a very good design, Leper, a lot of wasted fillrate and little flexibility...
<3> But more efficient solutions would be more complex, using multitexturing and much more
<2> i made a test of it in low resolution in another language
<2> i'll use multitexturing later
<2> once i get it working with one texture
<3> The design with multexturing might be very different
<2> maybe im misunderstanding you about multitexturing then
<2> http://www.expertgear.com/oblivierra/maptest/ here is what i mean
<2> i made this in flash
<3> Generally, I suspect you will want to blend multiple textures for your terrain rather than punching holes by alpha testing
<2> but it only uses 12 layers
<2> i want 100's of layers, something which flash cannot do
<3> I can't see Flash here
<2> oh :-/ darn
<2> hmm
<3> A terrain with 100 layers rendered on top of each other? I think you need a different approach
<2> hmm
<2> i know about traditional heightmap methods
<2> but this method would give me much more flexibility for my purposes
<3> It isn't practical, you won't have the fillrate or the video memory to store that
<2> too bad you can't see the flash though
<2> well hold on
<0> I can see it... I don't get the point tho
<3> It is terribly inefficient
<2> if i'm using one 2048 x 2048 texture isnt that the only texture i need to store in video memory?
<4> why would you need hundreds of layers for terrain in the first place?
<2> or it can even be a tiled texture, doesnt matter
<2> well for one it would be better for me than using voxels for terrain
<0> Maybe you should start talking about what it is you really want to do
<2> i want complex terrain that can deform at will, letting you punch tunnels through it, have overhanging cliffs etc
<2> i don't need to view it from side-on
<2> only from top-down plus some angles
<3> A heightmap won't do then, to begin with
<2> no, the traditional heightmap grid terrains don't do what i want
<2> voxels i don't like
Return to
#opengl
or
Go to some related
logs:
#nhl
#politics
#worldcup
#beginner
#beginner
#windowsxp
#windows
#nhl
#hardware
#visualbasic
|
|