3 ms·

I personally wish the code was just written cleanly and idiomatically. I wouldn't mind "300 lines of simple, idiomatic C++". What's the use of making code dense

I personally wish the code was just written cleanly and idiomatically. I wouldn't mind "300 lines of simple, idiomatic C++". What's the use of making code dense if you're going to reformat it anyway? (I say this in contrast to something which was explicitly "code golfed", which this code seems not to be.)

chubot 10y ago
I actually went through that exercise if anyone is interested. It ended up at probably 500 lines at first, and then 800 or so lines because I tried to port it to CUDA. It was mainly an exercise in learning CUDA -- i.e. how is CUDA different than C++? I got something running on my graphics card, but it didn't completely work and I moved onto other things. I haven't run this code since 2015 but I did have a lot of fun learning from it. $ wc -l smallpt.cpp 811 smallpt.cpp Another nice codebase I learned from is tinypy: http://www.tinypy.org/ http://www.tinypy.org/ It's written in a similarly condensed style. I'm inclined to agree with you at first, but honestly I find that reformatting code helps me get a feel for it! It is a mechanical exercise that reminds you of everything that's there. Going through and renaming functions and types to "your style" seems kinda frivolous but it actually helps IMO.
strainer 10y ago
I understand production and community code demands a most simple format but for me this program is just a few braces and vertical breaks short of perfection.
- btmorex 10y ago
  You must be a fucking genius then because: Vec w=nl, u=((fabs(w.x)>.1?Vec(0,1):Vec(1))%w).norm(), v=w%u; is completely unreadable and that's just one line.
  - jackmott 10y ago
    not that bad.
  - TillE 10y ago
    That really just needs some whitespace. Vec w=nl, u=((fabs(w.x) > .1 ? Vec(0,1) : Vec(1)) % w).norm(), v=w%u; Simple, right? I can see how it would look like garbage if you miss the three separate variables being initialized, but that should be familiar to most people with C/C++ experience.
    - strainer 10y ago
      % being overloaded as vector cross product is a bit mysterious here (until investigating Vec's definition) It might be helpful if the instantiations were written fully too, ie. Vec(0,1,0) : Vec(1,0,0)
  - strainer 10y ago
    No its fine and Im certainly no genius. I just dont need whitespace to 'reinforce' code expression - its a visual familiarity thing, quite a general reading skill. The only confusing thing in this line is the % operator being overloaded on Vecs to mean the cross product. What the calculation is actually for is what takes time to grok, but you cant expect that to be revealed by familiar formatting and expansive variable names.
kzf 10y ago
There you go (+ walkthrough video): https://users.cg.tuwien.ac.at/zsolnai/gfx/smallpaint/ https://users.cg.tuwien.ac.at/zsolnai/gfx/smallpaint/
erichocean 10y ago
> I personally wish the code was just written cleanly and idiomatically. PBRT fills that role nicely IMO.
- kutkloon7 10y ago
  I suppose you mean physically based raytracer? That's definitely not something you can read through in a single afternoon.
  - erichocean 10y ago
    It's easy to read through the parts of the PBRT[0] book that Smallpt implements in an afternoon. Of course, PBRT also implements a bunch of other stuff Smallpt doesn't which you can skip until you're ready. PBRT was created for pedagogical reasons and has very easy to follow code with full documentation of everything relevant. Smallpt is designed to be super small and doesn't really say why it works; PBRT does. As a bonus, a lot of other physically-based renderers you'll find on GitHub follow PBRT's overall architecture closely (such as Embree[1]), so they're also easy to read/understand if you already know PBRT. [0] http://pbrt.org/ http://pbrt.org/ [1] https://embree.github.io/ https://embree.github.io/

chubot 10y ago

I actually went through that exercise if anyone is interested. It ended up at probably 500 lines at first, and then 800 or so lines because I tried to port it to CUDA. It was mainly an exercise in learning CUDA -- i.e. how is CUDA different than C++? I got something running on my graphics card, but it didn't completely work and I moved onto other things. I haven't run this code since 2015 but I did have a lot of fun learning from it. $ wc -l smallpt.cpp 811 smallpt.cpp Another nice codebase I learned from is tinypy: http://www.tinypy.org/ http://www.tinypy.org/ It's written in a similarly condensed style. I'm inclined to agree with you at first, but honestly I find that reformatting code helps me get a feel for it! It is a mechanical exercise that reminds you of everything that's there. Going through and renaming functions and types to "your style" seems kinda frivolous but it actually helps IMO.

strainer 10y ago

I understand production and community code demands a most simple format but for me this program is just a few braces and vertical breaks short of perfection.

btmorex 10y ago
You must be a fucking genius then because: Vec w=nl, u=((fabs(w.x)>.1?Vec(0,1):Vec(1))%w).norm(), v=w%u; is completely unreadable and that's just one line.
- jackmott 10y ago
  not that bad.
- TillE 10y ago
  That really just needs some whitespace. Vec w=nl, u=((fabs(w.x) > .1 ? Vec(0,1) : Vec(1)) % w).norm(), v=w%u; Simple, right? I can see how it would look like garbage if you miss the three separate variables being initialized, but that should be familiar to most people with C/C++ experience.
  - strainer 10y ago
    % being overloaded as vector cross product is a bit mysterious here (until investigating Vec's definition) It might be helpful if the instantiations were written fully too, ie. Vec(0,1,0) : Vec(1,0,0)
- strainer 10y ago
  No its fine and Im certainly no genius. I just dont need whitespace to 'reinforce' code expression - its a visual familiarity thing, quite a general reading skill. The only confusing thing in this line is the % operator being overloaded on Vecs to mean the cross product. What the calculation is actually for is what takes time to grok, but you cant expect that to be revealed by familiar formatting and expansive variable names.

kzf 10y ago

There you go (+ walkthrough video): https://users.cg.tuwien.ac.at/zsolnai/gfx/smallpaint/ https://users.cg.tuwien.ac.at/zsolnai/gfx/smallpaint/

erichocean 10y ago

> I personally wish the code was just written cleanly and idiomatically. PBRT fills that role nicely IMO.

kutkloon7 10y ago
I suppose you mean physically based raytracer? That's definitely not something you can read through in a single afternoon.
- erichocean 10y ago
  It's easy to read through the parts of the PBRT[0] book that Smallpt implements in an afternoon. Of course, PBRT also implements a bunch of other stuff Smallpt doesn't which you can skip until you're ready. PBRT was created for pedagogical reasons and has very easy to follow code with full documentation of everything relevant. Smallpt is designed to be super small and doesn't really say why it works; PBRT does. As a bonus, a lot of other physically-based renderers you'll find on GitHub follow PBRT's overall architecture closely (such as Embree[1]), so they're also easy to read/understand if you already know PBRT. [0] http://pbrt.org/ http://pbrt.org/ [1] https://embree.github.io/ https://embree.github.io/