Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


Member Since 17 Jul 2013
Offline Last Active Nov 11 2014 09:15 AM

Posts I've Made

In Topic: RayPicking

01 September 2014 - 02:43 PM

@bluespud, Where in your update/render loop do you put the color picking code? just before the swapping of buffers or after? for example, the code i use to determine the end point of the ray has to be put at the start of all the transforms otherwise the endpoint gets transformed incorrectly. I would imagine the readpixel would need to go after the buffer is swapped (ie rendered to screen) to get the right pixel information?

You can actually call it inside the render loop so it would look like this:


-render the scene


-swap the buffers


Because Im doing this with a Gbuffer, I have the frame buffer still bound, which Im pretty sure is required.

In Topic: RayPicking

30 August 2014 - 12:15 PM

Personally, I've used color picking. Also as a note, I'm using deferred shading, so it might not work in your case. Basically I render both an albedo and a normal with RGBA. Not, normals don't need the extra alpha channel, so I can store data there. Each object in the scene has a unique identifier that it uploads to the GBuffer shader and renders it as the alpha in the normal channel. Then after everything is rendered, I use glReadPixels to check the pixel from the center of the screen and then take the alpha value and look for an object with that identifier on the CPU side of the scene. Basically, besides the read pixels and the searching bit, this is free because I was already rendering 1 to the alpha channel, and I just replaced it with a more meaningful value. Its also a great solution because it works pixel perfect which is really great. Theres almost no math involved, and Im sure you could adapt it for a forward rendering solution, maybe render to a frame buffer with 2 color attachments and take the ID from the second one and then draw a fullscreen quad with the first one to the screen. I know that thats getting a bit into deferred rendering, but I think it would be worth it in the end just because its so simple and fairly cheap.


Good luck!

In Topic: VBOs Crash When Using Textures

11 August 2014 - 09:24 AM

The postet code looks fine so far (without testing it)


Can you post the part where you create the texture?

Also the exception which is thrown (i assume there is one if you mention a crash) would be interesting, together with the information where your code exactly crashes

I can't imagine that the texture is the problem because both display lists and immediate mode have no problem using it. It throws EXC_BAD_ACESS right on glDrawArrays. If I bind texture 0 and shader 0, everything works swimmingly, which is like the weirdest thing I've ever heard.

In Topic: VBOs Crash When Using Textures

10 August 2014 - 06:52 PM

Your glBufferData calls are wrong.  Instead of "&QuadVertexData" you should use "QuadVertexData" (i.e without the "&") or "&QuadVertexData[0]".  Likewise for QuadTextureData.

While you're right, it doesn't make a difference and still crashes.

In Topic: lights, shadowmaps and render count

10 August 2014 - 08:53 AM

I myself have been thinking about this problem for quite a long time now, just in the back of my head without really reading anything on it. If you really needed to have several shadow maps, obviously drawing a scene with 300,000 polygons several times is going to be slow. If your scene is static besides the camera, you only need to render the shadow map once, and then your all good, since none of the geometry is changing. I've also heard that VBO's can be instanced to reduce the cost of rendering the same object multiple times, but Im not sure if it can be used for shadow maps, but I'd still look into it. If you need dynamic objects, such as a player's shadow, I would think it could be cheaper to do a frustum culling-type algorithm for each light on dynamic objects. If there is at least one object in the light's view, update the shadow map. Also then preform frustum culling and maybe a bit of occlusion culling to see if the camera can see the light. If it can't, why render the shadow map? I haven't tried anything, and they'll probably be fairly complex to implement, but Im sure that you'll see that these are a lot better than the brute force method. Good luck.