4 ms·

Off-topic, is there any mid-level 3D API that I can plug vertices into directly? Everything that I see is either super-low level (Vulcan, OpenGL) or super-high

Off-topic, is there any mid-level 3D API that I can plug vertices into directly? Everything that I see is either super-low level (Vulcan, OpenGL) or super-high level (Unity).

jleahy 6y ago
Like it or not, the answer is probably OpenGL. If you go with version 3.3 (a good choice in my opinion) and then it's really only a few function calls and you're submitting vertices, and it's going to be supported on any platform. Use glfw and you don't need to worry about platform stuff (creating windows is a pain otherwise). Counting the lines of a renderer I have lying around it's 300 lines (including much whitespace). That's very full functioned, it correctly positions the window in the center of the monitor, handles errors properly, takes mouse and keyboard input, sets up the view/projection matrices, uses shaders, etc.
- phendrenad2 6y ago
  Agreed. And despite being "deprecated", the "fixed-function" OpenGL 1.x API is still implemented on all major platforms (for now?), and it's even more high-level (although your graphics may look somewhat dated). Plus you can mix/match API levels (I think), so you can start with 1.x and move some things to 3.x/4.x style OpenGL when you need shaders. I wish Vulkan wasn't a huge steep learning cliff in comparison.
  - jleahy 6y ago
    It'll be there forever (compatibility), but the problem is there's not a lot of overlap between 1.x and 3.x/4.x. I think people are better sticking to the 3.x core profile. Shaders just aren't that hard and fixed function is a really outdated way of thinking. Generally I'd also say stick with 3.x (rather than 4.x) unless you need tesselation shaders.
    - moron4hire 6y ago
      I believe with the latest versions of the APIs, the fixed function pipeline stuff is now emulated in the programmable pipeline, but the two don't mesh well, so you end up with particularly bad performance. I've had to find and install the old DX9 runtime to get some older games to run at reasonable frame rate.
  - iainmerrick 6y ago
    Not Android and iOS (edit to add: and web!) if you consider those major platforms for your purposes. There you need OpenGL ES which doesn’t include the fixed-function pipeline.
- jleahy 6y ago
  And just for you, I pulled some very ancient code of mine (2012) and stripped it down enough so that it renders a single triangle (and you can move around), nothing more. https://github.com/jleahy/gldemo https://github.com/jleahy/gldemo That's a full OpenGL setup, with all the fiddly bits taken care of. Obviously it's a bit over the top (you don't need vertex buffer region management for one triangle), you don't need SIMD matmul, but that's the maximum. You could port that to any language with OpenGL bindings.
typedef_struct 6y ago
https://github.com/google/filament https://github.com/google/filament and ThreeJS are probably the closest
sxp 6y ago
For quick 3D visualization, I've used three.js and a minimal HTML page. It has loaders for many common 3D file formats so you start with one of the samples at https://threejs.org/examples/ https://threejs.org/examples/ and hack around until it loads the data that you want.
moron4hire 6y ago
I'm in kind of the same boat. I grew very disatisfied with Unity earlier this year and began looking for alternatives. I explored writing my own rendering engine, given that my requirements aren't very high. Back in January, I discovered this really cool .NET Standard 2.0 library for abstracting Direct3D 11, Vulkan, Metal, OpenGL 3, and OpenGL ES 3 called Veldrid: https://github.com/mellinoe/veldrid https://github.com/mellinoe/veldrid The documentation is pretty good, for its own parts, and it has a fair number of examples for setting up things like different windowing libraries. I was able to put together a set of code for a single demo running in Windows Forms, WPF, and Xamarin Forms fairly easily. It also has support for SDL2. Currently, I'm going through a Codevember exercise where I teach myself WebGL from scratch. From what I've learned so far, most of the graphics APIs these days work in very similar ways. And Veldrid polishes over the few differences (esp. in the case of OpenGL). WebGL does, too, in that they present an OpenGL front-end, but the back-end can be implemented in different graphics APIs (for example, on Windows it's actually implemented in D3D 11 through ANGLE). In general, you need to create a Shader Program--which is a combination of multipe Shaders of different types, e.g. Vertex, Compute, and Fragment--construct one or more Buffers to which you will load data (generally in a big, ol' smash of data), and configure how ranges within those Buffers will map to pointer locations within your Shader Program. However, I've generally found that there is little documentation anywhere on how to architect a data pipeline to use all of the various GPU resources efficiently. Everyone talks about "use as few draw calls as possible". But they don't really tell you how to achieve that. My feeling is that a Shader Program is loosely analogous to a Material in something like Three.js or Unity. I'm guessing that the ideal approach is to take all of the Meshes in Three.js, or all of the Renderers in Unity, that have all of the same Materials, and then combining their Geometries into a single block of memory. And that's where Uber Shaders come in, as an attempt to also combine all of the different ways in which you'd want to render different Materials into a single Shader Program.
- midnightclubbed 6y ago
  Combining meshes will reduce the cpu usage hugely (assuming you are talking about hundreds of meshes) but you may end up sending lots of offscreen geometry to the Gpu. Depending on your scene this may or may not be an issue. Some engines will do this behind the scenes or use indirect rendering (which gives the speed benefit of combining meshes without you manually combining). You should also be careful of monolithic Uber shaders especially if they branch as shader divergence can really kill gpu performance on some hardware. There is no one solution, just the one that best fits your usecase, hardware and coding time budget.
jlarocco 6y ago
I'm actually working on a library like that for Common Lisp, but it's still very much a work in progress. My goal is to have a framework where I can experiment with different parts of OpenGL by sub-classing something and then override a method or two, and have it "just work" with everything else in the framework (shaders, viewers, animation, user interaction, etc.) https://github.com/jl2/newgl/tree/buffer-refactor https://github.com/jl2/newgl/tree/buffer-refactor
fulafel 6y ago
You may be looking for a 3D rendering engine. There are lots of choices depending on your target platform, preferred programming language, license preferences, requirements for real time vs animation or image production, etc.
flohofwoe 6y ago
Shameless plug, check out sokol_gfx.h (and maybe sokol_gl.h, which is a simple GL 1.x style API on top of sokol_gfx.h): https://github.com/floooh/sokol https://github.com/floooh/sokol
- deleted 6y ago
  [deleted]
PudgePacket 6y ago
Webgl is honestly a pretty good mid ground between them.
Impossible 6y ago
wgpu and bgfx might be good options. Creative coding frameworks might be work looking at also (Processing, Cinder, Three.js, etc). Also lightweight "engines" like Sokol, Oryol, Raylib and Macroquad might be good options. There are a lot of options just not well known. Someone wanting the perfect high level but not too low level graphics API, where high and low are kind of arbitrary (don't want an engine, no or minimal boilerplate, most work done with code instead of a editor/gui, etc) is a common theme.
vnorilo 6y ago
You can get started with the oldskool immediate mode OpenGL, which is basically just direct emission of vertices triangle by triangle.
skohan 6y ago
WebGPU may become this

Off-topic, is there any mid-level 3D API that I can plug vertices into directly? Everything that I see is either super-low level (Vulcan, OpenGL) or super-high level (Unity).

jleahy 6y ago

Like it or not, the answer is probably OpenGL. If you go with version 3.3 (a good choice in my opinion) and then it's really only a few function calls and you're submitting vertices, and it's going to be supported on any platform. Use glfw and you don't need to worry about platform stuff (creating windows is a pain otherwise). Counting the lines of a renderer I have lying around it's 300 lines (including much whitespace). That's very full functioned, it correctly positions the window in the center of the monitor, handles errors properly, takes mouse and keyboard input, sets up the view/projection matrices, uses shaders, etc.

phendrenad2 6y ago
Agreed. And despite being "deprecated", the "fixed-function" OpenGL 1.x API is still implemented on all major platforms (for now?), and it's even more high-level (although your graphics may look somewhat dated). Plus you can mix/match API levels (I think), so you can start with 1.x and move some things to 3.x/4.x style OpenGL when you need shaders. I wish Vulkan wasn't a huge steep learning cliff in comparison.
- jleahy 6y ago
  It'll be there forever (compatibility), but the problem is there's not a lot of overlap between 1.x and 3.x/4.x. I think people are better sticking to the 3.x core profile. Shaders just aren't that hard and fixed function is a really outdated way of thinking. Generally I'd also say stick with 3.x (rather than 4.x) unless you need tesselation shaders.
  - moron4hire 6y ago
    I believe with the latest versions of the APIs, the fixed function pipeline stuff is now emulated in the programmable pipeline, but the two don't mesh well, so you end up with particularly bad performance. I've had to find and install the old DX9 runtime to get some older games to run at reasonable frame rate.
- iainmerrick 6y ago
  Not Android and iOS (edit to add: and web!) if you consider those major platforms for your purposes. There you need OpenGL ES which doesn’t include the fixed-function pipeline.
jleahy 6y ago
And just for you, I pulled some very ancient code of mine (2012) and stripped it down enough so that it renders a single triangle (and you can move around), nothing more. https://github.com/jleahy/gldemo https://github.com/jleahy/gldemo That's a full OpenGL setup, with all the fiddly bits taken care of. Obviously it's a bit over the top (you don't need vertex buffer region management for one triangle), you don't need SIMD matmul, but that's the maximum. You could port that to any language with OpenGL bindings.

typedef_struct 6y ago

https://github.com/google/filament https://github.com/google/filament and ThreeJS are probably the closest

sxp 6y ago

For quick 3D visualization, I've used three.js and a minimal HTML page. It has loaders for many common 3D file formats so you start with one of the samples at https://threejs.org/examples/ https://threejs.org/examples/ and hack around until it loads the data that you want.

moron4hire 6y ago

I'm in kind of the same boat. I grew very disatisfied with Unity earlier this year and began looking for alternatives. I explored writing my own rendering engine, given that my requirements aren't very high. Back in January, I discovered this really cool .NET Standard 2.0 library for abstracting Direct3D 11, Vulkan, Metal, OpenGL 3, and OpenGL ES 3 called Veldrid: https://github.com/mellinoe/veldrid https://github.com/mellinoe/veldrid The documentation is pretty good, for its own parts, and it has a fair number of examples for setting up things like different windowing libraries. I was able to put together a set of code for a single demo running in Windows Forms, WPF, and Xamarin Forms fairly easily. It also has support for SDL2. Currently, I'm going through a Codevember exercise where I teach myself WebGL from scratch. From what I've learned so far, most of the graphics APIs these days work in very similar ways. And Veldrid polishes over the few differences (esp. in the case of OpenGL). WebGL does, too, in that they present an OpenGL front-end, but the back-end can be implemented in different graphics APIs (for example, on Windows it's actually implemented in D3D 11 through ANGLE). In general, you need to create a Shader Program--which is a combination of multipe Shaders of different types, e.g. Vertex, Compute, and Fragment--construct one or more Buffers to which you will load data (generally in a big, ol' smash of data), and configure how ranges within those Buffers will map to pointer locations within your Shader Program. However, I've generally found that there is little documentation anywhere on how to architect a data pipeline to use all of the various GPU resources efficiently. Everyone talks about "use as few draw calls as possible". But they don't really tell you how to achieve that. My feeling is that a Shader Program is loosely analogous to a Material in something like Three.js or Unity. I'm guessing that the ideal approach is to take all of the Meshes in Three.js, or all of the Renderers in Unity, that have all of the same Materials, and then combining their Geometries into a single block of memory. And that's where Uber Shaders come in, as an attempt to also combine all of the different ways in which you'd want to render different Materials into a single Shader Program.

midnightclubbed 6y ago
Combining meshes will reduce the cpu usage hugely (assuming you are talking about hundreds of meshes) but you may end up sending lots of offscreen geometry to the Gpu. Depending on your scene this may or may not be an issue. Some engines will do this behind the scenes or use indirect rendering (which gives the speed benefit of combining meshes without you manually combining). You should also be careful of monolithic Uber shaders especially if they branch as shader divergence can really kill gpu performance on some hardware. There is no one solution, just the one that best fits your usecase, hardware and coding time budget.

jlarocco 6y ago

I'm actually working on a library like that for Common Lisp, but it's still very much a work in progress. My goal is to have a framework where I can experiment with different parts of OpenGL by sub-classing something and then override a method or two, and have it "just work" with everything else in the framework (shaders, viewers, animation, user interaction, etc.) https://github.com/jl2/newgl/tree/buffer-refactor https://github.com/jl2/newgl/tree/buffer-refactor

fulafel 6y ago

You may be looking for a 3D rendering engine. There are lots of choices depending on your target platform, preferred programming language, license preferences, requirements for real time vs animation or image production, etc.

flohofwoe 6y ago

Shameless plug, check out sokol_gfx.h (and maybe sokol_gl.h, which is a simple GL 1.x style API on top of sokol_gfx.h): https://github.com/floooh/sokol https://github.com/floooh/sokol

deleted 6y ago
[deleted]

PudgePacket 6y ago

Webgl is honestly a pretty good mid ground between them.

Impossible 6y ago

wgpu and bgfx might be good options. Creative coding frameworks might be work looking at also (Processing, Cinder, Three.js, etc). Also lightweight "engines" like Sokol, Oryol, Raylib and Macroquad might be good options. There are a lot of options just not well known. Someone wanting the perfect high level but not too low level graphics API, where high and low are kind of arbitrary (don't want an engine, no or minimal boilerplate, most work done with code instead of a editor/gui, etc) is a common theme.

vnorilo 6y ago

You can get started with the oldskool immediate mode OpenGL, which is basically just direct emission of vertices triangle by triangle.

skohan 6y ago

WebGPU may become this