• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
shiqiu1105

Tedious bugs in my bidirectional path tracer.

7 posts in this topic

Hi guys,

I have been trying to create my bidirectional path tracer for a long while.
But there were always bugs which I was having a hard time debugging!

The result image is down below.
My bidir path tracer generates noiser images than my path tracer when the same amount of samples are used :(

Bidir:
[img]http://www.edxgraphics.com/uploads/8/5/2/1/8521459/3031187.jpg?623[/img]
Normal path tracer:
[img]http://www.edxgraphics.com/uploads/8/5/2/1/8521459/7394597.jpg?624[/img]

Notice that not only is the bidir version noiser, they seem to converge to different colors too. Any idea how to debug?

Bidir path tracer is particularly noisy in the edges, as you can see.
Or can I put up the source code so that you guys can help?
0

Share this post


Link to post
Share on other sites
Uniformly sampled bidirectional tracer is noisier in mostly directly light situations.

On debugging: You're on the right track with the reference image comparison. Get ready for a boatload of pain though.

I really suggest you download the Intel compiler trial. It saves a lot of debugging time (as the generated code pretty much beats VC++ by 10-20% usually)

For BDPT, the weights for path configurations of a given path length must sum to 1. So, we can have any weights we want, as long as it sums to 1. Some things I would try

- render with path length = 3 only, compare uniform bdpt with reference
- render with path length = 3 only, render with 4 eye verts, 0 light verts weighted to 1,
- render with path length = 3 only, render with 3 eye verts, 1 light verts weighted to 1,

Also, I've found it extremely helpful to posterize the images in a photo editor (I use Paint.Net) and compare. It lets me see the lighting gradients very well.

Also, having a crapload of asserts is extremely helpful (check your understanding, detect undesirable nan/infs)

Also, I have some stuff in my blog when I implemented BDPT. (I have not yet written about MIS BDPT)

Here's my reference uniform BDPT code by the way
[url="https://github.com/jameszhao00/lightway/blob/master/sln/lightway/lightway/bdpt.cpp"]https://github.com/j...ghtway/bdpt.cpp[/url]

MIS BDPT (Does not handle specular / escaped ray)
[url="https://github.com/jameszhao00/lightway/blob/master/sln/lightway/lightway/bdptMIS.cpp"]https://github.com/j...way/bdptMIS.cpp[/url]

My implementation requires at least 2 eye vertices (so weights change slightly) Edited by jameszhao00
0

Share this post


Link to post
Share on other sites
I have to disagree, bi-directional path tracer should have a faster convergence, if you have smaller lightsources. They are kind of bad for light domes (IBL).
I mean, the noise is mostly visible in the in-directional areas, it shouldn't be like that. You might end up with some fire flies if you add specular surfaces, tho.

I'm not sure what your error is, but if both images converge to different result, it's clearly wrong. My wild guess would be that something is wrong with your probability calculations. check out:
http://graphics.stanford.edu/courses/cs348b-03/papers/veach-chapter10.pdf
and additionally
http://www.sjbrown.co.uk/2011/01/03/two-way-path-tracing/
1

Share this post


Link to post
Share on other sites
His implementation looks like uniform weighting (might be wrong). With standard path tracing, you have eye*-shadow-light connections, whereas in uniform BDPT you have a portion of paths requiring random hits vs the light (and higher variance). Thus, for mostly direct lighting (where eye*-shadow-light should be weighted more) uniform BDPT's increase variance should be very visible in a comparison with regular path tracing.

[quote]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]if you have smaller lightsources[/background][/left][/size][/font][/color]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)][/quote][/background][/left][/size][/font][/color]
[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][left][background=rgb(250, 251, 252)]Are you by any chance referring to MIS path tracing? where we combine brdf sampling (good for specularish surfaces) and explicit light sampling (good for small lights)?[/background][/left][/size][/font][/color]
0

Share this post


Link to post
Share on other sites
I have tried both the uniform and MIS approach. But I am not sure I calculated the path weights correctly, so I will take a look at your implementation, thanks a lot!!

I think they should converge to the same result, even with the uniform approach(it just takes a lot more samples). So color differences and noise clearly indicate there are errors.

This bug have been there for nearly 8 months, OMG..
1

Share this post


Link to post
Share on other sites
MIS BDPT weights isn't easy to get right. Understanding the bdpt implementation section in the Veach thesis and fully grasp the P(i+1)/P(i) notation (i.e. what is i? What is a path with 0 light vertex? etc) is very important.

Also, you can try summing weights of a path length and see if it gives you 1 for fully expressable paths (e.g. eye/light paths are not too short for open cornell boxes)

Also, for MIS BDPT if you're using an open cornell box it will look different unless you somehow correctly account for escaped rays. Edited by jameszhao00
0

Share this post


Link to post
Share on other sites
i am a beginner in making a bidirectional path tracer and i encounter with the same problem.
i think it is the result of geometry coupling term G or a bad weight function.
but i don't know how to solve it.
can anyone help? Edited by xieofxie
0

Share this post


Link to post
Share on other sites
[quote name='jameszhao00' timestamp='1341496372' post='4955977']
Uniformly sampled bidirectional tracer is noisier in mostly directly light situations.

On debugging: You're on the right track with the reference image comparison. Get ready for a boatload of pain though.

I really suggest you download the Intel compiler trial. It saves a lot of debugging time (as the generated code pretty much beats VC++ by 10-20% usually)

For BDPT, the weights for path configurations of a given path length must sum to 1. So, we can have any weights we want, as long as it sums to 1. Some things I would try

- render with path length = 3 only, compare uniform bdpt with reference
- render with path length = 3 only, render with 4 eye verts, 0 light verts weighted to 1,
- render with path length = 3 only, render with 3 eye verts, 1 light verts weighted to 1,

Also, I've found it extremely helpful to posterize the images in a photo editor (I use Paint.Net) and compare. It lets me see the lighting gradients very well.

Also, having a crapload of asserts is extremely helpful (check your understanding, detect undesirable nan/infs)

Also, I have some stuff in my blog when I implemented BDPT. (I have not yet written about MIS BDPT)

Here's my reference uniform BDPT code by the way
[url="https://github.com/jameszhao00/lightway/blob/master/sln/lightway/lightway/bdpt.cpp"]https://github.com/j...ghtway/bdpt.cpp[/url]

MIS BDPT (Does not handle specular / escaped ray)
[url="https://github.com/jameszhao00/lightway/blob/master/sln/lightway/lightway/bdptMIS.cpp"]https://github.com/j...way/bdptMIS.cpp[/url]

My implementation requires at least 2 eye vertices (so weights change slightly)
[/quote]

Hi I want to ask you something.

How do I weight the first eye vertex if I am using the pinhole camera (no intersectable area in the lens)?

Veach's thesis suggests we should set it to 1 / area, but in this case, we don't have area.
Should I just set the probability of the first node to 1.0?
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0