search

tobbebex / GPipe-Core

Core library of new GPipe, encapsulating OpenGl and providing a type safe minimal library
157 stars 29 forks source link

Status of project? #81

Open techmindful opened 3 years ago

techmindful commented 3 years ago

I'm surveying tools that can be useful for making a modern 3D Haskell game engine, and came across GPipe. I'd like to ask:

  1. Is this project mature enough for a task like that? Is it being actively developed and maintained?
  2. Is there a community for discussing GPipe, or is it just happening on GitHub Issues for now?
Chatanga commented 3 years ago

Obviously, GPipe as a project is dead. The library is worthy of interest, but lacks some features and has some performance issues (the generated shaders could be quite verbose due to the lack of factorization). I would say it isn’t a good candidate for your game engine, unless you are ready to spend significant time to improve on it and maybe consider rewriting it for Vulkan ?

techmindful commented 3 years ago

Obviously, GPipe as a project is dead. The library is worthy of interest, but lacks some features and has some performance issues (the generated shaders could be quite verbose due to the lack of factorization). I would say it isn’t a good candidate for your game engine, unless you are ready to spend significant time to improve on it and maybe consider rewriting it for Vulkan ?

That is so sad. I saw the last commit was in summer 2020, and thought it's still going on actively. I've been hunting for libraries for a Haskell game engine. This one excited me because of the type-safe shaders. I guess I have to stick with sdl and gl bindings for now.

pippijn commented 3 years ago

I'm doing a bit of work on it here: https://github.com/homectl/lambdaray

Feel free to look around. I'm probably not going to make PRs anytime soon, but changing String to Text made the compiler 4 times faster already. I'm planning to change the Expr type from Text (previously String) to something more semantic so I can do some post-processing on the expression tree. I'm hoping to speed things up that way.

57 is bothering me a bit as well. I don't know yet how to fix that. There's a ton of abstraction in this library, and on every single byte you upload to the GPU for a texture, it does runStateT (runKleisli c x) (ptr,pads) preceded by multiple dynamic dispatches via type classes (though that one doesn't really make much of a difference).

pippijn commented 3 years ago

FWIW, I think this project is pretty cool and definitely good for your game. Have a look at http://lambdacube3d.com/ as well, though. I used it a bit and I like it better than GPipe, but I ran into some limitations that I couldn't easily fix.

techmindful commented 3 years ago

@pippijn I'm pretty new to graphics programming actually. Really just looking for an optimal starting point. So is LambdaRay a project that expands on GPipe? It's a ray tracer. Can a ray tracer take care of the graphics needs of a game engine?

I've looked at LambdaCube before. I thought it's inactive. But their GitHub has some repo that's updated recently. However I'm not confident if I can use it to create some basic but more modern-looking graphics than Quake?

FWIW, I think this project is pretty cool and definitely good for your game.

Can you please clarify "it"?

pippijn commented 3 years ago

@techmindful

I'm new to it as well. Last week I knew nothing about it, but it took me only 2 days from nothing to https://youtu.be/rPi-KmVI4Yw with lambdacube. Now I'm investigating gpipe. The Ray tracer is really just a slightly involved example of something I'd like to be able to do efficiently with pure functional shaders. I think both gpipe and lambdacube are good starting points. LC is a bit higher level and easier to get started with, and reloading the shader when making changes to it takes 1 second which makes live coding and iterating on prototypes an extremely nice experience. LC does have a few issues like you need to get used to the error messages that can sometimes be quite cryptic, and sometimes the error is just a crash (lots of error handling missing in the compiler code). The lambdaray repo is mostly me working on gpipe itself. The Ray tracer can be ignored. I'm on IRC "pippijn" on freenode and irc.xinutec.net if you want to chat more. If you're looking to use gpipe, I'm happy to collaborate on making a higher level engine with you.

pippijn commented 3 years ago

Both LC and gpipe can be used to make more modern looking graphics than quake. For example, my lambdacnc project has multiple lights with shadows (needs a multi pass render pipeline, while quake is single pass).

pippijn commented 3 years ago

I'm also here with Csaba Hruska (LC author): https://gitter.im/LambdaCube-3D/Lobby

techmindful commented 3 years ago

@pippijn That demo is awesome! I'm glad to hear that LambdaCube is still active. I'm definitely joining the Gitter room, so thanks for linking. That's a great starting point for me!

sorki commented 3 years ago

I've recently built https://github.com/sorki/implicitpipe with GPipe so I'm not exactly happy about the situation.

I was experimenting with LambdaCube as well but decided against it as I love the concept of shader language embedded in Haskell instead of separate compiler. Also IIRC I wasn't able to do some low level things in LC such as multiple buffers but it was almost a year ago so my memory is blurry.

@pippijn - love your demo/project, looks like we are doing similar stuff, I'm hacking on

I've also ported a bunch of 2D UI drawing primitives from oui-blendish to https://github.com/cocreature/nanovg-hs - http://48.io/~rmarko/2020-12-21-114727_1188x1055_scrot.png

I'm on IRC as srk (#distrap, #ImplicitCAD, #haskell @freenode).