Jump to content

  • Log In with Google      Sign In   
  • Create Account


Scienthsine

Member Since 25 Sep 2008
Offline Last Active Sep 25 2012 09:16 AM
-----

Topics I've Started

Formula in Advanced Character Physics Paper

03 October 2011 - 09:13 PM

I've never quite _fully_ finished a verlet particle physics system based on this paper. I always get stuck on the Rigid Bodies section on page 3. Specifically when he's going through and deriving a formula for separating a constraint that has collided with a wall, it doesn't make sense to me. He eventually defines a symbol 'lambda' as:
Posted Image
However, delta is defined earlier in _this_ section as (q-p)

So wouldn't that be delta*delta... and wouldn't that cancel out with the bottom delta^2 to just: lambda = 1/(0.75^2+0./25^2) ? (Ofcourse with actual variables instead of constants for 0.75 and 0.25)

Do note that q and p are vectors, so the dot is a dot product... but the same rules still apply right?

This is the paper:
http://www.gamasutra.com/resource_guide/20030121/jacobson_03.shtml
Though note that some of the symbols are messed when not in an image.
This copy of it has all the symbols even in the text:
http://www.gotoandplay.it/_articles/2005/08/advCharPhysics_p02.php?PHPSESSID=566f57fb1cf5f20c333dab15b6436005

I'd very much appreciate any clarification or explanation anyone could provide. This has been a stumbling block for me for several years.

Thanks,
James Newman

Yet another OOP question.

19 September 2011 - 05:01 PM

I'm in the middle of writing a small graphics lib for my future games, and just found myself writing a Shader object. Something it rubs me wrong. What is the point in me wrapping glCreateShader into Shader::Create(), and glUseShader into myShader.use()? I think I'm biased towards more procedural code, so maybe that's just it... Ideally I won't ever touch opengl directly from the game code itself. Only the graphics lib will actually use the gl* commands... so is there any real benefit to the wrapping?

I'm interested in what other people do. I mean... it's already pretty OO imo...

[Edit] Yes and no seemed confusing.

Bindless Textures

30 January 2010 - 12:34 PM

I'm playing around with OpenGL 3.2, and it seems to me that binding textures really fragments what could otherwise be a pretty strait-forward batch drawing of primitives. IE: When drawing a bunch of 2d sprites, a vbo containing all of the data needed to draw them is trivial; however binding textures fragments the drawing calls. The best I can think of is to sort by image and draw each range from the vbo, but if drawing order is important, and not related to texture... this may not help much at all. It just seems to me that I should be able to pass an attribute to specify which texture to use... the texture is already in the gpu... so what's the problem? I could use texture arrays and all of my texture slots for a somewhat usable hack to get what I want, but it has it's limits. It seems nvidia's bindless extension is meant for buffers only, not textures... unless I'm missing something. Now... there are texture buffers, which may? be able to be bindless. They come out as a 1d texel array with no filtering or anything, so not ideal either. Does anyone know of something that would allow me to do this? Is there something I'm missing, or do I gotta just live with it?

glBindFragDataLocation segmentation fault [SOLVED]

08 December 2009 - 03:54 PM

've got all of my code to gl3+ compliance now, I think, except I'm still using fragdata in the fragment shader because my glBindFragDataLocation function causes a segmentation fault when I try to use it. Also, I'm using glew, and although 'glewinfo | grep glBindFragDataLocation' says I'm good for both glBindFragDataLocation and glBindFragDataLocationEXT, when I do a 'printf("%ld",(long)glBindFragDataLocation);' I get null. So... help? This is the area of code around my problem: GLuint myShaderProgram; myShaderProgram = glCreateProgram(); glAttachShader(myShaderProgram, myVertShader); glAttachShader(myShaderProgram, myFragShader); glBindAttribLocation(myShaderProgram, 0, "inVertex"); glBindAttribLocation(myShaderProgram, 1, "inColor"); glBindFragDataLocation(myShaderProgram, 0, "outColor"); //Comment this out, and it works. (with gl_FragData[0]). printf("%ld",(long)glBindFragDataLocationEXT);//0!? glLinkProgram(myShaderProgram); glUseProgram(myShaderProgram); and this is my fragment shader: #version 150 core in vec3 exColor; out vec4 outColor; void main() { vec3 tempC; tempC = exColor; tempC.r = tempC.r * 0.5; tempC.g = tempC.g * 0.5; tempC.b = tempC.b * 0.5; gl_FragData[0] = vec4(tempC,1.0); outColor = vec4(tempC,1.0); } Kinda new to this... so any help is appreciated! [edit] Found the problem, GLEW wasn't setting the function pointer for some reason, pulled it in on my own and it works. [/edit] [Edited by - Scienthsine on December 9, 2009 7:34:11 PM]

[SOLVED] glBindAttribLocation and NVidia

01 December 2009 - 01:10 PM

Does NVidia's drivers still not allow you to use the indices for old built-in vertex attributes? From: http://developer.download.nvidia.com/opengl/glsl/glsl_release_notes.pdf If so... doesn't this make glBindAttribLocation kinda useless? I would really like to have all 16 of my vertex attributes and be able to reference them with my own names... WTF NVidia? [Edited by - Scienthsine on December 2, 2009 5:52:44 PM]

PARTNERS