| |
| |
| |
|
Comments:
<0> Ah, didn't notice Krissa was back... most temporarily
<1> "Intellectuals solve problems, geniuses prevent them." - Albert Einstein
<2> If I bind a array of verticies to a certain vertex buffer object, render the scene, then do another bind to the same vertex buffer object, will it use the verticies of the array in the new bind instead of the old ones?
<3> eh hmm
<2> hey Lord!
<3> hi there
<3> what are you trying to do
<2> 1 sec
<2> glGenBuffersARB () glBindBufferARB () glBufferDataARB ()... render stuff ...glBindBufferARB () glBufferDataARB () /* same name that I got from glGen */
<3> you dont need to call bindbuffer the second time afaik
<2> I do ... on the same name though
<2> oh
<2> I don't?
<3> well everything else in opengl operates that way, ie you call glNormal and the "current"normal is set until you call it again
<3> same with texture bindings
<2> ahh
<3> if you've bound a texture to a target, its bound until you bind something else to that target
<2> but
<3> NO BUTS!
<3> :P
<2> I do a glBind glBufferData for verticies
<3> ok
<2> then I do immidiately the same thing for Texture coords
<2> glBind BufferData /* verticies */ glBind BufferData /* texcoords */
<2> aside from 2 glGenBuffers
<3> right, then you've bound a different name to that target (GL_ARRAY_BUFFER) so if you want to update the verts youll have to rebind that
<2> yeah
<2> Ok so... generally what I had in mind with a bind and a bufferdata is the way right? 'reusing' the same name
<2> with a new array
<3> yeah
<2> but I think doing gen delete gen delete is wasteful
<2> how expensive is that anyway?
<3> yes dont do that
<3> driver dependent, might be cheap, might be expensive, i dunno, but id reuse it
<3> of course if you're toggling between sets then its a bit silly
<2> no I can't actually
<2> like having them all ready and just using different names?
<2> with a bind Vertexarray on different names everytime?
<3> uhm, well if you have a limited set of vertex arrays, just upload them all to different names, instead of constantly uploading them over and over
<3> that was my point
<2> that's not possible, because the transformation matricies for polygon groups in the mesh (for every frame) totally ruins the chance for me to predict future normals
<2> so I have to transform the polygroups, regenerate the normls and p*** them down along with texcoords
<3> mkay, how do you regenerate the normals?
<2> cross of the edges
<3> average of face normals?
<2> no, I transform the polygroup the regenerate all normals for all faces
<3> ah face normals
<2> unless I do some really freaky stuff with eigenvectors
<2> eg. find the rotation effect of the transformation matrix and apply it to all normals
<2> then in that case I just have to transform the normals
<2> or should I say rotate, cause I left behind the 'translation' effect
<3> well then
<3> specify the STREAM type then ;)
<3> although the driver is clever
<2> I wish MS would just write rotation and translation matricies for polygroup/frame separately
<3> hmm cant you just transform the normals with the transpose inverse matrix?
<2> (.X format)
<3> ah
<2> transpose inverse of transformation
<3> yeah
<3> thats what opengl uses for its normals
<3> ie transpose inverse of the modelview
<3> or was it inverse transpose... hmm checking
<3> ah es
<3> yes
<3> transpose of the inverse of the upper left 3x3 of the modelview
<3> aka the proper way of transforming normals
<2> wait a minute
<2> omg
<2> isn't the 4th row and column for translation only?
<3> one of them is column
<3> the other is used for perspective stuff
<3> and i forget which is which in opengl :)
<2> I'm just generally saying
<2> in math
<3> yeah
<2> tx,ty,tz,1
<3> in homogenous coordinates
<2> let me check one of the meshes
<2> the rest just 'rotates' no?
<3> you use the last row/column for translation
<3> and scales/skews
<2> well ... I might scale =P
<2> if I make some wobly monster
<3> which is why its the inverse
<3> well that too
<3> or was that the transpose
<3> there was a nice doc about why
<2> so wait
<2> do I really need to do inverse transpose?
<2> well I'll try that out... sounds great
<3> shoot cant find the doc
<3> http://www.cs.wisc.edu/graphics/Courses/559-s2004/lectures/cs559-17.ppt slide 5
<2> Lord ... I don't know why I need inverse transpose
<2> can't I take out the translation terms?
<2> and make them all zero?
<3> qman: that doc explains why
<2> dude of course
<2> they're special orthogonal
<2> I just need to take out the translation terms
<3> http://www.cs.cmu.edu/~djames/15-462/Fall03/notes/C***Everitt-MathematicsOfPerPixelLighting.pdf
<3> here we go
<2> I don't need the inverse trnasponse
<3> you do
<3> :)
<2> Lord, it's all clear now
<3> well ok :)
<2> my transformation matricies are all special orthogonal man
<2> well unless they have skews
<2> suuuuure
<2> I'll do a inverse trans
<2> if I have skews
<2> gee nevermind, thanks
<2> later Lord
<3> l8r
Return to
#opengl
or
Go to some related
logs:
ezrecovery 5.1
spf2 policyd doesn't compile
#tcl
#computers
SQLDA missing or incorrect firebird
#hardware
babchuck carolina trade
jack daniels plastic bottle 0,7
#hardware
#windowsxp
|
|