Of course, a FAQ about torad might seem a little outdated in these days where everybody will be using radout and ddrad, but maybe someone has so much fallen in love with this nice little program that he never wants to give it back again. This page is devoted to you!
Please note also, that all of this has been written at a time when there was at most Autocad R12 available. A few things have changed dramatically since then, so that you may find stuff in here that may not make any sense to you now.
> My question is about translating solids. I tried even a simple box > primitive with none results. The file was created but empty. As i > understand Torad supports this level of primitives. There should be a paragraph in the the "CAVEATS" section of the manual with the following reading (I falsely assumed this to be obvious): Models created with the AME Solid modelling package must have surfaces defined with the command "SOLMESH". Otherwise they consist of only wireframe information wich cannot be extracted by torad.lsp. Have you ever tried to shade your solids within autocad? this is a good way to check what will be visible in radiance (as long as you stay with the default settings for exporting entities).
> From this may i understand that any meshed solid will be > translated to Radiance? I mean, even boolean operations will be > taken? Any kind of translated to Solid primitive will be taken? > I just understand from TORAD that only flat or extruded solids > will be translated (i.e. only plines extruded or solidified). Of course i have only told you half of the truth about the necessary additions to the torad manual... Again in the CAVEATS section it should also read: The "SOLID" entities in Autocad, which can be extracted with the "Extruded and flat Solids" option, have nothing to do with solid modelling or AME. These are a feature out of the 2D days of Autocad and are just flat quadrilateral faces which appear solidly filled when viewed from top. They form quadrilateral prisms if extruded, which can only be done vertically to their ground plane. AME solids, with or without boolean operations, consist internally (within the anonymous block definition) of polyface meshes - once they *are* meshed. Polyfaces are exported normally, though not really efficient, as they use large numbers of triangles to fill irregular shapes (check your solids with "SPLFRAME" on to get an idea).
> Yesterday i tried to transfer a mesh (a normal one i made for > topography), transfered it to Radiance without problem. > The problem was when i did pedit of the mesh and made smooth, > and then transfered to Radiance. The radiance file was empty. I was very cautious when writing this part of the code, and just disabled exporting of smoothed meshes internally. You can change this if you modify line 450 of esample.lsp from: (cond ((= 0 (logand flag (+ 2 4 8 64))) ;0, 1, 16, 32 allowed to: (cond ((= 0 (logand flag (+ 2 8 64))) ;0, 1, 4, 16, 32 allowed. The flag bit 4 in the group 70 of a polyline header entity tells if there were vertexes added due to smoothing. I never have used meshes but for landscape modelling in architecture where i didn't need smoothing. I do not know if and when autocad creates additional vertexes for smoothed meshes, nor whether it would show the new number of vertexes in the 71 and 72 groups of the header entity. This means, it is possible that your mesh will not be exported correctly when it is smoothed. This is a consequence of the way autocad handles spline curves and surfaces, which is not the greatest feature of it. If you encounter problems of that kind, you will need to modify the function meshtopoly in such a way, that it determines the correct number of vertices in a mesh itself, before extracting the shape of the single faces.
> The convertor produces a *.rad, a makefile, a > *.mat, in fact everything except the *.view (which can not be > produced under DOS => only 3 characters long for the extension). > > I had a look to the torad.lsp, I made few changes replacing the > strings ".view" by ".vie" but it still does not work. > I probably do not use it correctly... This is really a "problem" I did not notice back then when I wrote torad. Allthough I thought about the limitation of 8 characters for the basename, those 4 characters in the ".view" extension escaped me completely. It seems that until now most users have worked on unix systems, since you are the first one to tell me about this ... There are 4 places in torad.lsp where you need to replace ".view" by ".vie". [editorial note: ddrad now uses ".vf" for View File] After this, I dont see a reason why it should not work. Make sure not to modify any occurence of "view" (without the dot) since those are used to reference the dialog box item of that name. If they are changed, the state of the checkbox where you activate view file generation cannot be determined. There are other "view" strings used for referencing the internal list structure, which shouldn't be modified either. > That's right, I found them and I replaced the ".view" by ".vie" > and the results were the same... I can't explain that at the moment because I don't have a DOS system at hand to test it. In fact I never have tested torad on DOS, so I am glad that most of it seems to work there all the same ...
> The problem is that the 3d-meshes tend to be very wasteful, > converting what would have been a single polygon into thousands > of quadrilaterals. This is particularly harmful when the surface > being meshed is a light source or a mirror, creating thousands of > sources where only one is needed, thereby choking the renderer. > > Users have tried changing the AutoCAD meshing parameters to make > fewer polygons, but they say it has no effect. > > Perhaps meshing is nessecary in cases where boolean operations > are being done on surfaces, but for the majority of solids it > really isn't needed. Could the user get away with only meshing > those solids that need it, leaving the rest intact? > > Finally, how difficult would it be to convert higher-order > solids such as spheres and cylinders directly into the Radiance > equivalent? > > Thanks for any help or pointers you can offer, and thanks for > writing such a wonderful and robust translator! The main problem is, that Autocad itself is a plain surface modeler. The ADS solid modelling package which can be added to it tries to simulate a real solid modeller by creating blocks (entity groupings similar to instances in radiance) which contain the information of the solid objects. There are two representations of these objects. One a pure wireframe model and the other a meshed one. One can be converted to the other and back. The wireframe representation really contains only the edges of the solid as lines or arcs in space. So I have little chance to extract the surface information needed in radiance from it without writing some kind of solid modeller myself for filling the wireframe and tesselating the curves. There is a variable in ADS called "SOLWDENS" which controlls the degree of detail the solid is calculated with within a certain range. As I see from the manual, this variable must be set before the solid is created to take effect. Still, SOLWDENS only affects the appearance of curved surfaces. The higher its value, the more precise the curves will appear, at the cost of disc and memory space. With flat surfaces, the problem is even worse than you expect as they are no even divided into quadrilaterals but in fact triangulated! If you do solid modelling with simple primitives without using the boolean subtraction operation it might be relatively easy to convert those primitives to their equivalents in the .rad format. For this you would have to go into the data structures if ADS (there is an API in C) for accessing the structural information. But for this case I'm not sure what you really would need the solid modelling for (if not for having the intersection edges displayed in autocad itself). It might be much easier just to create blocks of the common primitives (box, cylinder, wedge, spheres[points], and certain prisms) by hand and just have their instances intersect each other.