what is the best way to put my primitives in the right order so transparency will work?
Back to front if you’re using blending in OpenGL. This gets tricky if you have a bunch of triangles in vertex arrays since there is no order guarantee when submitting a batch. It’s pretty effective to sort back to front on each object’s z-position (in camera space) and just disable rendering of back faces.
so you mean if i put 4 faces into a vertex array, and render it, then opengl won’t render in the order i sent them? and i realize i should render back to front, but how should i do that? average all the points in the face to get the center and compare those?
Averaging the points would do. I suggest using an index vertex array so you only have to reorder and update the indices. To optimise the sorting you can convert the distance from a float to an int using Float.toIntBits and then do a radix sort on the ints.
Incorrect.
Re-reading the spec, I you’re right. For some reason, I thought I heard drivers could render them in any order for efficiency, but it looks like they do it in the order that you provide indices in the index array (for glDrawElements). But that means to do correct transparent rendering, you have to resort the indices every frame if your camera changes since each triangles relative order could change.
You indeed have to manage sorting yourself, per frame. It’s always been like this, and will only be solved when we are rendering in additive blending mode or have raytracing renderers.
A generic sorting algorithm will perform rather poor in this case. What you need is an algorithm that excels at almost-sorted values with only a handful of elements requiring (a few) swaps. Bubble-sort seems like a good fit, if the camera moves slowly.
Radix sort can be handy in that case.
Cas 
Could you please enlighten me on how that beats bubble-sort in almost-sorted arrays?
AFAIK radix sort relocates every element ‘k’ times (k=number of digits) as the initial operation is to sort in the least significant digit, which almost guarantees every element being put at another postion.
The one I’m using doesn’t seem to have to move anything if nothing’s changed position (you pass in the previous sort order to start with). I may be wrong.
Cas
[quote=“Riven,post:7,topic:35887”]
That is a big if. And even small changes in the view position can result in dramatic changes in the sort order depending on the object being sorted. Also if you only sort objects within the view frustum you will get nn complexity when objects enter the view. Besides, the view is not always the only thing moving in a game. Transparent objects my be moving and rotating themselves. I would go for a stable sorting algorithm like radix sort. Then you don’t have to worry about the game pausing because bubble sort degenerating to nn.
i intend on first culling off anything that’s not in the frustum then sorting it based on distance from the camera, because i figure it’s not just the z-depth from the camera’s point of view, but if i’m looking at something transparent from the side, i’ve got to sort it too.
actually wouldn’t quicksort be faster than radix sort for this kind of thing?
If you can do radix sort and you have enough data that performance matters, then it ought to always be faster than quicksort. Just set it up to use a number of buckets passes less than log_2 of the number of values you are sorting.
If you use a quicksort for this almost in-order data then you’d better roll your own, because a lot of the simple ways of picking pivots will tend to O(n^2).
Ok 1 last question. would it be better to store primitives as a vector of say, a class for faces, a class for lines, and a class for points, or just a float vector and just keep track in the indices?
Keeping an object per point/line/face will cost you dearly with object overhead and cache coherency.
ok i lied maybe i do have one more question. should i radix sort according to the least significant or most significant digit?