Has anyone done any work on integrating radiance with a hardware solution? I'm thinking of porting the basics of radiance to an FPGA with a view to (near-)realtime rendering from AutoCAD or similar. I'm currently evaluating previous work in this area, and so far it appears that the most difficult bit of the problem would be the hardware implementation of complex functions for procedural textures and surface models - in particular the generic lookup tables for images / function data. Other than that it's just a lot of legwork... am I missing something?
Has anyone tried this in the past? Perhaps a different type of hardware acceleration? Please let me know if you've got any success / horror stories!
mike
ps: Another major problem for point + shoot rendering from 3D modeling programs is ensuring oconv has a bounded finishing time for any given model. Most models I work with in AutoCAD or Lightwave (exporter coming Real Soon!) need extensive conversion work before oconv will run to completion. (Most often it simply runs continuously until it dies because it uses up all available memory. >4GB! ) Are other people having similar problems?
ps: Another major problem for point + shoot rendering from 3D modeling programs is ensuring oconv has a bounded finishing time for any given model. Most models I work with in AutoCAD or Lightwave (exporter coming Real Soon!) need extensive conversion work before oconv will run to completion. (Most often it simply runs continuously until it dies because it uses up all available memory. >4GB! ) Are other people having similar problems?
Hi Mike,
the oconv code is not much if counted in lines and statements, but it is definitly one of the complicated parts of Radiance. The memory issue is certainly connected to the amount of fine detail in the scene, as one algrithm within oconv calls itself recursively again and again when stepping down the tree and subdividing the cube into octants and suboctants etc. This results in oconv 'blowing' itself up considerably, using far more memory for the process than the produced octree later has itself.
This means by subdividing the scene beforehand and then including the parts as instances you have far better chances to get a model 'oconved'.
(If I remember it right Greg once said that by using instances and subinstances etc the whole world could be converted to an octree with resolution down to some inches ...)
Another optimisation comes into play: if you have lots of similar instances, they are only allocated once. A drawback of using instance is that every ray has to undergo a transformation on entering, but for huge models this effect becomes negligible.
All in all this means of course some appropriate user intervention. Coming up with an automatic solution which e.g triggers subdivision of the scene automatically presumably will be not easy
Unless you're really, really careful, the communication with the FPGA will kill any savings you make in the ray tracing times on a hardware implementation. This has been found time and again for the past decades by the numerous people who have written or attempted ray-tracing on hardware. The literature is extensive in this area, and I suggest you start with one of the textbooks on parallel rendering algorithms, such as:
Practical Parallel Rendering
by Alan Chalmers (Editor), Timothy Davis (Editor), Erik Reinhard
Regarding oconv, you might have better luck converting some larger models into a Radiance mesh, which uses less memory to represent triangular tesselations. Most CAD software these days spits out hundreds of thousands of polygons, even when they aren't needed, such as for large, flat surfaces. Using Alias/Wavefront .OBJ as your export format, obj2mesh can convert these models much more efficiently into Radiance.
-Greg
ยทยทยท
From: Michael Kruger <[email protected]>
Date: February 28, 2005 3:24:07 AM PST
Has anyone done any work on integrating radiance with a hardware solution? I'm thinking of porting the basics of radiance to an FPGA with a view to (near-)realtime rendering from AutoCAD or similar. I'm currently evaluating previous work in this area, and so far it appears that the most difficult bit of the problem would be the hardware implementation of complex functions for procedural textures and surface models - in particular the generic lookup tables for images / function data. Other than that it's just a lot of legwork... am I missing something?
Has anyone tried this in the past? Perhaps a different type of hardware acceleration? Please let me know if you've got any success / horror stories!
mike
ps: Another major problem for point + shoot rendering from 3D modeling programs is ensuring oconv has a bounded finishing time for any given model. Most models I work with in AutoCAD or Lightwave (exporter coming Real Soon!) need extensive conversion work before oconv will run to completion. (Most often it simply runs continuously until it dies because it uses up all available memory. >4GB! ) Are other people having similar problems?
Unless you're really, really careful, the communication with the FPGA will kill any savings you make in the ray tracing times on a hardware implementation. This has been found time and again for the past decades by the numerous people who have written or attempted ray-tracing on hardware. The literature is extensive in this area, and I suggest you start with one of the textbooks on parallel rendering algorithms, such as:
Practical Parallel Rendering
by Alan Chalmers (Editor), Timothy Davis (Editor), Erik Reinhard
Thanks for the advice. I'm pretty sure that the memory capacities of FPGAs nowadays would allow me to store everything I need on the device, which should ensure communications overhead is relatively marginal. Most of the work I'm interested in doing with radiance is high-resolution and high-accuracy (10k renders, with high -ab & -ad) so I'm hoping that the tasks would be computensive enough to give me sufficient performance gains as to make it worthwhile. Anyhoo, I'm off to the bookstore...
Regarding oconv, you might have better luck converting some larger models into a Radiance mesh, which uses less memory to represent triangular tesselations. Most CAD software these days spits out hundreds of thousands of polygons, even when they aren't needed, such as for large, flat surfaces. Using Alias/Wavefront .OBJ as your export format, obj2mesh can convert these models much more efficiently into Radiance.
I'll give it a go. Just for reference, the models I'm using have less than 10k polygons so I'm not sure that that is the problem. (I've had problems in the past with 1k models.)
From: Michael Kruger <[email protected]>
Date: March 1, 2005 4:06:55 AM PST
Regarding oconv, you might have better luck converting some larger models into a Radiance mesh, which uses less memory to represent triangular tesselations. Most CAD software these days spits out hundreds of thousands of polygons, even when they aren't needed, such as for large, flat surfaces. Using Alias/Wavefront .OBJ as your export format, obj2mesh can convert these models much more efficiently into Radiance.
I'll give it a go. Just for reference, the models I'm using have less than 10k polygons so I'm not sure that that is the problem. (I've had problems in the past with 1k models.)
The only times I've heard of oconv getting stuck and using up memory is when there are many overlapping instances, or if many polygons come together at a single vertex, when it tries to resolve this down to the finest level. Otherwise, it should work -- especially with such a small model. If you send me one of these models, I'd love to have a look to see what's going on.
