[Bf-committers] viewport bug #27979
Ingo Randolf
ingo at quitch.net
Thu Aug 18 13:47:00 CEST 2011
Hi
Thanks for you answer. and your suggestions. you are definitely right about position calc (distance)...
- Sort:
the sorting is an insert-sorting in my understanding...
well it starts from an empty list everytime though...
what it does:
it creates a sorted chain of structures pointing to each other... obviously...
- look for each object for the correct place in the sort-chain (distance < current sort-element-distance ), and stop the for loop, if the place was found...
foreach (objects) {
aentry = current object-link (distance etc...)
for each element in sorting-chain {
if distance is smaller than distance in current sorting-element {
squeeze current object (aentry) into the list, or set it to beginning of list
remember current sorting element for next for-cycle (to be able to squeeze aentry in)
break; got out of the for-loop!! - we found the place
} else {
remember current sorting element for next for-cycle (to be able to squeeze aentry in)
}
}
if aentry could not find a place in the chain, it is the last element in that chain. let point the last sorting-element to this element
}
maybe this can be optimized - how? reusing sorting chain?
probably, the objects are sorted the same way each redraw... but how do we know that the order was changed without looking at every single object?
i could jump from one to another camera on the opposite side of objects -> order reversed...
- Draw:
yes, i am aware that i broke the selected-object-overdraw (also the objects-in-editmode-overdraw)...
but
if the drawtype is > OB_WIRE, then objects are depth-tested anyway... so i can draw them sorted...
if viewport is set to render wire or boundingbox, then depth_test is not turned on... still i could draw them sorted... a selected wireframe shows through an overlaying wireframe... same with boundingboxes...
so, i dont know if drawing selected objects afterwards makes sense...
ingo
> - Sort
> I have trouble understanding your sort but it seems really inefficient (O(n*n))
> Since the objects will most probably be sorted the same way on each
> redraw, you could keep the sorted list (or directly sort the original
> list if nothing depends on its order) and use insertion sort (very
> simple to implement) which would run O(n+d). n being the number of
> elements and d the number of swaps (e.g 0 if it is already sorted!).
>
> - Draw
> selected/edit mode objects are drawn last so that they overlay
> unselected objects and you probably broke that ;)
More information about the Bf-committers
mailing list