I would second the Netgear option. They are cost effective and seem to just work. One thing to bear in mind is that at 10gb wire speed, cabling starts to really matter. Cat5e works, but only for very short runs. (<5m) Even Cat6 is really only good to 60m. (Anything more needs to be fibre). I have seen quite a few shows where 10gb switches where declared 'broken' thanks to a bad (or old) patch cable.
Yes, that is definitely on the list. We are currently re-working the audio system to better support multi-channel playback (4.2.1 has the first version) and the next stage of this work is for more clever audio routing and monitoring.
We are hearing a lot about NDI lately, and the immediate question I always have is: given that it will never be better than live capture, is it still worth it? NDI will consume CPU and hardware resources and use compression to fit over a gigabit network cable. SDI based capture for example does not use CPU (Thanks to direct memory transfer to the GPU) so has a lower hardware overhead and much lower compression. (Not to mention latency).
So my question is; what do you want to do with it? What NDI sources would you like to use?
Everything in SHAPE is made of triangles, so even the square you have drawn is actually two triangles connected. The diagonal line you see is the border of those two triangles meeting. If you show only the texture (and not the mesh) it will go away.
I think i understand where you are coming from, though it is not quite as simple as it sounds.
First of all, for the most smooth output you want the engine to be running as close to 60FPS as possible. With inter-frame blending, even with 30FPS content we are rendering a unique frame with each render pass; half of them would be interpolated from the adjacent frames. (You can turn this off, its a pin in the media player if you want to see the difference). So i would always suggest striving for the highest framerate possible. If the framerate of the engine drops below the media frame rate then the player will start to drop frames which can quickly become noticeable.
In terms of knowing the 'potential frame-rate' that is very difficult. The frame rate is limited by any number of performance bottlenecks such as: Video Memory availability, System Memory bandwidth, Drive Access bandwidth, Drive latency, or GPU Texture bandwidth to list a few. Many of these can not be known until you measure them. The latency of the media drive has a huge effect on playback for example, and is itself dependant on many factors ranging from Windows pre-fetching to the drive's age and utilisation and can even be file dependant. This means that we dont really know what the system can do without actually trying it.
That being said, we do want to extend the performance meter to include other measures such as CPU utilisation and system temp. These will at least give you an indication of how much overhead is left in key areas of the system.
Changing the memory will not bring you any benefit in terms of performance. We work to balance the specification of the systems so that there is not a single bottleneck.
Over time we have to change what is in each system as the computer industry is constantly in flux, however an Amba built today will be very similar in capability to the very first ones.
So the short answer is we do not advise changing hardware in the systems. The software license that allows Hippotizer to run is also locked to the specific hardware; significant changes to that hardware could damage the license. If that were to happen, our support team would require the system to be restored to the original factory condition before re-issuing the license. This is to ensure the system meets specification (otherwise we would be unable to support it).