New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for vertex shader / custom buffer data #6
Comments
Tough call... the problem I see is that right now it has a narrow focus on creating effects and filters via shaders. If we allow general vertex handling etc, then this needs to become a (not-too-leaky) abstraction over all of OpenGL. Which could be really cool, but is quite a different idea! |
yeah, true. We could still provide a minimal support of vertex, but I get that this brings new responsability for the library and stuff to maintain. Also I don't think this change so much the focus, this just extends a bit more the genericity of the lib (removing hardcoded part from impls). This allows to be more generic and for instance integrating shaders that relies on different vertex shader. Now the buffer thing is more tricky, but for use case that implies "static" buffer (like we could recreate this example I guess http://jlongster.com/First-Impressions-using-React-Native ), I think it should work great, but once there are dynamic shapes, this might be complex to make the descriptive approach performant. Anyway, this library should be driven by use-case, so for now we focus on doing effects over content, Probably for now, we should focus on implementing remaining features / porting the implementation everywhere (Android) |
not our current focus. we can reopen if we figure out a simple use-case & an implementation plan. |
I would like to see this. Maybe react-gl can act as a compositor library, exposing the vertex buffer and vertex shaders only. Then separate libraries can be used to create 2D and 3D primitives and common shaders. |
gl-react* I definitely agree and it could allow much more use-case, it's a challenge though. We will probably keep pushing forward features on the "final part" of the pipeline (fragment shader) in a near future but I agree that on the long term we should investigate on ways to generalise gl-react more to move the "hardcoded cursor" to the left (in following diagram) and probably not having anything hardcoded :) We are open to contribution too :) There are probably a bunch of things to figure out on how to implement this properly (especially on react-native) and how to provide a nice API on gl-react. |
I highly vote for this. While I have no experience with ios programming, I do have experience with Linux/Android one, so I can try to implement VBO interface for react-native. Looking at https://developer.apple.com/library/ios/documentation/3DDrawing/Conceptual/OpenGLES_ProgrammingGuide/TechniquesforWorkingwithVertexData/TechniquesforWorkingwithVertexData.html it seems that ios part shouldn't be much harder. |
The hard part is probably how to define and support a useful and consistent Unlocking this feature will make people start using it with huge vertex So these are to be investigated, it's not our priority at the moment, but Le dim. 31 juil. 2016 12:02, Alex R notifications@github.com a écrit :
|
the vertex and buffer should NOT be hard coded by implementations but provided by gl-react-core (and defaulted if none is provided).
Something like:
This would allow more advanced use-cases (like 3D shapes).
Now giving more power means we have to be more generic and expose much more OpenGL things.
This might be challenging and we will have to identify a subset of use-cases to start with.
The text was updated successfully, but these errors were encountered: