Equalizer - Parallel Rendering

Hey Harris, In the RSP connection, the hostname is used to set the Multicast group, while the interface specifies the IP address of the adapter used for sending and receiving multicast packets. Your connection is supposed to look like this: connection { hostname "224.0.0.1" #or any other address in the multicast address range

Hi Stefan, I think you got me on the right track there: After setting the value to 10, I'm getting an assertion on the root node object, which I'm keeping in the FrameData. It looks like all the previous versions are still kept alive until the assertion is thrown. I'm pretty sure this happens when deserializing a graph node object,

Hey Stefan, we are moving forward with our project and right now I am composing the final eqc files. I have everything working with traditional TCPIP connections, but I would like to try out RSP since TCPIP seems pretty slow (especially when doing soft frame barriers). I am trying to make an EQ config file based off the Hactar example that

So I assume that means the render clients are leaking. Most likely this is due to missing sync() on some objects. Try setting the 100 to 10 in Object::notifyNewHeadVersion and see who is throwing an assertion. HTH, Stefan. -- View this message in context: [link]

Hi, MinGW is not supported at this time. Feel free to provide a fix, or use the VS2008 generator. To build, you should clone Buildyard, configure it and then execute the ALL_BUILD target in VS. HTH, Stefan. ______________________________ _________________ eq-dev mailing list [email protected]

Hi all, Could anyone please provide me with a step by step short tutorial on how exactly to build eqHello (hopefully scalable to the other examples) on Windows 7? So far I'm running into a lot of strange errors just trying to generate make files with cmake: Attempt to use MinGW as the build toolchain (MinGW make files, MinGW GCC and

Hello Stefan, thanks for your quick reply! 2012/5/4 Stefan Eilemann <[email protected]>: That makes sense, so I moved the sync() call from the Renderer to Node::frameStart(). There was also a leak inside the application, which I tracked down by now. This application leak was the cause for the continuous memory leaking

Hi, one more thing: having a simple reproducer in eqPly or standalone will help you to isolate the problem and me to give you advice or fix the bug. Cheers, Stefan. ______________________________ _________________ eq-dev mailing list [email protected] [link]

Hi Matteo, Nice. :) So far it looks like one typical way to implement scene graph distribution. I'm assuming you've got one copy of the SG per node. In that case, you should do the sync() in Node::frameStart(). Is the application, the render ... [More] clients or both leaking? You've got to figure out who is leaking the memory. The delta objects buffer quite some stuff (see [1]), so that might be one cause. However, they should not keep leaking memory over time. [Less]

Unsurprisingly, this time we’ll look into the MTQueue. The multi-threaded queue is the blocking, fully threadsafe big brother of the LFQueue discussed last week. The MTQueue is fully thread-safe, that is, any public method can be called from any thread at any given time. Any request which will wait until it can be satisfied. Naturally, [...]