Menu
▾
▴
glsdk-devel
|
From: H. H. <hen...@gm...> - 2008-08-26 14:05:48
|
Okay we will need to discuss about the actual tutorial content at some
point. I consider that we would need 'samples' and 'tutorials'. Samples are
complete demos with comments. Tutorials would be documents, explaining one
concept with source code snippets scattered around. We should focus on the
tutorials.
For the initial SDK release I think we should include stuff for beginner
level. That is, stuff of basic workings of OpenGL3. The use of VBOs, vertex
arrays, shaders, FBOs, matrices... There should also be sections for
different operating systems about basic context creation, maybe. Tutorial
focus should be about explaining basics and why something is done in some
way. Beginners may be puzzled about the complexities of OpenGL3 context
creation or the matrix layout of OpenGL. These things and many more needs to
be explained.
Also we may want to distinguish what goes into tutorials and what goes into
programming guide. Should we have programming guide? Any ideas what kind of
guide that should be?
Other issues:
1. What is the basic tutorial structure? Every tutorial should follow some
coherent structure.
2. What will the actual tutorials be? Titles...
3. What coding convention are we going to use for the source code snippets?
I propose we use GNU-like style, as we have been using it for the baselibs.
Like this,
void
some_func (int a, int b)
{
// 2 space for tabs
int x;
for (x = 0; x < 10; ++x)
{
}
}
If somebody does not want to write tutorials in our convention, that is
cool, we may do the conversion once you submit the tutorial for us. (the
tutorials don't actually have to be written yet)
Once we get these things decided upon, a sort of tutorial convention
document should be made (nothing fancy, just outlining the general style).
--
Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-26 14:48:56
|
As far as code structure goes, I was thinking something like this for tutorials:
void opengl_init()
{
}
void opengl_draw()
{
}
void opengl_deinit()
{
}
int main(int argc, char** argv)
{
// GLFW init stuff
opengl_init();
while(running)
{
// Check for events
opengl_draw();
}
opengl_deinit();
}
It's simple, and it's easy to get started on tutorial content before
our basecode is written - as long as you have the three core
functions, you can port it to our basecode easily.
Branan
On Tue, Aug 26, 2008 at 7:05 AM, Henri Häkkinen <hen...@gm...> wrote:
> Okay we will need to discuss about the actual tutorial content at some
> point. I consider that we would need 'samples' and 'tutorials'. Samples are
> complete demos with comments. Tutorials would be documents, explaining one
> concept with source code snippets scattered around. We should focus on the
> tutorials.
>
> For the initial SDK release I think we should include stuff for beginner
> level. That is, stuff of basic workings of OpenGL3. The use of VBOs, vertex
> arrays, shaders, FBOs, matrices... There should also be sections for
> different operating systems about basic context creation, maybe. Tutorial
> focus should be about explaining basics and why something is done in some
> way. Beginners may be puzzled about the complexities of OpenGL3 context
> creation or the matrix layout of OpenGL. These things and many more needs to
> be explained.
>
> Also we may want to distinguish what goes into tutorials and what goes into
> programming guide. Should we have programming guide? Any ideas what kind of
> guide that should be?
>
> Other issues:
>
> 1. What is the basic tutorial structure? Every tutorial should follow some
> coherent structure.
>
> 2. What will the actual tutorials be? Titles...
>
> 3. What coding convention are we going to use for the source code snippets?
> I propose we use GNU-like style, as we have been using it for the baselibs.
> Like this,
>
> void
> some_func (int a, int b)
> {
> // 2 space for tabs
> int x;
> for (x = 0; x < 10; ++x)
> {
> }
> }
>
> If somebody does not want to write tutorials in our convention, that is
> cool, we may do the conversion once you submit the tutorial for us. (the
> tutorials don't actually have to be written yet)
>
> Once we get these things decided upon, a sort of tutorial convention
> document should be made (nothing fancy, just outlining the general style).
>
> --
> Henri 'henux' Häkkinen
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
|
|
From: H. H. <hen...@gm...> - 2008-08-26 15:53:46
|
Maybe. There is no need to have them opengl_ prefix and the functions should
be declared static.
On Tue, Aug 26, 2008 at 5:49 PM, Branan Riley <br...@gm...> wrote:
> As far as code structure goes, I was thinking something like this for
> tutorials:
>
> void opengl_init()
> {
> }
>
> void opengl_draw()
> {
> }
>
> void opengl_deinit()
> {
> }
>
> int main(int argc, char** argv)
> {
> // GLFW init stuff
> opengl_init();
> while(running)
> {
> // Check for events
> opengl_draw();
> }
> opengl_deinit();
> }
>
>
> It's simple, and it's easy to get started on tutorial content before
> our basecode is written - as long as you have the three core
> functions, you can port it to our basecode easily.
>
> Branan
>
> On Tue, Aug 26, 2008 at 7:05 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Okay we will need to discuss about the actual tutorial content at some
> > point. I consider that we would need 'samples' and 'tutorials'. Samples
> are
> > complete demos with comments. Tutorials would be documents, explaining
> one
> > concept with source code snippets scattered around. We should focus on
> the
> > tutorials.
> >
> > For the initial SDK release I think we should include stuff for beginner
> > level. That is, stuff of basic workings of OpenGL3. The use of VBOs,
> vertex
> > arrays, shaders, FBOs, matrices... There should also be sections for
> > different operating systems about basic context creation, maybe. Tutorial
> > focus should be about explaining basics and why something is done in some
> > way. Beginners may be puzzled about the complexities of OpenGL3 context
> > creation or the matrix layout of OpenGL. These things and many more needs
> to
> > be explained.
> >
> > Also we may want to distinguish what goes into tutorials and what goes
> into
> > programming guide. Should we have programming guide? Any ideas what kind
> of
> > guide that should be?
> >
> > Other issues:
> >
> > 1. What is the basic tutorial structure? Every tutorial should follow
> some
> > coherent structure.
> >
> > 2. What will the actual tutorials be? Titles...
> >
> > 3. What coding convention are we going to use for the source code
> snippets?
> > I propose we use GNU-like style, as we have been using it for the
> baselibs.
> > Like this,
> >
> > void
> > some_func (int a, int b)
> > {
> > // 2 space for tabs
> > int x;
> > for (x = 0; x < 10; ++x)
> > {
> > }
> > }
> >
> > If somebody does not want to write tutorials in our convention, that is
> > cool, we may do the conversion once you submit the tutorial for us. (the
> > tutorials don't actually have to be written yet)
> >
> > Once we get these things decided upon, a sort of tutorial convention
> > document should be made (nothing fancy, just outlining the general
> style).
> >
> > --
> > Henri 'henux' Häkkinen
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Glsdk-devel mailing list
> > Gls...@li...
> > https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> >
> >
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
--
Henri 'henux' Häkkinen |
|
From: Jason M. <ko...@gm...> - 2008-08-26 17:59:31
|
To me, the most important thing about tutorials is this: they're tools
for teaching. Which means that they need to be laid out in a specific
order (increasing complexity) and with specific intents in mind. Which
means that for the initial tutorials, we should sit down and decide
what the initial tutorials ought to be. We don't necessarily have to
write them ourselves, but we should define what their topics are.
I was thinking something on the order of this:
1: My first triangle: Hello-world for graphics.
2: Transformation and Camera
3: Normals and Per-vertex lighting
4: Per-fragment lighting
5: Texture mapping
6: Framebuffer blending
7: Point-sprites
8: Render-to-texture
9: Depth, order, and blending: Introducing the depth buffer and
dealing with alpha blending with lots of objects.
The idea being that each tutorial builds on the other, introducing new
complexity to the previous one.
On Tue, Aug 26, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...> wrote:
> Maybe. There is no need to have them opengl_ prefix and the functions should
> be declared static.
>
> On Tue, Aug 26, 2008 at 5:49 PM, Branan Riley <br...@gm...> wrote:
>>
>> As far as code structure goes, I was thinking something like this for
>> tutorials:
>>
>> void opengl_init()
>> {
>> }
>>
>> void opengl_draw()
>> {
>> }
>>
>> void opengl_deinit()
>> {
>> }
>>
>> int main(int argc, char** argv)
>> {
>> // GLFW init stuff
>> opengl_init();
>> while(running)
>> {
>> // Check for events
>> opengl_draw();
>> }
>> opengl_deinit();
>> }
>>
>>
>> It's simple, and it's easy to get started on tutorial content before
>> our basecode is written - as long as you have the three core
>> functions, you can port it to our basecode easily.
>>
>> Branan
>>
>> On Tue, Aug 26, 2008 at 7:05 AM, Henri Häkkinen <hen...@gm...>
>> wrote:
>> > Okay we will need to discuss about the actual tutorial content at some
>> > point. I consider that we would need 'samples' and 'tutorials'. Samples
>> > are
>> > complete demos with comments. Tutorials would be documents, explaining
>> > one
>> > concept with source code snippets scattered around. We should focus on
>> > the
>> > tutorials.
>> >
>> > For the initial SDK release I think we should include stuff for beginner
>> > level. That is, stuff of basic workings of OpenGL3. The use of VBOs,
>> > vertex
>> > arrays, shaders, FBOs, matrices... There should also be sections for
>> > different operating systems about basic context creation, maybe.
>> > Tutorial
>> > focus should be about explaining basics and why something is done in
>> > some
>> > way. Beginners may be puzzled about the complexities of OpenGL3 context
>> > creation or the matrix layout of OpenGL. These things and many more
>> > needs to
>> > be explained.
>> >
>> > Also we may want to distinguish what goes into tutorials and what goes
>> > into
>> > programming guide. Should we have programming guide? Any ideas what kind
>> > of
>> > guide that should be?
>> >
>> > Other issues:
>> >
>> > 1. What is the basic tutorial structure? Every tutorial should follow
>> > some
>> > coherent structure.
>> >
>> > 2. What will the actual tutorials be? Titles...
>> >
>> > 3. What coding convention are we going to use for the source code
>> > snippets?
>> > I propose we use GNU-like style, as we have been using it for the
>> > baselibs.
>> > Like this,
>> >
>> > void
>> > some_func (int a, int b)
>> > {
>> > // 2 space for tabs
>> > int x;
>> > for (x = 0; x < 10; ++x)
>> > {
>> > }
>> > }
>> >
>> > If somebody does not want to write tutorials in our convention, that is
>> > cool, we may do the conversion once you submit the tutorial for us. (the
>> > tutorials don't actually have to be written yet)
>> >
>> > Once we get these things decided upon, a sort of tutorial convention
>> > document should be made (nothing fancy, just outlining the general
>> > style).
>> >
>> > --
>> > Henri 'henux' Häkkinen
>> >
>> >
>> >
>> > -------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Moblin Your Move Developer's
>> > challenge
>> > Build the coolest Linux based applications with Moblin SDK & win great
>> > prizes
>> > Grand prize is a trip for two to an Open Source event anywhere in the
>> > world
>> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> > _______________________________________________
>> > Glsdk-devel mailing list
>> > Gls...@li...
>> > https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>> >
>> >
>>
>> -------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Moblin Your Move Developer's
>> challenge
>> Build the coolest Linux based applications with Moblin SDK & win great
>> prizes
>> Grand prize is a trip for two to an Open Source event anywhere in the
>> world
>> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>> _______________________________________________
>> Glsdk-devel mailing list
>> Gls...@li...
>> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
>
> --
> Henri 'henux' Häkkinen
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
>
|
|
From: Andrew G. <and...@gm...> - 2008-08-26 18:11:32
|
I would insert either after #1 or after #2:
My first cube: Hello 3D world!
It's the perfect lead-in to camera/perspective/normals but (slightly) more
complicated than a single triangle. Might be good to note when the GLShape
library starts to be used. Right after getting a triangle displayed? Once
texture mapping is involved? Maybe the cube tutorial explains what's
involved in a cube (beyond the triangle tutorial) then shows the beginner
how to do the same thing using the GLShape library.
pudman
On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> wrote:
> To me, the most important thing about tutorials is this: they're tools
> for teaching. Which means that they need to be laid out in a specific
> order (increasing complexity) and with specific intents in mind. Which
> means that for the initial tutorials, we should sit down and decide
> what the initial tutorials ought to be. We don't necessarily have to
> write them ourselves, but we should define what their topics are.
>
> I was thinking something on the order of this:
>
> 1: My first triangle: Hello-world for graphics.
> 2: Transformation and Camera
> 3: Normals and Per-vertex lighting
> 4: Per-fragment lighting
> 5: Texture mapping
> 6: Framebuffer blending
> 7: Point-sprites
> 8: Render-to-texture
> 9: Depth, order, and blending: Introducing the depth buffer and
> dealing with alpha blending with lots of objects.
>
> The idea being that each tutorial builds on the other, introducing new
> complexity to the previous one.
>
> On Tue, Aug 26, 2008 at 8:53 AM, Henri Häkkinen <hen...@gm...>
> wrote:
> > Maybe. There is no need to have them opengl_ prefix and the functions
> should
> > be declared static.
> >
> > On Tue, Aug 26, 2008 at 5:49 PM, Branan Riley <br...@gm...> wrote:
> >>
> >> As far as code structure goes, I was thinking something like this for
> >> tutorials:
> >>
> >> void opengl_init()
> >> {
> >> }
> >>
> >> void opengl_draw()
> >> {
> >> }
> >>
> >> void opengl_deinit()
> >> {
> >> }
> >>
> >> int main(int argc, char** argv)
> >> {
> >> // GLFW init stuff
> >> opengl_init();
> >> while(running)
> >> {
> >> // Check for events
> >> opengl_draw();
> >> }
> >> opengl_deinit();
> >> }
> >>
> >>
> >> It's simple, and it's easy to get started on tutorial content before
> >> our basecode is written - as long as you have the three core
> >> functions, you can port it to our basecode easily.
> >>
> >> Branan
> >>
> >> On Tue, Aug 26, 2008 at 7:05 AM, Henri Häkkinen <hen...@gm...>
> >> wrote:
> >> > Okay we will need to discuss about the actual tutorial content at some
> >> > point. I consider that we would need 'samples' and 'tutorials'.
> Samples
> >> > are
> >> > complete demos with comments. Tutorials would be documents, explaining
> >> > one
> >> > concept with source code snippets scattered around. We should focus on
> >> > the
> >> > tutorials.
> >> >
> >> > For the initial SDK release I think we should include stuff for
> beginner
> >> > level. That is, stuff of basic workings of OpenGL3. The use of VBOs,
> >> > vertex
> >> > arrays, shaders, FBOs, matrices... There should also be sections for
> >> > different operating systems about basic context creation, maybe.
> >> > Tutorial
> >> > focus should be about explaining basics and why something is done in
> >> > some
> >> > way. Beginners may be puzzled about the complexities of OpenGL3
> context
> >> > creation or the matrix layout of OpenGL. These things and many more
> >> > needs to
> >> > be explained.
> >> >
> >> > Also we may want to distinguish what goes into tutorials and what goes
> >> > into
> >> > programming guide. Should we have programming guide? Any ideas what
> kind
> >> > of
> >> > guide that should be?
> >> >
> >> > Other issues:
> >> >
> >> > 1. What is the basic tutorial structure? Every tutorial should follow
> >> > some
> >> > coherent structure.
> >> >
> >> > 2. What will the actual tutorials be? Titles...
> >> >
> >> > 3. What coding convention are we going to use for the source code
> >> > snippets?
> >> > I propose we use GNU-like style, as we have been using it for the
> >> > baselibs.
> >> > Like this,
> >> >
> >> > void
> >> > some_func (int a, int b)
> >> > {
> >> > // 2 space for tabs
> >> > int x;
> >> > for (x = 0; x < 10; ++x)
> >> > {
> >> > }
> >> > }
> >> >
> >> > If somebody does not want to write tutorials in our convention, that
> is
> >> > cool, we may do the conversion once you submit the tutorial for us.
> (the
> >> > tutorials don't actually have to be written yet)
> >> >
> >> > Once we get these things decided upon, a sort of tutorial convention
> >> > document should be made (nothing fancy, just outlining the general
> >> > style).
> >> >
> >> > --
> >> > Henri 'henux' Häkkinen
> >> >
> >> >
> >> >
> >> >
> -------------------------------------------------------------------------
> >> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> > challenge
> >> > Build the coolest Linux based applications with Moblin SDK & win great
> >> > prizes
> >> > Grand prize is a trip for two to an Open Source event anywhere in the
> >> > world
> >> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> > _______________________________________________
> >> > Glsdk-devel mailing list
> >> > Gls...@li...
> >> > https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> >> >
> >> >
> >>
> >>
> -------------------------------------------------------------------------
> >> This SF.Net email is sponsored by the Moblin Your Move Developer's
> >> challenge
> >> Build the coolest Linux based applications with Moblin SDK & win great
> >> prizes
> >> Grand prize is a trip for two to an Open Source event anywhere in the
> >> world
> >> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> >> _______________________________________________
> >> Glsdk-devel mailing list
> >> Gls...@li...
> >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> >
> >
> >
> > --
> > Henri 'henux' Häkkinen
> >
> >
> > -------------------------------------------------------------------------
> > This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> > Build the coolest Linux based applications with Moblin SDK & win great
> > prizes
> > Grand prize is a trip for two to an Open Source event anywhere in the
> world
> > http://moblin-contest.org/redirect.php?banner_id=100&url=/
> > _______________________________________________
> > Glsdk-devel mailing list
> > Gls...@li...
> > https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> >
> >
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Glsdk-devel mailing list
> Gls...@li...
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
>
|
|
From: Jason M. <ko...@gm...> - 2008-08-26 18:24:54
|
Actually, that reminds me (I generated that list basically off the cuff). Rather than a "my first cube", we should do a whole tutorial on the different kinds of primitives: triangle strips, lists, fans, etc. Also, we should have a tutorial on map buffer (specifically map buffer range, once conformant drivers are more prevelant), for dealing with dynamic geometry. This would probably be after Transform&Camera, but before normals and per-vertex lighting. On Tue, Aug 26, 2008 at 11:11 AM, Andrew Gajda <and...@gm...> wrote: > I would insert either after #1 or after #2: > My first cube: Hello 3D world! > > It's the perfect lead-in to camera/perspective/normals but (slightly) more > complicated than a single triangle. Might be good to note when the GLShape > library starts to be used. Right after getting a triangle displayed? Once > texture mapping is involved? Maybe the cube tutorial explains what's > involved in a cube (beyond the triangle tutorial) then shows the beginner > how to do the same thing using the GLShape library. > > pudman > > On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> wrote: >> >> To me, the most important thing about tutorials is this: they're tools >> for teaching. Which means that they need to be laid out in a specific >> order (increasing complexity) and with specific intents in mind. Which >> means that for the initial tutorials, we should sit down and decide >> what the initial tutorials ought to be. We don't necessarily have to >> write them ourselves, but we should define what their topics are. >> >> I was thinking something on the order of this: >> >> 1: My first triangle: Hello-world for graphics. >> 2: Transformation and Camera >> 3: Normals and Per-vertex lighting >> 4: Per-fragment lighting >> 5: Texture mapping >> 6: Framebuffer blending >> 7: Point-sprites >> 8: Render-to-texture >> 9: Depth, order, and blending: Introducing the depth buffer and >> dealing with alpha blending with lots of objects. >> >> The idea being that each tutorial builds on the other, introducing new >> complexity to the previous one. |
|
From: H. H. <hen...@gm...> - 2008-08-29 08:51:19
|
Someone has posted us a suggestion in the OpenGL forums for the first tutorial: http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245033&Main=47674#Post245033 I think we should begin to put more effort on making actual tutorials, reference manuals, programming guides etc. than what we are now having. The first tutorial (drawing a simple triangle) should be quite trivial without the need of mathlib (although which is already quite complete) or shapelib. The lack of GLFW GL3 support does put us on akward situation, but what I haved talked with the GLFW guys, they are putting a full effort to it. Is there anyone who would be interested on writing stuff for this? Because without the tutorials and other documentation, we will not be able to put this SDK through. Rob, you have been quiet for long time. Are you still with us? Anyone else? On Tue, Aug 26, 2008 at 9:25 PM, Jason McKesson <ko...@gm...> wrote: > Actually, that reminds me (I generated that list basically off the > cuff). Rather than a "my first cube", we should do a whole tutorial on > the different kinds of primitives: triangle strips, lists, fans, etc. > > Also, we should have a tutorial on map buffer (specifically map buffer > range, once conformant drivers are more prevelant), for dealing with > dynamic geometry. This would probably be after Transform&Camera, but > before normals and per-vertex lighting. > > On Tue, Aug 26, 2008 at 11:11 AM, Andrew Gajda <and...@gm...> > wrote: > > I would insert either after #1 or after #2: > > My first cube: Hello 3D world! > > > > It's the perfect lead-in to camera/perspective/normals but (slightly) > more > > complicated than a single triangle. Might be good to note when the > GLShape > > library starts to be used. Right after getting a triangle displayed? > Once > > texture mapping is involved? Maybe the cube tutorial explains what's > > involved in a cube (beyond the triangle tutorial) then shows the beginner > > how to do the same thing using the GLShape library. > > > > pudman > > > > On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> > wrote: > >> > >> To me, the most important thing about tutorials is this: they're tools > >> for teaching. Which means that they need to be laid out in a specific > >> order (increasing complexity) and with specific intents in mind. Which > >> means that for the initial tutorials, we should sit down and decide > >> what the initial tutorials ought to be. We don't necessarily have to > >> write them ourselves, but we should define what their topics are. > >> > >> I was thinking something on the order of this: > >> > >> 1: My first triangle: Hello-world for graphics. > >> 2: Transformation and Camera > >> 3: Normals and Per-vertex lighting > >> 4: Per-fragment lighting > >> 5: Texture mapping > >> 6: Framebuffer blending > >> 7: Point-sprites > >> 8: Render-to-texture > >> 9: Depth, order, and blending: Introducing the depth buffer and > >> dealing with alpha blending with lots of objects. > >> > >> The idea being that each tutorial builds on the other, introducing new > >> complexity to the previous one. > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > -- Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-29 14:52:20
|
Rob's getting a digest, so I think he's just following our progress for now I can write the _code_ for a triangle tutorial, but I'm not all that great at explaining things, as I'm sure some of you have figured out by now. Branan On Fri, Aug 29, 2008 at 1:51 AM, Henri Häkkinen <hen...@gm...> wrote: > Someone has posted us a suggestion in the OpenGL forums for the first > tutorial: > > http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245033&Main=47674#Post245033 > > I think we should begin to put more effort on making actual tutorials, > reference manuals, programming guides etc. than what we are now having. The > first tutorial (drawing a simple triangle) should be quite trivial without > the need of mathlib (although which is already quite complete) or shapelib. > The lack of GLFW GL3 support does put us on akward situation, but what I > haved talked with the GLFW guys, they are putting a full effort to it. > > Is there anyone who would be interested on writing stuff for this? Because > without the tutorials and other documentation, we will not be able to put > this SDK through. Rob, you have been quiet for long time. Are you still with > us? Anyone else? > > On Tue, Aug 26, 2008 at 9:25 PM, Jason McKesson <ko...@gm...> wrote: >> >> Actually, that reminds me (I generated that list basically off the >> cuff). Rather than a "my first cube", we should do a whole tutorial on >> the different kinds of primitives: triangle strips, lists, fans, etc. >> >> Also, we should have a tutorial on map buffer (specifically map buffer >> range, once conformant drivers are more prevelant), for dealing with >> dynamic geometry. This would probably be after Transform&Camera, but >> before normals and per-vertex lighting. >> >> On Tue, Aug 26, 2008 at 11:11 AM, Andrew Gajda <and...@gm...> >> wrote: >> > I would insert either after #1 or after #2: >> > My first cube: Hello 3D world! >> > >> > It's the perfect lead-in to camera/perspective/normals but (slightly) >> > more >> > complicated than a single triangle. Might be good to note when the >> > GLShape >> > library starts to be used. Right after getting a triangle displayed? >> > Once >> > texture mapping is involved? Maybe the cube tutorial explains what's >> > involved in a cube (beyond the triangle tutorial) then shows the >> > beginner >> > how to do the same thing using the GLShape library. >> > >> > pudman >> > >> > On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> >> > wrote: >> >> >> >> To me, the most important thing about tutorials is this: they're tools >> >> for teaching. Which means that they need to be laid out in a specific >> >> order (increasing complexity) and with specific intents in mind. Which >> >> means that for the initial tutorials, we should sit down and decide >> >> what the initial tutorials ought to be. We don't necessarily have to >> >> write them ourselves, but we should define what their topics are. >> >> >> >> I was thinking something on the order of this: >> >> >> >> 1: My first triangle: Hello-world for graphics. >> >> 2: Transformation and Camera >> >> 3: Normals and Per-vertex lighting >> >> 4: Per-fragment lighting >> >> 5: Texture mapping >> >> 6: Framebuffer blending >> >> 7: Point-sprites >> >> 8: Render-to-texture >> >> 9: Depth, order, and blending: Introducing the depth buffer and >> >> dealing with alpha blending with lots of objects. >> >> >> >> The idea being that each tutorial builds on the other, introducing new >> >> complexity to the previous one. >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's >> challenge >> Build the coolest Linux based applications with Moblin SDK & win great >> prizes >> Grand prize is a trip for two to an Open Source event anywhere in the >> world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> Glsdk-devel mailing list >> Gls...@li... >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > > > -- > Henri 'henux' Häkkinen > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > |
|
From: Andrew G. <and...@gm...> - 2008-08-29 14:58:17
|
I think we could all easily participate in the peer-review process of the explanations. Plus, there's lots of tutorials out there explaining VBOs and shaders anyway. Makes for a good starting point. I think it would be beneficial to include GL2.1 variants of the tutorials as well, assuming they use the 3.0 forward compatible path (using 2.1 extensions). That allows use to actually use and test these things on older hardware (when the tutorials don't require DX10 features) and on non-Windows platforms (while we wait for 3.0 GLX). On Fri, Aug 29, 2008 at 10:52 AM, Branan Riley <br...@gm...> wrote: > Rob's getting a digest, so I think he's just following our progress for now > > I can write the _code_ for a triangle tutorial, but I'm not all that > great at explaining things, as I'm sure some of you have figured out > by now. > > Branan > > On Fri, Aug 29, 2008 at 1:51 AM, Henri Häkkinen <hen...@gm...> > wrote: > > Someone has posted us a suggestion in the OpenGL forums for the first > > tutorial: > > > > > http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=245033&Main=47674#Post245033 > > > > I think we should begin to put more effort on making actual tutorials, > > reference manuals, programming guides etc. than what we are now having. > The > > first tutorial (drawing a simple triangle) should be quite trivial > without > > the need of mathlib (although which is already quite complete) or > shapelib. > > The lack of GLFW GL3 support does put us on akward situation, but what I > > haved talked with the GLFW guys, they are putting a full effort to it. > > > > Is there anyone who would be interested on writing stuff for this? > Because > > without the tutorials and other documentation, we will not be able to put > > this SDK through. Rob, you have been quiet for long time. Are you still > with > > us? Anyone else? > > > > On Tue, Aug 26, 2008 at 9:25 PM, Jason McKesson <ko...@gm...> > wrote: > >> > >> Actually, that reminds me (I generated that list basically off the > >> cuff). Rather than a "my first cube", we should do a whole tutorial on > >> the different kinds of primitives: triangle strips, lists, fans, etc. > >> > >> Also, we should have a tutorial on map buffer (specifically map buffer > >> range, once conformant drivers are more prevelant), for dealing with > >> dynamic geometry. This would probably be after Transform&Camera, but > >> before normals and per-vertex lighting. > >> > >> On Tue, Aug 26, 2008 at 11:11 AM, Andrew Gajda <and...@gm...> > >> wrote: > >> > I would insert either after #1 or after #2: > >> > My first cube: Hello 3D world! > >> > > >> > It's the perfect lead-in to camera/perspective/normals but (slightly) > >> > more > >> > complicated than a single triangle. Might be good to note when the > >> > GLShape > >> > library starts to be used. Right after getting a triangle displayed? > >> > Once > >> > texture mapping is involved? Maybe the cube tutorial explains what's > >> > involved in a cube (beyond the triangle tutorial) then shows the > >> > beginner > >> > how to do the same thing using the GLShape library. > >> > > >> > pudman > >> > > >> > On Tue, Aug 26, 2008 at 1:59 PM, Jason McKesson <ko...@gm...> > >> > wrote: > >> >> > >> >> To me, the most important thing about tutorials is this: they're > tools > >> >> for teaching. Which means that they need to be laid out in a specific > >> >> order (increasing complexity) and with specific intents in mind. > Which > >> >> means that for the initial tutorials, we should sit down and decide > >> >> what the initial tutorials ought to be. We don't necessarily have to > >> >> write them ourselves, but we should define what their topics are. > >> >> > >> >> I was thinking something on the order of this: > >> >> > >> >> 1: My first triangle: Hello-world for graphics. > >> >> 2: Transformation and Camera > >> >> 3: Normals and Per-vertex lighting > >> >> 4: Per-fragment lighting > >> >> 5: Texture mapping > >> >> 6: Framebuffer blending > >> >> 7: Point-sprites > >> >> 8: Render-to-texture > >> >> 9: Depth, order, and blending: Introducing the depth buffer and > >> >> dealing with alpha blending with lots of objects. > >> >> > >> >> The idea being that each tutorial builds on the other, introducing > new > >> >> complexity to the previous one. > >> > >> > ------------------------------------------------------------------------- > >> This SF.Net email is sponsored by the Moblin Your Move Developer's > >> challenge > >> Build the coolest Linux based applications with Moblin SDK & win great > >> prizes > >> Grand prize is a trip for two to an Open Source event anywhere in the > >> world > >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ > >> _______________________________________________ > >> Glsdk-devel mailing list > >> Gls...@li... > >> https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > > > > > > > -- > > Henri 'henux' Häkkinen > > > > > > ------------------------------------------------------------------------- > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > _______________________________________________ > > Glsdk-devel mailing list > > Gls...@li... > > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Glsdk-devel mailing list > Gls...@li... > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X