On 23. Jan, 2007, at 0:32 , Scott Senften wrote:
So I'm trying to wrap my head around the example eqPly and I'm
beginning to think that I'm trying to equate it too hard to SGI's MPK.
The most simplified comparison is that a MPK C Callback is a virtual C++
method in Equalizer, e.g., instead of doing mpkChannelSetDrawCB() you
override eq::Channel::draw(). More below.
What I'm really trying to understand is the control flow between
the application and the server, just basic stuff like...
Once the server is running with a configuration, all other
equalizer apps that start will connect to that server, correct?
Correct. The client library tries to connect by default to a server
on the localhost.
eq::NodeFactory, I'm assuming, is the way to get the server to
connect to your specific application by overloading the various
compoents of eq::Config, eq::Node, eq::Pipe, and eq::Channel. Is
that correct?
Correct.
It also appears, similar to MPK, that eq::Channel is where the
majority of the work is done for rendering.
Also correct. Window::create might be of interest as well.
Say I start the server with server/eqServer.64 examples/configs/2-
window.DB.eqc where in channel::draw() is the decision made on
which half of the model to draw. Is the model itself made up of
multiple nodes, each having it's own bounding box?
The model (PlyModel) is a octtree structure for frustum culling,
holding all the data. Each bounding box has a range between 0..1,
which is used for 'DB-culling'. Right now eqPly loads the whole data
set on each node, but only draws the frustum-visible range. A real
application would want to instantiate only the data 'range' needed
for rendering. Like in MPK, Equalizer provides the context on what
to draw in Channel::draw, i.e., the frustum and range.
Is this the list of candidates? If so, where is that list
populated and how?
The data is loaded from a ply file in plyFileIO.cpp, which
calls PlyModel::setFaces which generates the octtree. The code
shows its age, I copied most of it from the flip.ply MPK example.
Where does the compositing take place? I assume that's in the
server. If I want to change a compositing mode or add my own, do I
extend the server?
Physically it happens on the client. The server computes the rendering
tasks (compositing is one of them) and sends them to the appropriate
nodes. The task computation for compositing happens in server/
compound.cpp,
the compositing itself in eq::Channel::assemble().
Obviously, I haven't torn through the server and client library
code. I went looking through the documentation but couldn't find
what I was looking for. If I missed something in the
documentation, just point me that way with RFTM.
I am afraid this is not documented. I did not expect anybody to go
to that level yet. The method overriding approach is outlined in
<http://www.equalizergraphics.com/api.html>, but you figured this
one out by yourself already.
Any other insights for someone just trying to understand the
architecture and development environment would be most welcome.
All existing documentation is either on the website or in the code. The
internal architecture is not documented, but feel free to pick my
brains.
The same was true for MPK, just that developers typically couldn't even
look at the internal code. ;)
The most notable differences in the architecture are:
- The configuration is serverized
- The server computes rendering tasks, and sends them to the nodes
- Asynchronous execution, i.e., the rendering threads are not explicitly
sync'ed each frame
- Addition of nodes in the resource hierarchy
- Pipe threads instead of window threads
- Compounds have no explicit mode - see <http://
www.equalizergraphics.com/documents/design/compounds.html>
The development environment is just a bunch of Makefiles - see src/
README
for an introduction.
HTH,
Stefan.
_______________________________________________
eq-dev mailing list
[email protected]
https://in-zueri.ch/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
