So i came up with an idea that should help optimization and everything;
back to the queue system; i think it can be implemented so that expert
users can get crazy renders and so that novices aren’t confused by the
fancy buttons and blinking lights.
*** The Idea ***
What is a Queue:
A Queue is a list of pointers to primitives and their type. The queue
is ordered based on type (this makes for pushing and popping the GLName
very easy and optimized).
Each engine has a Queue. There is an additional Queue that is the
defaultQueue. The reasoning? Well say i don’t have a default and i
have five atoms; say the default rendering is BS. I take atom 1 and
make it Stick rendering. Now, if i change my default to Stick, then all
will be added to the Stick queue. Then, if i change back default to BS,
then atom 1 goes along with it because by nature it would be transfered
to the BS queue with the rest? Just saying we need to be distinct in
which are associated with which queue for what reason (default or user
set). The queues also don’t queue in a tradional sense, they are more
of a “set” because once rendered, the items stay in the set, don’t move
out. Plus the ordering is not first in first out.
How does this help? Well, first of all it makes everything much simpler
for the renderers, they need only one function that inputs a queue, then
just iterate through a list. If anything we could have the queues be
multilayered by type so that we could have loops for each type etc etc.
This can be worked on. It also means per render we are only calling a
function per renderer rather than a function per primitive. If a queue
is empty it won’t even call the function.
Why is this good? Well, I think one of the coolest things about this
would be the fact that we could setup multiple engines for each item.
Say i want to render a BS for an atom AND i want to render something
using the same primitive. In fact i could add primatives to multiple
queues.
Also, when i say primitive i mean molecule too. So at startup the
default queue has the Molecule, Atoms, Bonds and Residues in it. Then
we can start moving things around and figure out hte GUI to do this.
But i think it solves all your concerns and mine too.
Please remember, that if a rendering engine needs to know information
about the molecule to render the primitive, it can always call
OBAtom::parent and get that information. It’s a matter of thinking
bottom up or top down. I think bottom up
Let me know what you think. I might try to work on it a bit this
weekend if you’re intersted in it.
I also have the idea that we’ll have a sidebar treeview that you list
the primitives of the molecule. This would be how to select the
individual rendering options (or at least the easiest way).
-Donald