# moagstar

Member

256

263 Neutral

• Rank
Member
1. ## SH Lighting: Image looks too dark

It depends on the coordinate system you project in, so you're Y may be inverted - if it's completly dark with -1.0f for the direction then put it back to 1.0f. What order sh were you using in the original image? - Remember the lower the order the less light - You could try a higher order to get some more of the high frequency lighting in there. The reference images in Green's article are using 5th order SH. Again, inter-reflection will add more light in. I'm not sure that the incident lighting calculation you are using is particularly good either, you basically have a huge area light, with a cosine falloff towards zero at the bottom so only one of the samples you are taking is at full intensity - Look at page 15 and page 44 of green's article for a better lighting function.
2. ## SH Lighting: Image looks too dark

Apologies, my eyes are rubbish ;) It is the similarity in colour that made me think the two objects were lying in the same plane! I think the problem comes from the fact that the you're light direction is incorrect, try inverting the y so that the light is travelling toward the plane from above. You can tell pretty much where most of you're light is coming from by looking at the first three linear coefficients i.e. in your case : Coefficient 1: -1.23085 -1.23085 -1.23085 Coefficient 2: 0.000889914 0.000889914 0.000889914 Coefficient 3: 0.00193114 0.00193114 0.00193114 Coefficient 1 (1,-1) is roughly equivalent to a direction of negative y Coefficient 2 (1, 0) is roughly equivalent to a direction of positive z Coefficient 3 (1, 1) is roughly equivalent to a direction of negative x So looking at those three coefficients for incident lighting you can tell pretty much which direction most of the light is coming from, this should help you debug alot of lighting problems. So what you have is a negative y component of -1 so the light is travelling mainly in the positive y direction (outwards - away from your model). I think if you negate the y direction of you're light it should look a bit brighter. HTH
3. ## SH Lighting: Image looks too dark

There are several things that could be causing this, how are you calculating incident lighting? The surface albedo may be 1.0f, but if you are using low intensity lighting then you will get dark surfaces. Another thing to remember from the reference images that they are including indirect lighting, which will account for some of the illumination on surfaces, with a single plane you naturally will not get any of this illumination. Try 3 planes togethor. So you might want to check these, but looking at the image, if you have a single directional light coming from above, then you should see that the plane gets lighter in this area, which is the opposite of what you are seeing, so perhaps you're lighting coefficients are incorrect? EDIT : Could you post the method you are using to calculate the lighting and the first 9 coefficients of you're lighting?
4. ## DLL Memory leak

If you could paste the code where you allocate and write to the char buffer then it may be easier to see where the problem is.
5. ## My executable's Dependencies (DLLs)

Does anyone have any idea how these 'Dependancy Checking' programs work? It would be useful to write a custom command line tool that checked for dll dependancies and copied to a specified location, that way it could be incorporated as part of the build process (plus I'm curious ;) I imagine it must spawn the exe process and hook into the dll loading routine somehow. Any ideas?
6. ## My executable's Dependencies (DLLs)

If you create a setup project it should detect the dependencies for you, however I just tried a simple test and it didn't detect the depend .dlls for me :( I found this freeware app which will detect dependencies for you : Dependency Checker
7. ## DLL Memory leak

That sounds very fishy indeed looking at your code, sizeof(TextToSpeech) should be 10 (2 pointers + 2 bools) It sounds to me that you are allocating a buffer somewhere which will receive the string of characters, and then the string that you are reading in is exceeding the size of the buffer. Where do you allocate memory for char *cTextFileAscii? I'd be willing to be this is the memory that is getting trampled. Do you delete the memory allocated for cTextFileAscii in your destructor? Check that you are setting the pointer to NULL after you have deleted it, and when you write into cTextFileAscii, ensure that you never write more than you have allocated.
8. ## DLL Memory leak

The reason why my original code sample was causing an exception is because I was deliberatly trampling the memory (i.e. writing passed the allocated memory) you can see I allocated 4 chars, but copied over 15 chars, overwriting 9 bytes of memory, so when deleting that pointer the memory footer had been trampled, which causes an error in _crtIsVaildHeapPointer(); So it could be possible that you are trampling the memory (i.e. writing past the allocation). You can rule this out using data breakpoints on your end of your dynamically allocated data to find out when the footer is being trampled. The virtual destructor is only important when you are using a heirarchy of classes.
9. ## DLL Memory leak

Ah, yes, you need __declspec(import), as a suggestion use the same header file for the class and select __declspec(import) or __declspec(export) depending on a hash define, it will become tiresome updating two headers. You can put the specifier on the class rather than per-function (see the code example from before)
10. ## DLL Memory leak

Although you need to ensure that you are using the correct build options, this still sounds like a memory trampling bug, something along the lines of : In your DLL... #ifdef IMPORT class __declspec(dllimport) CSomeClass #else class __declspec(dllexport) CSomeClass #endif { public: char *someData; CSomeClass(); virtual ~CSomeClass(); }; CSomeClass::CSomeClass() { someData = new char[4]; } CSomeClass::~CSomeClass() { delete [] someData; } In your EXE... #define IMPORT #include "../DLL Test/SomeClass.h" INT WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, INT) { const char name[] = "DLL Testing App"; CSomeClass *instance = new CSomeClass; memcpy(instance->someData, name, sizeof(name)); delete instance; _CrtDumpMemoryLeaks(); return 0; } The situation here will definatly cause a exception in _crtIsValidHeapPointer(), is this at all similar to what you are trying to do? Perhaps you could post some code?
11. ## LNK2001 build errors with DirectSound

Looks like you need to link with dxguid.lib and dsound.lib

13. ## DLL Memory leak

This sounds like a memory trashing problem, where something is overwriting past the size of your dynamically allocated memory. An easy way to debug this is to put a data breakpoint on the memory location : basePtr + sizeof(DataType) Where basePtr is the pointer returned from new. The program will break when the memory at that location is written to, i.e. where it is getting overwritten and should show you where you are causing the problem.
14. ## there is no d3dx8.lib, but still looking for it?

Which version of DirectX are you using? If you are using DX9 you should be linking with d3dx9.lib not d3dx8.lib DON'T rename them!
15. ## beginner's question about simple directx

If you look at the DirectX documentation, there are some simple step - by - step tutorials on getting a basic window up and running, which are a good start for beginners, DirectX Graphics -> Tutorials and Samples -> Tutorials -> Direct3D Tutorials. If you are struggling to get to grips with DirectX a good start might be to take a look at GLUT it's very simple, and easy to get something up and running. Alternatively the nehe tutorials are also very useful for OpenGL programming