Lloyd A Treinish: |> Has anyone done off-screen hardware-accelerated rendering with DX on |> UNIX? Alternatively, has anyone worked on implementing texturing in |> the software rasterizer? | |One is brute force, treating the images as a field of regular quads and |warping (Mark->Compute->Unmark) or interpolating (Map) that to the surface |and s/w rendering. Assuming the images are of interesting size and unless |you are on a decent SMP machine, that will be slow.
Thanks for the response Lloyd. This is close to what I'm doing now. For now, the "texture" is the same res as the grid so it's just a Replace, but that will change RSN. As you said, it's slow -- it really limits scene complexity. No need for volume rendering in this project fortunately, but thanks anyway. |Also, I thought, but could easily be mistaken, that Greg had enabled |off-screen h/w rendering (e.g., set Options rendering mode to hardware |prior to pass objects to Render->WriteImage) That's what I'm looking for. However I tried this, and I get the same timings w/ and w/o rendering mode = hardware. Greg, if you implemented this, did it get committed? I didn't expect to see a difference because a grep of the DX source finds no mention of PBuffers. AFAIK, GLXPbuffers are the only way to do HW-accel off-screen rendering on X (SGI, and possibly Sun). GLXPixmap rendering isn't hardware-accelerated from everything I've read. If I were to give it a go, how much trouble do you think it'd be to add PBuffer rendering support. One key point is that PBuffers aren't X Drawables (like Windows and Pixmaps), so I'm guessing this'd boil down to how well the X drawing functionality in DX is abstracted behind a DX "drawing interface". Thanks, Randall -- Randall Hopper (mailto:[EMAIL PROTECTED]) Lockheed Martin Operation Support EPA Scientific Visualization Center US EPA MD/24 ERC-1A; RTP, NC 27711
