0
$\begingroup$

You can enclose arbitrary amount of vertices within glBegin/glEnd statements. Does OpenGL limit the number of vertices you create or it allocates memory for more?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
1
$\begingroup$

OpenGL implementations aren't assumed to have unlimited memory, but the specification imposes no specific restrictions on this. That is, you can't ask how many vertices you can send. Instead, if you trip some limit, you'll get a GL_OUT_OF_MEMORY error and rendering will fail.

But in 2023... you're really should not care. If you're using old compatibility APIs from 1992, then you probably aren't going to be sending enough vertices to trip any limits from any card that was made after the year 2000. So this is basically sophistry.

Improve this answer
$\endgroup$
12
  • 3
    $\begingroup$ @MaximMogulev: Please don't write a software renderer in the style of a 3-decades-old graphics API. Make the user give you sequences of vertex data as arrays. That will make your consuming code way faster and will eliminate the question, since they are in control of how much memory is allocated. $\endgroup$
    – Nicol Bolas
    Commented Feb 27, 2023 at 18:52
  • 1
    $\begingroup$ @MaximMogulev No, it's really not convenient for anything or anyone. Not for you developing the API nor for anyone using it, be it even for simple test cases like a cube or a triangle. What does anyone who ever wants to render something have? Yes, a list of vertices at least. And that's what you want to render. Noone wants to use Begin/End, neither did anyone 30 years ago. I got an array of vertices, render me an array of vertices. It really makes everyone's life easier. The only reason to do it like GL did 30 years ago is nostalgia. If that's your reason, okay, but "convenience" isn't one $\endgroup$
    – Christian Rau
    Commented Mar 4, 2023 at 0:27
  • 1
    $\begingroup$ @MaximMogulev: "The modern API demands to use buffer objects." But he didn't say anything about buffer objects; he said "arrays". Users should be able to allocate arrays for vertex data and pass them into your software renderer. That's the point: not making a function call for each attribute of a vertex. If they want to change some data, they can just change it in their array. Note that you could do this even in GL 1.1. $\endgroup$
    – Nicol Bolas
    Commented Mar 4, 2023 at 17:03
  • 1
    $\begingroup$ @MaximMogulev: "I really want but still can't understand why people prefer doing..." Because all of that stuff is 1) extremely slow, 2) requires way too much effort for anything semi-complex, and 3) has limited flexibility. This stuff is useful for new developers at best, and even then, I would argue that learning to use buffer objects, shaders, and the like is way better in the long-run than using a child-like API that you will eventually have to ditch if you want to do something vaguely real anyway. $\endgroup$
    – Nicol Bolas
    Commented Mar 4, 2023 at 17:13
  • 1
    $\begingroup$ First of all, noone says you have to implement VBOs or anything like that. That's the beauty of a software renderer, just take an array from the user and render that, why emulate GL at all? Implementing Begin/End is a ton more hassle, for something that is then clunky to use. And second, I actually do think modern GL is easier and simpler and definitely less code because you only need to actually care about what you use. Simple shaders are basically one-liners with almost no uniforms. But that's beside the point of Begin/End just not making sense for an API that processes a bunch of things. $\endgroup$
    – Christian Rau
    Commented Mar 6, 2023 at 8:27