jujumbura

Hello all,

 

I have been making some functions that create "rounded" vertex meshes for me by sweeping over two angles ( vertical and horizontal ) and then using trigonometry to determine x, y and z position values.  The normal for a sphere made this way is simple, but I have started generating more complicated shapes where the normal can't be easily stripped from the position.

 

So, I am trying to determine the best way to find this normal value.  I know that the normal is given by the reciprocal of the tangent of an equation, and I can find the tangent by taking the derrivative.  But I can I use my original equations for x, y and z in terms of the two angles, or do I need to use different equations?

 

Thank you for any advice!

Hello all,

I have been thinking for a while about the relationship between World, Bone and Normal matrices as they pertain to vertex processing.  Assuming I have a mesh with position and normal data that needs to be transformed, it seems like I must do one of three things:

1) Send each matrix individually to the vertex shader, and have it transform the position and normal values multiple times.  So the vertex shader would entail a multiplication of the position by the bone and then the world matrices, and a multiplication of the normal by the bone-normal and then the world-normal matrices.

2) Pre-multiply the matrices on the CPU so that the position and normal values only require a single transform.  Then the vertex shader would only require a multiplication of the position by a combined matrix, and a multiplication of the normal by a combined matrix.

3) Some partial combination of 1) and 2).


So I'm wondering, is there some "tried and true" way of doing this or does it really just depend on my situation?  If I am CPU bound and I am trying to draw lots of individually positioned meshes, then option 1) makes more sense.  If I am GPU bound and I am trying to draw a few very complex meshes, then option 2) makes more sense.  But I can't help wondering if there is some clever technique that tends to get the best of both worlds; this is surely something that has been tackled by many a graphics programmer.

Any advice?  Thank you for reading!

Hello all,

I have recently been wondering about the rendering pipeline, and I am hoping somebody could help clarify some things to me.

My understanding is that in general, vertices are procssed by the vetex shader, then are rasterized into fragments, which are then processed by the fragment shader, and finally all fragments are converted into pixels in the frame buffer. I know I am skipping some steps here ( geometry shaders, clipping, etc. ), but if I have gotten anything completely wrong there, please let me know.

My question though, is at what point does the GPU stop working on one stage and then move on to the next? For example, does the GPU immediately begin rasterizing a triangle the moment it has three vertices fully processed, or does it finish processing the entire mesh and THEN begin rasterizing? Similarly, does the GPU start running the fragment shader on each fragment as soon as it is generated by rasterization, or does it create a batch of fragments and then shade the whole set?

Thanks much for any advice!

Hello all; this is more of a "musing" than a question, but I was hoping somebody else might give me some feedback on my thoughts.

Throughout my experience in game development, there is a particular philosophy that continues to prove true to me, which is the following: the best systems are always hierarchichical.  That is to say, flow of execution starts at the top and moves downward, not upward, and not horizontally.  As a simple example, take a UI Panel which manages a set of Buttons as children.  The Buttons control their internal state based on input, but the Panel handles focus issues, and ultimately runs the updates.  Systems like these are easy to understand, easy to extend, and often reuseable.  Plus, since the code and data is encapsulated, these models make high-level control and multi-threading much easier.

But unfortuately, outside of elements like a UI ( which is naturally a hierarchical abstraction ), real-life game programming rarely fits into this box.  The problem is all those darn interactions!  On my projects, there is usually a simulation composed of objects which are "semi-autonomous", but also influenced by all sorts of other systems such as player input, physical collisions, scripted sequences, and specialized game rules.  The result is that everybody is mucking with everybody else's state, constantly.  To facilitate this, I typically turn to singletons.  As an example, the "TouchManager" will find objects from the "ObjectManager" based on screen location, then will manipulate the objects ( drag & drop ), which may have the side-effect of impacting other objects on release.  The result of all this is that I'll call an Update() somewhere, which ends calling functions across multiple systems without  any upper-level coordination.  Usually this is all works fine, as long as everybody is careful, but occasionally this will produce some nasty problems, like removing from an object from an update-list during update, or breaking reentrancy restrictions.  It feels like spaghetti code, and I keep thinking there's got to be a better way.

The only other "way" though that I can think of is deferred execution.  In some cases this works pretty well; I will frequently use a CollisionManager that will detect collisions between objects, but won't actually make any immediate changes.  Instead, it produces records which are later processed by the objects themselves to make changes to state.  This is great, but it is effective primarily because it only entails one extra pass, in which all handling can be performed.

But there are more complex "rules-based" interactions which would be very tedious to defer.  For example, object A casts a "spell" on object B, which causes objects C1, C2, and C3 to be created.  And on that same frame, the whole lot of them need to simultaneously enter a coreographed animation ( this is a real example! ).  In order to accomplish this without object A directly calling functions on B and C1-3, there would need to be 3 rounds of message-passing to be handled, with a ton of parameters being passed around.  Theoretically possible, but painful.  Yet, perhaps I just haven't found the right framework for this sort of system?  I'd be open to working this way, if it can be proven to be flexible and involve minimal overhead.

Has anybody else found themselves in the same gameplay programmer rut, and emerged with a better plan?  A way to get features accomplished without singletons everywhere?  I'd love to hear your feedback if so.  Thanks much for reading!