Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ray Tracing in pure CMake

64.github.io

Post reply on HN
Print view View original

121–130 of 167 posts

Re: Ray Tracing in pure CMake

#121

Post by delta64 »

Someone wrote: post #17
xyzzy_plugh wrote: post #3

I refuse to even look at this. I've seen ray tracing in a PDF before but this is too far.

IMO, this isn’t that impressive. Turns out that CMake has a scripting language that can be used to implement a ray tracer, and do that multi-threaded. The model being rendered also is hard-coded in the ray tracer. I expected a monstrosity that had multiple targets for every pixel (“ray arriving at (x,y)”, “ray arriving at (x,y) after one bounce”, etc), with some magic to merge all the outputs of the last bounce into…

> The model being rendered also is hard-coded in the ray tracer.

This is true - but there's no reason why it couldn't be modified to read in a scene description. It's more a proof of concept than anything else.

Re: Ray Tracing in pure CMake

#123

Post by delta64 »

bawana wrote: post #12

Please clarify for me the part about the set exec command. You create n workers but you pass the whole image size to each. Why isn’t the image size divided by the number of workers?

It figures out which rows to render using its own worker index

Re: Ray Tracing in pure CMake

#124

Post by cmrdporcupine »

mkl95 wrote: post #29
knorker wrote: post #19

Well well well, we finally found something CMake can actually do. Please, everyone, stop using CMake. It doesn't do its one job.

I have mixed feelings about CMake. Non trivial scripts look like an spaghetti ball, but it's an extremely powerful spaghetti ball.

From my perspective that's possibly a partially-good thing. Don't do non-trivial things if you can avoid it. Projects should stay on the path of consistent practices, follow standards of packaging, and try to follow conventions that the build system lays out. Stay with standard libraries, avoid custom tooling when possible, etc. If what you're doing requires a boatload of scripting in CMake, you need a good justification for it, and if that justification is there then writing the scripting for the build system is the least of your concerns.

But yes it really is ugly once you get off the well beaten track of "here's my source now make a library out of it with a C compiler and a few standard options." I have a personal project I fiddle with that glues together verilator, fusesoc, CMake, a RISC-V compiler toolchain, and some custom scripting into xilinix vivado.. and it terrifies me just a little.

Re: Ray Tracing in pure CMake

#125

Post by bluGill »

appleflaxen wrote: post #78
bluGill wrote: post #27

Earlier quoted context omitted.

The syntax is weird and inconsistent. Built ins are case insensitive, but user defined functions are sensitive. No way to return values from functions, except by jumping to the scope of the caller and changing its variables unexpectedly. (Better hope you know what the caller does) That isn't a complete list . Despite the above cmake is your best choice of build system for C. Though some competitors could overtake it.

which competitors? any thoughts on why are build tools so hard to get right?

Build2 is one that a coworker of mine likes. There are others.

What makes it hard is the problem is a lot deeper than most people realize, so most attempts are not powerful enough to be useful. They are clean until someone points out one of the many edge cases that were not thought of, and by the time you support even a few of them your clean design is a mess of uglyness.

Making it worse build systems are an afterthought to most develpers so you end up with a mess just because the programers are not taking care to write good clean code in the build system.

Re: Ray Tracing in pure CMake

#126

Post by tn1 »

MaxBarraclough wrote: post #110
knorker wrote: post #95

Earlier quoted context omitted.

I can't speak for MSVC support, but to me CMake fails all other bullet points. especially cross-platform package detection. I haven't seen anything except autotools get this right.

> especially cross-platform package detection I disagree here. CMake has working FindXyz modules for most major libraries. To write one of those modules is an exercise in soul-destroying tedium, but there's a pretty impressive body of existing modules out there, many of them officially bundled with CMake. When used correctly, both CMake and Autotools are capable of robust package-detection. Regarding point 1: CMake w…

> CMake has working FindXyz modules for most major libraries

Unless you have that library installed anywhere that is not /usr/include Then you have to just hope and pray that there's some magic incantation that will make it find the right one (especially if your system-installed version is the wrong version and you'd really like to use the newer version you installed to $HOME)

Re: Ray Tracing in pure CMake

#127

Post by nrdvana »

delta64 wrote: post #122
nrdvana wrote: post #115

High-five from the opengl-bash guy! http://www.nrdvana.net/cmdlinegl/

Thanks! This is extremely impressive, and looks like far more effort haha

The OpenGL interpreter was a lot of effort, but the bash scripts that feed it were basically the same problem you worked out: how to implement 3d vector math in a language of integers, array variables, and functions without references or return values.

Re: Ray Tracing in pure CMake

#128

Post by chubot »

gumby wrote: post #80
chubot wrote: post #76

This is cool, someone should port this to bash, which also only supports integers. Then I can use it as a benchmark for https://www.oilshell.org :) Also bash can do the multicore part very easily with processes, like cmake.

> This is cool, someone should port this to bash, which also only supports integers. With a little bitfield support (you could always call out to dc but you can do boolean arithmetic directly in bash) you can simply implement IEEE 754 in bash.

Yeah bash has 64 bit signed integers and bitwise ops on them. I'd be interested in seeing a floating point implementation. I think it would be pretty much identical to an implementation in C with signed long.

    echo $(( 2**63 | 1 ))
    -9223372036854775807

Re: Ray Tracing in pure CMake

#129

Post by nrdvana »

chubot wrote: post #76

This is cool, someone should port this to bash, which also only supports integers. Then I can use it as a benchmark for https://www.oilshell.org :) Also bash can do the multicore part very easily with processes, like cmake.

Feel free to use my bash 3d geometry library

https://github.com/nrdvana/CmdlineGL/blob/master/share/lib-b...

Re: Ray Tracing in pure CMake

#130

Post by nrdvana »

delta64 wrote: post #122
nrdvana wrote: post #115

High-five from the opengl-bash guy! http://www.nrdvana.net/cmdlinegl/

Thanks! This is extremely impressive, and looks like far more effort haha

Btw, one of the things I came up with in bash was an “object oriented” pattern (antipattern?) where a “constructor” function would declare variables for “attributes” and functions for “methods”, like for example declaring an object named Vector1 whose fields are Vector1_x Vector1_y Vector1_z and methods like Vector1_Normalize and Vector1_SetMagnitude. The functions would be eval’d for each instance of the object during the constructor to reference the attributes and methods of that named object instance. Is this possible in cmake? (I don’t know cmake at all)
Post reply on HN