Burnt_Fyr

2) Why strips over lists? While strips make sense as a performance standpoint,

No. They don't. They are actually horribly inefficient in terrain rendering.

 

Think about it. With strips, you are always reusing last two vertices for current triangle.

 

With a triangle list of the terrain heightmap, it is possible (I know, because I implemented it) to create a shape that for a 100x100 grid (20,000 tris) executes Vertex Shader only 056*20,000 times - simply because it reuses the vertices that are in post-transform vertex cache and keeps the cache warm with last 24 vertices all the time. The variant with 0.67*20,000 is easier to code, though.

 

With TriStrip, the best you can get is  1.01 *20,0000

As the OP said, I'm just reiterating what I have been told in the past. Paraphrasing here: "Strips are faster than lists, but in today's hardware, the difference is negligible."

 

Not to derail the OP's thread, but I was assuming the use of indexed geometry, and after reading your other reply, I thought that may have been the sticking point. As you said, using indexed geometry enables the post transform cache, reusing 2 vertices results in only a single xecution of the vertex shader for each triangle after the first, per row of quads. However upon doing the math, I see 202 shader executions per row of quads by 100 rows = 20200, or as you put it, 1.01 * 20000. 

 

After unfurrowing my brow, I end up with the same count for lists. Could you explain a bit more in depth how lists are faster than strips, specifically how you arrived at the other 2 figures you gave for the naive and optimized list method?

I always start with a deck of index cards, as i find it's much quicker to try new ideas, and i'm less prone to wasting time making it pretty as i would with a dedicated uml program(starUML is my personal favorite btw). I got the idea about using CRC cards, from an article I cannot recall, but this covers it pretty well.

 

I start usually with classes i know will exist(usually model classes), and and a scratch pad of paper. I use the paper to prototype the interactions of classes, which i can then turn into real code down the line. As the design evolves, I start to get an idea of new classes that may be neccessary to facilite these interactions. I can write specific properties of classes on the back side when i know they will be needed. With a basic rough plan, I'll check and see if there are opportunities to use composition or inheritence to save work when it comes to coding. I model these relationships on a cork board with safety pins and string. If i like how it comes together I'll take a picture, and can use that as a reference for later. Once I've got a paper prototype down, I'll move it all into starUML, and export as a c++ project, which basically does all the boilerplate for you, and then I can go back to my scratch pad scrawlings to start writing implementations.

To what you mentioned, even if you needed to recalculate every child object transform for a change in the parent, isn't that still less work than calculating ALL objects EVERY frame? at worst case you are only adding an extra boolean check(if(this->moved) { do child stuffs }) per object. At best you are saving N-1 transform calculations per frame.

Matrix multiplication is not commutative, so yes it is a big difference.

To add to, and clear up some of what columbo said, a 4x4 matrix can represent a set of orthonormal basis and a position relative to some other coordinate system. Depending on matrix layout, as in Row/Column majorness, Row/Column vectors, as well as handedness or the coordinate frame this can be setup in a few different ways. In Row Major, left handed system( that which directx uses by default) these are laid out like this:

[ x.x, x.y, x.z, 0] // X axis vector
[ y.x, y.y, y.z, 0] // Y axis
[ z.x, z.y, z.z, 0] // Z axis
[ P.x, P.y, P.z, 1] // Point in parent frame to translate local origin to.

I tend to call these the Right, Up, and Forward vectors. The x axis points to the right of your object, the Y axis points up out of your object, and the Z axis points in front of the object. So as Columbo said, your desired vector can be pulled from one of the rows of the matrix. Whether or not it is the one you define as up is up to you(pun intended) In reality, Up down left right front back, are all terms we use to describe things relative to our coordinate frame.

 

If this is puzzling to you, realize that the difference between row or column vectors has to deal with how we manipulate the vectors(it affects matrix multiplication)the majorness of a matrix has to deal with how it is indexed in memory(does the first index point to a row, or a column) and that the handedness really has no effect on the math until it comes to projecting onto a 2d frame.

 

 

http://fgiesen.wordpress.com/2012/02/12/row-major-vs-column-major-row-vectors-vs-column-vectors/

 

This article should help clear out some confusion that I may have induced.

I'm regurgitating what i've read here(less then a week ago actually).

 

In dx9 flexible vertex formats, or their shader equivelents, had to be checked against the shaders each time a shader was bound, and this is why changing shaders was such a huge performance factor. In DX11, the input layouts are checked against a shader at creation time, so switching shaders has much less overhead in the newer api. As long as the semantics in a layout match the semantics in the shaders to be used, then a single layout can be used for multiple shaders afaik.

I think you should first seperate the idea of geometry, buffers, and the game objects themselves.

 

Geometry is just that. A collection of verts and faces that make up some object. It is not the object itself, nor is it a buffer. It is just points and lines.

 

Buffers are render objects, they are behind the interface of your rendering system. You can have a buffer created from geometry, but again, it is not geometry in and of itself.

 

Your Game object is the higher level object in game or engine code.

 

Your game wants some entities, so it creates game objects, and adds them to the world. The objects have visual representations, so the geometry is loaded from a file. Since this process was started in the game code, it knows what formats are needed, and buffer objects can be created via the rendering system. (So the system has no idea about the game objects, yet can be told how to structure the buffer data). When you render the scene, the game objects Render method can pass game info such as what buffers are needed, what shaders and constants(transforms, lighting info, etc) to the rendering system. After the game objects have pushed their data, the renderer can make the draw calls, knowing how many of each object, where they are, which of them need shadows, etc using a batching system to reduce hangups.

 

Bear in mind that I have little to no idea of what i'm talking about on any professional level, only that i've been hobby developing for a few years.

 

TL,DR: Your render api should expose methods to create buffers, and draw them, and little more. Internally it can use information deduced from the draw calls to optimize for performance. In a sense, your meshes are tightly coupled to your render API, but they are also encapsulated, and this little detail helps reduce coupling from outside of the renderer, where games have little business doing stuff.

A simpler method IMO would be to draw all overlays last, disabling depth testing before hand.

in addition to what was said,ie: using some form of broad phase culling of objects that can't possibly collide, your loops are naive in that they check each item with each other item... twice. Better would be to change the second loop to:

for(int i=0; i< objects.size() ; i++)
{
   for(int j=0; j<i; j++)
   {
	   // check collisions
   }
}

Your implementation results in n^2 tests, the above in a little over 1/2 that.

for an example in code, look for Eberle's paper on clipping a mesh against a plane. It has a function Get ordered vertices that does exactly what you want, and describes the process, which is essentially the same as Khos described. Pixalot's method will work as well, but might be confusing in the realm of 3d, where left and right are not absolutes.

I think most people would recommend CEGUI, though I have no experience with it, so I can't say if it is the tool you are looking for.

As Xanather mentioned, box 9 or 9 quad or what ever it is called is a very nice method for ui window construction, allowing windows to stretch without distortion. I'm sure something similar could be done for basic circles, but i have a feeling you want something more organic than that.

Resizing from a control is as easy as calling window.resize(), howeve, implementing resize() that will work in multi resolutions, will require a layer of abstraction, using a virtual coordinate system(or just make the entire thing in NDC space).

There was a really good article on here a while back, about making a custum ui... I'm sure you can still find it here somewhere. Basically all windows and controls are decendents of a base class, and each is a node in a linked list of windows/controls that are drawn from bottom up. When you resize your window, it can pass the resize info down to it's children, as well as to it's siblings, so that they maybe adjusted in turn.

#1 no... easy as pie, use 2 arrays, on keydown, mark key as down, on key up, mark key up... next frame, copy 1st array to the second, and repeat... A key that was down last frame and this frame is held, else it's a new button press.

#2 no...

#3 Input should be just like any other task such as physics, or rendering, ie: it will be processed during a slice of the timestep,  so collect your key ups key downs when they occur, process them all at once.

As Alvaro mentioned, each os will have it's own method of providing keyboard input. In windows, this would be the windows message pump, and the keyup/keydown messages. This is where a prebuilt library will help, but it is not necessary.

In my experience, which compared to many here is negligible, UML is a nice tool. I use basic class diagrams to get an idea of how classes can be generallized(hmm... all 3 of these have a transform function, perhaps a superclass should be created) and broken into separate codebases/libs. I also am a big fan of sequence diagrams, so I can see who will call what to get the job done.

On the other hand, as Simon mentioned, UML is it's own language, so essentially you are writing code twice, each time you change your code, you must update your UML model to reflect the changes, or vice versa. I find it the same way with documentation. So you may end up writing your program 3 times in 3 languages. Enter tools like doxygen, to extract usable documentation, or staruml(my personal fav uml modeller) to extract uml class diagrams from a code base.

My work flow now is: a

quickie design model, using starUML, pen and paper is fine, but with starUML I can then export as c++( interfaces only, unfortunately it doesn't write implementations ).
test/debug/rinse/repeat until I'm happy it works as expected.
import the 'finished' project into starUML as an implementation model.
create docs with doxygen.

Rather than building your quat from scratch each time, you need to update your models orientation from it's previous orientation. I'm not great with quats but here is what i do with matrices, the ideas should perkolate through regardless.

Edit: didn't see answer previously, do as derkai says

to match a real sailing vessel, you can calculate center of effort from sails(centroid will work) and apply the force there. this will cause the vessel to heel, as well as turn. as the hull heels(rolls) and pitches the center of boyancy changes and provides force and torque as well.