Menu
▾
▴
Re: [Glsdk-devel] Glsdk-devel Digest, Vol 1, Issue 53
|
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
> ******************************************
|
