# nickelplate

Member

31

122 Neutral

• Rank
Member
1. ## Six Lessons from the "Mainstream" Software Industry

While game developers would certainly benefit from learning more about processes, I really doubt things like the CMM are the answer. See "The Immaturity of CMM" by James Bach. http://www.satisfice.com/articles/cmm.htm That GameDaily article isn't bad, but there really is nothing particularly insightful in there. And the final words at the end ... why not point to _real_ references, like books or research papers? Really lame for an article on lesssons that come from the "vast body of research into conventional software development". [Edited by - nickelplate on August 6, 2005 3:13:54 PM]
2. ## Our future with Longhorn?

Microsoft has more Win32 software, and relies on more Win32 code than any other software company. That alone almost ascertains that Longhorn will run much of Win32 software out there with little problem, imo.
3. ## Books of worth

Quote:Original post by JuNC A good book on ray tracing is 'Realistic Ray Tracing (2nd ed.)' by Peter Shirley & R. Keith Morley. Makes a nice complement to Jensens book for introductory material. There really is no substitute for scouring citeseer and google for interesting papers though ;) Indeed. There is also "Advanced Global Illumination", by Philip Dutré, Philippe Bekaert & Kavita Bala. An excellent resource for anyone who wants to learn about global illumination algorithms imo.
4. ## Photon Mapping, Need Explanations

For tone mapping, I've found that the photographic tone reproduction method developed by Reinhard, Stark and Shirley works rather well. The paper describing that algorithm is available from the following URL: Photographic Tone Reproduction for Digital Images. Look into section 3.1 titled "Initial luminance mapping". To obtain the world luminances for a pixel, I first convert the pixel values to Yxy; the world luminance is then the Y value. Y is then scaled by Ld/L, where Ld is the displayable luminance and L the scaled luminance, and the pixel is converted back to RGB. Here is my implementation (lwhite and lblack are the minimum and maximum world luminances in the image, respectively). real averageLum, lwhite, lblack; // Compute the world luminances image->ConvertToYxy(lwhite, lblack, averageLum); averageLum = exp(averageLum); real scaleFactor = m_keyValue/averageLum; lwhite *= (lwhite*scaleFactor); // Tone map the image for (uint i = 0; i < width; i++) { for (uint j = 0; j < height; j++) { Color luminance = image->GetPixel(i, j); real L = luminance[0]; luminance[0] = L * (lwhite + L) / (lwhite + lwhite*L); image->SetPixel(i, j, luminance); } } image->ConvertFromYxy();
5. ## Misc questions III - what difference do assignment operator return types make?

Q1 - It's needed to do things like this: v1 = v2 = v3; Where v1, v2 and v3 are all Vectors. To understand how the return value is used, picture the above statement as follows: v1 = (v2 = v3); // v1 takes the value returned by (v2=v3) Q4 - The return type is const to avoid using the result as an l-value. Generally you wouldn't want to do this: (v1 += v2) = v3; // would change the vector returned by += operator Edit: fixed typos.
6. ## Forum search.

It would be nice to be able to sort search results by date, number of replies and number of views (by clicking on date, replies, views respectively). Especially by date.
7. ## Passing a reference to pointer.

I see. I'm adopting a temporary solution, i.e. passing a Node* and downcasting to a SceneNode* afterwards. Everything works fine, but I will revise my design to see if I can't come with another solution not involving rtti. Thanks greatly for your input guys.
8. ## Passing a reference to pointer.

I have a problem passing a pointer by reference to a parsing function. The function prototype is: void ReadNode(Node*& nodeToRead); It basically reads a node description from a parsing stream, and allocates memory for the new node accordingly. The node is NULL in case of invalid node description. I'm using this function to parse scene nodes. The SceneNode class derives from the Node class. SceneNode* nodeToRead = NULL; ReadNode(nodeToRead); I'm getting the following error: error C2664: 'Betelgeuse::Parser::ReadNode' : cannot convert parameter 1 from 'Betelgeuse::SceneNode *' to 'Betelgeuse::Node *& ' A reference that is not to 'const' cannot be bound to a non-lvalue I get the same error when using a pointer to pointer instead. I don't understand why it doesn't work. The code compiles when I use a Node pointer instead, but keeping this change would require a rather significant change in my design. Any explanation and suggestion would be greatly appreciated.
9. ## Path tracing and indirect illumination.

I have a question regarding the computation of indirect illumination in stochastic path tracing. I'm implementing the algorithm described in "Advanced Global Illumination". The indirect paths are evaluated recursively using Russian roulette, and the recursion stops with a probability alpha, alpha being the absorption probability. Now the common value for 1-alpha is the hemispherical reflectance of the surface. The formula for this quantity is given in equation no.64 of Philip Dutré's Global Illumination Compendium. Now how do I go at estimating the numerator in said formula, i.e.: integrate over hemisphere of outgoing direction { integrate over hemisphere of incoming direction { brdf(in,out) * cos_theta_in * cos_theta_out } } I'm not sure how I should do it, since the brdf isn't necessarily constant. With a constant brdf, as in the case of lambertian surfaces, I would obtain a reflectance of brdf*pi. Also, what other choices of values for the absorption probability would be acceptable? Thanks, ::Nickel::
10. ## Need help with Random Number Generator.

Download the paper titled "Improving noise" on Perlin's noise page. A reference implementation is featured on that page as well, but I would suggest reading the paper first before using that implementation in your code.
11. ## new[]/delete[] overload (warning C4291).

Thanks for your input, RenderTarget. The operator new[] is used in only one method in the class, originally as follows. if(alloc) in=new(FFTW) Complex[size]; I rewrote that line like this: if(alloc) in = (Complex*)(operator new [](size, FFTW)); I don't get the warning anymore, though I'm wondering if there is no "standard" way of achieving the same result, as it's not very common to call new[] the way I did. Thanks again, nickelplate.
12. ## new[]/delete[] overload (warning C4291).

Hi, I'm using the fftw++ header class for the fftw3 fast Fourier transform library in a pet project. When I include the fftw++.h header file in my code, I get the following warning: warning C4291: no matching operator delete found; memory will not be freed if initialization throws an exception The fftw++ header overloads operators new[] and delete[], like this: inline void *operator new [](size_t size, Complex) { size_t offset=sizeof(Complex)-(size % sizeof(Complex)); void *p=fftw_malloc(size+offset); p=(char *) p+offset; if(size && !p) cerr << endl << "Memory limits exceeded" << endl; return p; } inline void operator delete [] (void *p, Complex, size_t size) { for(size_t i=size-1; i != (size_t) -1; i--) ((Complex *) p).~Complex(); p=(char *) p-sizeof(Complex); fftw_free(p); } It seems I have to rewrite operator delete[], I tried interchanging the parameters Complex and size_t to make them match the declaration of operator new[], i.e. void operator delete[](void *p, size_t, Complex) but it didn't solve the problem. I would like to get rid of this warning without disabling it by using a #pragma directive. I'm using Visual Studio .NET 2003. Any input would be appreciated.