I was surprised at how little code it takes to generate the gopher, using your library, that's cool.
I started generating the gopher locally abd let it go through one iteration, taking 4:34, until I realized it takes 1000 iterations to fully render :) I killed it.
Most of them rendered on the order of ~30 minutes. The gopher I ran overnight, although it really only needed about 2 hours to get really good quality. Keep in mind these durations are for large resolutions.
I'm interested in more information about why you decided to alter GOMAXPROCS and what your results were from testing.
I've had a play with this myself and found that it cause sporadic and unpredictable crashing (very different style of application though - I was building a webserver). However this was an earlier iteration of Go (possibly Go 1.1 but likely 1.2) so things may have improved since then, or you might have found a saner way of tweaking it.
When GOMAXPROCS > 1, your program goes from "everything is executed sequentially" to "everything is maybe executed in parallel." This can expose data race bugs in your code that aren't present when GOMAXPROCS = 1.
You know, that's entirely possible. I was playing around with different methods of passing data between goroutines for increasing performance and I knew one of the methods I was testing wasn't idiomatic Go. However since I wasn't getting race conditions normally i assumed that the GOMAXPROCS fault wasn't down to my shonky code.
The weird thing is I thought I'd read somewhere that said Go defaulted to a process per CPU core (like the OP has hardcoded ib this project). I'm guessing that isn't the case then? It sadly wouldn't be the first time I've misread something! :(
I don't have anything to compare to, but Go seems quite fast. I would guess no worse than 2x C in this case, but I'm pulling that number out of my butt.
Actually I was originally going to write this in C but it started to be a PITA and I had the spontaneous idea that maybe Go would be the right choice for this (never used it before). It totally was. No way I would've had this level of results so quickly in C.
Being a big fan of Python and C, Go seems like a really good middle ground. Really happy to have learned it.
I'm very very impressed by your code quality especially when this is just your first Go project. I'm an experienced Go developer btw. You're just so good.
As someone trying to learn the basics of rendering, I was really pleased to see your project pop up on the github explore email today. It's very easy to follow, even for a non-Go programmer like me.
Performance question from a no-Go programmer though - does returning objects from functions incur a cost? For example "func Reflect() Ray {}" or "func Add() Vector" - do they create a new object on the heap? If so is that an issue in Go?
Not very often I can look at a library and easily follow the code. I may spend a couple afternoons reading it just to understand how this works. Very nice.
Use `go get github.com/fogleman/pt/pt` and the code will be downloaded to $GOPATH/src/github.com/fogleman/pt/pt. Go imports are all absolute paths from $GOROOT or $GOPATH.
I always looked go as a programming language to develop systems and tools but , this is very interesting . Would be interesting in a benchmark results of rendering with other languages .
The code is really nice and clean [1], great job for someone's first Go project! I think it's a great example of how Go's simple and clean language design can lead more people to write high quality, readable code.
Question, I see you're using your own Vector and Matrix types and methods. Have you considered using an existing vector math library like mathgl [2]? Nothing wrong with your decision, I just wanted to hear your thoughts.
I'm getting runtime errors when trying to run the example locally, and compile errors for others (e.g. suzanne.go, 'not enough arguments in call'). Was there a recent update that broke the code?
The only reason I'm commenting is to point it might have been easier for users if you linked to the project homepage rather than the readme file itself.
How big is the binary? I had to ask since you linked to the site of iq, the guy who wrote the insanely awesome Elevated 4k demo [1] and several other nice 4k procedurally-generated graphics [2].
This is very nice. I wonder how hard it would be to turn this into a network renderer (I suppose farming out sections to other machines is challenging with path tracing, but may be wrong).
51 comments
[ 3.0 ms ] story [ 108 ms ] threadDo you read a file that contains anything you need to render, if so, can you produce said file with another 3D software?
I started generating the gopher locally abd let it go through one iteration, taking 4:34, until I realized it takes 1000 iterations to fully render :) I killed it.
You can also reduce the resolution.
I've had a play with this myself and found that it cause sporadic and unpredictable crashing (very different style of application though - I was building a webserver). However this was an earlier iteration of Go (possibly Go 1.1 but likely 1.2) so things may have improved since then, or you might have found a saner way of tweaking it.
(I'd suggest using Go's race detector.)
The weird thing is I thought I'd read somewhere that said Go defaulted to a process per CPU core (like the OP has hardcoded ib this project). I'm guessing that isn't the case then? It sadly wouldn't be the first time I've misread something! :(
Actually I was originally going to write this in C but it started to be a PITA and I had the spontaneous idea that maybe Go would be the right choice for this (never used it before). It totally was. No way I would've had this level of results so quickly in C.
Being a big fan of Python and C, Go seems like a really good middle ground. Really happy to have learned it.
You nailed the idiomatic go approach to development imho. Very nice.
Performance question from a no-Go programmer though - does returning objects from functions incur a cost? For example "func Reflect() Ray {}" or "func Add() Vector" - do they create a new object on the heap? If so is that an issue in Go?
Did this last year comparing Go 1.2 with C/C++ (and lots of other languages contributed by others.)
The original version: http://kidoman.io/programming/go-getter.html
"Hello World" wasn't challenging enough for you then!
Nice work.
How does this work?
[0]https://tools.ietf.org/search/rfc1436
Question, I see you're using your own Vector and Matrix types and methods. Have you considered using an existing vector math library like mathgl [2]? Nothing wrong with your decision, I just wanted to hear your thoughts.
[1] http://gotools.org/github.com/fogleman/pt/pt
[2] http://godoc.org/github.com/go-gl/mathgl/mgl64
The only reason I'm commenting is to point it might have been easier for users if you linked to the project homepage rather than the readme file itself.
Is it your first time writing a path tracer? Because this is pretty awesome.
[1] http://www.pouet.net/prod.php?which=52938
[2] http://www.iquilezles.org/prods/index.htm