• Create Account

# Arjan B

Member Since 04 Nov 2007
Offline Last Active May 14 2016 03:39 AM

### #5271828'Remove' direction from velocity

Posted by on 19 January 2016 - 08:16 AM

Just to add to Alvaro's comment: projection of A onto B gives you all of A in the direction of B. This is why he/she subtracts that projection from A. The Wikipedia page on vector projection calls this the rejection of A from B: https://en.wikipedia.org/wiki/Vector_projection

### #5263722Uploading a 1D texture in OpenGL - All (0, 0, 0, 1)

Posted by on 26 November 2015 - 12:06 PM

Wow, thanks a lot guys!

I ended up doing what Juliean said, which brought me right to the glUniform1f() function. And exactly as Nanoha stated, it generated a GL_INVALID_OPERATION error, which was fixed by simply replacing the 'f' with an 'i'. Wish I'd posted here sooner, I spent tons of hours sadly staring at my screen as well.

Thanks again!

### #5248547Is ray tracing hard or is it just me?

Posted by on 24 August 2015 - 09:54 AM

I think it's appropriate here to link to Bacterius' journal: http://www.gamedev.net/blog/2031-ray-tracing-devlog/. I think he does a good job at thoroughly explaining the process of writing a raytracer.

### #5159162Beginning GLSL - Quick Question

Posted by on 08 June 2014 - 05:45 PM

Good luck! This online book helped me greatly: http://www.arcsynthesis.org/gltut/index.html

### #5158878Beginning GLSL - Quick Question

Posted by on 07 June 2014 - 04:30 AM

Well, uniform variables in GLSL remain constant over a drawing call, like glDrawArrays() for example. So with a separate call, I meant that you have your uniform matrix set for drawing the background tiles, draw them, set the uniform matrix for your character and then draw that one.

If you were to use a different shader for drawing your character, which uses an extra matrix that you don't want to have in the drawing of your background tiles, then you would have to create a separate shader and program for this. You then just bind the right program right before you draw.

Now my initial suggestion of using an extra matrix might be overkill for simple quads (I assume you draw 2D sprites on quads). If all you plan sprites to have is different positions, then you could use some uniform offset/position variable. For all these different characters, you would first set the uniform position variable, then draw that character. This might be very similar to what you are doing now, I guess.

I'd like to add that I'm by no means an expert, I'm just putting my thoughts out there.

### #5158639Beginning GLSL - Quick Question

Posted by on 06 June 2014 - 02:09 AM

Instead of altering a buffer with positions, wouldn't it be a good idea to draw your character in a separate call and alter the matrix that specifies where it will be drawn?

Usually, when working with a 3D mesh, the vertex positions are specified in its own model coordinate system. Using a set of matrices, you can transform those positions from its model space to a place in the world, and then possibly perspective projection and so on. The perspective projection stays mostly the same for all meshes, while the matrix that moves the mesh from model space to world space changes from mesh to mesh.

For your 2D game, you could have an extra matrix that specifies a translation and a rotation for the sprite that you are drawing. It's made up of the position and orientation of your character, for example.

### #5157129The future of VR in gaming

Posted by on 31 May 2014 - 06:09 AM

I'm doing my master's in CSE now, and last semester I had a course called Interactive Virtual Environments. We did not have access to an Oculus Rift or Kinects, but we did get access to a CAVE: a front, left, right and bottom wall, with projectors on each wall for stereoscopic view. It also had a motion and orientation detector attached to the glasses that were used for the stereoscopic view.

Groups were left free about what sort of world to create for this CAVE, but had to look into how "real" their worlds were perceived by the user. Our group, for example, built a big scary bridge, which users would have to walk over. The second walk, big bloody swinging axes would appear. Other walks, there would be holes in the bridge. Other walks were a combination of the two, or faster swinging axes, for example.

It was interesting to see how users would evade the axes and the holes, even though there was no perceivable penalty for going right through/over them. Since being hit by huge axes and falling through holes usually does not end well in the real world, made them immediately assume that it would be no different in our virtual world.

Even though a lot of users enjoyed the experience, they all said that they did not feel that the world was very real. Our programmer art skills might be to blame. But the use of a Wii-mote to move, instead of moving in the world by moving your own body, is what I think to be the biggest factor in this.

All in all, I really enjoyed working on this project. The video you showed looks really impressive. It's funny to see how the guy also tries to evade the table with his legs, kind of like how our users tried to evade the holes.

### #5122367Path tracing - Incorrect lighting

Posted by on 09 January 2014 - 08:17 AM

I was able to fix it!

In my intersection function for the "world" I had an output parameter for the distance to the closest intersection, but I never saved that distance in the output parameter. This fixed the weird pattern you can see in the previous post.

I got horizontal black lines in the image as well, which were due to the fact that my intersection functions did not take rounding errors into account yet. So now I make use of the Ray's minimum t value to determine whether an intersection is considered valid.

Thanks for the help, everyone!

PARTNERS