search

alecjacobson / computer-graphics-shader-pipeline

Computer Graphics Assignment about the Shader Pipeline
14 stars 23 forks source link

Problem building the assignment on VS #2

Open Reinaesaya opened 5 years ago

Reinaesaya commented 5 years ago

I can't seem to build the starter code on Visual Studio. I get the following error:

image

alecjacobson commented 5 years ago

We're not sure it's working correctly on windows, yet. Did you pull c09aaec2235d180cf3cc38085ff554a763cce69c ?

alecjacobson commented 5 years ago

(meanwhile "use cdf" is the official instruction)

psarahdactyl commented 5 years ago

These are the same build errors I had before the changes I pushed today

Reinaesaya commented 5 years ago

I pulled the latest revision around 30 minutes ago, which is c09aaec.

Reinaesaya commented 5 years ago

I tried working on CDF via NX. The project builds, but does not run, indicating a GLX version error:

image

lcapacitor commented 5 years ago

I can't seem to build the starter code on Visual Studio. I get the following error:

image

I think you can try to add "#undef near" and "#undef far" in main.cpp to disable the previously defined macros somewhere in "miniwindef.h". After doing that, I am able to build it. But, when I run "shaderpipeline ../data/test-01.json", it gives me a black screen nothing else...

alecjacobson commented 5 years ago

Oh, I thought @psarahdactyl had pushed the changes regarding near and far. They're pushed now.

Regarding CDF, please contact techsupport@teach.cs.toronto.edu if you'd like instructions about using it remotely (it's more complicated for graphics apps). Otherwise, you can go physically to a machine with a monitor.

psarahdactyl commented 5 years ago

Oh sorry, I thought I did. Oops

AkilasZ commented 5 years ago

I can confirm the black-screen being seen in VS on Windows that @lcapacitor sees. I am very disappointed to see that this avenue is also not working, and that techsupport is taking a while to respond to my ticket. Is a workaround for the black screen known?

lcapacitor commented 5 years ago

@AkilasZ My workaround is just going to the CDF lab or finding a Linux machine with GPU. VS on Windows is so annoying for this project...

alecjacobson commented 5 years ago

I'm not a windows user, so I'm having trouble debugging this. Looking over @psarahdactyl 's shoulder it seemed to be an issue reading the .json / .glsl, etc files from the given paths. It might be as simple as convincing VS to read the relative paths correctly.

AkilasZ commented 5 years ago

If it helps any, after some debugging this morning it looks like the problem might be the JSON not being read properly due to permission problems with the infile call in read_json.h

AkilasZ commented 5 years ago

That is, adding this code to read_json.h:

if( !infile ) { std::cout << "blah" << std::endl; std::cout << "---" << std::endl << filename << std::endl << "---" << std::endl; std::cerr << "Error code: " << std::strerror(errno); return false; }

Results in :

image

alecjacobson commented 5 years ago

Is there a windows way to check the permissions on the file? Is there a reason it would not be readable? (On Mac/linux I can issue ls -l test-01.json to see if I have read access.

AkilasZ commented 5 years ago

After hours of fiddling, I've gotten a very good lead after shifting the read_json call around main.cpp. It looks like there might be a problem with the last_modification.h file for Windows. Will keep looking into this

AkilasZ commented 5 years ago

Progress! I think it is because in last_modification.h, the Windows version of the function is called, which uses Windows file handles:

image

The highlighted line is me adding something to close the file handle. This would explain why we get a Permission Denied after the any_change call in main but not before -- the file is being used by some other function without being closed. I can confirm I get something now:

image

AkilasZ commented 5 years ago

However, as you will notice, I am getting different colors than the in the reference, and I also see this in the console:

image

alecjacobson commented 5 years ago

It's strange that you're not getting a more verbose error message.

There's a small chance that everything is actually OK. For the error message, you're getting infologLength must be >0 in print_shader_info_log.h. Usually this would indicate an error, but then when it tries to grab and print the log string it seems nothing substantial is in it. Maybe it's just a newline and there's no error? None of the other error messages fire, so otherwise OpenGL thinks it has successfully compiled the shaders.

If you can/know how, could you figure out what's in the infoLog string and what the positive infologLength actually is?