Yep, that's it, sorta; you might want to use some other kind of logic to generate the uv's in a different way.
I looked at it again a few minutes ago, messing with something esle, and totally wondered why I didn't just stuff the line thickness and uv generator part in one patch. Here's a slight tweak. No difference in use really.
The problem with calculating normals on the fly is that you really need to have 3 vertices before you can make a valid normal... I've looked at it from many different ways, and doing normals for a non static structure, where you're making vector structures of normals from positions always gives me problems when the amount of vertices is in flux.
The way I get around that is to create vertices, get a depth image of those vertices, create a normal map based on that depth buffer image, and then light. Vade's Rutt Etra code probably sheds some light on how one could approach that, as well as some demos I've made that make normal maps from depth channel, and especially some of cwright's qtz's that have shown some really cool glsl shaders that render texture and normal map so that you can have lit scene (though he only implemented it to deal with one gl light as far as I remember/know). The image/glsl approach is more likely to result in less headaches... but I may be wrong. Getting those to draw at the same time can be hard sometimes, but maybe not as hard as the vector position->normal struct route when the structure isn't a fixed count.
Somewhere around here, it seems like I may have posted something that generates normals using a "feed vectors to something that makes normal structure" and then render". I'm not happy with it... besides what I'm mentioning about having to usually have 3+verts before the normals can be made, there's this issue of timing. If you have to have the verts to make the normals, but the patch has to evaluate to pull the verts, you're making the verts, but the patch needs the normals in that struct index as well... it seems like it's hard to get stuff to synch up correctly basically.
I've tried this from multiple perspectives - OpenCL, standard api QC, skanky QC. OpenGL exposes the ability to "feed" normals to a triangle or quad strip very easily, it's just all the things I mentioned above that make it kind of problematic (for me at least), and lean towards the depth->normal based approaches.
i noticed the get mesh component indices patch to be off. i compared a dae to gl header and get indices was a totally different count than the header. if you open the dae in text edit and checked the indices count and it is what it should be. strange how qc reports it totally wrong. is there a work around for this ? generate indices doesn't always work either ?
this is cool. you can sort of draw in your face when using video as texture.
Ah, just found this. Thanks!
Edit: first response: What?! That's all it takes!?
To calculate normals, any special considerations? Would it be the vector cross product for index i, i+1 and i+2 in the queue?
Yep, that's it, sorta; you might want to use some other kind of logic to generate the uv's in a different way.
I looked at it again a few minutes ago, messing with something esle, and totally wondered why I didn't just stuff the line thickness and uv generator part in one patch. Here's a slight tweak. No difference in use really.
The problem with calculating normals on the fly is that you really need to have 3 vertices before you can make a valid normal... I've looked at it from many different ways, and doing normals for a non static structure, where you're making vector structures of normals from positions always gives me problems when the amount of vertices is in flux.
The way I get around that is to create vertices, get a depth image of those vertices, create a normal map based on that depth buffer image, and then light. Vade's Rutt Etra code probably sheds some light on how one could approach that, as well as some demos I've made that make normal maps from depth channel, and especially some of cwright's qtz's that have shown some really cool glsl shaders that render texture and normal map so that you can have lit scene (though he only implemented it to deal with one gl light as far as I remember/know). The image/glsl approach is more likely to result in less headaches... but I may be wrong. Getting those to draw at the same time can be hard sometimes, but maybe not as hard as the vector position->normal struct route when the structure isn't a fixed count.
Somewhere around here, it seems like I may have posted something that generates normals using a "feed vectors to something that makes normal structure" and then render". I'm not happy with it... besides what I'm mentioning about having to usually have 3+verts before the normals can be made, there's this issue of timing. If you have to have the verts to make the normals, but the patch has to evaluate to pull the verts, you're making the verts, but the patch needs the normals in that struct index as well... it seems like it's hard to get stuff to synch up correctly basically.
I've tried this from multiple perspectives - OpenCL, standard api QC, skanky QC. OpenGL exposes the ability to "feed" normals to a triangle or quad strip very easily, it's just all the things I mentioned above that make it kind of problematic (for me at least), and lean towards the depth->normal based approaches.
i noticed the get mesh component indices patch to be off. i compared a dae to gl header and get indices was a totally different count than the header. if you open the dae in text edit and checked the indices count and it is what it should be. strange how qc reports it totally wrong. is there a work around for this ? generate indices doesn't always work either ?