Menu
▾
▴
glsdk-devel — Main development list for the OpenGL SDK
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(248) |
Sep
(51) |
Oct
(9) |
Nov
(3) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Andrew G. <and...@gm...> - 2008-08-29 21:36:28
|
These are all great, and given their granularity it allows someone to skip around a bit to focus on exactly what they need. That said, the more granular the tutorials, the more work! :-) The tutorial format will have to be played with, and I'm sure people will probably be very opinionated on what constitutes a clear and readable tutorial that "engages" the user. So, chicken or egg? Does someone create a simple triangle demo or context creation and then we (or one person) takes a stab at presenting a tutorial based on it? Or should a tutorial format be tested covering the basics of context creation (without necessarily full code included in the tutorial)? Hopefully in the coming weeks I'll have a chance to actually submit something, whether code, tutorial/documentation, or other, so I won't just be an opinionated voice on this list. |
|
From: Branan R. <br...@gm...> - 2008-08-29 21:31:06
|
While we're on the subject, we should standardize on top/bottom/interleaved posting. I think most mail clients default to top posting on replies. I like top-posting for general replies, with interleaving for comments on specific things. Any objections to that? |
|
From: H. H. <hen...@gm...> - 2008-08-29 21:29:25
|
Okay, I am writing the GLM API reference manual pages and I think we should
decide on some doc conventions.
1) Should we use verbs in imperative form or in present tense form? For
example, which is better:
* (imperative) Convert radians into degrees.
* (present tense) Converts radians into degrees.
2) What is the general layout of a reference pages? Some ideas:
------
DESCRIPTION
Converts radians into degrees.
Parameters
radians -- radians to convert
Return value
Returns *radians* as degrees.
or perhaps:
------
DESCRIPTION
Converts radians into degrees.
PARAMETERS
radians -- radians to convert
RETURN VALUE
Returns *radians* as degrees.
Other sections; SEE ALSO, COPYRIGHT etc.
3) Anything else we should decide on?
At some point we should establish documentation editors who would have
access to our SVN 'docs/' subdirectory, and who go through the docs and
correct any misspellings and typos and check the conformance against our
conventions. These editors should be native English speakers, which I am
not.
--
Henri 'henux' Häkkinen |
|
From: Branan R. <br...@gm...> - 2008-08-29 21:23:14
|
Since error tolerance should be standard across all of GLSDK, I'm
explaining a way to do that. Ideally we should have a config.h that
has these sorts of things, but that's more involved. I'll add a
config.h template and instructins on how to add things to over the
weekend.
Add these lines to trunk/CMakeLists.txt, just above the chunk that sets -Wall:
SET(GLSDK_ERROR_TOLERANCE <default value> CACHE STRING "The error
tolerance for floating-point operations")
ADD_DEFINITIONS(-DGLSDK_ERROR_TOLERANCE=${GLSDK_ERROR_TOLERANCE})
In your glm header file, you should have a construct like this, just
in case it's used outside of our build system:
#ifdef GLSDK_ERROR_TOLERANCE
#define GLM_ERROR_TOLERANCE GLSDK_ERROR_TOLERANCE
#else
#define GLM_ERROR_TOLERANCE <default value>
#endif
On Fri, Aug 29, 2008 at 1:00 PM, Henri Häkkinen <hen...@gm...> wrote:
> I have a GLM_ERROR_TOLERANCE preproc define in my mathlib which I think
> should be customizable from the build system. At the moment, I just define
> it in 'src/glm/defs.h'. This is just something which is used internally and
> not publicly visible. Could you tell me of how to put this into CMake?
>
> On Fri, Aug 29, 2008 at 6:03 PM, Branan Riley <br...@gm...> wrote:
>>
>> A couple more buidsystem points (this is what I get for not reading
>> things completely before replying
>>
>> * Debug and release builds are already possible using
>> -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. There's also a
>> "RelWithDebInfo", which builds an optimized binary with debug symbols.
>>
>> * Building the docbook files can be done with ADD_CUSTOM_COMMAND.
>> There may even be a CMake module to handle DocBook stuff.
>>
>> Branan
>>
>> On Fri, Aug 29, 2008 at 4:40 AM, Henri Häkkinen <hen...@gm...>
>> wrote:
>> > There are also other things where people could contribute to.
>> >
>> > Let me try to write a list of things to do:
>> >
>> > - a better build system, which would:
>> > * output libs into libs/ subdir and tests/ under subdir or similar
>> > * allow debug and release builds
>> > * build html, manpage etc. documentation from the DocBook files
>> >
>> > - help with Branan's shapelib
>> >
>> > - help with current mathlib issues
>> > (http://sourceforge.net/tracker/?group_id=237607&atid=1103788)
>> >
>> > - writing the GLM API reference in DocBook format (i am currently
>> > working on
>> > this)
>> >
>> > - writing the SDK programming guide or at least designing it's contents
>> >
>> > - (low priority) someone who would collect all the decided coding
>> > conventions etc. pieces into a more coherent file
>> >
>> > - (low priority) updated and professionally looking website with a CMS
>> >
>> >
>> > On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote:
>> >>
>> >> > The reason why we haven't actually written tutorials is that nobody
>> >> > has actually showed interest yet.
>> >> > Hopefully we will get activity once GLFW gets GL3 update.
>> >>
>> >> Two more reasons:
>> >> -we still have no final decision if we use GLFW or not - we could
>> >> assume
>> >> it will support OpenGL 3.0 eventually and temporarily make examples
>> >> using
>> >> OpenGL 2.1 (using only what's in 3.0)
>> >>
>> >> -we still have no shader library (minimally it should provide one
>> >> default
>> >> shader) - this is a minor problem, not an obstacle
>> >>
>> >>
>> >> Honestly if we had both I wouldn't write tutorials anyway, but I should
>> >> be
>> >> "back in business" at the end of the year. Right now all I have is an
>> >> old
>> >> laptop with Intel GPU (somewhere around GeForce 2).
>> >>
>> >>
>> >>
>> >> -------------------------------------------------------------------------
>> >> 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
>
>
>
> --
> 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-29 21:09:10
|
Thanks for this. I will check it out sometime soon and possibly integrate it into our code base if it passes our tests. If I accept it, I will give you a credit for the contribution. You may send me your full name or whatever moniker you wish to be identified with to my personal email address ( hen...@gm...). -- Henri 'henux' Häkkinen |
|
From: Rob B. <rb...@bl...> - 2008-08-29 20:55:41
|
Please be aggressive about trimming your posts when quoting previous posts. We really don't need a full quoting of a digest or of the trailerplate block on each message... just take a second before hitting send to see if you left in more text than you really needed to. this 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 > ^^^ ugh |
|
From: v71 <mj...@ti...> - 2008-08-29 20:46:45
|
rotation concatenation
void RotGl( float yaw,float pitch,float roll ,float tx,float ty,float tz)
{
float cosx,cosy,cosz;
float sinx,siny,sinz;
sinx=sin( yaw );
siny=sin( pitch );
sinz=sin( roll );
cosx=cos( yaw );
cosy=cos( pitch );
cosz=cos( roll );
m[ 0]= cosy*cosz;
m[ 4]= cosy*sinz;
m[ 8]=-siny;
m[ 12]= tx;
m[ 1]= sinx*siny*cosz-cosx*sinz;
m[ 5]= sinx*siny*sinz+cosx*cosz;
m[ 9]= sinx*cosy;
m[ 13]= ty;
m[ 2]= cosx*siny*cosz+sinx*sinz;
m[ 6]= cosx*siny*sinz-sinx*cosz;
m[ 10]= cosx*cosy;
m[ 14]= tz;
m[ 3]= 0.0f;
m[ 7]= 0.0f;
m[ 11]= 0.0f;
m[ 15]= 1.0f;
}
----- Original Message -----
From: <gls...@li...>
To: <gls...@li...>
Sent: Friday, August 29, 2008 10:40 PM
Subject: Glsdk-devel Digest, Vol 1, Issue 53
> Send Glsdk-devel mailing list submissions to
> gls...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/glsdk-devel
> or, via email, send a message with subject or body 'help' to
> gls...@li...
>
> You can reach the person managing the list at
> gls...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Glsdk-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Documentation (Jason McKesson)
> 2. Re: [GLM] development roadmap ( Henri H?kkinen )
> 3. Re: checking in (Jason McKesson)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 29 Aug 2008 12:32:39 -0700
> From: "Jason McKesson" <ko...@gm...>
> Subject: Re: [Glsdk-devel] Documentation
> To: gls...@li...
> Message-ID:
> <11a...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Aug 29, 2008 at 11:19 AM, Branan Riley <br...@gm...> wrote:
>> In most linux distributions, there are already tools that convert
>> docbook to other formats - for example, the docbook-utils package has
>> several commands that read docbook files and output PDF, html, man
>> pages, even RTF.
>>
>> If there is a set of tools like this that is available cross-platform,
>> we don't have to worry about writing any java/c/python/whatever code
>> to handle docbook files - we just tell people that want to build the
>> docs themselves what they need to download.
>>
>> If we just want to convert docbook to HTML or another XML format, a
>> home-grown XSLT-based solution is probably fine. If we want to be able
>> to make other formats, an already-written tool is probably better.
>>
>> Branan
>
> Windows does not come with a set of DocBook tools. I can't speak to
> MacOSX.
>
> But my other point still stands: we should not be relying on the user
> to build their own documentation. Or, more specifically, the user
> should not need to "build" documentation if they want it. Our
> distribution should contain documentation in the final forms, not just
> DocBook. With the exception of man pages, the final documentation is
> all platform-neutral.
>
> I know that's the *NIX thing to do, having a special build to make
> documentation, but it's very much not standard procedure on other
> platforms.
>
> As for the tools themselves, DocBook XSL is the standard, which
> produces reasonably decent documentation.
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 29 Aug 2008 23:00:25 +0300
> From: " Henri H?kkinen " <hen...@gm...>
> Subject: Re: [Glsdk-devel] [GLM] development roadmap
> To: gls...@li...
> Message-ID:
> <fb6...@ma...>
> Content-Type: text/plain; charset="utf-8"
>
> I have a GLM_ERROR_TOLERANCE preproc define in my mathlib which I think
> should be customizable from the build system. At the moment, I just define
> it in 'src/glm/defs.h'. This is just something which is used internally
> and
> not publicly visible. Could you tell me of how to put this into CMake?
>
> On Fri, Aug 29, 2008 at 6:03 PM, Branan Riley <br...@gm...> wrote:
>
>> A couple more buidsystem points (this is what I get for not reading
>> things completely before replying
>>
>> * Debug and release builds are already possible using
>> -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. There's also a
>> "RelWithDebInfo", which builds an optimized binary with debug symbols.
>>
>> * Building the docbook files can be done with ADD_CUSTOM_COMMAND.
>> There may even be a CMake module to handle DocBook stuff.
>>
>> Branan
>>
>> On Fri, Aug 29, 2008 at 4:40 AM, Henri H?kkinen <hen...@gm...>
>> wrote:
>> > There are also other things where people could contribute to.
>> >
>> > Let me try to write a list of things to do:
>> >
>> > - a better build system, which would:
>> > * output libs into libs/ subdir and tests/ under subdir or similar
>> > * allow debug and release builds
>> > * build html, manpage etc. documentation from the DocBook files
>> >
>> > - help with Branan's shapelib
>> >
>> > - help with current mathlib issues
>> > (http://sourceforge.net/tracker/?group_id=237607&atid=1103788)
>> >
>> > - writing the GLM API reference in DocBook format (i am currently
>> > working
>> on
>> > this)
>> >
>> > - writing the SDK programming guide or at least designing it's contents
>> >
>> > - (low priority) someone who would collect all the decided coding
>> > conventions etc. pieces into a more coherent file
>> >
>> > - (low priority) updated and professionally looking website with a CMS
>> >
>> >
>> > On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote:
>> >>
>> >> > The reason why we haven't actually written tutorials is that nobody
>> >> > has actually showed interest yet.
>> >> > Hopefully we will get activity once GLFW gets GL3 update.
>> >>
>> >> Two more reasons:
>> >> -we still have no final decision if we use GLFW or not - we could
>> >> assume
>> >> it will support OpenGL 3.0 eventually and temporarily make examples
>> using
>> >> OpenGL 2.1 (using only what's in 3.0)
>> >>
>> >> -we still have no shader library (minimally it should provide one
>> default
>> >> shader) - this is a minor problem, not an obstacle
>> >>
>> >>
>> >> Honestly if we had both I wouldn't write tutorials anyway, but I
>> >> should
>> be
>> >> "back in business" at the end of the year. Right now all I have is an
>> old
>> >> laptop with Intel GPU (somewhere around GeForce 2).
>> >>
>> >>
>> >>
>> -------------------------------------------------------------------------
>> >> 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
>>
>
>
>
> --
> Henri 'henux' H?kkinen
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> Message: 3
> Date: Fri, 29 Aug 2008 13:40:40 -0700
> From: "Jason McKesson" <ko...@gm...>
> Subject: Re: [Glsdk-devel] checking in
> To: gls...@li...
> Message-ID:
> <11a...@ma...>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I like this. It puts into contrast what separates tutorials from examples
> from demos.
>
> A *demo *is just a program with documentation that shows how to do
> something. The code itself may not be well formatted, but you can learn
> some
> effect by reading the demo's docs.
>
> An *example *is a well-documented program. That is, the documentation
> actually walks you, step-by-step, through the relevant parts of code.
> Examples can often skip initialization or so forth, but they need to
> explain
> in detail the code relevant to the purpose of the example.
>
> A *tutorial *is a teaching aid. It is important for tutorials to have a
> sequence (one tutorial teaches things that are used in the next), and it
> is
> important for them to engage the reader. The code listing for the tutorial
> isn't nearly as important as how the tutorial itself is written. And as
> you
> point out, a tutorial doesn't even need to have a functional codelist; it
> exists to help the reader learn the concepts involved.
>
> This tells me that tutorials need to be something we do "in-house," rather
> than commissioning people to provide them. Or, at the very least, we
> should
> provide the actual subject for each tutorial. A certain standard level of
> quality needs to exist for them, and it will take concerted effort to
> maintain that level of quality.
>
> As for the "stops on the road", the main problem is the dramatic jump
> between "I've got a GL window" and "render something". It requires
> introducing VBOs and shaders. The VBO stuff is fairly simple; it's much
> like
> a form of malloc. The problem comes with shaders, which are incredibly
> complicated. I suppose in a tutorial, you can just handwave it as "magical
> setup work that we'll detail later," but I'd be at least a little
> concerned
> about how that would read to a user.
>
> To expand on your list a bit:
>
> - How do I have a camera independent of the transform for the object?
> - Requires multiple objects
> - Introduces multiple sequential transforms
> - Concatenates them into one matrix for ease-of-use
>
> - How do I map textures?
> - Introduces passing of texture coordinates
> - Introduces texture mapping fragment operations
>
> - How do I introduce lighting?
> - Needs to be after the camera one.
> - Start with directional lights and a semi-complicated object (sphere).
> - Introduce normals and the diffuse lighting equation
> - Do per-vertex lighting, passing a color value.
> - Deal with normal transforms as separate from position transforms.
> - Interactions with textures.
>
> - What about better lighting?
> - Introduce a specular term.
> - Use it per-vertex. Show why this is bad.
> - Move to per-fragment lighting.
> - Different interactions with textures.
>
>
> On Fri, Aug 29, 2008 at 9:41 AM, Rob Barris <rb...@bl...> wrote:
>>
>> Hello Henri , yep I'm still here..
>>
>> I think the #1 goal has to be "walk developers step by step
>> through
>> use of the API". I think to keep focus that we may need to set some
>> explicit *non*-goals for a period of time, and here are a few I would
>> suggest, since they don't help teach the API.
>>
>> a) SIMD optimization for the math lib. <- fun, but off course.
>> b) anything that would tip the balance towards "web site authoring
>> and maint" and away from making code.
>> c) 3D geometry/math tutorials - we can link to any number of
>> books/
>> sites for this stuff
>> d) anything else that consumes calendar time at the expense of
>> demo
>> code.
>>
>> One class of example that might be interesting would be a Rosetta
>> stone, where several ways to accomplish the same goal are shown. For
>> example, simplest thing I can think of, a tumbling triangle. You can
>> do it with all the math on the CPU and push finished verts to the
>> GPU. You can then say "maybe I should do the rotation in the shader"
>> and demonstrate how to hoist code from CPU to GPU and have it run in
>> the shader. You could show one version where we compute the rotation
>> matrix on the CPU and pass that as a uniform to be used trivially in
>> the shader, then you could do one where (just for kicks) we pass Euler
>> angles as uniforms and let the shader generate the matrix itself. We
>> could do one where we pass non-Cartesian verts (azimuth/elevation and
>> radius) and let the shader do polar-to-cartesian conversion. By the
>> end of it you've learned a few different ways to push data from CPU to
>> GPU and have it acted on.
>>
>> stops on the API-learning road.. please add some stops here
>>
>> - how do I establish a context and put it on the screen
>> - make a window, init context, clear, swap
>>
>> - how do I put data in a buffer so GPU can see it
>> - no drawing - just demonstrate the buffer API's
>> - perhaps BufferData some floats into a buffer, then map
>> it
> and
>> print the values seen
>>
>> - how do I draw the simplest possible triangle
>> - pass-through shader for vert position
>> - "write red" for pixel
>> - constant verts for geometry in a VBO
>>
>> - how can I change the color of the triangle
>> - introduce per vertex color attribute
>> - vertex shader passes it through
>> - alter pixel shader to read it and emit it
>>
>> - introduction to uniforms - communicate to shaders
>> - show color change using uniform (several ways to do
>> this)
>>
>> - how can I move the triangle
>> - see above
>>
>> that's a lot of good tutorial steps before we even start talking
>> about more than one triangle. Ideally you get to the end of this
>> phase and you have an idea of how to put data in a buffer, how to lay
>> out some vertex data, how to draw a triangle, and how to communicate
>> on a very basic level with the shaders, and no usage of deprecated APIs.
>>
>> Rob
>>
>>
>> -------------------------------------------------------------------------
>> 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
>>
> -------------- next part --------------
> An HTML attachment was scrubbed...
>
> ------------------------------
>
> -------------------------------------------------------------------------
> 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
>
>
> End of Glsdk-devel Digest, Vol 1, Issue 53
> ******************************************
|
|
From: v71 <mj...@ti...> - 2008-08-29 20:41:53
|
I can send my shpe library to whom is interested into developing, just give me your private email to send the zipped files ----- Original Message ----- From: <gls...@li...> To: <gls...@li...> Sent: Friday, August 29, 2008 8:18 PM Subject: Glsdk-devel Digest, Vol 1, Issue 52 > Send Glsdk-devel mailing list submissions to > gls...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/glsdk-devel > or, via email, send a message with subject or body 'help' to > gls...@li... > > You can reach the person managing the list at > gls...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Glsdk-devel digest..." > > > Today's Topics: > > 1. Re: [GLM] development roadmap (Branan Riley) > 2. Documentation (Branan Riley) > 3. Re: Documentation (Jason McKesson) > 4. checking in (Rob Barris) > 5. Re: Documentation (Branan Riley) > 6. Re: Documentation (Jason McKesson) > 7. Re: Documentation (Branan Riley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Aug 2008 08:03:23 -0700 > From: "Branan Riley" <br...@gm...> > Subject: Re: [Glsdk-devel] [GLM] development roadmap > To: gls...@li... > Message-ID: > <cad...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > A couple more buidsystem points (this is what I get for not reading > things completely before replying > > * Debug and release builds are already possible using > -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. There's also a > "RelWithDebInfo", which builds an optimized binary with debug symbols. > > * Building the docbook files can be done with ADD_CUSTOM_COMMAND. > There may even be a CMake module to handle DocBook stuff. > > Branan > > On Fri, Aug 29, 2008 at 4:40 AM, Henri H?kkinen <hen...@gm...> > wrote: >> There are also other things where people could contribute to. >> >> Let me try to write a list of things to do: >> >> - a better build system, which would: >> * output libs into libs/ subdir and tests/ under subdir or similar >> * allow debug and release builds >> * build html, manpage etc. documentation from the DocBook files >> >> - help with Branan's shapelib >> >> - help with current mathlib issues >> (http://sourceforge.net/tracker/?group_id=237607&atid=1103788) >> >> - writing the GLM API reference in DocBook format (i am currently working >> on >> this) >> >> - writing the SDK programming guide or at least designing it's contents >> >> - (low priority) someone who would collect all the decided coding >> conventions etc. pieces into a more coherent file >> >> - (low priority) updated and professionally looking website with a CMS >> >> >> On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote: >>> >>> > The reason why we haven't actually written tutorials is that nobody >>> > has actually showed interest yet. >>> > Hopefully we will get activity once GLFW gets GL3 update. >>> >>> Two more reasons: >>> -we still have no final decision if we use GLFW or not - we could assume >>> it will support OpenGL 3.0 eventually and temporarily make examples >>> using >>> OpenGL 2.1 (using only what's in 3.0) >>> >>> -we still have no shader library (minimally it should provide one >>> default >>> shader) - this is a minor problem, not an obstacle >>> >>> >>> Honestly if we had both I wouldn't write tutorials anyway, but I should >>> be >>> "back in business" at the end of the year. Right now all I have is an >>> old >>> laptop with Intel GPU (somewhere around GeForce 2). >>> >>> >>> ------------------------------------------------------------------------- >>> 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 >> >> > > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Aug 2008 08:51:19 -0700 > From: "Branan Riley" <br...@gm...> > Subject: [Glsdk-devel] Documentation > To: gls...@li... > Message-ID: > <cad...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > Since we've decided on DocBook files for our documentation, we now > have the question of how we're going to convert those into HTML, PDF, > or whatever format we decide upon. > > There are lots of tools for this, but I don't know which ones are > cross-platform, and which ones will meet our needs. I can't make CMake > generate our docs until I know what tool we're using for it. > > Branan > > > > ------------------------------ > > Message: 3 > Date: Fri, 29 Aug 2008 09:42:27 -0700 > From: Jason McKesson <ko...@gm...> > Subject: Re: [Glsdk-devel] Documentation > To: gls...@li... > Message-ID: <48B...@gm...> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Branan Riley wrote: >> Since we've decided on DocBook files for our documentation, we now >> have the question of how we're going to convert those into HTML, PDF, >> or whatever format we decide upon. >> >> There are lots of tools for this, but I don't know which ones are >> cross-platform, and which ones will meet our needs. I can't make CMake >> generate our docs until I know what tool we're using for it. >> > There's really only 1 tool for transforming XML into other things: XSLT. > It is a language for converting XML documents into other XML documents > (though it can also output text and non-X-HTML). > > The two most common XSLT processors are Saxon (Java) and the LibXML2 (C) > XSLT processor. There are Saxon processors for XSLT 1 and 2, but LibXML2 > only supports XSLT 1. Fortunately (or unfortunately, if you like XSLT > 2), the only XSLT documents that are in the wild are version 1; the > complexity of writing a version 2 processor tends to keep people away > from it (despite the fact that Saxon's XSLT 2 implementation has been > available for a good 2 years now). > > DocBook XSL is generally the common way of transforming DocBook into > various output formats. Converting DocBook to PDF requires an additional > tool: Apache FOP (or another XSL-FO processor), which is a Java tool. > Indeed, most XSL-FO processors are Java, but FOP is the only free one of > any real quality that I know of. > > Also, CMake should not be generating our docs at all. I wouldn't want to > force Java on someone just to give them PDF. The documentation building > should be done when we go about the process of making a release, and the > final documents should be part of that release. > > However, I would suggest we hold off on dealing with the documentation > conversion issue for the time being. My main focus at present is on GLE, > and document conversion needs to deal with formatting questions that I > don't have time to focus on right now. > > > > ------------------------------ > > Message: 4 > Date: Fri, 29 Aug 2008 09:41:59 -0700 > From: Rob Barris <rb...@bl...> > Subject: [Glsdk-devel] checking in > To: gls...@li... > Message-ID: <3A0...@bl...> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > Hello Henri , yep I'm still here.. > > I think the #1 goal has to be "walk developers step by step through > use of the API". I think to keep focus that we may need to set some > explicit *non*-goals for a period of time, and here are a few I would > suggest, since they don't help teach the API. > > a) SIMD optimization for the math lib. <- fun, but off course. > b) anything that would tip the balance towards "web site authoring > and maint" and away from making code. > c) 3D geometry/math tutorials - we can link to any number of books/ > sites for this stuff > d) anything else that consumes calendar time at the expense of demo > code. > > One class of example that might be interesting would be a Rosetta > stone, where several ways to accomplish the same goal are shown. For > example, simplest thing I can think of, a tumbling triangle. You can > do it with all the math on the CPU and push finished verts to the > GPU. You can then say "maybe I should do the rotation in the shader" > and demonstrate how to hoist code from CPU to GPU and have it run in > the shader. You could show one version where we compute the rotation > matrix on the CPU and pass that as a uniform to be used trivially in > the shader, then you could do one where (just for kicks) we pass Euler > angles as uniforms and let the shader generate the matrix itself. We > could do one where we pass non-Cartesian verts (azimuth/elevation and > radius) and let the shader do polar-to-cartesian conversion. By the > end of it you've learned a few different ways to push data from CPU to > GPU and have it acted on. > > stops on the API-learning road.. please add some stops here > > - how do I establish a context and put it on the screen > - make a window, init context, clear, swap > > - how do I put data in a buffer so GPU can see it > - no drawing - just demonstrate the buffer API's > - perhaps BufferData some floats into a buffer, then map it and > print the values seen > > - how do I draw the simplest possible triangle > - pass-through shader for vert position > - "write red" for pixel > - constant verts for geometry in a VBO > > - how can I change the color of the triangle > - introduce per vertex color attribute > - vertex shader passes it through > - alter pixel shader to read it and emit it > > - introduction to uniforms - communicate to shaders > - show color change using uniform (several ways to do this) > > - how can I move the triangle > - see above > > that's a lot of good tutorial steps before we even start talking > about more than one triangle. Ideally you get to the end of this > phase and you have an idea of how to put data in a buffer, how to lay > out some vertex data, how to draw a triangle, and how to communicate > on a very basic level with the shaders, and no usage of deprecated APIs. > > Rob > > > > > ------------------------------ > > Message: 5 > Date: Fri, 29 Aug 2008 09:46:58 -0700 > From: "Branan Riley" <br...@gm...> > Subject: Re: [Glsdk-devel] Documentation > To: gls...@li... > Message-ID: > <cad...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > Yes, technically XSLT is the only way to transform it. I meant there > are a number of programs already created that are already layered on > top of XSLT, at least in Linux. I don't know about the Windows and Mac > worlds. If we can use on of those, it saves us the trouble of writing > our own. > > As for forcing people to build docs, I can add a GLSDK_DOCS flag just > like we have a GLSDK_TEST flag, so CMake only builds the docs when you > want it to. > > Branan > > On Fri, Aug 29, 2008 at 9:42 AM, Jason McKesson <ko...@gm...> wrote: >> Branan Riley wrote: >>> Since we've decided on DocBook files for our documentation, we now >>> have the question of how we're going to convert those into HTML, PDF, >>> or whatever format we decide upon. >>> >>> There are lots of tools for this, but I don't know which ones are >>> cross-platform, and which ones will meet our needs. I can't make CMake >>> generate our docs until I know what tool we're using for it. >>> >> There's really only 1 tool for transforming XML into other things: XSLT. >> It is a language for converting XML documents into other XML documents >> (though it can also output text and non-X-HTML). >> >> The two most common XSLT processors are Saxon (Java) and the LibXML2 (C) >> XSLT processor. There are Saxon processors for XSLT 1 and 2, but LibXML2 >> only supports XSLT 1. Fortunately (or unfortunately, if you like XSLT >> 2), the only XSLT documents that are in the wild are version 1; the >> complexity of writing a version 2 processor tends to keep people away >> from it (despite the fact that Saxon's XSLT 2 implementation has been >> available for a good 2 years now). >> >> DocBook XSL is generally the common way of transforming DocBook into >> various output formats. Converting DocBook to PDF requires an additional >> tool: Apache FOP (or another XSL-FO processor), which is a Java tool. >> Indeed, most XSL-FO processors are Java, but FOP is the only free one of >> any real quality that I know of. >> >> Also, CMake should not be generating our docs at all. I wouldn't want to >> force Java on someone just to give them PDF. The documentation building >> should be done when we go about the process of making a release, and the >> final documents should be part of that release. >> >> However, I would suggest we hold off on dealing with the documentation >> conversion issue for the time being. My main focus at present is on GLE, >> and document conversion needs to deal with formatting questions that I >> don't have time to focus on right now. >> >> ------------------------------------------------------------------------- >> 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 >> > > > > ------------------------------ > > Message: 6 > Date: Fri, 29 Aug 2008 11:01:28 -0700 > From: "Jason McKesson" <ko...@gm...> > Subject: Re: [Glsdk-devel] Documentation > To: gls...@li... > Message-ID: > <11a...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > On Fri, Aug 29, 2008 at 9:46 AM, Branan Riley <br...@gm...> wrote: >> Yes, technically XSLT is the only way to transform it. I meant there >> are a number of programs already created that are already layered on >> top of XSLT, at least in Linux. I don't know about the Windows and Mac >> worlds. If we can use on of those, it saves us the trouble of writing >> our own. > > I'm not sure I understand what you're talking about when you refer to > programs that are "layered on top of XSLT." Can you give me an > example? > > We should not be looking for any XSLT implementation on the host > system. Instead, our system for building documents should use a > specific XSLT implementation (which takes specific command-line > arguments), and we should simply deliver the results. > > > > ------------------------------ > > Message: 7 > Date: Fri, 29 Aug 2008 11:19:09 -0700 > From: "Branan Riley" <br...@gm...> > Subject: Re: [Glsdk-devel] Documentation > To: gls...@li... > Message-ID: > <cad...@ma...> > Content-Type: text/plain; charset=ISO-8859-1 > > In most linux distributions, there are already tools that convert > docbook to other formats - for example, the docbook-utils package has > several commands that read docbook files and output PDF, html, man > pages, even RTF. > > If there is a set of tools like this that is available cross-platform, > we don't have to worry about writing any java/c/python/whatever code > to handle docbook files - we just tell people that want to build the > docs themselves what they need to download. > > If we just want to convert docbook to HTML or another XML format, a > home-grown XSLT-based solution is probably fine. If we want to be able > to make other formats, an already-written tool is probably better. > > Branan > > On Fri, Aug 29, 2008 at 11:01 AM, Jason McKesson <ko...@gm...> > wrote: >> On Fri, Aug 29, 2008 at 9:46 AM, Branan Riley <br...@gm...> wrote: >>> Yes, technically XSLT is the only way to transform it. I meant there >>> are a number of programs already created that are already layered on >>> top of XSLT, at least in Linux. I don't know about the Windows and Mac >>> worlds. If we can use on of those, it saves us the trouble of writing >>> our own. >> >> I'm not sure I understand what you're talking about when you refer to >> programs that are "layered on top of XSLT." Can you give me an >> example? >> >> We should not be looking for any XSLT implementation on the host >> system. Instead, our system for building documents should use a >> specific XSLT implementation (which takes specific command-line >> arguments), and we should simply deliver the results. >> >> ------------------------------------------------------------------------- >> 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 > > > End of Glsdk-devel Digest, Vol 1, Issue 52 > ****************************************** |
|
From: Jason M. <ko...@gm...> - 2008-08-29 20:40:30
|
I like this. It puts into contrast what separates tutorials from examples
from demos.
A *demo *is just a program with documentation that shows how to do
something. The code itself may not be well formatted, but you can learn some
effect by reading the demo's docs.
An *example *is a well-documented program. That is, the documentation
actually walks you, step-by-step, through the relevant parts of code.
Examples can often skip initialization or so forth, but they need to explain
in detail the code relevant to the purpose of the example.
A *tutorial *is a teaching aid. It is important for tutorials to have a
sequence (one tutorial teaches things that are used in the next), and it is
important for them to engage the reader. The code listing for the tutorial
isn't nearly as important as how the tutorial itself is written. And as you
point out, a tutorial doesn't even need to have a functional codelist; it
exists to help the reader learn the concepts involved.
This tells me that tutorials need to be something we do "in-house," rather
than commissioning people to provide them. Or, at the very least, we should
provide the actual subject for each tutorial. A certain standard level of
quality needs to exist for them, and it will take concerted effort to
maintain that level of quality.
As for the "stops on the road", the main problem is the dramatic jump
between "I've got a GL window" and "render something". It requires
introducing VBOs and shaders. The VBO stuff is fairly simple; it's much like
a form of malloc. The problem comes with shaders, which are incredibly
complicated. I suppose in a tutorial, you can just handwave it as "magical
setup work that we'll detail later," but I'd be at least a little concerned
about how that would read to a user.
To expand on your list a bit:
- How do I have a camera independent of the transform for the object?
- Requires multiple objects
- Introduces multiple sequential transforms
- Concatenates them into one matrix for ease-of-use
- How do I map textures?
- Introduces passing of texture coordinates
- Introduces texture mapping fragment operations
- How do I introduce lighting?
- Needs to be after the camera one.
- Start with directional lights and a semi-complicated object (sphere).
- Introduce normals and the diffuse lighting equation
- Do per-vertex lighting, passing a color value.
- Deal with normal transforms as separate from position transforms.
- Interactions with textures.
- What about better lighting?
- Introduce a specular term.
- Use it per-vertex. Show why this is bad.
- Move to per-fragment lighting.
- Different interactions with textures.
On Fri, Aug 29, 2008 at 9:41 AM, Rob Barris <rb...@bl...> wrote:
>
> Hello Henri , yep I'm still here..
>
> I think the #1 goal has to be "walk developers step by step through
> use of the API". I think to keep focus that we may need to set some
> explicit *non*-goals for a period of time, and here are a few I would
> suggest, since they don't help teach the API.
>
> a) SIMD optimization for the math lib. <- fun, but off course.
> b) anything that would tip the balance towards "web site authoring
> and maint" and away from making code.
> c) 3D geometry/math tutorials - we can link to any number of books/
> sites for this stuff
> d) anything else that consumes calendar time at the expense of demo
> code.
>
> One class of example that might be interesting would be a Rosetta
> stone, where several ways to accomplish the same goal are shown. For
> example, simplest thing I can think of, a tumbling triangle. You can
> do it with all the math on the CPU and push finished verts to the
> GPU. You can then say "maybe I should do the rotation in the shader"
> and demonstrate how to hoist code from CPU to GPU and have it run in
> the shader. You could show one version where we compute the rotation
> matrix on the CPU and pass that as a uniform to be used trivially in
> the shader, then you could do one where (just for kicks) we pass Euler
> angles as uniforms and let the shader generate the matrix itself. We
> could do one where we pass non-Cartesian verts (azimuth/elevation and
> radius) and let the shader do polar-to-cartesian conversion. By the
> end of it you've learned a few different ways to push data from CPU to
> GPU and have it acted on.
>
> stops on the API-learning road.. please add some stops here
>
> - how do I establish a context and put it on the screen
> - make a window, init context, clear, swap
>
> - how do I put data in a buffer so GPU can see it
> - no drawing - just demonstrate the buffer API's
> - perhaps BufferData some floats into a buffer, then map it
and
> print the values seen
>
> - how do I draw the simplest possible triangle
> - pass-through shader for vert position
> - "write red" for pixel
> - constant verts for geometry in a VBO
>
> - how can I change the color of the triangle
> - introduce per vertex color attribute
> - vertex shader passes it through
> - alter pixel shader to read it and emit it
>
> - introduction to uniforms - communicate to shaders
> - show color change using uniform (several ways to do this)
>
> - how can I move the triangle
> - see above
>
> that's a lot of good tutorial steps before we even start talking
> about more than one triangle. Ideally you get to the end of this
> phase and you have an idea of how to put data in a buffer, how to lay
> out some vertex data, how to draw a triangle, and how to communicate
> on a very basic level with the shaders, and no usage of deprecated APIs.
>
> Rob
>
>
> -------------------------------------------------------------------------
> 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-29 20:00:16
|
I have a GLM_ERROR_TOLERANCE preproc define in my mathlib which I think should be customizable from the build system. At the moment, I just define it in 'src/glm/defs.h'. This is just something which is used internally and not publicly visible. Could you tell me of how to put this into CMake? On Fri, Aug 29, 2008 at 6:03 PM, Branan Riley <br...@gm...> wrote: > A couple more buidsystem points (this is what I get for not reading > things completely before replying > > * Debug and release builds are already possible using > -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. There's also a > "RelWithDebInfo", which builds an optimized binary with debug symbols. > > * Building the docbook files can be done with ADD_CUSTOM_COMMAND. > There may even be a CMake module to handle DocBook stuff. > > Branan > > On Fri, Aug 29, 2008 at 4:40 AM, Henri Häkkinen <hen...@gm...> > wrote: > > There are also other things where people could contribute to. > > > > Let me try to write a list of things to do: > > > > - a better build system, which would: > > * output libs into libs/ subdir and tests/ under subdir or similar > > * allow debug and release builds > > * build html, manpage etc. documentation from the DocBook files > > > > - help with Branan's shapelib > > > > - help with current mathlib issues > > (http://sourceforge.net/tracker/?group_id=237607&atid=1103788) > > > > - writing the GLM API reference in DocBook format (i am currently working > on > > this) > > > > - writing the SDK programming guide or at least designing it's contents > > > > - (low priority) someone who would collect all the decided coding > > conventions etc. pieces into a more coherent file > > > > - (low priority) updated and professionally looking website with a CMS > > > > > > On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote: > >> > >> > The reason why we haven't actually written tutorials is that nobody > >> > has actually showed interest yet. > >> > Hopefully we will get activity once GLFW gets GL3 update. > >> > >> Two more reasons: > >> -we still have no final decision if we use GLFW or not - we could assume > >> it will support OpenGL 3.0 eventually and temporarily make examples > using > >> OpenGL 2.1 (using only what's in 3.0) > >> > >> -we still have no shader library (minimally it should provide one > default > >> shader) - this is a minor problem, not an obstacle > >> > >> > >> Honestly if we had both I wouldn't write tutorials anyway, but I should > be > >> "back in business" at the end of the year. Right now all I have is an > old > >> laptop with Intel GPU (somewhere around GeForce 2). > >> > >> > >> > ------------------------------------------------------------------------- > >> 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 > -- Henri 'henux' Häkkinen |
|
From: Jason M. <ko...@gm...> - 2008-08-29 19:32:29
|
On Fri, Aug 29, 2008 at 11:19 AM, Branan Riley <br...@gm...> wrote: > In most linux distributions, there are already tools that convert > docbook to other formats - for example, the docbook-utils package has > several commands that read docbook files and output PDF, html, man > pages, even RTF. > > If there is a set of tools like this that is available cross-platform, > we don't have to worry about writing any java/c/python/whatever code > to handle docbook files - we just tell people that want to build the > docs themselves what they need to download. > > If we just want to convert docbook to HTML or another XML format, a > home-grown XSLT-based solution is probably fine. If we want to be able > to make other formats, an already-written tool is probably better. > > Branan Windows does not come with a set of DocBook tools. I can't speak to MacOSX. But my other point still stands: we should not be relying on the user to build their own documentation. Or, more specifically, the user should not need to "build" documentation if they want it. Our distribution should contain documentation in the final forms, not just DocBook. With the exception of man pages, the final documentation is all platform-neutral. I know that's the *NIX thing to do, having a special build to make documentation, but it's very much not standard procedure on other platforms. As for the tools themselves, DocBook XSL is the standard, which produces reasonably decent documentation. |
|
From: Branan R. <br...@gm...> - 2008-08-29 18:18:58
|
In most linux distributions, there are already tools that convert docbook to other formats - for example, the docbook-utils package has several commands that read docbook files and output PDF, html, man pages, even RTF. If there is a set of tools like this that is available cross-platform, we don't have to worry about writing any java/c/python/whatever code to handle docbook files - we just tell people that want to build the docs themselves what they need to download. If we just want to convert docbook to HTML or another XML format, a home-grown XSLT-based solution is probably fine. If we want to be able to make other formats, an already-written tool is probably better. Branan On Fri, Aug 29, 2008 at 11:01 AM, Jason McKesson <ko...@gm...> wrote: > On Fri, Aug 29, 2008 at 9:46 AM, Branan Riley <br...@gm...> wrote: >> Yes, technically XSLT is the only way to transform it. I meant there >> are a number of programs already created that are already layered on >> top of XSLT, at least in Linux. I don't know about the Windows and Mac >> worlds. If we can use on of those, it saves us the trouble of writing >> our own. > > I'm not sure I understand what you're talking about when you refer to > programs that are "layered on top of XSLT." Can you give me an > example? > > We should not be looking for any XSLT implementation on the host > system. Instead, our system for building documents should use a > specific XSLT implementation (which takes specific command-line > arguments), and we should simply deliver the results. > > ------------------------------------------------------------------------- > 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-29 18:01:17
|
On Fri, Aug 29, 2008 at 9:46 AM, Branan Riley <br...@gm...> wrote: > Yes, technically XSLT is the only way to transform it. I meant there > are a number of programs already created that are already layered on > top of XSLT, at least in Linux. I don't know about the Windows and Mac > worlds. If we can use on of those, it saves us the trouble of writing > our own. I'm not sure I understand what you're talking about when you refer to programs that are "layered on top of XSLT." Can you give me an example? We should not be looking for any XSLT implementation on the host system. Instead, our system for building documents should use a specific XSLT implementation (which takes specific command-line arguments), and we should simply deliver the results. |
|
From: Branan R. <br...@gm...> - 2008-08-29 16:46:55
|
Yes, technically XSLT is the only way to transform it. I meant there are a number of programs already created that are already layered on top of XSLT, at least in Linux. I don't know about the Windows and Mac worlds. If we can use on of those, it saves us the trouble of writing our own. As for forcing people to build docs, I can add a GLSDK_DOCS flag just like we have a GLSDK_TEST flag, so CMake only builds the docs when you want it to. Branan On Fri, Aug 29, 2008 at 9:42 AM, Jason McKesson <ko...@gm...> wrote: > Branan Riley wrote: >> Since we've decided on DocBook files for our documentation, we now >> have the question of how we're going to convert those into HTML, PDF, >> or whatever format we decide upon. >> >> There are lots of tools for this, but I don't know which ones are >> cross-platform, and which ones will meet our needs. I can't make CMake >> generate our docs until I know what tool we're using for it. >> > There's really only 1 tool for transforming XML into other things: XSLT. > It is a language for converting XML documents into other XML documents > (though it can also output text and non-X-HTML). > > The two most common XSLT processors are Saxon (Java) and the LibXML2 (C) > XSLT processor. There are Saxon processors for XSLT 1 and 2, but LibXML2 > only supports XSLT 1. Fortunately (or unfortunately, if you like XSLT > 2), the only XSLT documents that are in the wild are version 1; the > complexity of writing a version 2 processor tends to keep people away > from it (despite the fact that Saxon's XSLT 2 implementation has been > available for a good 2 years now). > > DocBook XSL is generally the common way of transforming DocBook into > various output formats. Converting DocBook to PDF requires an additional > tool: Apache FOP (or another XSL-FO processor), which is a Java tool. > Indeed, most XSL-FO processors are Java, but FOP is the only free one of > any real quality that I know of. > > Also, CMake should not be generating our docs at all. I wouldn't want to > force Java on someone just to give them PDF. The documentation building > should be done when we go about the process of making a release, and the > final documents should be part of that release. > > However, I would suggest we hold off on dealing with the documentation > conversion issue for the time being. My main focus at present is on GLE, > and document conversion needs to deal with formatting questions that I > don't have time to focus on right now. > > ------------------------------------------------------------------------- > 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: Rob B. <rb...@bl...> - 2008-08-29 16:43:03
|
Hello Henri , yep I'm still here.. I think the #1 goal has to be "walk developers step by step through use of the API". I think to keep focus that we may need to set some explicit *non*-goals for a period of time, and here are a few I would suggest, since they don't help teach the API. a) SIMD optimization for the math lib. <- fun, but off course. b) anything that would tip the balance towards "web site authoring and maint" and away from making code. c) 3D geometry/math tutorials - we can link to any number of books/ sites for this stuff d) anything else that consumes calendar time at the expense of demo code. One class of example that might be interesting would be a Rosetta stone, where several ways to accomplish the same goal are shown. For example, simplest thing I can think of, a tumbling triangle. You can do it with all the math on the CPU and push finished verts to the GPU. You can then say "maybe I should do the rotation in the shader" and demonstrate how to hoist code from CPU to GPU and have it run in the shader. You could show one version where we compute the rotation matrix on the CPU and pass that as a uniform to be used trivially in the shader, then you could do one where (just for kicks) we pass Euler angles as uniforms and let the shader generate the matrix itself. We could do one where we pass non-Cartesian verts (azimuth/elevation and radius) and let the shader do polar-to-cartesian conversion. By the end of it you've learned a few different ways to push data from CPU to GPU and have it acted on. stops on the API-learning road.. please add some stops here - how do I establish a context and put it on the screen - make a window, init context, clear, swap - how do I put data in a buffer so GPU can see it - no drawing - just demonstrate the buffer API's - perhaps BufferData some floats into a buffer, then map it and print the values seen - how do I draw the simplest possible triangle - pass-through shader for vert position - "write red" for pixel - constant verts for geometry in a VBO - how can I change the color of the triangle - introduce per vertex color attribute - vertex shader passes it through - alter pixel shader to read it and emit it - introduction to uniforms - communicate to shaders - show color change using uniform (several ways to do this) - how can I move the triangle - see above that's a lot of good tutorial steps before we even start talking about more than one triangle. Ideally you get to the end of this phase and you have an idea of how to put data in a buffer, how to lay out some vertex data, how to draw a triangle, and how to communicate on a very basic level with the shaders, and no usage of deprecated APIs. Rob |
|
From: Jason M. <ko...@gm...> - 2008-08-29 16:42:07
|
Branan Riley wrote: > Since we've decided on DocBook files for our documentation, we now > have the question of how we're going to convert those into HTML, PDF, > or whatever format we decide upon. > > There are lots of tools for this, but I don't know which ones are > cross-platform, and which ones will meet our needs. I can't make CMake > generate our docs until I know what tool we're using for it. > There's really only 1 tool for transforming XML into other things: XSLT. It is a language for converting XML documents into other XML documents (though it can also output text and non-X-HTML). The two most common XSLT processors are Saxon (Java) and the LibXML2 (C) XSLT processor. There are Saxon processors for XSLT 1 and 2, but LibXML2 only supports XSLT 1. Fortunately (or unfortunately, if you like XSLT 2), the only XSLT documents that are in the wild are version 1; the complexity of writing a version 2 processor tends to keep people away from it (despite the fact that Saxon's XSLT 2 implementation has been available for a good 2 years now). DocBook XSL is generally the common way of transforming DocBook into various output formats. Converting DocBook to PDF requires an additional tool: Apache FOP (or another XSL-FO processor), which is a Java tool. Indeed, most XSL-FO processors are Java, but FOP is the only free one of any real quality that I know of. Also, CMake should not be generating our docs at all. I wouldn't want to force Java on someone just to give them PDF. The documentation building should be done when we go about the process of making a release, and the final documents should be part of that release. However, I would suggest we hold off on dealing with the documentation conversion issue for the time being. My main focus at present is on GLE, and document conversion needs to deal with formatting questions that I don't have time to focus on right now. |
|
From: Branan R. <br...@gm...> - 2008-08-29 15:51:13
|
Since we've decided on DocBook files for our documentation, we now have the question of how we're going to convert those into HTML, PDF, or whatever format we decide upon. There are lots of tools for this, but I don't know which ones are cross-platform, and which ones will meet our needs. I can't make CMake generate our docs until I know what tool we're using for it. Branan |
|
From: Branan R. <br...@gm...> - 2008-08-29 15:03:19
|
A couple more buidsystem points (this is what I get for not reading things completely before replying * Debug and release builds are already possible using -DCMAKE_BUILD_TYPE=Debug or -DCMAKE_BUILD_TYPE=Release. There's also a "RelWithDebInfo", which builds an optimized binary with debug symbols. * Building the docbook files can be done with ADD_CUSTOM_COMMAND. There may even be a CMake module to handle DocBook stuff. Branan On Fri, Aug 29, 2008 at 4:40 AM, Henri Häkkinen <hen...@gm...> wrote: > There are also other things where people could contribute to. > > Let me try to write a list of things to do: > > - a better build system, which would: > * output libs into libs/ subdir and tests/ under subdir or similar > * allow debug and release builds > * build html, manpage etc. documentation from the DocBook files > > - help with Branan's shapelib > > - help with current mathlib issues > (http://sourceforge.net/tracker/?group_id=237607&atid=1103788) > > - writing the GLM API reference in DocBook format (i am currently working on > this) > > - writing the SDK programming guide or at least designing it's contents > > - (low priority) someone who would collect all the decided coding > conventions etc. pieces into a more coherent file > > - (low priority) updated and professionally looking website with a CMS > > > On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote: >> >> > The reason why we haven't actually written tutorials is that nobody >> > has actually showed interest yet. >> > Hopefully we will get activity once GLFW gets GL3 update. >> >> Two more reasons: >> -we still have no final decision if we use GLFW or not - we could assume >> it will support OpenGL 3.0 eventually and temporarily make examples using >> OpenGL 2.1 (using only what's in 3.0) >> >> -we still have no shader library (minimally it should provide one default >> shader) - this is a minor problem, not an obstacle >> >> >> Honestly if we had both I wouldn't write tutorials anyway, but I should be >> "back in business" at the end of the year. Right now all I have is an old >> laptop with Intel GPU (somewhere around GeForce 2). >> >> >> ------------------------------------------------------------------------- >> 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 > |
|
From: Branan R. <br...@gm...> - 2008-08-29 14:56:59
|
I'll look at improving the CMake buildsystem a bit more. I don't necessarily know that we want to do build output to specific directories, but I can make "make install" work properly at the very least, and set the default install path to 'build/install'. Branan On Fri, Aug 29, 2008 at 4:40 AM, Henri Häkkinen <hen...@gm...> wrote: > There are also other things where people could contribute to. > > Let me try to write a list of things to do: > > - a better build system, which would: > * output libs into libs/ subdir and tests/ under subdir or similar > * allow debug and release builds > * build html, manpage etc. documentation from the DocBook files > > - help with Branan's shapelib > > - help with current mathlib issues > (http://sourceforge.net/tracker/?group_id=237607&atid=1103788) > > - writing the GLM API reference in DocBook format (i am currently working on > this) > > - writing the SDK programming guide or at least designing it's contents > > - (low priority) someone who would collect all the decided coding > conventions etc. pieces into a more coherent file > > - (low priority) updated and professionally looking website with a CMS > > > On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote: >> >> > The reason why we haven't actually written tutorials is that nobody >> > has actually showed interest yet. >> > Hopefully we will get activity once GLFW gets GL3 update. >> >> Two more reasons: >> -we still have no final decision if we use GLFW or not - we could assume >> it will support OpenGL 3.0 eventually and temporarily make examples using >> OpenGL 2.1 (using only what's in 3.0) >> >> -we still have no shader library (minimally it should provide one default >> shader) - this is a minor problem, not an obstacle >> >> >> Honestly if we had both I wouldn't write tutorials anyway, but I should be >> "back in business" at the end of the year. Right now all I have is an old >> laptop with Intel GPU (somewhere around GeForce 2). >> >> >> ------------------------------------------------------------------------- >> 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: Branan R. <br...@gm...> - 2008-08-29 14:53:49
|
You could tag both [doc,glm] Not that hard to write code that can parse [TOPIC] or [TOPIC1,TOPIC2] Branan On Fri, Aug 29, 2008 at 3:49 AM, Henri Häkkinen <hen...@gm...> wrote: > I studied some DocBook and started to write the GLM API reference on my own. > Somebody who knows about DocBook would you be kind enought to check my docs > in 'docs/sdk_reference/glm' and give me some advices. > > Also, when committing GLM API changes, should I use [DOC] or [GLM] tag for > commit messages? > > -- > 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: 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: H. H. <hen...@gm...> - 2008-08-29 11:40:33
|
There are also other things where people could contribute to. Let me try to write a list of things to do: - a better build system, which would: * output libs into libs/ subdir and tests/ under subdir or similar * allow debug and release builds * build html, manpage etc. documentation from the DocBook files - help with Branan's shapelib - help with current mathlib issues ( http://sourceforge.net/tracker/?group_id=237607&atid=1103788) - writing the GLM API reference in DocBook format (i am currently working on this) - writing the SDK programming guide or at least designing it's contents - (low priority) someone who would collect all the decided coding conventions etc. pieces into a more coherent file - (low priority) updated and professionally looking website with a CMS On Fri, Aug 29, 2008 at 12:19 PM, <gl...@mo...> wrote: > > The reason why we haven't actually written tutorials is that nobody > > has actually showed interest yet. > > Hopefully we will get activity once GLFW gets GL3 update. > > Two more reasons: > -we still have no final decision if we use GLFW or not - we could assume > it will support OpenGL 3.0 eventually and temporarily make examples using > OpenGL 2.1 (using only what's in 3.0) > > -we still have no shader library (minimally it should provide one default > shader) - this is a minor problem, not an obstacle > > > Honestly if we had both I wouldn't write tutorials anyway, but I should be > "back in business" at the end of the year. Right now all I have is an old > laptop with Intel GPU (somewhere around GeForce 2). > > > ------------------------------------------------------------------------- > 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: H. H. <hen...@gm...> - 2008-08-29 10:49:45
|
I studied some DocBook and started to write the GLM API reference on my own. Somebody who knows about DocBook would you be kind enought to check my docs in 'docs/sdk_reference/glm' and give me some advices. Also, when committing GLM API changes, should I use [DOC] or [GLM] tag for commit messages? -- Henri 'henux' Häkkinen |
|
From: <gl...@mo...> - 2008-08-29 09:19:57
|
> The reason why we haven't actually written tutorials is that nobody > has actually showed interest yet. > Hopefully we will get activity once GLFW gets GL3 update. Two more reasons: -we still have no final decision if we use GLFW or not - we could assume it will support OpenGL 3.0 eventually and temporarily make examples using OpenGL 2.1 (using only what's in 3.0) -we still have no shader library (minimally it should provide one default shader) - this is a minor problem, not an obstacle Honestly if we had both I wouldn't write tutorials anyway, but I should be "back in business" at the end of the year. Right now all I have is an old laptop with Intel GPU (somewhere around GeForce 2). |
1 message has been excluded from this view by a project administrator.
