[examples] proposal and discussion of fixed-function (i.e. GRAPHICS_API_OPENGL_11) visualization example

[meisei4]

This example i hope to propose to have discussion regarding usefulness for teaching/exposing raylib learners to the ability of raylib compatability with the non-programmable fixed function graphics subset (GRAPHICS_API_OPENGL_11). The example serves both as a demo of non programmable set up, but also doubles as a visualizer that is intended to help intuit the fundamental concepts of the fixed function stages themself.

Resources that helped guide me for this this example so far:

• https://en.wikipedia.org/wiki/Fixed-function_(computer_graphics)
• https://en.wikipedia.org/wiki/Texture_mapping#Perspective_correctness
• Etay Meiri (OGLDEV) Perspective Projection Tutorial
• Keenan Crane Computer Graphics (CMU 15-462/662)

Visuals:

knot_h264_10mb.mp4

cube.mp4

sphere_h264_10mb.mp4

[JeffM2501]

This is more than an example, you have changes to rModels.c..... are they required for this to work? If so they should be addressed in a separate PR that describes what the changes are and what they do.

As for the example, it is very cool, but also quite large and complex, it may be overload for a new user.

[raysan5]

@meisei4 Despite being super-cool, this example is quite big for raylib examples, usually examples stay under 200-300 locs... Also, why rmodels requires some modifications, are those modifications specific of PS2?

Let's me check the example more carefully and see if it can bee simplified...

[meisei4]

Thanks for the initial responses! I will try to clean up the PR specifically, i had planned to get the rmodels.c changes in before, they are needed for some behavior i was testing with raylib4Consoles and ps2, but they are also important for some of texture and color behavior that i test in this example/demo (although i think they need review design-wise because some of it still doesnt sit right with me, i will make a PR for that)

Also @raysan5 i do have plans to take some chunks out of here for core_3d_camera_view (the one mentioned in #5209), but i also think that if this example can be restructured perhaps, its one that i really wished existed when i first heard about raylib's ability to target older graphics pipelines.

Also I feel like there should at least be some examples that for directly targetting opengl11 as i think many people might benefit from learning what potential that provides and why its so special (I often see many questions on discord where i don't think people know what its intended for, let alone how how it even works) and now with the software renderer i think it could also be good timing/justification for such

[meisei4]

I have added Orthographic camera toggle and will now be splitting this PR into two separates (annotated later):

1. fixes to OPENGL11 DrawMesh and LoadmModel behavior with texcoord strictness
2. reducing this demo to be for core_3d_camera_view (removing majority of the complexity -> ~250 LOC)

I will likely close this ticket once those are made, and then move this "demo" to a proposal for raylib-extras I hope

[raysan5]

@meisei4 this example should definitely be simplified for merging into raylib but, please, keep the original one in some repo or add it to raylib-extras, it is definitely useful for education!

[meisei4]

I have begun decomposing the example into a single example, where only orthographic an perspective view is shown.

I am having trouble trimming down the LOC for the opengl33 case in specific due to some things i am uncertain on how to achieve via opengl33 without these simple shaders.

Also i am still probably using Meshes too much rather than simpler things like direct draws (i.e. for the frustum wires), and render texture to a plane/rect rather than trying to continue using the placeholder meshes -- but still trying to match at least a bridging style between opengl11 and 33

My brain is really stuck between opengl11 and opengl33 usages. I imagine this would be simple to just redesign everything with only opengl33 in mind or just use wire frames for the target meshes -- but i am also still trying to learn from this aswell. I wonder if we could just allow for GenMesh functions to also be "dynamic" uploadable rather than purely static uploads, like a flag in the function parameters to choose from when calling any of the stock GenMesh functions

I will need to think about what is still needed to be reduced

[raysan5]

@meisei4 No worries, I can help with the review but it's a big example and I need time, at least some weeks to jump into it...

[meisei4]

@raysan5 I understand, I have reduced the LOC i think drastically for the opengl33 version where now its much simpler but with much less visual features, i imagine this is fine perhaps? although it removes alot of the things i was experimenting with, but I think that with this example and then a kind of link to the more verbose examples including how it works in opengl11 and then the full verbose "demo" (now including OPENGL11 and 33 gating for side by side demonstration), being in raylib-extras it could maybe be ok to just call it finalized here?

FINAL: https://github.com/raysan5/raylib/blob/41c9975118c7e1065ff9311f62904bc557898188/examples/core/core_3d_camera_view.c

-- only wire frames, no colors, no mesh for the frustum, no aspect, etc etc, lots of things removed, only visualizing the ortho verse perspective camera

I still think it could use a review of course, and then i could perhaps make a new ticket to just merge the opengl33 version only? I am open to anything, i do want to respect your time🙇‍♂️, and i also think i have spent maybe too much time on this, and i am hoping to move on to other investigations with audio study, and raylib rust bindings (where i actually have this exact same demo rewritten to use the rust bindings)

[meisei4]

@JeffM2501 I was wondering what you think would be the next steps for me to try to request merge into raylib-extras? I would mainly be wanting to merge the full demo (now with opengl33 and opengl11 gating side by side: https://github.com/raysan5/raylib/blob/41c9975118c7e1065ff9311f62904bc557898188/examples/core/core_3d_fixed_function_didactic.c) Do you think this is ok?