You should probably share your machine specs at this point as I was unable to repro on Intel macOS, latest Ventura (teapot loads fine).
1 Like
I was running it on Intel macOs Monterey.
Just updated to Ventura 13.4 and now I am getting this:
Still no teapot.
My mistake, I was checking it in the DemoRunner, not the stand-alone tutorial. Maybe you should try the DemoRunner to see if that works (it’s in the extras folder)?
1 Like
If your second screenshot is from the OpenGL tutorial, I think that’s supposed to be the result. There is no texture mapping applied to the teapot as there is in the DemoRunner example.
1 Like
Both screenshots are from DemoRunner unfortunately. The second screenshot is from OpenGLAppDemo.h.
Great, with that info I was able to repro your issue. I am not on latest Monterrey so I will try again with latest, and if I can repro again, we could perhaps then try and spot the issue. I get these errors in my console in 12.6.3:
**2023-05-29 11:25:36.613620-0700 OpenGLAppTutorial[26663:416562] fopen failed for data file: errno = 2 (No such file or directory)**
**2023-05-29 11:25:36.613739-0700 OpenGLAppTutorial[26663:416562] Errors found! Invalidating cache...**
**2023-05-29 11:25:36.674242-0700 OpenGLAppTutorial[26663:416562] fopen failed for data file: errno = 2 (No such file or directory)**
**2023-05-29 11:25:36.674305-0700 OpenGLAppTutorial[26663:416562] Errors found! Invalidating cache...**
**2023-05-29 11:25:46.541221-0700 OpenGLAppTutorial[26663:416561] Persistent UI failed to open file file:///Users/<username>/Library/Saved%20Application%20State/com.JUCE.OpenGLAppTutorial.savedState/window_7.data: No such file or directory (2)**
I also got this warning in Xcode:
This warning appears to be a non-issue according to: UI API called from background thread, however @reuk’s fix does not touch the part of the class where this warning is emitted:
Update: I’m whittling it down, the issue persists on latest Monterrey but I don’t have the issue on Catalina with JUCE 7.0.2 and 7.0.5. I’ll try once more with latest JUCE on Ventura.
@TPeters do you have a mac that cannot update beyond Monterrey like a mid-2015 MacBook Pro or similar?
1 Like
@kcoul I have an iMac that can’t be updated beyond Big Sur. But, it doesn’t allow me to install Xcode, which makes it useless in reproducing the issue I’m experiencing.
Ok I definitely empathize as I have more and more macs that are stuck on various versions of macOS now due to things that got left in the dust, mostly soundcard control panels stuck in the 32-bit era.
One other question before I poke at Ventura a bit more - is there any reason you can’t base what you’re doing on the DemoRunner version of the OpenGL example instead? This issue is most likely to be some technical “gotcha” (that I’m curious about) than whether Monterrey (or Big Sur) can fundamentally draw the teapot in OpenGL.
So you might just want to base your work on the DemoRunner version instead…? Perhaps by porting code from it bit by bit into an empty JUCE Application if you want that starting point?
1 Like
Yes, I could definitely give that a try. I just expected the tutorial project to work as is and was hoping to sort of follow along. Thank you @kcoul )
No problem, I’ll let you know if I discover anything else!
1 Like
let’s see if the problem is in the teapot.
declare a buffer (memory that the graphic card will use to store the vertices)
GLuint vertexVBO = 0;
creates and loads the buffer in initialise() with a triangle
juce::gl::glGenBuffers(1, &vertexVBO);
juce::gl::glBindBuffer(juce::gl::GL_ARRAY_BUFFER, vertexVBO);
Vertex vertex[3] = { { -1,-0.5,0, 0,0,0, 1,0,0,1, 0,0 }, { 1,-0.5,0, 0,0,0, 0,1,0,1, 0,0 }, { 0,1,0, 0,0,0, 0,0,1,1, 0,0 } };
juce::gl::glBufferData(juce::gl::GL_ARRAY_BUFFER, (GLsizeiptr)3 * sizeof(Vertex), vertex, juce::gl::GL_STATIC_DRAW);
draw the triangle by replacing shape->draw(*attributes);
glBindBuffer(juce::gl::GL_ARRAY_BUFFER, vertexVBO);
attributes->enable();
glDrawArrays(GL_TRIANGLES, 0, 3);
attributes->disable();
to see the colors it is necessary to replace in the shader the color orange by the color of the vertices
vec4 color = destinationColour;
1 Like
opengl is working then, the problem may be in the resource file, check if the file “wasOk” and if the file paths are correct
Shape()
{
auto dir = juce::File::getCurrentWorkingDirectory();
int numTries = 0;
while (! dir.getChildFile ("Resources").exists() && numTries++ < 15)
dir = dir.getParentDirectory();
if (shapeFile.load (dir.getChildFile ("Resources").getChildFile ("teapot.obj")).wasOk())
for (auto* s : shapeFile.shapes)
vertexBuffers.add (new VertexBuffer (*s));
}
2 Likes
Thank you @Marcusonic!
Yes, something seems off regarding the file path. The line ‘dir = dir.getParentDirectory();’ executes 15 times, yet the subsequent ‘if’ block does not run. The teapot file doesn’t “existsAsFile”.
Shape()
{
auto dir = juce::File::getCurrentWorkingDirectory();
int numTries = 0;
while (! dir.getChildFile ("Resources").exists() && numTries++ < 15)
dir = dir.getParentDirectory(); // this line runs 15 times
if (shapeFile.load (dir.getChildFile ("Resources").getChildFile ("teapot.obj")).wasOk())
for (auto* s : shapeFile.shapes) // this block doesn't execute
vertexBuffers.add (new VertexBuffer (*s));
}
Here’s what my file tree looks like.
I’m probably missing something—if you could point me in the right direction, I would appreciate it.
When your app is run, the “current” directory is probably not pointing to your “OpenGLAppTutorial” folder.
1 Like
Thank you @reFX !
Currently, I am puzzled as to why juce::File::getCurrentWorkingDirectory().getChildFile ("Resources"); returns the path name of /, and not /Resources. Could you please clarify this for me?
with auto dir = juce::File::getCurrentWorkingDirectory(); I get the complete path to the working directory, which is the same as the project folder. This path is the one set in the visual studio options for the working directory $(ProjectDir)
2 Likes
This was it!: 
Thank you, everyone, for you comments! 
1 Like
If it helps, here we had also rendering problems when updating to macOS 13.4
1 Like