|
PDP-1 posted:I got my terrain renderer running with adjustable level of detail (LOD). Its set up right now to adjust details much closer to the camera than normal and to draw in greyscale so that the LOD switches are easier to see for debugging. The changes in detail 'pop' a lot less on more normal settings. Cool stuff, I'm thinking of writing a terrain renderer as well. What kind of technique are you using for your LOD?
|
| # ¿ Jun 3, 2010 17:50 |
|
|
|
| # ¿ May 18, 2013 17:27 |
|
|
 Just your normal raytracer.
|
| # ¿ Aug 29, 2010 15:03 |
|
|
Seawaffle posted:This looks nice and crisp as opposed to the terrible crap that spews out when I write a raytracer. What's the secret? The 2 guys after you had it right. I used supersampling (http://en.wikipedia.org/wiki/Supersampling) with 4 samples per pixel for that render. The basic idea is to cast more than one primary ray per pixel and calculate an average from the results to form the final color for the pixel. How you choose to calculate the direction of the sub pixel rays is up to you. I took the laziest way out and distributed the sample points by using a uniform grid. The grid doesn't provide the best results (jittering would be better I think) but it's really trivial to implement. Edit: I just remembered I did also scale it down with Photoshop because the original render is too wide to post  However, the aliasing is not noticeable in the original either.
Foiltha fucked around with this message at Aug 30, 2010 around 05:46 |
| # ¿ Aug 30, 2010 04:58 |
|
|
 Been working on my raytracer a bit more. The rendered scene consists of around a 105,000 triangles with 2 bounces for reflections. Without supersampling it took about 16 seconds to render at 1280x800 and with 4x supersampling you can multiply that by 4. So it's really not all that fast, but it's just a hobby for me so I'm pretty satisfied with it. I wrote a bounding volume hierarchy that encloses all the triangles in a AABB tree, which really makes all the difference when you want to start rendering meshes. Without some sort of acceleration structure (BVH, KD tree etc) it's really, really painful to render anything over a thousand triangles. If anyone cares, the BVH took about 700 ms to build. I should probably write a neat little GUI with QT to make it easier to create scenes and modify rendering variables but I've been pretty burnt out due to university work. I'm probably gonna implement something not-as-critical like raycasting based ambient occlusion (which means reading about Monte Carlo methods which I'm not familiar with) before I get around to making the actually useful GUI or multihreading the trace algorithm because that's how I roll 
Foiltha fucked around with this message at Sep 19, 2010 around 16:23 |
| # ¿ Sep 19, 2010 13:17 |
|
|
Zakalwe posted:Awesome advice about speedups. Great advice, thanks. I'm not really that well versed in ray tracing or computer graphics for that matter and this is actually my first raytracer, so all advice is welcome. I'm not really aiming for real time performance, but speed is always nice. Packet tracing is basically based on utilizing SSE calculations for ray packet intersections and traversals, right? I have never done anything with SSE so implementing all that might be a bit too hard for me, but I might look into it after I've actually got a decent non-RT raytracer working. Any good papers/sites about SSE in packet tracing or just SSE in vector calculations in general? As you seem to have guessed, I'm using a naive median split as my construction heuristic. I've only glanced at other heuristics but SAH seems to be the most popular choice and I'm most likely going to implement it when I have the chance to actually study it. Thanks for the thread advice is well. Threads and SAH (or some other heuristic other than the median split) are probably the two things I'm gonna implement as soon as I have the time. Packet tracing is probably going to have wait for a while or a really, really long while. Converting my calculations to SSE might be a bit painful as I have no SSE skills
|
| # ¿ Sep 20, 2010 12:50 |
|
|
clockwork automaton posted:I started using Qt because initially I was told "okay, this is going to be cross platform" -- but then later I was told "okay, actually this is going to just be windows" and Qt runs slow as hell on windows machines (esp. if you have an embedded OpenGL window like I do). Care to provide any benchmarks? I've never heard about Qt being slow on Windows. Even massive industry applications like Maya are using Qt these days and I really doubt they'd do that if it was slow as hell.
|
| # ¿ Dec 6, 2010 06:40 |
|
|
 C++, OpenMP for multithreading shenanigans and Qt for the GUI. I'm drowning in university work so I haven't had time to work on this ray tracer as much as I'd like. The ambient occlusion is really crude, the supersampling method is just a silly uniform grid, shadows are turned off and there's a gazillion other things I'd like to work on. Ah well, hopefully I'll have some time to work on it in a couple months.
|
| # ¿ Mar 14, 2011 12:50 |
|
|
I really, really want to use that.
|
| # ¿ Aug 16, 2011 17:08 |
|
|
UraniumAnchor posted:Yeah, yeah, babby's first raytracer, but I wrote the core in python and then turned the matrix math into a C module (making it about 10x faster), so it's a learning experience for multiple reasons. What sort of render times are you getting for the teapot scene? If you're brute-forcing the intersection tests (i.e. testing each ray for intersection with each polygon), you should look into bounding volume hierarchies or k-d trees. They make a huge difference in scenes with more than a few polygons/primitives.
|
| # ¿ Dec 7, 2011 13:14 |
|
|
Azazel posted:
How are you handling simultaneous development for both platforms? Are you using something like Unity?
|
| # ¿ Jan 14, 2012 09:06 |
|
|
That looks so good. My silly Whitted ray tracer with ambient occlusion looks like crap in comparison 
|
| # ¿ Mar 10, 2012 07:50 |
|
|
Gordon Cole posted:Most if it should be pretty straightforward except for Guitar Pro, reverse engineering that file format isn't going to be fun. You should probably look into the source of TuxGuitar. It seems to support Guitar Pro files: http://sourceforge.net/projects/tuxguitar/
|
| # ¿ Apr 16, 2012 05:51 |
|
|
geera posted:Overview dashboard I've been working on to put up on a TV I want to mount in our IT area. Everything is loaded via AJAX from a Python/Flask server that I wrote to collect the data from random sources on the network. Neat! I've been using Flask a lot lately and it's fantastic for stuff like this. What are you using for the charts?
|
| # ¿ Mar 19, 2013 16:06 |
|
|
|
| # ¿ May 18, 2013 17:27 |
|
|
mobby_6kl posted:... rolled my own multi threading instead of using OpenMp, this time it actually it almost quartered the time instead of increasing it I'm sort of curious what went wrong here. I think for my old ray tracer I just added a single #pragma omp parallel for and my rendering time got quartered. Anyhow, if you're looking to add a neat little feature to your ray tracer before tackling tree structures, I'd recommend adding supersampling to reduce jaggies. Basically you just create multiple rays for each pixel: http://en.wikipedia.org/wiki/Supersampling. It's really simple to implement and makes the renders look a lot neater!
|
| # ¿ May 4, 2013 17:18 |
|
...
