Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Silverlan

Member Since 02 May 2013
Offline Last Active Yesterday, 06:55 AM

Topics I've Started

Occlusion Culling - Combine OctTree with CHC algorithm?

11 December 2014 - 02:03 PM

I'm trying to implement occlusion culling in my engine to improve my framerate. The general idea is this:

The entire scene is split into OctTree nodes where all visible meshes are contained. The scene is very dynamic, therefore some of the nodes in the OctTree change every frame.

There's only a single OctTree for the entire scene.

 

I want to combine this system with the coherent hierarchical culling algorithm, but I'm unsure how to do so.

The CHC algorithm basically travels through the OctTree hierarchy, looks for visible nodes, and marks them as such.

The problem is, the CHC algorithm needs to be run several times, once for the view camera, then for each light (to cull shadow casters), again for reflections, etc. That means the CHC implementation has to be separated from the actual OctTree and can't be directly integrated.

It still does, however, need the same hierarchy structure as the OctTree to be able to traverse correctly, which means I essentially have to 'duplicate' the OctTree hierarchy for each CHC instance. This is problematic, because as I've said, the OctTree is dynamic and nodes can change, which would be difficult to reflect in the CHC tree.

More importantly, the duplication and constant synchronization between the OctTree and the CHC Tree seems like an unnecessary drain of resources and speed.

 

Alternatively I could store the CHC node information directly in each OctTree node, but I'd need some sort of container to account for all CHC instances and that seems highly impractical.

 

I can't help but feel there has to be a better way, but I'm out of ideas.

Any help would be much appreciated.


Bullet - Setting up a slider constraint (btSliderConstraint) / Using btMatrix.setEulerZYX?

13 November 2014 - 04:25 PM

I'm trying to figure out how to create a slider constraint, but so far none of my attempts have worked properly.

 

In the fork lift demo from the SDK, the slider constraint for the fork is set up like this:

btTransform localA;
btTransform localB;
[...]
localA.setIdentity();
localB.setIdentity();
localA.getBasis().setEulerZYX(0, 0, M_PI_2);
localA.setOrigin(btVector3(0.0f, -1.9f, 0.05f));
localB.getBasis().setEulerZYX(0, 0, M_PI_2);
localB.setOrigin(btVector3(0.0, 0.0, -0.1));
m_forkSlider = new btSliderConstraint(*m_liftBody, *m_forkBody, localA, localB, true);
m_forkSlider->setLowerLinLimit(0.1f);
m_forkSlider->setUpperLinLimit(0.1f);
m_forkSlider->setLowerAngLimit(0.0f);
m_forkSlider->setUpperAngLimit(0.0f);
m_dynamicsWorld->addConstraint(m_forkSlider, true);

The parameters to create a new slider constraint are:

btSliderConstraint (btRigidBody &rbA, btRigidBody &rbB, const btTransform &frameInA, const btTransform &frameInB, bool useLinearReferenceFrameA)

In the demo, the slide direction is set up with these two lines:

localA.getBasis().setEulerZYX(0, 0, M_PI_2);
[...]
localB.getBasis().setEulerZYX(0, 0, M_PI_2);

I'm assuming these are euler angles with z = pitch, y = yaw and x = roll.

In this case the fork is moving upwards and downwards.

Changing it to (M_PI_2, 0, 0) allows it to move left / right, and with (0, M_PI_2, 0) it's forward / backward.
 
M_PI_2 is a rotation of 90 degrees so that makes sense to me. Problem is, this only seems to work if the angles are aligned on an axis, meaning something like (M_PI_4, M_PI_2, 0) ends up doing the same as (0, M_PI_2, 0), which I don't really understand.
 
Could someone please enlighten me how to actually use setEulerZYX, or how to set up the slider constraint for a specific (non-world-axis-aligned) axis?
 
 

[PhysX] Allow players to slide down slopes / Controller contact callbacks

18 October 2014 - 10:21 AM

I know that PhysX already has a built-in function to allow character controllers slide down slopes, but I need a bit more control.

The problem is, with PxControllerNonWalkableMode::ePREVENT_CLIMBING_AND_FORCE_SLIDING it just seems to accelerate the controller more and more until it has reached the end of the slope. PxControllerNonWalkableMode::ePREVENT_CLIMBING on the other hand cancels out any up- or downwards velocity on the controller altogether, until the controller has left the slope.

 

I want the controller to be able to slide down, but affected by gravity.

To do that I need some sort of callback which allows me to retrieve whatever actor the player is standing on, as well as the normal of the triangle / surface.

Is there such a callback in PhysX, and if not, how can I achieve what I want to do?


Creating multiple OpenGL contexts with GLFW on different threads

17 September 2014 - 10:24 AM

I'm using GLFW 3.0.4.
I'm trying to improve my loading times by having all resources, including textures, loaded on a separate thread. Problem is, to actually use any opengl functions in a different thread, without blocking the main one, I need a separate opengl context as well.
GLFW doesn't seem to provide any functions to create an independent context, you can only create it in combination with a window. That's not much of a problem however, considering you can just hide it. The problem is this:

 

Note: This function may only be called from the main thread.

(http://www.glfw.org/docs/latest/group__window.html#ga5c336fddf2cbb5b92f65f10fb6043344)

 

So that path is basically down the drain.

 

Are there any alternatives for what I'm trying to do, or would I have to end up using a different library for creating the window/rendering context? If so, which one?


Vertices with multiple UV coordinates and glDrawElements()?

01 September 2014 - 01:00 AM

This is essentially the same problem as the one described in this thread, however, seeing as the thread was started in 2003, things may have changed by now.

 

Basically, the problem is that my model can have multiple UV coordinates for vertices which are used by more than one face.

I'm using glDrawElements, but I'd like to avoid having to duplicate my vertices, just to fill it up to correlate with my UV coordinates.

 

Is there a way to use a separate index buffer for the UV coordinates and use that in conjunction with the main index buffer for the vertices?

Or is there an alternative altogether?


PARTNERS