@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