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

default shaders #1

Closed
slimsag opened this issue Jul 29, 2014 · 3 comments
Closed

default shaders #1

slimsag opened this issue Jul 29, 2014 · 3 comments
Milestone

Comments

@slimsag
Copy link
Contributor

slimsag commented Jul 29, 2014

It would be nice if renderers could provide default shaders that work for most generic cases. The default shader should try to encapsulate all current examples such that no shader is needed.

This issue is a complaint from a user about not being able to use the graphics engine without explicitly writing GLSL shaders.

@slimsag slimsag mentioned this issue Aug 22, 2014
@slimsag slimsag added this to the Version 1.1 milestone Aug 22, 2014
@slimsag
Copy link
Contributor Author

slimsag commented Aug 29, 2014

According to Draw(r image.Rectangle, o *Object, c *Camera) at http://azul3d.org/gfx.v1#Canvas:

// The object will not be drawn if any of the following cases are true:
//  o.Shader == nil
//  len(o.Shader.Error) > 0
//  len(o.Meshes) == 0
//  !o.Meshes[N].Loaded && len(o.Meshes[N].Vertices) == 0

Meaning this would require a documentation change to azul3d/gfx -- which is okay, but for backwards compatibility guarantees we have to bump the version number up (silly for just this one thing).

Upon more thought into this issue -- the real truth is that:

  • Beginners are confused that you have to specify a shader for simple things ("I don't want to shade a model, I just want to display it.").
  • They must learn that shaders are required -- you cannot display an object without a shader, period. Modern graphics API's don't let you (hiding this is just causing them to not learn how things work).
  • We declare shaders in the examples as []byte in the Go source code -- which is semi confusing for people reading over it (mixing between Go->GLSL->Go etc). We should instead declare these in seperate .vert and .frag files in the example's directory (and comment them well).

See new issue for this at azul3d/examples#4

@slimsag slimsag closed this as completed Aug 29, 2014
@dskinner
Copy link

I think that's a fine idea, plus many editors support glsl files. Maybe another idea for an example is dynamic reloading of a shader file via fsnotify.

It's actually kind of a touchy subject reloading a shader file depending on the editor used and how it "saves" a file, but the code isn't overly verbose and for someone learning shaders, having a way to edit the glsl file and see those changes immediately while running the program is a great learning tool.

@slimsag
Copy link
Contributor Author

slimsag commented Aug 29, 2014

Maybe another idea for an example is dynamic reloading of a shader file via fsnotify.

Very interesting idea! Please create an issue for that at azul3d/issues as I would like to see that feature somewhere too, or even hear other's thoughts on it.

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

No branches or pull requests

2 participants