Skip to content
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

Closed
gre opened this issue Sep 3, 2015 · 7 comments
Closed

Support for vertex shader / custom buffer data #6

gre opened this issue Sep 3, 2015 · 7 comments

Comments

@gre
Copy link
Owner

gre commented Sep 3, 2015

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:

var shaders = GL.Shaders.create({ shaderName: { frag, vert } });
// and then
<GL.View shader={shaders.shaderName} buffer={[ 1, 2, 3, 4, 5, /* whatever*/ ]} ...  />

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.

@mrspeaker
Copy link
Contributor

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!

@gre
Copy link
Owner Author

gre commented Sep 15, 2015

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,
if someone later have another use case, we can discuss here.

Probably for now, we should focus on implementing remaining features / porting the implementation everywhere (Android)

@gre
Copy link
Owner Author

gre commented Feb 17, 2016

not our current focus. we can reopen if we figure out a simple use-case & an implementation plan.

@gre gre closed this as completed Feb 17, 2016
@joewood
Copy link

joewood commented Feb 24, 2016

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.

@gre
Copy link
Owner Author

gre commented Feb 24, 2016

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 :)

screen shot 2016-02-24 at 18 17 00

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.

@0181532686cf4a31163be0bf3e6bb6732bf

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.

@gre
Copy link
Owner Author

gre commented Jul 31, 2016

The hard part is probably how to define and support a useful and consistent
API so you can fully use all features resulting of introducing vertex
shaders and data and continuing maintaining this so it's performant.

Unlocking this feature will make people start using it with huge vertex
model, so it have to be performant. I'm not sure the react-native bridge
will be fast enough. Especially there are no native array support.

So these are to be investigated, it's not our priority at the moment, but
for sure feel free to experiment on this and we accept PRs.

Le dim. 31 juil. 2016 12:02, Alex R notifications@github.com a écrit :

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.


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/ProjectSeptemberInc/gl-react/issues/6#issuecomment-236421491,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAM50zZBPbB_IQHonJ3H7zm-rbfxbULlks5qbHKYgaJpZM4F3DJ7
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants