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