Jump to content

  • Log In with Google      Sign In   
  • Create Account

Geometrian

Member Since 10 Apr 2007
Offline Last Active Today, 09:17 AM
-----

Topics I've Started

*Want* Multiple Base Objects

31 May 2013 - 07:59 PM

Hi,

 

I had come across an . . . unusual programming situation.

 

I have a FBO2D base class, which implements a 2D framebuffer object, and I wanted to implement a FBOCube class derived from it, implementing a cubemap framebuffer object. The point is that FBOCube is essentially six FBO2D classes, but it still kinda makes sense to derive from it. In effect, I want six FBO2D parents for a single object. The language is C++.

 

I realize this is awful, and I'm redesigning it, but I thought it was an interesting thing. I'm pretty sure it's not possible in C++. I'm curious: what does the programming community think?

 

-G


Fixed-Function Light Flickering when dot(N,L)=0

27 May 2013 - 04:57 PM

Hi,

 

I have a bizarre problem. There is a simple OpenGL fixed-function light drawn at (0.0f,10.0f,-1.0f). There are several boxes that happen to have faces lying in the plane z=-1.0f. Consequently, the light vector and the normal are exactly orthogonal.

 

When this happens, instead of being black, the color flickers light and dark along that face, even when the camera is stationary. The draw settings are identical each frame. It's not a z-fighting effect; there's only one layer of polygons, and the flickering continues even when the camera is stationary. Each vertex of the face appears either lit or unlit, though it's unpredictable which a given vertex will be from frame to frame.

 

The light has no ambient, and by tweaking the light's diffuse and specular factors, I find that the problem only occurs when the light's specular coefficient is nonzero. Perturbing the light slightly along z fixes the problem; it's only when the light is exactly in line with the surface that the problem occurs. I can fix the problem better by just using a shader (which I plan to do anyway), but I'm wondering if anyone has encountered this before?

 

I suspect it may be some kind of driver bug.

Hardware: NVIDIA GeForce GTX 580M

Driver: 305.60

 

Thanks,

-G


Sloped Bullet Heightmap Inaccurate

14 May 2013 - 02:10 PM

Hi,
 
I can create a Bullet heightmap and collide with it. The results generally seem to be correct (large scale features are there). To test, I drop some objects in random places and have a look.
 
A perfectly flat heightmap is collided perfectly (of any height, as long as it's constant).
 
However, if the heightfield is sloped, objects penetrate a surprisingly far distance (seemingly related to the slope at that point).
 
For completeness, how the heightfield is made:

float scale[3] = {1.0f,1.0f,1.0f};
 
//create and fill data
 
btHeightfieldTerrainShape* new_shape = new btHeightfieldTerrainShape(data_size[0],data_size[1], data, 1.0f, 0.0f,scale[1], 1, PHY_FLOAT, true);
new_shape->setLocalScaling(btVector3(scale[0],1.0f,scale[2]));

offset[0] = scale[0]*data_size[0] * 0.5f;
offset[1] = scale[1]              * 0.5f;
offset[2] = scale[2]*data_size[1] * 0.5f;
 
//translate heightmap's associated body to "offset", thus
//putting one corner of the heightmap at the origin.

Here's a screenshot from underneath a heightmap of some cubes falling on it. Notice that the cubes penetrate about 10% to 20% of their depth in!
image1go.png

 

Thanks,

-G


OpenGL Erroneous Context Version

25 April 2013 - 12:17 AM

Hi,

I need at least an OpenGL 2.1 context, and preferably more. I am interfacing directly to the Win32 layer.

I'm setting up a context in one of two methods; neither works correctly all of the time.

Method 1:
1: Create an invisible dummy window that "hosts" the context
2: Make context with wglCreateContext
3: Set context to be current
4: Load extensions
5: Make a new (visible) window and use the context in it.

Method 1 seems to work fine for most programs using this code, and glGetString(GL_VERSION) typically indicates a 4.2 context (as high as my card supports). However, in one particular program, for some reason it instead indicates a 1.2 context and advanced functionality subsequently fails.

To try to solve this, I changed the code to implement method 2.

Method 2:
1: Create an invisible dummy window that "hosts" all contexts
2: Make a dummy context with wglCreateContext
3: Set the dummy context to be current
4: Load extensions
5: Make a new context with wglCreateContextAttribsARB having the desired properties
6: Set the dummy context to be not current and then set the new context to be current
7: Delete dummy context
8: Make a new (visible) window and use the new context in it.

Using this, I can get an OpenGL 3.1 context to work correctly (since my programs use OpenGL 2 functionality, a 3.2 context is not used). However, for that one particular program, something very odd happens. glGetString(GL_VERSION) indicates a 1.2 context, but trying to check it with this:
int version[2];
glGetIntegerv(GL_MAJOR_VERSION, version );
glGetIntegerv(GL_MINOR_VERSION, version+1);
printf("OpenGL %d.%d\n",version[0],version[1]);
. . . indicates the 3.1 context as requested! However, the advanced functionality still fails, so I suspect it is wrong in saying so.

It's worth noting that the code for the one particular program where both methods fail is directly copied from a program that works. For some reason, when compiled, the binaries don't hash to the same value, which means that some configuration option might be perturbing this problem into existence.

-G

Facilities for Physics-Based Animation

20 April 2013 - 02:16 PM

Hi,

 

I'm looking for a way to animate humanoid characters in a physically-based manner. This is a problem of Physics and AI, but I think it's more a problem of AI. I asked about it on BulletPhysics.org here, but didn't get any answers. The problem is: given a ragdoll character, make it, under its own force, move around.

I have looked around a bit, but wasn't able to find anything useful in the way of a toolkit--mostly it's just technical papers on the topic.

My requirement is that the character is able to walk or run in any direction over fairly varied terrain, and get up after a fall. Pose matching, within reason, is also necessary. Minor attempts to correct if an obstacle has been tripped over would be nice. Open source is a must.

 

Having read a bit of the literature, I realize that these aren't trivial requirements, but there are for example youtube videos that demonstrate the technology in action. The problem is, there aren't toolkits that do it, as far as I can tell.


Thanks,


PARTNERS