Thanks much for all the info. I will take a bit to digest everything.
Not sure if you support this functionality already -- but it would likely be a piece of cake for you. I once had need to use RT techniques to figure out solar visibility and equivalent area for a solar aircraft from every view angle. Visibility is determined by shadowing / occluding. Then there is another term that takes into account the angle between the light ray and the solar panel normal vector that calculates a knock-down factor for refraction through the glass. The final answer is given in terms of equivalent area. Most who do this use a point source for the sun, but with sophisticated ray tracing, you could include the effect of the umbra too. Best, Rob On Tue, Mar 9, 2021 at 12:00 PM Christopher Sean Morrison via brlcad-devel < [email protected]> wrote: > > On Mar 9, 2021, at 1:50 AM, Rob McDonald <[email protected]> wrote: > > Thanks Sean, that is exactly what I was looking for. The output from > rtedge looks great. > > Is there any documentation of the edge detection algorithms applied in > rtedge? It is done as a raster, do you know if it can be done as a vector > instead? > > > It is currently performed as a raster operation, operating at a specified > resolution, but it certainly could be done in vector space instead. Note > that while the output is raster, the edge detection is not exactly > happening in raster space. It happens in the 3D space via ray tracing > taking things like surface curvature, material properties, depth > differences, and unique objects into consideration. The manual page > explains in a bit more detail (running “man rtedge” in mged or archer or > running “brlman rtedge” on the system command line will display relevant > documentation. > > Vector output is definitely something we’ve talked about implementing, but > have yet to do so. There’s a couple approaches that come to mind that > wouldn’t be terribly difficult. First approach could be to limit > consideration to explicit geometry such as NURBS or polygonal meshes where > you evaluate a 2D projection of the geometry. Second approach that isn’t > limited would be to perform adaptive refinement over the existing 2D raster > method to evaluate projected curve connectivity. There are a number of > papers and implementations that have demonstrated both can work rather well. > > I went to try to look for the code. I must admit, I couldn't really > figure out where to start looking. I'm also on a Mac -- would using 7.24.0 > pose any problems for playing with this? I'd like to be able to read a > STEP or IGES file and then see what rtedge produces. > > > There’s some detail and references, including pointers to the existing > code for rtedge, available at > https://brlcad.org/wiki/Vector_Drawings_from_NURBS > > Obviously, longer term I'm looking to steal good ideas and implement them > natively in OpenVSP. We don't have any sort of ray tracing engine, so our > implementation will have to be considerably different. > > > The most common uses case for BRL-CAD is as an embedded solid ray-tracing > engine. The LIBRT ray tracing library could be integrated into OpenVSP > where geometry is (trasnparently to the user) passed to librt or rtedge and > rasterized to a hidden-line rendering. We could even create a high-level > image rendering library to help simplify the process depending on your > needs. > > Cheers! > Sean > > _______________________________________________ > BRL-CAD Developer mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/brlcad-devel >
_______________________________________________ BRL-CAD Developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/brlcad-devel
