Re: [Flightgear-devel] bug report
On Tue, 2013-01-08 at 22:02 +0800, bhfx2...@sina.com wrote: > Version 2.10.0 > Simgear > window xp sp2 visual studio 2008+sp1 > > BVHPageNodeOSG(78): errorC2440: cannot convert > "const osg::Matrixf::value_type * to SGMatrixd Hi bhfx2012, Well I had no trouble with BVHPageNodeOSG.cxx(line 78) when I last compiled SG in Windows 7, using MSVC100 (2010), and OSGtrunk (2012/10/26) a few days ago (2013/01/02)... For fun, I just updated Simgear to 2.10 in my XP SP2 machine, and again had no problem with this file, or any file for that matter, using OSG 3.1.3 (circa 2012.05.15) using MSVC8 (2005). So, as asked before, directly - What OSG are you using? Obtained from where? Did you compile it, or are you using binaries from somewhere? What Boost version are you using? Obtained from where? Maybe it is something to do with the particular version combination. The compiler error seems strange, but maybe someone else has seen it before... Sorry can not be more help at this time... Regards, Geoff. -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader organization for 3.0
By the way, do you know this book ? http://books.google.fr/books/about/Texturing_and_Modeling.html?id=bDlSJd8GfMcC&redir_esc=y Regards, -Fred -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader organization for 3.0
> De: "Renk Thorsten" > > > Geometry shader can also process adjacency information if provided > > by the > > CPU through special primitives (GL_TRIANGLES_ADJACENCY and > > GL_TRIANGLE_STRIP_ADJACENCY) > > Oh, right - a geometry shader can probably receive a triangle as > input, compute its center of gravity, shift all vertices outward by > 5-10 m and return a slightly larger triangle to the vertex stage. I > know very little about geometry shaders, but it'd be a nice reason > to have a look. > > So, a sketch for a (probably rather unsophisticated scheme): > > * have a geometry shader make every triangle a little larger > > -> in level terrain, we get then overlap of differently textured > landclasses, and since we know how large we made the overlap region, > we can later fade the textures in that region > -> in sloped terrain, we get artefacts as the enlarged triangles do > not fit together properly, so > > * at the vertex shading stage, we need to determine if the terrain is > flat or not > -> if the terrain is flat, we use the overlap region to blend > textures later > -> if the terrain is a bit sloped, we shrink the overlap region (i.e. > we tell the fragment shader to fade to alpha much faster) > -> if the terrain is very sloped, we reduce it to zero > > * at the fragment stage, we somehow tag fragments in the region where > textures overlap and give them some alpha value > -> we end up with blended textures and (hopefullly manageable) > artifacts > > What's not clear to me is how we determine if a fragment is close to > a triangle edge or not. Somehow this requires to compare > uninterpolated vertex coordinates with interpolated vertex > coordinates, but it's not clear to me how the uninterpolated > coordinates can be passed to the fragment stage. > > What's also not clear to me if this would ultimately fail due to > z-fighting... > > Also, this scheme would operate on *any* triangle, regardless if it > is actually at the landclass boundary or not. I do believe its > operation would not show when there is no landclass boundary as one > blends same with same texture. > > Feels somehow still... unsatisfactory. > > > How about extending the BTG format to record for each vertex the > > distance to boundary (in tc unit). The terragear toolchain would compute it > > offline and the runtime loader would convey that value to the shader as a > > vertex attribute. Distance for each fragment would be interpolated in a > > varying. > > Well, yes - so then we know how far a fragment is from the boundary, > but what we don't know is what the texture is I should blend into - > so somehow we'd need to transport that, also allowing for edges in > which n different textures meet... Ugly, ugly... First, from your sketch, I think you misunderstood where the gs fit. In fact it operates on the result of the vertex shader, and its output is directly rasterized to the fragment shader. But you can have a null vertex shader (that do nothing except outputting its input) and do the vertex work in the gs as you can have all the vertices of the primitive in the same function. But currently the gs is not able to tell if the edge of the current triangle processed is convex or concave, because it has no idea of the 3 adjacent triangles. The geometry shader specification adds new primitives with adjacency. See http://web.engr.oregonstate.edu/~mjb/cs519/Handouts/geometry_shaders.6pp.pdf (6th slide). That can be used to generate silhouettes if the normals don't point to the same direction. But that would require to modify the C++ code in order to push the adjacency information to the GPU. By the way, as a gs is able to create geometry, instead of expanding a single triangle, you can output the original triangle and a flat boundary around it using 3 quads (in fact 6 additional triangles). Combined with adjacency information, that way there would be no extra geometry for the edge shared by 2 triangles of the same landmass and only one when landmass differs. Anyway, I don't thing the using geometry shader without adjacency info is satisfactory for the reason you already exposed (z-fighting, hairy surface, etc) Regards, -Fred -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Wayland, again
Awright then, I'll find out how to make a Wayland program and then supply you a prototype Wayland OSGV. -- 'We may not be Anonymous, for you can track our eMail. But we are soon to be legion, for we do not want censorship.' -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader organization for 3.0
> Geometry shader can also process adjacency information if provided by the > CPU through special primitives (GL_TRIANGLES_ADJACENCY and > GL_TRIANGLE_STRIP_ADJACENCY) Oh, right - a geometry shader can probably receive a triangle as input, compute its center of gravity, shift all vertices outward by 5-10 m and return a slightly larger triangle to the vertex stage. I know very little about geometry shaders, but it'd be a nice reason to have a look. So, a sketch for a (probably rather unsophisticated scheme): * have a geometry shader make every triangle a little larger -> in level terrain, we get then overlap of differently textured landclasses, and since we know how large we made the overlap region, we can later fade the textures in that region -> in sloped terrain, we get artefacts as the enlarged triangles do not fit together properly, so * at the vertex shading stage, we need to determine if the terrain is flat or not -> if the terrain is flat, we use the overlap region to blend textures later -> if the terrain is a bit sloped, we shrink the overlap region (i.e. we tell the fragment shader to fade to alpha much faster) -> if the terrain is very sloped, we reduce it to zero * at the fragment stage, we somehow tag fragments in the region where textures overlap and give them some alpha value -> we end up with blended textures and (hopefullly manageable) artefacts What's not clear to me is how we determine if a fragment is close to a triangle edge or not. Somehow this requires to compare uninterpolated vertex coordinates with interpolated vertex coordinates, but it's not clear to me how the uninterpolated coordinates can be passed to the fragment stage. What's also not clear to me if this wouldultimately fail due to z-fighting... Also, this scheme would operate on *any* triangle, regardless if it is actually at the landclass boundary or not. I do believe its operation would not show when there is no landclass boundary as one blends same with same texture. Feels somehow still... unsatisfactory. > How about extending the BTG format to record for each vertex the distance > to boundary (in tc unit). The terragear toolchain would compute it > offline > and the runtime loader would convey that value to the shader as a vertex > attribute. Distance for each fragment would be interpolated in a varying. Well, yes - so then we know how far a fragment is from the boundary, but what we don't know is what the texture is I should blend into - so somehow we'd need to transport that, also allowing for edges in which n different textures meet... Ugly, ugly... * Thorsten -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] bug report
Version 2.10.0 Simgear window xp sp2 visual studio 2008+sp1 BVHPageNodeOSG(78): errorC2440: cannot convert "const osg::Matrixf::value_type * to SGMatrixd-- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader organization for 3.0
A random idea : > I can de-emphasize them by having one or two overlay textures > continuous across a boundary, so they don't stick out dramatically > at first sight as they would do without texture mixing, but I do not > know how to make them really go away except in very specific cases > (using vegetation ordering in altitude and gradient in the > mountains) - the shader simply doesn't know where the seams are, so > they can't be hidden. How about extending the BTG format to record for each vertex the distance to boundary (in tc unit). The terragear toolchain would compute it offline and the runtime loader would convey that value to the shader as a vertex attribute. Distance for each fragment would be interpolated in a varying. A clause in the effect file would control if that attribute is really needed to same GPU memory in case of simple effects not relying on this distance. BTW: fixed-function opengl as already the concept of polygon edge : we can express the fact that a triangle edge is a polygon edge in case of tessellation. It's a boolean attribute of the vertex. Geometry shader can also process adjacency information if provided by the CPU through special primitives (GL_TRIANGLES_ADJACENCY and GL_TRIANGLE_STRIP_ADJACENCY) Regards, -Fred -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader organization for 3.0
Hi Stuart, > That sounds like an excellent plan. Let me know how I can help. yes, I could definitely need a hand... Now since the holiday period is over, my coding time just decreased dramatically... So, if you like, I could give you what I have in terms of autumn colors and hires terrain shader/effect files so far and you could implement the GUI you envision for the future as well as the autum color rotation for trees like you suggested and maybe also test/refine the autumn effect for more/different areas (I've just tested central Europe, and many of the texture sheets are just proof-of-concept edited). I could then focus on ironing out the remaining quirks in the shader code, clean everything up and do some performance-enhancing tricks. Btw - the promised Wiki page documenting the terrain shader capabilities and configuration options from materials.xml is just growing, so it'll be ready soon: http://wiki.flightgear.org/Procedural_Texturing * Thorsten -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader organization for 3.0
> Agreed, this stuff is all about plausible heuristics, but I think this > one fails the 'plausible in enough areas' test. Hopefully we'll (soon) > be able to suggest land cover updates to fix any areas with these kind > of data issues, once the world scenery rebuild completes. Somewhat ironically, the procedural heuristics tends to produce (at least for my taste) much better visuals in lowres scenery than in hires scenery. The reason is that while I can fix tiling and detail resolution for good, I can not really fix the sharp landcover boundaries. I can de-emphasize them by having one or two overlay textures continuous across a boundary, so they don't stick out dramatically at first sight as they would do without texture mixing, but I do not know how to make them really go away except in very specific cases (using vegetation ordering in altitude and gradient in the mountains) - the shader simply doesn't know where the seams are, so they can't be hidden. As a result, we get beautifully organic transitions of forest into grass or rock patches where the shader drives the transition, mixed with the straight line divisions introduced by landcover (and terrain tile) boundaries. And thus for instance the lowres desert scenery around Las Vegas where all is essentially classified as ShrubCover and then all visible structure is generated by the shader looks more to me a bit more compelling than hires France scenery where lots of rock bands are genuine landcover. So to my mind, the landcover boundaries are currently the single most severe obstacle to close-to-photo-quality terrain rendering, and I think any strategy to give the shaders the means to smooth them over would be highly valuable (needless to say, I don't have any idea how to do that in the current framework - somehow if we would know the center position of each triangle, we could expand it in the vertex shader to overlap with the neighbours and make the edge more transparent in the fragment shader - that would do the trick - but we don't have the triangle center position...). Anyway, my 5 cents... * Thorsten -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of Wayland and Flightgear
> De: "James Turner" > On 8 Jan 2013, at 06:01, Jack Johnson wrote: > > Flightgear does not support Wayland yet. > > Pretty sure this is entirely an OSG issue - maybe you should > investigate the status there. We just take osgViewer and use it (on > all platforms), so whatever osgViewer does regarding X11 or Wayland > is what we'll do too. Maybe Jack ignore that we rely mostly on Direct Rendering for OpenGL 3D acceleration and not on networked X11 protocol for drawing the view. Regards, -Fred -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The state of Wayland and Flightgear
On 8 Jan 2013, at 06:01, Jack Johnson wrote: > Flightgear does not support Wayland yet. Pretty sure this is entirely an OSG issue - maybe you should investigate the status there. We just take osgViewer and use it (on all platforms), so whatever osgViewer does regarding X11 or Wayland is what we'll do too. James -- Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS and more. Get SQL Server skills now (including 2012) with LearnDevNow - 200+ hours of step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only - learn more at: http://p.sf.net/sfu/learnmore_122512___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
