Here's a thread for sharing renderings that people make involving either BRL-CAD geometry models or BRL-CAD rendering. Feel free to post your own pictures.
To kick things off, here's a rendering I made a few months back: t62.png
I don't remember exactly, but this image has pretty much all the knobs turned all the way up, so it was computationally intensive and rendered at a ridiculous resolution for a huge poster printing. I believe it was 16384x16384 with hypersampling (don't recall exact setting but probably -H3), shadow rays (300 sample rays per hit if I recall correctly), and ambient occlusion (forget how many samples, but it was a lot too!). Basically, in the "trillions of rays" ballpark. I should calculate the actual. Regardless, rendering with remrt took something like 4-8 hours using over 300 cores. The poster looks amazing. ;)
Really need to get ambient working with rt's cutting plane option... Screen-Shot-2020-08-27-at-12.46.23-AM.png
This building render turned out pretty nice, though. Wow, this is an oldie! building_1024.png
the building looks cool
Did you make it in BRL-CAD?
@Sumagna Das yes, that's a pure BRL-CAD model made from scratch
that was 14 years ago though, and my memory of who all worked on it is fuzzy. I remember directing and coordinating a lot, but I think there was a summer student or two involved in taking measurements and creating the geometry. I put the scene together, created and textured the ground, and rendered it.
Preview of a new model from Chris McGregor Screen-Shot-2022-04-04-at-10.19.15-PM.png
Improved ambient occlusion support for cut planes.. before and after:
Screenshot-2024-02-28-at-10.12.14-AM.png
10k random points and lines to center
10k_moss_samples.png
Cool. This sampling method converges to a very precise surface area metric in a fraction of a second:
sphvalidation.png
Somewhat better view of what's going on...
Screenshot-2024-03-02-at-2.14.00-PM.png
Testing out three different methods for visualizing a model's exploded complexity in a collage format:
image.png
(All three are incomplete, still running as those are just previews -- full res is print-quality)
Hah - wacky cool
There was a really cool collage I saw at Siggraph that gave me the idea. Still have to pad the images better and probably cull out negative cuts, but idea is to spread it all out in one image.
Reminds me of that old "exploded views" paper from siggraph years ago
I think it was this... https://grail.cs.washington.edu/projects/exview3D/
![]()
and baseline fixed..
![]()
final result in ibrt
![]()
![]()
![]()
3D scans of oak logs with visible toolmarks. Break of bronze and iron age in central Europe. Assembled in GIMP.
@Pavel Jansa that's pretty cool - you might want to run "gist" on one of them and see what you think of the output...
If you set its material, you could even get it to report mass properties.
ADRT master-slave rendering! Been probably 10+ years since this was last tested working.
![]()
![]()
Fun with TOR - the previously impossible Y-only scaling operation, both wireframe and raytraced.
how you doing the implicit?
https://github.com/BRL-CAD/brlcad/compare/main...nonuniform
I don't know that it will actually be mergeable in its current form, but I was curious to see if it was possible.
Basically stashing the matrix on the primitive as an attribute and teaching the loading codes to read and apply it
oh, of course it's possible. always have known that, issue is really just that there's no clean way to do it without breaking format. it needs the affine matrix at shot time, but it's only available at export time. only hack is to hang it off an attribute during export, which is exactly what it did there. that was one of the motivations for binary attributes a few years back, but still considered it an egregious hack and entirely backwards incompatible.
looking at the change, rather fugly that it introduced a whole new callback to lookup and apply the affine transformation AND manually injected code all over the place to go through it. that seems entirely unnecessary to me. just needed a static helper for prep/tess/plot.
interesting to consider the implications in more detail. with some cleanup and changes, might be something there.
dynamic secondary render cell plot overlay:
![]()
![]()
How is it backwards incompatible? Not arguing for merging it in, but in the absence of code to process the attribute it'll handle the shapes in question the same way it currently does, correct? Just ignore the attribute and raytrace as it would now - no wronger than it's ever been... The new rendering code would just be more correct than older code.
preliminary progress on a full OSM-spec-conformant building generator ![]()
Normals are a bit wonky, but this is a non-trivial IGES import of https://grabcad.com/library/battleship-hms-dreadnought-update-3-1
![]()
![]()
dm set lighting 2 helps quite a bit for this one.
![]()
That's probably where I'll leave it for this round - color is per-face, and if we make individual breps for open shells rather than forcing associated faces into a single brep container we can show some of the colors, but longer term the drawing layer and data storage need some sort of per-face-color capability to do this right.
Last updated: Sep 08 2026 at 02:02 UTC