raylib 2022 wishlist!

[raysan5]

Here it is a small wishlist with some of the improvements I'd like to see in raylib in the future.

raylib has grown A LOT in the last few years and maintenance is getting complicated. For this year 2022 I'd like to focus efforts on library stability between platforms, some small improvements and a better testing of available features. I'll try to avoid new features as much as possible, specially if they are big additions and involve critical parts of the library.

Here it is my personal wishlist divided by modules:

module: rcore

• REDESIGN: Module subdivision. This module has grown a lot with every new supported platform (~7000 loc), at some point it could be divided into separate modules. Actually, this is not expected to be implemented at this moment but I take note here for the future. Two possible approaches:

  • Divide by platform:
    • rcore_desktop.c - PLATFORM_DESKTOP (Windows, Linux, macOS)
    • rcore_android.c - PLATFORM_ANDROID
    • rcore_native.c - PLATFORM_DRM/PLATFORM_RPI
    • rcore_web.c - PLATFORM_WEB
  • Divide by technology
    • rcore_glfw.c - GLFW library based
    • rcore_sdl.c - SDL library based
    • rcore_native.c - Native implementation

• ✔️ REVIEW: Update GLFW to latest version. PLATFORM_DESKTOP uses GLFW library for window and inputs functionality, the library is amalgamated into a single compile-unit as rglfw.c. Latest changes to GLFW require a review of rglfw.c inclusions.

• ADDITION: Support SDL library backend. SDL library is an alternative to GLFW, it's a bit bigger than GLFW and provides some additional functionality probably not required by raylib but it could be nice to support it as an alternative backend (only the main library, not the auxiliar ones).

• ✔️ REVIEW: PLATFORM_DRM. With latest RPI OS Bullseye, Dispmanx-based solution for native (headless) rendering on Rapsberry Pi has been removed. raylib uses Dispmanx on PLATFORM_RPI implementation, now it becomes deprecated and the alternative PLATFORM_DRM implementation should be used. I got no plans to remove PLATFORM_RPI for the moment because it still works with RPI OS Legacy (Buster-based) but some efforts to improve the PLATFORM_DRM implementation are required, it has not been tested enough and some issues with display initialization were reported. It requires more testing. [core] Issues running in native mode with PLATFORM_DRM in Bullseye in RPI Zero W #2439

• ✔️ REVIEW: File-path access functionality. I miss some functions to the file-path access API provided by raylib, like recursive directory files scan of filtered by type file scan. Also API consistency/naming should be reviewed.

• ✔️ REVIEW: Load/Unload functions name consistency. Usually, functions that allocate memory in some way start with Load*() and have an Unload*() equivalent (there are some exceptions: Gen*(), Image*(), Text*()). Also, functions that operate over internal static variables or return a direct value use Get*() or Set*() convention. Some functions do not follow that rule and should be reviewed. This is an API-breaking change so I'd like to think about it carefully before changing the API.

  • ✔️ GetDirectoryFiles()/ClearDirectoryFiles() -> LoadDirectoryFileset()/UnloadDirectoryFileset()
  • ✔️ GetDroppedFiles()/ClearDroppedFiles() -> LoadDroppedFilepaths()/UnloadDroppedFilepaths()
  • ❌ SaveStorageValue()/LoadStorageValue() -> REMOVED! (Moved to example)
  • ❌ LoadVrStereoConfig()/UnloadVrStereoConfig() -> Currently they just use values, no memory is allocated.

• ✔️ REVIEW: Fullscreen modes (specially on PLATFORM_WEB). Fullscreen is a very complex world, specially on web, there are many possible strategies to scale content to fullscreen. Reviewing all the possible options and supporting them in some way is really difficult and requires a lot of work.

module: rlgl

• ✔️ REVIEW: OpenGL 4.3 functionality mapping. rlgl implements an abstraction API over OpenGL to simplify usage and expose only the required functionality. Recently some OpenGL 4.3 functionality was added but the functions map directly to OpenGL equivalents, not sure if that is abstracted enough in case it had to be ported to other graphic APIs. It's something I'd like to review more carefully.
• ❌ ADDITION: Support more texture pixel formats. Pixel format support is a bit limited, some additional formats could be added to the list, specially the 16bit per channel ones.

module: rshapes

• ✔️ REDESIGN: Support standalone usage. This module is coupled to rlgl but considering it's only intended to define shapes and fill vertex data buffers, it could be converted into a completely portable module to be used with any library/engine that supports vertex buffers (mostly any modern library/engine). Some functions that need to be reviewed/removed:
  • ❌ REVIEW: rlSetTexture() and rlTexCoord*() -> Do we need texture-mapping for basic shapes? Yes, keeping them for now.
  • ✔️ REMOVE: rlCheckRenderBatchLimit() -> That check should be internal to rlgl when accumulating the vertex data to the buffers. Actually it's required to define the size required for the data provided and check if the buffer overflows, so a draw call is issued and a new buffer is started.
  • ✔️ REVIEW: rlgl stack mechanism usage: rlPushMatrix()/rlPopMatrix(). Vertex transformations are managed internally by rlgl using a stack system similar to OpenGL 1.1. If rshapes is intended to be used standalone, with any other graphic backend, transformations should be applied in the module and the transformed vertex should be send to the buffer. So the buffer system required could be very simple and processed by any API.

module: rtextures

• ✔️ REDESIGN: Move image formats loaders to external files. Currently some image format loaders (compressed textures) are implemented inside the module, those functions could be moved to an external single-file header-only library, so, expendable and shareable code is not contained inside the textures module. The involved functions are:

  • LoadDDS()
  • LoadPKM()
  • LoadKTX()/SaveKTX()
  • LoadPVR()
  • LoadASTC()

• ✔️ REVIEW: Possible functions out-of-scope. Some functions could be out-of-scope for raylib, exposing a functionality that actually belongs to a higher-level library/engine. Possible functions to review:

  • ✔️ REMOVED: DrawTextureQuad() -> Is tiling parameter really required?
  • ✔️ REMOVED: DrawTextureTiled() -> It draws texture n times to accomplish the tiling effect... -> Moved to example!
  • ❌ DrawTextureNPatch() -> NPatch is very useful but it seems to belong to a higher level engine...
  • ✔️ REMOVED: DrawTexturePoly() -> Do we really need this? rlgl exposes more functionality in a similar way... -> Moved to example!

• ❌ ADDITION: Support 16bit/32bit per channel on Image drawing. Only 8 bit per channel images are supported at this moment, it could be improved. Related issue: [textures] ImageDraw() and ExportImage() (.png) does not support f32bit per channel image data #2222

module: rtext

• ✔️ REVIEW: Improve codepoints functionality. The API to deal with Unicode codepoints instead of text-bytes is a bit limited and it feels a bit inconsistent, it requires some review and maybe add some new function.
• ✔️ REVIEW: Text management functionality. I'd like to review the Text*() functions API in case of missing functions or inconsistencies. Also note that some functions load memory that must be managed by the user.
• REVIEW: External libraries warnings. Some of the external libraries used generate warning on compilation, those warnings should be reviewed and the improvements sent to original authors. Most notable case is stb_truetype because most of the exposed advance API is not used by raylib.

module: rmodels

• ✔️ ADDITION: Support M3D file format, including animations.
• ✔️ ADDITION: Support glTF animations. That functionality was broken and removed from raylib 4.0. I'm considering adding it again but this time it would require better testing and better maintainability. One first approach could be adding it as an example.
• REVIEW: Improve obj loader. Current obj-loading library has some limitations and issues. I'm considering an alternative or a custom implementation. Related issue: [models] Window hangs when loading certain obj files #2219 (comment)
• ✔️ REVIEW: Possible functions out-of-scope. Some functions could be out-of-scope for raylib, exposing a functionality that actually belongs to a higher-level library/engine. Possible functions to review:
  • DrawBillboardPro()
  • ✔️ REMOVED: DrawCubeTextureRec() -> Moved to a separate example: models_draw_cube_texture.c
  • ✔️ REMOVED: UnloadModelKeepMeshes()

module: raudio

• ✔️ REVIEW: Update to latest miniaudio. A new release of miniaudio was published recently, raudio should implement this last release. I did the porting but for some reason audio stopped working, it seems the port requires a bit more work.
• ✔️ REVIEW: Buffers refilling mechanism. Current implementation uses a single buffer with an offset to simulate a double-buffering system, this implementation could be improved with a multi-buffer system.
• ✔️ REVIEW: External libraries warnings. Some of the external libraries used generate warning on compilation, those warnings should be reviewed and the improvements sent to original authors.
• ✔️ REVIEW: stb_vorbis usage. raylib currently uses a single-file header-only prefixed fork of stb_vorbis. It should be reviewed to include latest stb_vorbis changes or replaced by another OGG library (if exists).
• ✔️ REVIEW: General audio improvements. There are some open PRs adding improvements to the module, like panning and effects support. Review is pending.

module: raymath

• REVIEW: Quaternions-Euler transforms. After the last big update of the library it seems the Quaternion to/from Euler conversions do not work as expected, they should be reviewed, there is a related example (core_quat_conversion.c) but it's not clear enough, it should also be reviewed.

module: rcamera

• ✔️ REDESIGN: Rewrite the module. Current implementation should be completely reviewed, it was originally created +7 year ago and it has many issues. [rcamera] Redesign #2507 Some of the desired features for the re-implementation would be:

  • Single-file header-only with no external dependencies, neither raylib
  • Use an internal global data structure if any variable is required, lazy initialization
  • Allow changing between camera modes with no breaks in the view
  • Expect input state to be provided externally and allow multiple input systems
  • Simple API, similar to current (avoid breaking code... if possible)

module: rgestures

• REDESIGN: Rewrite the module. Current implementation should be completely reviewed, it was originally created +7 year ago and it has many issues. Some of the desired features for the re-implementation would be:

  • Single-file header-only with no external dependencies, neither raylib
  • Receive touch points data properly for processing, considering touch ids and multi-touch
  • Manage TouchEvents instead of GestureEvent -> More low-level data processing

module: raygui

• 💬 REDESIGN: Improve RAYGUI_STANDALONE. Current implementation is very coupled to raylib and despite it can be used in standalone mode, implementation is quite difficult. It would be nice to completely decouple it from raylib (in a similar way to DearImGui or Nuklear) and provide separate implementations depending on the required backend (i.e. raygui-raylib.h provide binding functions for raylib).

examples

• ✔️ ADDITION: Classification by difficulty. I think it would be nice to organize the examples by a difficulty level, so starting users can focus efforts on easy examples first and move to more difficult examples later on. This improvement will require some way to show that on the raylib webpage and also on the example code description.

• ADDITION: Index functions by usage example. Index all raylib functions by example using them and list with links that information, so users can easily find an example using a specific function. Functions with no example related would require a new example.

• New examples. There are some examples that neew to be added or improved, here some of them:

  • ADDITION: [rlgl] G-Buffers usage -> New API was added in raylib 4.0 but no usage example yet
  • ✔️ ADDITION: [text] Codepoints loading -> Some users asked how to load custom Unicode charsets from a font and use it
  • REVIEW: [core] core_split_screen -> Add FP camera movement per view (as much simple as possible)
  • ❌ REVIEW: [core] core_quat_conversion -> Not working as expected, it requires review. It's also a bit confusing, maybe a better example could be designed. -> Example removed.
  • REVIEW: [textures] textures_blend_mode -> Make it more visual, with buttons and blending selector
  • REVIEW: [others] easings_testbed -> Make it more visual, with buttons and easing selector

Those are some of the improvements I had on my list for next raylib version. It's a long list and it requires lot of work. Note that not all those improvements are expected to be implemented, it's just a reference to draw an action line to follow for future raylib.

As always, contributions are welcome. Feel free to comment.

[GithubPrankster]

Dividing by technology could be the way to go, seeing situations where having Raylib in another platform also means needing a new technology for rcore. For example, homebrew for consoles.

[RobLoach]

With having an alternative backend of SDL, I see a path forwards for alternatives like this. I for one would be curious about a software renderer for low-power devices.

[raysan5]

Actually... I'm afraid SDL will be only used with the OpenGL backend, the software-rendering backend can not be easily hooked to raylib architecture, most of the modules depend on rlgl... but, well, it worth some investigation...

[will-fagerstrom]

Index functions by usage example. Index all raylib functions by example using them and list with links that information, so users can easily find an example using a specific function. Functions with no example related would require a new example.

I think this would be pretty helpful. As someone who is new to Raylib I found myself scratching about trying to get started. It took me a while to figure out the best documentation Raylib has is the examples and the best way to figure out how something is used is greping for the function in an example.

I think having some additional signal for the new developer that the examples are where you should be looking would be very helpful

[chriscamacho]

DrawTexturePoly() -> Do we really need this? rlgl exposes more functionality in a similar way...

yes we really do need this! and texturing for basic shapes too, while rlgl might expose this, rlgl isn't AT ALL friendly to novice users...

Something like DrawTextuePoly fits well with the idea that raylib can be for novice users and teaching graphics programming.

The same argument goes for texturing basic shapes, giving the novice user an easier way into techniques like texture mapping and gets them used to ideas like UV coords before (or without) having to drop down to a lower level like rlgl.

[raysan5]

I'd like to know how many users actually use or have ever used DrawTexturePoly(). It looks useful from a technical point of view but I'm afraid not many (if any) novice users ever needed it.

[Khhs167]

I am not sure how to classify, but fonts get this ugly shadow, which isn’t there in most programs with font support. A setting or something to fix this would be nice, there might be a solution, but I do not know. Hope this is a good thing to add onto here, and I wish raylib and all of its developers a happy new year

[raysan5]

I'm not sure what you mean with font-shadow, I recommend you open an issue with some comparison images between raylib and other libraries/engines to better understand the issue. It's probably just related to font rasterization size and texture filtering, both parameters can be configured by user when loading fonts.

[RicoP]

Review rays global function names to not clash with windows kernel API (CloseWindow, ShowCursor, ...)

[raysan5]

Sorry, no plans for that. Collisions can already be avoided.

[RicoP]

So far the general advice for avoiding collisions is "play with the link settings for long enough and pray it works". Not everyone wants to use mingw.

[raysan5]

Sorry, no plans to change that.

[Peter0x44]

Ensuring raylib is linked first, and windows.h/raylib.h are never both included in the same translation unit is typically fine. You don't have to use mingw either.

[Kamelitoloveless]

-add iOS support
-build tools around Raylib to have an integrated 2D game engine instead on relying on many external tools.

[raysan5]

Good to know! Out of curiosity, what additional image file formats are not supported by raylib and required to be supported?

[tusharsingh09]

*.jpg and jpeg I tried loading it once but INFO said it's unsupported. And then *.ase which is the Aseprite saving format or if I become successful enough maybe all other editor specific file formats.

[RobLoach]

*.ase which is the Aseprite saving format or if I become successful enough maybe all other editor specific file formats.

You're going to like raylib-aseprite.

[raysan5]

*.jpg and *.jpeg are already supported but support must be enabled in config.h with SUPPORT_FILEFORMAT_JPG. *.ase is an intermediate file-format and afaik it's not open-source but proprietary from Aseprite creators, technically it can not (or should not) be used on an open-source software... despite the file-format specs are open...

[tusharsingh09]

*.ase which is the Aseprite saving format or if I become successful enough maybe all other editor specific file formats.

You're going to like raylib-aseprite.

Ok now that's cool

[RobLoach]

Nothing! raylib is ✨PERFECT✨

[KTRosenberg]

Hi. Out of curiosity, is a Metal backend on the roadmap somewhere? (sorry if I missed it.) OpenGL is vastly inferior on mac. Is this an area you’d want external contributions for?

[GithubPrankster]

If the divide by tech happens, someone could implement a Sokol backend, as it supports Metal.

[futureapricot]

Recently Android released the GameActivity Library which adds several improvements on how graphics and audio are executed in modern android, and allows integration with Android Libraries and debugging tools.
It would be nice to have Raylib integrated with this as games could be developed in C and then easily integrated with Play Store capabilities and stuff like advertisement, allowing more professional raylib games to be published.

[npisanti]

I wanted to suggest getting a way to pan Sounds, happy to see there is a PR for that, it's quite fundamental!

Also as a little note, actually the naming for the Sound 's method are a bit imprecise, SetSoundVolume() actually sets the sound amplitude, that is different than the volume (that is measured in dB and scales better to the perceived loudness), and SetSoundPitch() sets the playback speed not the pitch that is measured in semitones (so for example -12.0 would give a speed of 0.5, halving the playback and sounding an octave lower), anyway that is not very much a problem as the inability to set the pan for the Sounds.

Thanks anyway for the great work on raylib!

[ghost]

Thoughts on adding sokol backend? I feel like raylib can do the best with sokol along SDL too...

[KTRosenberg]

Wouldn’t it make more sense for raylib just to provide some generic triangle buffer to feed into anything, with vertex descriptors and so on?

[raysan5]

I'm afraid this is not an easy option, sokol headers are in the same line of raylib. There are also multiple headers for different functionality, similar to raylib modules. soko-gfx could be an option but still it should be wrapped by raylib rlgl, neither an easy task because both sit in the same level.

[raysan5]

@KTRosenberg Actually rlgl somewhat provides that kind of information with its rlVertexBuffer, rlRenderbatch and rlDrawCall.

[KTRosenberg]

I’d suggest going down the route of creating more of these generic abstractions than supporting X library. It seems like you’re on the right path there. One option might be—at the end of a given frame, you could get some command buffer you could switch on in a loop and interpret as a series of commands, and then the programmer has to write their own “interpreter” of said commands into whatever backend they want. This would require deferring all operations though, so maybe not at the end of the frame. You could as the programmer provide hooks into a backend if you really wanted. This may be too low-level though. There’s probably a happy medium somewhere. The goal is really just to support vulkan, metal, and dx11/dx12 without raylib having to implement all of that.

[chriscamacho]

a callback would work, then raylib could just call with a buffer of "commands" as any pass might be required...

[royqh1979]

[rmodel]

• add glTF scenes support
  Then it would be more intuititive to use models exported by blender.

[scienclopodia]

Maybe support for icons on Mac. Not the window but the icon on the "dock" as macOS calls it. When I use the SetWindowIcon() it says that it is not supported. Maybe there can be a function for the icon in the "dock" for macOS?

[raysan5]

I'm afraid icons in macOS are managed externally, not compiled inside the executable.

[staatzstreich]

Hello.... A little bit late :) but ... maybe you are interested in generating a Icon-Set by yourself and integrate it in your "App - Bundle" this Gist can help => https://gist.github.com/jamieweavis/b4c394607641e1280d447deed5fc85fc#saving-images

The Info.plist I used then looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
    <dict>
        <key>CFBundleExecutable</key>
        <string>Patience</string>
        <key>CFBundleGetInfoString</key>
        <string>1.0.0, Copyright 2022 staatzstreich.de</string>
        <key>CFBundleIdentifier</key>
        <string>de.staatzstreich.PatienceMax</string>
        <key>CFBundleIconFile</key>
        <string>icon.icns</string>
        <key>CFBundleDocumentTypes</key>
        <array>
        </array>
        <key>CFBundleInfoDictionaryVersion</key>
        <string>6.0</string>
        <key>CFBundlePackageType</key>
        <string>APPL</string>
        <key>CFBundleShortVersionString</key>
        <string>1.0.0</string>
        <key>CFBundleSignature</key>
        <string>PatienceMax</string>
        <key>CFBundleVersion</key>
        <string>1.0.0</string>
        <key>NSHumanReadableCopyright</key>
        <string>Copyright 2022 Michael Staatz (https://staatzstreich.de).</string>
        <key>LSMinimumSystemVersion</key>
        <string>10.9</string>
    </dict>
</plist>

[gAndy50]

I really like the idea of raylib-gui being standalone.

[jacknicklenson]

adding an external simd library(there are some header only or 2 file .h/.c simd libraries) and using it in raymath.h file to further speed-ups ?

[callumtw]

This one's really minor, but it would be great if DrawGrid() had a Color parameter, for consistency with all the other draw methods!

[raysan5]

agree, I considered it.

[ksdhans]

Here are a few improvements I'd like to see:

• Support interpolation of model animations between frames so it's possible to have smooth animation at varying speeds (e.g., a version of UpdateModelAnimation() with a float frame)
• Add the ability to offload model animations to the GPU for higher performance (lower priority, but nice to have)
• Support 2D bone based animation as well (such as is created by Spine or DragonBones)

[raysan5]

Support interpolation of model animations between frames so it's possible to have smooth animation at varying speeds (e.g., a version of UpdateModelAnimation() with a float frame)

That would be a nice addition but first glTF animations should be properly supported. Also note that interpolation should be done on CPU side and it could be costly depending on the number of bones. Process: for each bone, between two consecutive frames, each bone Transform (translation, rotation, scale) should be interpolated, using a specific interpolation function (easing?).

Add the ability to offload model animations to the GPU for higher performance (lower priority, but nice to have)

GPU skinning usually requires a big amount of data send to GPU every frame to process vertex transformations on the shader (Bones and Transform for the frame to process), depending on the GPU/GLSL-version this could be very slow, despite the gain of processing all vertex in parallel in the GPU. But the real problem is retrieving those transformed vertices back to the CPU, in case physics (or other processings) are required for the 3D model. It requires Transform Feedback support, only available in latest versions of OpenGL, not supported by raylib.

Support 2D bone based animation as well (such as is created by Spine or DragonBones)

This one is already implemented with an external library: https://github.com/WEREMSOFT/spine-raylib-runtimes, it's even listed in the official Spine Runtimes website.

BTW, thanks for your great videos about raylib! :D

[ksdhans]

Support interpolation of model animations between frames so it's possible to have smooth animation at varying speeds (e.g., a version of UpdateModelAnimation() with a float frame)

That would be a nice addition but first glTF animations should be properly supported.

Makes sense.

Also note that interpolation should be done on CPU side and it could be costly depending on the number of bones. Process: for each bone, between two consecutive frames, each bone Transform (translation, rotation, scale) should be interpolated, using a specific interpolation function (easing?).

Lerp and slerp seem to work okay (link).

Add the ability to offload model animations to the GPU for higher performance (lower priority, but nice to have)

GPU skinning usually requires a big amount of data send to GPU every frame to process vertex transformations on the shader (Bones and Transform for the frame to process), depending on the GPU/GLSL-version this could be very slow, despite the gain of processing all vertex in parallel in the GPU.

Depending on the model complexity, I'd expect the volume of data for the bone transforms to be less than the transformed vertices.

But the real problem is retrieving those transformed vertices back to the CPU, in case physics (or other processings) are required for the 3D model. It requires Transform Feedback support, only available in latest versions of OpenGL, not supported by raylib.

I didn't think about that. Mind you, I'd probably use a lower resolution mesh for physics, so that would have to be transformed separately, anyway..

Support 2D bone based animation as well (such as is created by Spine or DragonBones)

This one is already implemented with an external library: https://github.com/WEREMSOFT/spine-raylib-runtimes, it's even listed in the official Spine Runtimes website.

I totally missed that. Nice!

BTW, thanks for your great videos about raylib! :D

Thanks. You're welcome.

[Jeff425]

Support for glVertexAttribIPointer in rlgl would be nice for those of us messing around with shaders.

[raysan5]

@Jeff425 What would be the specific use case for that function? Maybe most raylib users don't need it...

[Jeff425]

I wanted to write my own shader for animation tweening and I wanted to use ivec4 to hold boneIds in the shader.
Right now I am casting the float to an int in the shader, but would be nice to support more OpenGL features

[chriscamacho]

@Jeff425 if you link to the OpenGL library you can directly call this function, depending what functions you use you do need to take care not to disturb the OpenGL state that raylib depends on, take a look at my GUI template where the GUI render directly uses OpenGL

[JupiterRider]

Can we have a method to get the amount of draw calls?

Godot, Monogame, Libgdx and others have something:
https://github.com/MonoGame/MonoGame/blob/develop/MonoGame.Framework/Graphics/GraphicsMetrics.cs#L26

https://github.com/libgdx/libgdx/blob/master/gdx/src/com/badlogic/gdx/graphics/profiling/GLProfiler.java#L104

[raysan5]

Actually there was an issue in the past to provide that information (#1295) but it was finally discarded, I think most raylib users do not need that information and advanced users could just use rlgl and access that data directly.

[raysan5]

Today I've been investigating the possibility to support 16 bpc texture pixel formats. Usually 8-bit per channel file-formats are the standard format and only some advance uses require more resolution per channel. One of those special cases are the HDR textures, using 32 bpc float values (despite the Radiance .hdr file comes with 3 byte for rgb values + 1 byte for exponent: RGBE.

When moving to 16 bit-per-channel formats, we have several options, the two common ones are: 16 bit unsigned short values or 16 bit half float values. Unsigned short textures support seems quite limited and not common while half float textures supports varies depending on OpenGL version and usually requires OES_texture_float extension.

It seems the use is very specific and support across OpenGL versions is not consistent. I finally decided to skip this feature for now. I couldn't find real use cases for those formats and if there is any it's probably out-of-scope for raylib.

[will-ca]

While looking into raylib's capabilities for 3D, I noticed that, at least, a while ago, there was some uncertainty about which model formats to support.

I'd like to throw in my two cents and emphasize the importance of robust glTF support. glTF is basically the modern format for 3D graphics assets, and to my knowledge the first and only format (due to PBR) where you can publish from any program, load in any other program, and reliably have your models look and behave correctly with rich materials and animations.

glTF is an open standard developed by the Khronos Group, same as OpenGL and Vulkan. And as far as Khronos Group offerings go, glTF is doing pretty well. It has significant buy-in from Google (via Filament, ModelViewer, Draco), Microsoft (via Babylon.js, .NET), and Facebook (via Facebook.com, Metaverse). I haven't looked too much into these, but other industrial giants like Dassault, Autodesk, Amazon, and Adobe seem to be on board too. The credited contributors to the specs also include employees acting on behalf of Mozilla, Samsung, Shopify, Target, IKEA, Wayfair, Intel, Adidas, and Unity. And on top of that there are also a number of smaller companies specifically focusing on 3D asset management, like Sketchfab and UX3D, that use glTF as a major part of their value proposition, plus massive community projects like Three.JS that have full support for it.

For me personally, I really like the simple, straightforward, open-ended call-your-own-functionality framework that raylib seems to offer. It looks almost perfect. But lack of full support for glTF is basically the one issue that I can't look past, which in my view means that I don't think I can see raylib as viable for any project that I want to sink significant effort into. It means that I expect that sooner or later, I'm going end up having to basically implement my own rendering engine, and I don't want to take that risk. Some other features like out-of-the-box frustum culling and occlusion culling would be nice too, but really glTF is the most crucial.

(Also I'd advise caution doing skinning on the CPU. Not that I've ever implemented it myself, but I assume that's what Blender does (since accuracy is more important than responsiveness there), and I would not consider Blender's realtime animation playback performance to be anywhere near acceptable for video games, even for relatively simple models, and even when compared to something like Three.JS. — Isn't it a much smaller amount of data anyway to send only the bone transforms to the GPU each frame, instead of computed positions for each vertex? And I'd probably tend to agree with Ksdhans about retrieving the posed mesh too; Anyone doing anything sufficiently involved to require access to the posed mesh should probably use a lower-poly mesh anyway, and already be prepared to compute its deformation themselves (or more likely just parent a cylinder to each bone).)

Anyway, that's just my thoughts, after looking into raylib and alternatives for the last day or so and really hoping I can use it. I understand there are different possible use cases, priorities, design goals, etc. Overall this looks like an amazing library, and I hope it continues evolving and improving. But incomplete glTF support for 3D means I can't jump right in with a ready-to-go asset pipeline, which means that I can't use it— It's a bit like if an image editor supported JPEG, but the green channel is always zero.

[raysan5]

raylib already supports most glTF features, including meshes and materials loading. Animations were partly supported in the past but incomplete, so it was removed from raylib. Full support for glTF is a complex endeavour but contributors willing to work on that task are welcome.

About skinning on CPU, it has been used for +25 years in all platforms, including today. GPU skinning without transform feedback support is useless on a professional environment and unfortunately some backends targeted by raylib do not support that feature (OpenGL ES 2.0).

Kind reminder that raylib is an open source project, feel free to use it or not. Or maybe you can contribute to it to make it better.

[will-ca]

Kind reminder that raylib is an open source project, feel free to use it or not. Or maybe you can contribute to it to make it better.

Yeah, I don't mean to sound harsh, so sorry if it sounded that way. The parts of raylib that are fully fleshed out look amazing, which is why I really hoped the 3D capabilities would be just as good/complete. Maybe in the future I might try to implement some of it myself, but I don't think I have the resources to tackle something of that involvement myself right now— So for now it can't really meet my specific desired use cases, and I thought it might be useful to provide some feedback on why that is. But to be clear, I'm not complaining, and I actually really admire the way you and the community here have built this library and engaged— I know I have a choice to either use something else or contribute the missing features myself, so since I'm not ready to write the code I figured I should at least mention it just because the rest of the library really does make me want to use it.

[chriscamacho]

GPU skinning without transform feedback support is useless

I don't agree, given that an awful lot of colliders (especially IK character colliders) use very simple collision shapes like cylinder or more usefully capsule.

Honestly while its not "voxel" perfect (as it were) you really can't tell, on top of that if you are using a display meshes for all collision detection the computational load is going to be very significant...

[YusufSuleman]

A Mesh merging system.
Like I want to merge verticies that are overlapping or close enough to each other and generate a mesh from that. I think this is what Minecraft does. It seems stupidly hard doing this myself and unefficient.

[raysan5]

@orcmid Yes, this is a very specific use-case requirement, also quite high-level feature and out-of-scope for raylib.

[YusufSuleman]

There's nothing I can do? What lib is that?

[orcmid]

Sorry, I wasn't specific. You or colleagues might create some code and a header that would provide this for your specialized cases, making it re-usable for you and perhaps others. It would be a specialized/custom supplement to raylib, and added to your app source-code folder.

This is the original simple "library" idea for modularizing the source code of programs.

Whether you can find existing code that you could adapt in this way is something you'd have to search for. It might be in books on graphical programming or elsewhere.

It seems stupidly hard doing this myself and unefficient.

I assume from this remark that you have an idea about some method, and then need to look around for any efficient way to do it. Try StackOverflow and also the raylib Discord.

[YusufSuleman]

"StackOverflow"? Nice mistake 😄

[orcmid]

"StackOverflow"? Nice mistake 😄

[StackOverflow(https://stackoverflow.com/)

[ryantrawick]

I would really like to have support for reading gyroscope and accelerometer values from modern gamepads like the PS4/PS5 DualShock and the Switch/Switch Pro Controller. It's nice that the DualShock's triggers can be read as an axis already.

It would also be nice to have more controller names than 360 and PS3. Maybe we can use SDL's gamepad database that has hundreds mapped correctly.

[raysan5]

raylib already uses SDL's gamepad database, provided by GLFW.

About gyroscope and accelerometer data, afaik, it should be returned by GetGamepadAxisMovement() requesting the right axis.