this will probable explain it much better then I could
mine is a single linked looped list and I am using an array of children which makes it possible for each and every class to maintain any number of lists without a container class to manage them. I will try to extract it from my code if you really want it. I plan to release my framework when it is finished but I can't really say how long that will be.
http://en.wikipedia.org/wiki/Linked_list
another headache.. object picking!
I've read about different methods and looks like ray casting is a way to go in my case. But I'm having problems with gluUnProject , not sure what to feed to it.
Samples I've seen are useing something like that to obtain values for it:
glGetIntegerv(GL_VIEWPORT,@viewport);
glGetDoublev(GL_PROJECTION_MATRIX,@projectionMatri x);
glGetDoublev(GL_MODELVIEW_MATRIX,@modelMatrix);
those get me identity matrices for projection and model. I guess it's because i'm doing all 'projection' computations in shaders only. I think I know how to fill projection and viewport matrices but every model has it's own model matrix. Should I just use any's model matrix for gluUnProject ? (tried and it didn't work ;p )
Do you really need ray casting? If you only want to select objects at e.g. a given cursor position, just go for color selection. Especially with shaders that's pretty simple and fast. I'm using this technique for selection too (see here). It's easy to implement and extremly fast.
It works like this :
- Render your scene to the backbuffer (so it's not visible), but only with colors and basic geometry. E.g. one building red, another yellow
- Limit the viewport to the cursor position (for performance)
- Read the pixel under the cursor (glReadPixels)
- Compare read colors with your color-to-object-table
It's very fast and can be implemented in just a few minuts. Especially when using only shaders you just need a new shader the outputs selection colors to the fragment buffer.
If you want to use ray casting, you can check nxPascal demos. Model and Picking demos both use that math. Doing it mathematically has the advantage of knowing exactly which model face the ray hits, and what is the normal vector at that point.
There is also GL_SELECT based function on the works, but it's not working in my tests yet. I used that style many years ago, so at least there's some code left.
@Sascha: I'd use color picking if i could but I'm not texturing voxels and I don't plan to. To do color picking in this scenario I guess I'd have to render geometry with unique colours and then change them to proper values from some reference texture?
@User137: yeah, I'm using your engine as a reference from time to time but picking there is done in a way I've described in my previous post. Where do I get model matrix from if glGetDoublev(GL_MODELVIEW_MATRIX) doesn't seem to do it's job?
Internet says GL_SELECT is obsolete and shouldn't be used anymore
edit: another problem with color picking is that I have tons of cubes on the scene so lookup would be costly unless I encode cube coords into color..
Last edited by laggyluk; 09-01-2013 at 06:37 PM.
The old OpenGL-Selection (GL_SELECT) shouldn't be used anymore and as far as I know it isn't available in newer OpenGL-versions anyway. And even if it would, hardware vendors decided to drop hardware support for it some time ago, so rendering in selection mode is done in software and therefore often extremly slow.
As for color selection via shaders : No, you don't need textures at all. Just assing a color to each voxel when creating it (you've got 24 Bits to encode your color, that should be sufficent), render with that color, pick it from the backbuffer and compare. If you render a lot of cubes you should have some kind of visibility check (e.g. an octree), so you can use that to speed up this process.
Bookmarks