Rendering Design

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 :slight_smile:

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

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.

Well, my original design idea was that there was a set/list/queue of
renderer/primitive pairs. So the user pushed on those 5 atoms (or the
entire molecule) paired with the stick render engine.

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.

Right. And with my recent change to the render engines, they can just
not implement a certain type of render call or return false early and
nothing happens. (Ideally, in your system, if the render engine
returns false for something in its queue, that primitive is removed.)

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.

Yes, exactly. :slight_smile:

Let me know what you think. I might try to work on it a bit this
weekend if you’re intersted in it.

I think it’s great, and not because it’s similar to my original
design. We’ve tried a different approach and it doesn’t work quite as
cleanly.

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).

I think Kalzium has something like this already. It’d be nice to have
a hierarchy for the molecule and other “folders” for things like
measurements, constraints, … whatever, I guess. :slight_smile:

Cheers,
-Geoff

Am Samstag 02 September 2006 00:39 schrieb Geoffrey Hutchison:

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).

I think Kalzium has something like this already. It’d be nice to have
a hierarchy for the molecule and other “folders” for things like
measurements, constraints, … whatever, I guess. :slight_smile:

Yes, in Kalzium there is a treewidget which displays the atoms. I grouped them
after their type (Carbon, oxygen, nitrogen…). I displayed their ID (that is
what openbabel returns from OBAtom::GetID() or something like that) as well.
I played around with different ideas, for example to also display the atomic
weight (might be interesting for isotopes, eg a Carbon is no C12 but C13).
In the end I didn’t really like it :wink:

To do the right thing™ we need a model/view-design here (Trolltech calls it
Interview). But to be honest I am not really sure what to display… But for
whatever we decide, with different views we can display things differently.

The two classes are

http://doc.trolltech.com/4.2/qabstractitemmodel.html
http://doc.trolltech.com/4.2/qtreeview.html


Gruß,
Carsten Niehaus

Well, my original design idea was that there was a set/list/queue of
renderer/primitive pairs. So the user pushed on those 5 atoms (or the
entire molecule) paired with the stick render engine.

This sorta suffers the same issue we’re having now because each time we
render we’d have to go through and filter out hte pairs just for that
renderer etc etc. But yeah, i see what you mean.

Right. And with my recent change to the render engines, they can just
not implement a certain type of render call or return false early and
nothing happens. (Ideally, in your system, if the render engine
returns false for something in its queue, that primitive is removed.)

Oh, see, the renderer takes the queue and uses it. Ideally it should be
a const set. But the Widget only knows whether it gets a true or false for
the whole queue. If we have the widget itterate through the lists then
we suffer the same problem we had last time (context switches for
function calls for each item). Well i’ll implement it and you can
critique it tomm. I’ll be at the football game.

I think it’s great, and not because it’s similar to my original
design. We’ve tried a different approach and it doesn’t work quite as
cleanly.

Yup

I think Kalzium has something like this already. It’d be nice to have
a hierarchy for the molecule and other “folders” for things like
measurements, constraints, … whatever, I guess. :slight_smile:

Oh man, that’s so brilliant i should’ve thought of it. Rendering little
arrows for the constraints and stuff… Good Good.

-Donald