So, OGD1 is flexible due to the FPGA. I would definitely use it.
But, I interface with one of several 'dumb' terminals, connecting to a 'CPU server' which does the 'real' computing. The 'video card' idea ties silicon to a screen. Each of my 'dumb' terminals has it's own screen. A lot of 'dumb' terminals each with OGD1 would be neither 'dumb' nor inexpensive. Could OGD1 compute in a 'CPU server' without a screen, sending video through ethernet to a 'dumb' terminal? I guess it would be far too latent. Hence the local 'video card' idea. Sigh. On 11/15/06, Timothy Miller <[EMAIL PROTECTED]> wrote:
On 11/15/06, Nick LaForge <[EMAIL PROTECTED]> wrote: > This project currently conserves the old bag of tricks... but will it > be possible to adapt it to 'raytrace'? If not, I see no reason to use > it over the Intel. Well, obviously, OGD1 can be used for anything that fits in the FPGA. Also, there has been at least one FPGA-based raytracing project. We're stuck having to implement things the "old way" because that's what the market demands. In order to reach the maximum number of people, we have to design the hardware that supports the applications they want to run. Changing from rasterizing to ray-tracing would be an incredible paradigm shift, for which there is no existing software. Think hard about what would be required to translate OpenGL into what a raytracer would need. At the object level, perhaps it could be done, but given the limitations imposed by OpenGL's assumptions, the image quality wouldn't be much better, but the performance would be much worse. We can experiment with ray-tracing engines in hardware. We need to consider the general cases. How can we represent any object we want in a scene? How does the raytracing engine process the scene? What kind of interface would we provide to the applications? And how would legacy apps be emulated?
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
