Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 30 Aug 2006
Offline Last Active Yesterday, 10:25 AM

#5162992 Can't use imageBuffer with integer data (Compute Shader)?

Posted by JoeJ on 26 June 2014 - 05:47 AM

Ooops, solved:


layout (binding = 4, rgba32ui) uniform uimageBuffer TpackInt;


...i just forgot to add the u rolleyes.gif

#5065328 How do I get the euler angle from a matrix?

Posted by JoeJ on 27 May 2013 - 01:53 PM

I once extended that so it can handle various orders. I did not check if it works with orders like XYX, but XYZ is ok.

Note that it's for OpenGL matrices, so you need to swap matrix indices.


static v3f ToEulerAngles (matrix4f &m, int order = 0x012) // 0x012 = xyz, 0x201 = zxy and so on...

  int a0 = (order>>8)&3;
  int a1 = (order>>4)&3;
  int a2 = (order>>0)&3;

  v3f euler;
  // Assuming the angles are in radians.
  if (m.m[a0][a2] > 0.9999)
  { // singularity at north pole
   euler[a0] = -atan2(m.m[a2][a1], m.m[a1][a1]);
   euler[a1] = -PI/2;
   euler[a2] = 0;
   return euler;
  if (m.m[a0][a2] < -0.9999)
  { // singularity at south pole
   euler[a0] = -atan2(m.m[a2][a1], m.m[a1][a1]);
   euler[a1] = PI/2;
   euler[a2] = 0;
   return euler;
  euler[a0] = -atan2(-m.m[a1][a2], m.m[a2][a2]);
  euler[a1] = -asin ( m.m[a0][a2]);
  euler[a2] = -atan2(-m.m[a0][a1], m.m[a0][a0]);
  return euler;


#5051464 Realistic/alternative first person carrying of objects

Posted by JoeJ on 09 April 2013 - 06:01 AM

Have you already implemented an interaction model?

I ask because - usually you get the effects of your ideas by unwanted accident, while developing :)

It is harder to create a responsive and stiff interaction than a laggy one.

If your model is responsive, it is easy to make it more smooth, laggy, or feeling heavy as you want.

I like the ideas, i saw most of them done very well in the game 'Penumra' for the first time.

It's more physics related than Amnesia and you should toke a look, if you don't know it already.

HL2, Dead Space... are not very good examples. They use Gravity Guns and other magic forces to operate on objects.

I think this is not a question of game design, it's done to hide the physics engines weakness (Push an object against a wall,

and it starts jittering... but you don't recognize - you think it's because the 'magic force')

If you're free to choose physics engine - take a look an Newton!

And if you wanna be really innovative - think most about how to handle the rotation of the objects :)

#5044833 Shaders and VBOs, Performance and Relation

Posted by JoeJ on 20 March 2013 - 04:16 AM

Downgrade? Don't treat my disagreement as attack to you or the things you said.

I just wanted to point out that both methods should result in equal GPU instructions and performance.


Except the performence difference all the other questions already had good answers.

We all know we should not use deprecated stuff and how to put a percent value in relation with a fixed number.

#5044802 Shaders and VBOs, Performance and Relation

Posted by JoeJ on 20 March 2013 - 02:09 AM

Don't agree to all of that.


Both options calculate a combined modelview / projection matrix once per frame.

I assume Danicco simply forgot to post the 2nd projection setup, and matrix setup does not affect performance because he uses lots of vertices (?)


And both should do a single matrix mult per vertex.


Option 1 does it in shader and option 2 too, because OGL will add the necessary instructions automatically (If it doesn't know it should not), right?

Thus my assumption that this accidently happens to option 1 too.

Maybe there's even a driver bug forcing this to happen all the time - who knows?


Also, pure FPS should be accurate enough to measure a 25% difference, if there are enough vertices in the test.

#5044523 Android game loop issues

Posted by JoeJ on 19 March 2013 - 04:08 AM

Edit: "i've all that in one class/file, if you wanna keep Java as less as possible" means:

I use only one activity (GLViewSurface), and generate the second thread within that - so only one activity but multiple thread.


Some personal advice: Understanding lifecycle is somehow frustrating - don't mix that stuff with your game code - don't divide your game code in a way you think android might request.

Keep the interface between OS and game as small as possible. That way the game keeps portable and fun developing, while the frustrating OS section keeps small and exchangeable :)

#5044517 Android game loop issues

Posted by JoeJ on 19 March 2013 - 03:42 AM

You should consider adding multithreading from start on - it was some work for me to add it later.

Because on mobiles calls to OGL do not return until the GPU finished its job, even single cores benefit from it.


For me it looks somehow like this (i've all that in one class/file, if you wanna keep Java as less as possible):




float accelV[3]; // global sensor data


PhysicsThreadFunc () // called from thread 1


      if update request flag -> do physics using accelV, game logic, setup render stuff and store results



GraphicsThread () // onFrameDraw called from thread 2


      if results are ready, copy them, render and set request flag // while rendering (CPU mostly waiting), next physics step executes in parallel



AcceleromaterMessage () // called frequently from thread 3 - you can set the update rate only by symbolic definitions ('GAME', 'FASTEST'...)


      accelV[0] = ... // simply update - writing a float is atomic, so no need to synchronize with simultaneous read access from other threads


#5044380 How to center a rotated line between two angles

Posted by JoeJ on 18 March 2013 - 04:46 PM

I want to calculate the distance d that moves the beta angled blue line out of unit circle center so that both alpha angles are equal.

Seems not so easy than i initially thought - please help :)



#5040430 How feasible is using the NDK?

Posted by JoeJ on 07 March 2013 - 10:12 AM

Using NDK is a must for me, as it allows to share 99,9% of code with IOS, and i can develop my game with Visual Studio 99,9 % of the time :)

Using native activity is only available on updated devices, so i avoid it and use java for those things:


* Loading files (c file functions work, but can't access the comprerssed package contents so easy)

* Sound (OpenAL is available but relatively new to Android)

* Threading (never tried pthreads, but they would be available on IOS too!)

* Creationg OGL context 

* reading sensors

* (Network, server communiction... if you need)


Expect a little bit of pain getting all this basic things to work, but then it shouldn't be a problem

to run any OGL engine with a few #ifdefs, no matter how complex it is

NDK itself is just C++ as you know it - Nvidia has some nice Installers that setup all you need (Cygwin...)

#5026045 What is the point of using Catmull-Clark subdivision shaders?

Posted by JoeJ on 27 January 2013 - 07:27 AM

actually, the artist have barely control over where bulging etc. happens

I've never modelled anything with catmull-clark surfaces -- is the tesselation shape dependent only on the vertex positions and normals, like phong tesselation?
Normals are ignored. The new points are build by averaging neighbouring polygon centers, edge centers, vertices... The different rules for subdivided corner points / edge-, poly-centers are simple, but because the process is recursive, it's difficult to accelerate.

I've done a lot of modeling with catmull clark and also made my own editor because i was not happy with crease options from commercial apps.
For modeling organic shapes catmull clark is the best option. With proper creases it's also a very good alternative to nurbs for things like cars etc., while still easier to understand.
Cons are: You need to avoid triangles and use regular quad grids whenever possible. A good model will end up with mostly quads, some 5 sided and a few 6 sided polygons.
Subdividing a typical triangulated mesh makes no sense - you need to have the original quadbased model to get good results.

The first subdivision step is special, it does the most important work and ends up with a mesh containing quads only.
For a good HW-acceleration it gives sense to do it with its own algorithm, maybe on CPU.
For following steps it could give sense to switch to a more hardware friendly method, like bezier patches.

If anyone has experience with practical HW-acceleration i would like to hear something about it too...
Note that this can be a very good thing, because if you do the skinning with the low res control mesh, you get MUCH better final high res skinning! This also saves some work, as you don't need to skin the subdivided stuff.

Skinning is where difference to other tesselation methods shows up most noticeably. Because the corner vertices get smoothed too, not just the surface around them. Maybe it's hard for a programmer to get the point why they are so good compared th other methods - but with skinning the difference in visual quality is really huge. Trust me :)

#5012063 octree stackoverflow

Posted by JoeJ on 18 December 2012 - 08:50 AM

sNode = nodes[i];

This adds the object to a vector, right? It looks like it replaces the current pointer with a new one, storing only one object at the end.
I'm noob with stl and c++11.

The image looks nice (min / max is good way to define axis aligned boxes),
but you need to visualize that inside your engine, to proof that its right.

I'd do this: Turn off Z-Test, traverse the entire tree, if a leaf is found, draw its slightly shrinked extends with a transparent color.
Build the color from the nodes memory adress, so you can see different nodes better.
For each object in the node, draw a line from node center to object center.

Afterwards draw all objects in wireframe. Navigate through the scene, and check if the objects are linked correctly to the nodes.
If an object has no line, or the line points to a node far away, you know more.

If still anything looks right, visualize the cameras viewing pyramid (to see that, you need two cameras, one to observe and one for yourself to fly around).
While traversing octree, draw nodes extends in white wireframe, if they fail the observeds cameras frustum check.

...that's some work, but you will surely see the bug - from another perspective - and then its easy to find it.
And its good for future bugs.

#5011976 octree stackoverflow

Posted by JoeJ on 18 December 2012 - 04:17 AM

I still believe its a geometirc issue.
Are the missing objects popping depending on camera or do the never appear?
Did you check after the creation, if each object ist at least in one node?
Did you visualize the node extends, maybe one of the 8 cases has a bug?

For occlusion query it's good to draw objects in raw front to back order, even without occ. test that saves pixel shader due to early z-test.
To achieve that you draw objects by traversing the octree bottom down drawing the near child first.
Here the loose octree has advantage too, because front back order is more precise and you draw large objects (good occluders) first.
but its easy to try that after you found the bug...

Some other things you may or may not end up with later, just to keep in mind:
Node extends and position can be calculated dynamically while traversal, no need to store them for each node.
If you align the grid at integer coords, you can use brachless integer bitmath for very fast searching in the tree.
Mostly it's a win to either point to an array of 8 children (some of them may end up unused), or there are no children.

Personally i use it for the same purpose, but i have not made any of those optimisations listed above :)
But i did it with a software-renderer that used quadtreecompressed lightmaps, so each scanline was clipping a line into the quadtree,
and there i saw a great speedup.

#5011828 octree stackoverflow

Posted by JoeJ on 17 December 2012 - 03:54 PM

Hi there,
I can't read your code - too much stl :/
But i remember the pitfalls with octrees, so that might be helpful, if you don't know it:

The problem is: What to do with an object that is split by one or more grid planes?
Put it in each node and draw it multiple times?
Put it in one node and missing to draw it whaen the node is clipped? (guessing thats your problem)

Solution: Put each object to the node, where this condition is true:
objects bounding box center is inside node
AND the largest dimenson from the objects bounding box <= the dimenson of the node.
AND the largest dimenson from the objects bounding box > half the dimenson of the node.

... this results in large objects at the top levels, and small objects at the bottom levels of the tree.

While clipping extrude the nodes by one half of its dimension at each side (so it has 4 times its volume).
This is the volume that surely covers all objects.

I guess that is called 'loose octree', but i'm not sure.