Thread: Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 53

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

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
> ******************************************

Thread: Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 53

Utility libraries for working with OpenGL.

glsdk-devel