Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 19 Oct 2005
Offline Last Active Today, 06:44 PM

Topics I've Started

cost of rendering 'modular' entity models

19 October 2014 - 05:35 PM

 Hi everyone.


 I'm working on a problem where players can 'design' their player avatars by effectively choosing different limb models to be animated via skeletal animation type system. These limb models are not meant to be seamless. I'm curious as to whether or not there is any way I can draw these modular player models more efficiently without having to perform a draw call for each of these model pieces as well as submit a modelview matrix for each one. Each player model is comprised of 10 of these model pieces, which are extremely cheap as far as shaders and geometry is concerned.


 Any ideas? Suggestions? One idea is to generate a VBO for each possible combination of pieces, but this just seems very extreme if I were to have 5 possible model types for each player model segment (5^10th = 9.7 million combinations).


EDIT: I am targeting OpenGL 3.3, just FYI

generating branching structures without recursion

28 September 2014 - 07:13 PM

 I thought I had this figured out, but now I'm starting to believe that I was mistaken. I'm working on generating simple branching structures (trees, basically) using a simple command scripting language that supports looping, but not recursion. There is also a stack that I can use the push/pop commands to save the current branch state and load it back to continue working from.


 I'm very limited with what I can do with this scripting system, and for some reason I thought I had this figured out, but apparently I don't. Either I can't remember what I thought of, or what I thought of was totally wrong. My original 'aha' solution involved using two nested loops, and I keep thinking I had some clever use of the push/pop orientation stack that let the loops properly generate branches on branches to a defined depth, but I just can't remember or see what I was going to do.


 Is it even possible? Am I just going mad?

detecting 3D array configurations

04 June 2014 - 11:43 AM

 Hi all.


 I've been wracking my brain trying to find a simple solution to this problem, but everything I come up with seems overly complicated.


 I have a 2x2x2 array where each cell can be on or off. This yields 256 possible states for the array. The problem I'm having is finding a way to detect a specific set of configurations - including their multiple possible orientations AND mirrored versions - without having to resort to creating a look up table. There are no requirements that disallow a simple look up table to determine which configuration the cells are in, except that I'd rather have a solution that could be expanded to larger arrays.


 The closest to a solution I've devised thus far involves counting how many adjacent cells (eg: 0, 0, 0 - 1, 0, 0), diagonal cells (0, 0, 0 - 1, 1, 0) and opposing cells (0, 0, 0 - 1, 1, 1) there are, and comparing those numbers to the numbers involved in each configuration. This overcomes checking for various orientations and mirrored versions of specific cell configurations, but requires that cells are all manually inspected and compared against other cells, which seems unavoidable, but I keep getting this nagging feeling that I could somehow represent the array in a way that allows for an XOR or two against template configurations to count these relationships more quickly.


 This is a very abstract problem without a clear and concise method of solving it. I've tried looking at it from many different angles and have exhausted myself for the time being. I'm merely seeking any insight anybody may have about an effective and efficient solution beyond what I have come up with on my own so far.



Perfectionism and Programmer's Block

12 May 2014 - 04:44 PM

 Hi there. I wanted to query the collective knowledge and experience of those who haunt these forums in an effort to find relief from something I can only describe as programmer's block.


 I know what I want to make, but the knowledge about programming I've gained the past few years have only made it harder to get anything done without trying to do it 'right'. For some reason, doing it 'right' is taking precedent over getting it done. It becomes more of a chore, and less of a fun hobby.


 Just getting into OpenGL 3+ has become a daunting task, trying to implement a highly versatile rendering system capable of everything I can't forsee.


 That's just the issue though, the sense that I always code myself into a corner with projects, which has instilled a deep need to do everything as generalized, modular, and data-driven as possible. I feel I have taken certain programming tenets to extremes, yielding to nothing.


 I have heard things such as YAGNI (you aren't gonna need it) and KISS (keep it simple stupid) and I'm still struggling. How do I surrender!? What should I focus on. I just want to switch off this awareness I have gained, or at least tone it down, to where I can actually knock stuff out and enjoy doing it.


 Has anybody else struggled with knowing too much to be productive? I'm paralyzed!



Texture Atlas Indexing with Texture

30 September 2013 - 03:05 PM

I'm looking for any tips, pointers, resources, etc. concerning the use of a sort of atlas indexing texture, representing a scene for example, where each texel indicates a particular texture in an atlas texture... and doing this in OpenGL, using GLSL. I'm very familiar with GL itself, and have done a few neat things in GLSL, but consider my experience rather limited.


There are two ways that I see going about this. The index texture could either simply index the atlas one-dimensionally, with only one color component (unsigned byte), minimizing the index texture's size, which is ideal if it needs refreshing for animation or any sort of dynamic features. Translating the texel index byte into UV coordinates would be a simple affair carried out on the GPU. I'm unclear as to the method by which I could even access a texture (via sampler2/3D) as an unsigned integer value, as opposed to a floating point value from 0.0 to 1.0.. Sure I could multiply by 255, but is this necessary?


The other option would be to store the actual UV coordinates to the origin of an indexed texture contained in the atlas, which is (in my mind) a more CPU based approach. More bandwidth would be used transferring the atlas-indexing texture to the GPU for dynamic scene purposes, having more data, etc..


I'm just trying to figure a balance between simplicity and efficiency, and my lacking know-how with GLSL is limiting me to mere trial-and-error, but I figured I may as well try to look for any advice from more experienced GPU programmers on this.


Just a side note, the index texture itself would not be very large, smaller than a single 'tile' in the atlas. I was also wondering about utilizing a buffer texture object (http://www.opengl.org/wiki/Buffer_Texture), which seems to be better suited for what I'd like to accomplish here. The primary goal is minimizing the actual geometry being drawn to, ideally, a simple primitive with the index texture mapped to that the GPU utilizes to plot the various texture tiles from the atlas onto the primitive. So, each index texture texel would be a texture tile from the atlas.


Any advice, pointers, tips, links, etc.. are much appreciated. It may seem like I have it all figured out, but I really just have the jist of it down and would like some more detailed technical information about doing this sort of thing. Thanks.