Re: [osg-users] OpenSceneGraph-2.8.0-rc6 tagged, please test
Hi Martin,
On Sun, Feb 22, 2009 at 9:54 PM, Martin Spott martin.sp...@mgras.net wrote:
Ok, unless I'm getting contradictory test results tomorrow, this looks like
a working procedure to build OSG 2.8 on AIX = 5 with GCC.
1.) Point CMake to CURL- and probably other libraries like:
-D CURL_LIBRARY=/opt/freeware/lib/libcurl.a \
-D CURL_INCLUDE_DIR=/opt/freeware/include/curl
Did you build libcurl and other libraries yourself?
It does sound like the CMake find modules don't have these paths
listed for AIX so it'd be worth contacting the CMake team about their
placement so they can adjust their search paths to find these libs.
2.) Apparently the test for 'libm' fails on my AIX machine (I'm unable to
tell why), so call CMake with:
-D MATH_LIBRARY=/lib/libm.a
Starting to sound like CMake hasn't been tested much under AIX... so
it'd be worth pinging them about your findings, they are normally very
responsive about get things like this fixed, then hopefully you won't
have problems with future revs of CMake.
3.) I suspect there's an old workaround for AIX releases _before_ AIX 5.
Presumably the previous releases had their OpenGL headers stored in
/usr/include/OpenGL/. Therefore I had to modify a little compile time
switch:
diff -urNb include/osg.release/GLU include/osg/GLU
--- include/osg.release/GLU Wed Oct 3 22:21:01 2007
+++ include/osg/GLU Sun Feb 22 21:59:07 2009
@@ -16,7 +16,8 @@
#include osg/GL
-#if defined(__APPLE__) || defined (_AIX)
+#if defined(__APPLE__) || \
+(defined (_AIX) !defined (_AIX51))
#include OpenGL/glu.h
#else
#include GL/glu.h
4.) Finally, almost all of the floating point types seem to be undefined on
AIX, at least with GCC - I decided to re-use some switches which are alredy
in place for the use on other commercial Unix systems:
diff -urNb include/osg.release/Math include/osg/Math
--- include/osg.release/MathSun Nov 23 12:35:43 2008
+++ include/osg/MathSun Feb 22 22:24:46 2009
@@ -44,7 +44,9 @@
#include float.h
#endif
-#if defined (sun) || defined (__APPLE__)
+#if defined (sun) || \
+defined (__APPLE__) || \
+(defined (_AIX) defined (__GNUC__))
#include float.h
@@ -93,7 +95,8 @@
#if defined (sun) || \
defined (__hpux) || \
-defined (APPLE_PRE_10_2)
+defined (APPLE_PRE_10_2) || \
+(defined (_AIX) defined (__GNUC__))
#ifndef floorf
inline float floorf(float value) { return
static_castfloat(floor(value)); }
Could you post the header file changes to osg-submissions, I can then
merge them with svn/trunk and the OSG-2.8 branch so that when we make
2.8.1 it should work better out the box under AIX.
Even though my server has 8 CPU's, they only run at 200 MHz each, so I don't
expect the build to be ready before tomorrow :-)
I remember when such a machine would have been considered high end...
but over a decade has past since then!
Thanks for perceiving with this testing.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non emissive ParticleSystem and lighting
Sukender's post lets me know I'm not the only one having the problem, so I must do things correctly. Sure, using the particles systems as emissive and changing on the run particles colors would work, but it's a pain (!). Having a specific set of classes taking care of the internals of the particle behaviour should allow the programmer to let them live they life whatever the changing of conditions. Besides, it's what the interface leads to expect, the emissive and lighting boolean being free to take the 'false' value (actually I don't understand why it doesn't work - at least concerning the ambient -, since in the implementation everything seems to be done to enable LIGHTING onto the stateset... but I must be missing something). If useful, I'll try today to find some time to modify the simple sample code to show the problem. As I recall, the key is the lighting parameter, the emissive_particles ones allowing just to have an additive blend func on sprites... I'm using myself customized PS subclasses (to ensure deterministic randoms, and other things) and a bit more complex lighting conditions model, but the anomaly will be same. Christophe --- Message d'origine --- De : Robert Osfield robert.osfi...@gmail.com À : OpenSceneGraph Users osg-users@lists.openscenegraph.org Sujet : Re: [osg-users] Non emissive ParticleSystem and lighting Date : dim 22 fév 2009 11:41:45 CET Can't you change the particle colour to be appropriate for different times of day? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Load uniform sampler2D in shader from .osg file
Hi, I still cant get this working. I tried using getSteteSet instead of GetOrCreateStateSet, but it returns a valid StateSet and when i get the texture attribute list, its size is 1 (so i assume tha this is the texture unit im looking for). After that i create the unifor using this texture unit number (0): Code: osg::Uniform* textureUniform = new osg::Uniform(osg::Uniform::SAMPLER_2D, baseMap); textureUniform-set(0); ss-addUniform(textureUniform); But it still shows as black. Any idea? J. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7178#7178 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
Hi Paul and Robert, What Paul points out about GL 3.1 raises a simple question: Will OSG 3 be... 1. Based on GL 3.0? 2. Based on GL 3.1? 3. API agnostic, but will wait GL 3.0? 4. API agnostic, but will wait GL 3.1? 5. other? Going directly to an API agnostic OSG seems as risky as interesting. And IMHO, waiting for GL 3.1 seems very interesting too, as we may see the 3D future's a bit clearer. However, if GL 3.1 does not come shortly after 3.0, we may loose too much time. Any rough idea on the delay before GL 3.1 specs are released? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 20 Feb 2009 17:58:15 +0100, Paul Martz pma...@skew-matrix.com a écrit: Hi folks -- As a Khronos member, I have some insider knowledge about OpenGL 3.1, but as the spec is not yet available, I am not at liberty to divulge specifics. Instead, though, I'll reference the slide set presented at last year's SIGGRAPH in which it stated clearly and plainly plan on deprecated functionality going away sooner rather than later. If you interpolate from there, then in OpenGL 3.1 (and GLSL 1.40) and beyond, the fixed function pipe is gone, and all associated state is gone, and all predefined uniforms are gone. So, to answer the query how to access lighting state from a shader?, you can't set it on the host, and you can't access it from a shader, because it no longer exists. If you need _any_ uniform in your shader, you must explicitly create that uniform on the host and explicitly declare it in your shader. This is the future of OpenGL. Also worth noting, glVertexPointer, glColorPointer, glNormalPointer, etc., are also all gone, and correspondingly, gl_Vertex, gl_Color, etc., are all gone as well. All vertex data, including the vertices themselves, get passed to shaders as generic attributes. The modelview and projection matrix uniforms are gone; you'll need to create them yourself if you need them. ftransform() is gone. This greatly changes the way you think about OpenGL, and about how the scene graph should work, and how to move forward with OSG. I have some ideas about a scene graph built on Open GL 3.1. I haven't really finalized them yet, but supporting the current OSG core API seems unlikely. I suggest you wait for OpenGL 3.1 to be released before you make solid plans for OSG's future. You really need to see the 3.1 spec (and GLSL 1.40) to know which direction to steer the OSG ship. The 3.1 spec will probably be out very soon (before SIGGRAPH). Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
Hi all, IMO, trying to create the shader-fixed mapping ourselves is a mistake. Others surely encountered the same promblem and it may have already been solved, or partially solved (as the ShaderGen Ralph and Brian told about). I think some people of the OSG community could even join an existing project to ensure that it fits our needs. Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Fri, 20 Feb 2009 16:00:08 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Brian + Ralf, I did recall 3DLabs doing something, but didn't recall the name of this project... thanks for the pointers, and thank too to Mike for preserving shadergen. Anybody know about the portability of this app? Is Windows only? Also does anybody know of documented list of mapping? Robert. On Fri, Feb 20, 2009 at 2:40 PM, Brian R Hill bhil...@csc.com wrote: Mike Weiblen's site has the shadergen tool. http://mew.cx/glsl/shadergen/ Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. • -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Robert Osfield robert.osfi...@gmail.com Sent by: osg-users-boun...@lists.openscenegraph.org Date: 02/20/2009 09:12AM Subject: [osg-users] Fixed function pipeline - GLSL shaders Hi All, One of the items I have ticking away as a background process is the topic of how we should gracefully manage the transition from the usage of fixed function pipeline to entirely shader based implementations. One motivation is the obvious one - GL3 and OpenGL ES don't have any fixed function pipeline, so we need to know how to implement the current OSG functionality that relies upon fixed function pipeline, and a second more subtle one - how to manage the combination of different shaders in a way that is as flexible and intuitive as the fixed function pipeline is for composing different elements of state together. This isn't an easy problem to solve, and rather than try to come up with a complete solution right now, in tinkering round the edges trying to get a better picture of the landscape of the problem. One area we can map out right now is that of how existing fixed function pipeline features would map to GLSL shaders. I recall that such a mapping has been published, but a quick search on the web didn't pin point it. Does anyone have a reference to such a body of work? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non emissive ParticleSystem and lighting
Hi Roland, Maybe I'm too tired to see it, but where it the link with doing diffuse or ambient interact with the particle without having to code things? Anyway, this was a very interesting article. Thanks! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Sun, 22 Feb 2009 21:13:11 +0100, Roland Smeenk osgfo...@tevs.eu a écrit: Sukender, Look for premultiplied alpha. This allows for mixing additive and alpha blending in a single texture. See http://home.comcast.net/~tom_forsyth/blog.wiki.html#[[Premultiplied%20alpha]] -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7171#7171 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
Hi Robert et al, I thought about concept of generating shader code in cull traversal from shader snippets. Snippet is a piece of GLSL code that implements certain functionality like texture sampling or lighting, usually few lines of code. Snippets have defined inputs like required varyings, uniforms and output variables of dependant snippets. Output of snippet is a glsl variable (i.e. texture coordinate, texture color) for internal snippet or gl_FragColor/gl_FragData for terminal snippet. Snippets sit in a StateSet just like modes and attributes. In cull traversal dependency graph of snippets is created. From this graph GLSL program is generated or fetched from cache. This approach would allow to seamlessly use functionality from different toolkits without the need to rewrite shaders or to use ubershader. Toolkits such as osgShadow or osgFX would expose shader snippets for certain effects (shadow, phong lighting, atmospheric fog, etc) which could be merged into snippet dependency graph. To imlement fixed function pipeline functionality one can define mapping from modes/attributes to snippets. It is just a concept. I do not know would it work in terms of ease of use and extensibility. GLSL is a must in these days especially for one reason - per pixel lighting. It is a pity that it is not exposed in a fixed function pipeline. In my applications I map fixed function pipeline to GLSL with custom visitor. Based on state set modes (lighting, fog, ...) and vertex attributes (normal, tangent, texco, ...) GLSL shaders are generated and cached in a map (modes, vertAttribs)=shader so they are unique. Only certain cases of FFP are handled. Visitor is called in ReadFileCallback to convert FFP to GLSL. In typical scenario You need only a few unique shaders (light on/off, color map on/off, normal map on/off, env map on/off, fog on/off). Such simple solution really pays off in visual quality of scenes. Regards, Maciej 2009/2/20 Robert Osfield robert.osfi...@gmail.com Hi All, One of the items I have ticking away as a background process is the topic of how we should gracefully manage the transition from the usage of fixed function pipeline to entirely shader based implementations. One motivation is the obvious one - GL3 and OpenGL ES don't have any fixed function pipeline, so we need to know how to implement the current OSG functionality that relies upon fixed function pipeline, and a second more subtle one - how to manage the combination of different shaders in a way that is as flexible and intuitive as the fixed function pipeline is for composing different elements of state together. This isn't an easy problem to solve, and rather than try to come up with a complete solution right now, in tinkering round the edges trying to get a better picture of the landscape of the problem. One area we can map out right now is that of how existing fixed function pipeline features would map to GLSL shaders. I recall that such a mapping has been published, but a quick search on the web didn't pin point it. Does anyone have a reference to such a body of work? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
HI Sukender, On Mon, Feb 23, 2009 at 9:38 AM, Sukender suky0...@free.fr wrote: What Paul points out about GL 3.1 raises a simple question: Will OSG 3 be... 1. Based on GL 3.0? 2. Based on GL 3.1? 3. API agnostic, but will wait GL 3.0? 4. API agnostic, but will wait GL 3.1? 5. other? Going directly to an API agnostic OSG seems as risky as interesting. And IMHO, waiting for GL 3.1 seems very interesting too, as we may see the 3D future's a bit clearer. However, if GL 3.1 does not come shortly after 3.0, we may loose too much time. Any rough idea on the delay before GL 3.1 specs are released? First I have to say that the OSG 2.8 already has almost all of the hardware support that will be available in OpenGL 3, thanks to the OpenGL 2.x extensions that we already support. The whole idea of OpenGL 3.1 being new clean API isn't actually that critical as we already have implemented the scene graph, it's not as if we are about to write a new game from a completely clean slate, so the value in the new trimmed API is not so critical for us, OpenGL 2.x + extensions actually does pretty well. This fact puts us in a position of strength, we can move to supporting GL 3 when we ready, and the similarity between GL 3 and GL 2 + extensions actually means a lot of high level solutions will work across both as well. Taken in this context GL 3 isn't the big leap in itself. The big leap is embracing more flexible composition of state, this is in essence what the next gen scene graph will have to embrace. My current thought on the overall situation for the future of the OSG is that we need to make composition of state better across OpenGL 2, OpenGL 3, as well OpenGL ES and OpenCL + C++ rendering backends. In this context the GL3 is actually a relatively minor part of jigsaw, and rather than OSG 2.x being an OpenGL 2.x scene graph, and OSG 3.x being an OpenGL 3.x scene graph, OSG 3.x becomes a scene graph + flexible rendering backends that are associated with different types of graphics context that we create. If OSG 3.x isn't able to make this leap then I think it would fall rather short of the opportunities available in widening the OSG's platform capabilities. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
HI Marciej, You thoughts on shader snippets being collected and assembled into programs that are then cached is roughly what I've been envisaging as well. It's something I did try to get my head around when we integrated GLSL into the core OSG a few years back, but the complexity of this system meant that much more time would have to be invested in developing, so rather than be so ambitious we went for the current approach of decoupling uniforms from osg::Program, but not the whole hog of decoupling osg::Shader from osg::Program. The full blown shader composition is something we do need to address in the next generation of the OSG. Exactly what the interface should be, and how we implement the back-end is the big hard part. Once we have such a scheme in place then provided only fixed function style capabilities in GL3 or GL2 GLSL path ways should be much easier. At this point the distinction between the fixed function pipeline and shader pipeline will melt away and become an implementation detail, rather than a scene graph interface one. Robert. On Mon, Feb 23, 2009 at 10:04 AM, Maciej Krol mack...@gmail.com wrote: Hi Robert et al, I thought about concept of generating shader code in cull traversal from shader snippets. Snippet is a piece of GLSL code that implements certain functionality like texture sampling or lighting, usually few lines of code. Snippets have defined inputs like required varyings, uniforms and output variables of dependant snippets. Output of snippet is a glsl variable (i.e. texture coordinate, texture color) for internal snippet or gl_FragColor/gl_FragData for terminal snippet. Snippets sit in a StateSet just like modes and attributes. In cull traversal dependency graph of snippets is created. From this graph GLSL program is generated or fetched from cache. This approach would allow to seamlessly use functionality from different toolkits without the need to rewrite shaders or to use ubershader. Toolkits such as osgShadow or osgFX would expose shader snippets for certain effects (shadow, phong lighting, atmospheric fog, etc) which could be merged into snippet dependency graph. To imlement fixed function pipeline functionality one can define mapping from modes/attributes to snippets. It is just a concept. I do not know would it work in terms of ease of use and extensibility. GLSL is a must in these days especially for one reason - per pixel lighting. It is a pity that it is not exposed in a fixed function pipeline. In my applications I map fixed function pipeline to GLSL with custom visitor. Based on state set modes (lighting, fog, ...) and vertex attributes (normal, tangent, texco, ...) GLSL shaders are generated and cached in a map (modes, vertAttribs)=shader so they are unique. Only certain cases of FFP are handled. Visitor is called in ReadFileCallback to convert FFP to GLSL. In typical scenario You need only a few unique shaders (light on/off, color map on/off, normal map on/off, env map on/off, fog on/off). Such simple solution really pays off in visual quality of scenes. Regards, Maciej 2009/2/20 Robert Osfield robert.osfi...@gmail.com Hi All, One of the items I have ticking away as a background process is the topic of how we should gracefully manage the transition from the usage of fixed function pipeline to entirely shader based implementations. One motivation is the obvious one - GL3 and OpenGL ES don't have any fixed function pipeline, so we need to know how to implement the current OSG functionality that relies upon fixed function pipeline, and a second more subtle one - how to manage the combination of different shaders in a way that is as flexible and intuitive as the fixed function pipeline is for composing different elements of state together. This isn't an easy problem to solve, and rather than try to come up with a complete solution right now, in tinkering round the edges trying to get a better picture of the landscape of the problem. One area we can map out right now is that of how existing fixed function pipeline features would map to GLSL shaders. I recall that such a mapping has been published, but a quick search on the web didn't pin point it. Does anyone have a reference to such a body of work? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
This paper might be of interest: Automated Shader Generation using a Shader Infrastructure http://www.codesampler.com/papers/Automated%20Shader%20Generation%20using%20a%20Shader%20Infrastructure.pdf -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7186#7186 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenSceneGraph-2.9.0 dev release tagged
Hi All, Another week, another dev release, no massive changes since 2.8.0, but a few bug fixes and minor feature additions that should keep us all happy ;-) Developmer release page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases Details: OpenSceneGraph-2.9.0, released on 23rd February 2009. OpenSceneGraph-2.9.0, changes include: o Under VisualStudio builds VisualStudio specific version information now embedded in core libraries and plugins. o Improved support in osgconv for writing out of compressed imagery to .osg or .ive files with external imagery. o Support for using ARB_vertex_program and ARB_fragment_program added to osgforest example. o Points support added to dxf plugin. o Bug fixes to State::reset(), dxf plugin, hdr plugin and draw instanced for ushort and uint versions of osg::DrawElements?. source package : OpenSceneGraph-2.9.0.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.0 OpenSceneGraph The bug fixes above have also made it into the OSG-2.8 post 2.8.0, so testing the build out for 2.9.0 will be a useful precursor to use make a 2.8.1 stable release. I'll leave going for a 2.8.1 release till next month as this will give us all a bit more time to find further bugs that weren't revealed in the run up to 2.8.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Switching post-processing on/off
Ken, I experienced something similar with osgPPU. I can add a osgPPU post processor to a camera and even switch between different post processors, but returning to a non render-to-texture camera did not work. For now I am settling for using a pass though post processor, but I would like to entirely disable the extra render pass. Does anybody else have any experience with switching on/off the RTT at runtime? -- Roland -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7187#7187 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Fixed function pipeline - GLSL shaders
Hi Robert,
I think shader composition would be the next big thing for OSG although
robust design is far from trivial. For most users hiding shaders or
snippets would be the good thing. I would love to have state sets with OSG
modes not GL ones i.e.
StateSet
{
OSG_LIGHTING ON
osgLightingModel {
mode PHONG
}
OSG_NORMAL_MAP ON
OSG_SHADOW ON
OSG_FOG ON
osgFogModel {
mode VOLUMETRIC
upDir 0 0 1
}
}
Power user could register ther own modes/attributes handled by external
toolkits. With this approach different backends for GL1, GL2, GL3, GLES,
Sofware rasterizer, Software raytracer, DirectX :) could be implemented.
Regards,
Maciej
2009/2/23 Robert Osfield robert.osfi...@gmail.com
HI Marciej,
You thoughts on shader snippets being collected and assembled into
programs that are then cached is roughly what I've been envisaging as
well. It's something I did try to get my head around when we
integrated GLSL into the core OSG a few years back, but the complexity
of this system meant that much more time would have to be invested in
developing, so rather than be so ambitious we went for the current
approach of decoupling uniforms from osg::Program, but not the whole
hog of decoupling osg::Shader from osg::Program.
The full blown shader composition is something we do need to address
in the next generation of the OSG. Exactly what the interface should
be, and how we implement the back-end is the big hard part. Once we
have such a scheme in place then provided only fixed function style
capabilities in GL3 or GL2 GLSL path ways should be much easier. At
this point the distinction between the fixed function pipeline and
shader pipeline will melt away and become an implementation detail,
rather than a scene graph interface one.
Robert.
On Mon, Feb 23, 2009 at 10:04 AM, Maciej Krol mack...@gmail.com wrote:
Hi Robert et al,
I thought about concept of generating shader code in cull traversal from
shader snippets. Snippet is a piece of GLSL code that implements certain
functionality like texture sampling or lighting, usually few lines of
code.
Snippets have defined inputs like required varyings, uniforms and output
variables of dependant snippets. Output of snippet is a glsl variable
(i.e.
texture coordinate, texture color) for internal snippet or
gl_FragColor/gl_FragData for terminal snippet. Snippets sit in a StateSet
just like modes and attributes. In cull traversal dependency graph of
snippets is created. From this graph GLSL program is generated or fetched
from cache. This approach would allow to seamlessly use functionality
from
different toolkits without the need to rewrite shaders or to use
ubershader.
Toolkits such as osgShadow or osgFX would expose shader snippets for
certain
effects (shadow, phong lighting, atmospheric fog, etc) which could be
merged
into snippet dependency graph. To imlement fixed function pipeline
functionality one can define mapping from modes/attributes to snippets.
It
is just a concept. I do not know would it work in terms of ease of use
and
extensibility.
GLSL is a must in these days especially for one reason - per pixel
lighting.
It is a pity that it is not exposed in a fixed function pipeline. In my
applications I map fixed function pipeline to GLSL with custom visitor.
Based on state set modes (lighting, fog, ...) and vertex attributes
(normal,
tangent, texco, ...) GLSL shaders are generated and cached in a map
(modes,
vertAttribs)=shader so they are unique. Only certain cases of FFP are
handled. Visitor is called in ReadFileCallback to convert FFP to GLSL. In
typical scenario You need only a few unique shaders (light on/off, color
map
on/off, normal map on/off, env map on/off, fog on/off). Such simple
solution
really pays off in visual quality of scenes.
Regards,
Maciej
2009/2/20 Robert Osfield robert.osfi...@gmail.com
Hi All,
One of the items I have ticking away as a background process is the
topic of how we should gracefully manage the transition from the usage
of fixed function pipeline to entirely shader based implementations.
One motivation is the obvious one - GL3 and OpenGL ES don't have any
fixed function pipeline, so we need to know how to implement the
current OSG functionality that relies upon fixed function pipeline,
and a second more subtle one - how to manage the combination of
different shaders in a way that is as flexible and intuitive as the
fixed function pipeline is for composing different elements of state
together.
This isn't an easy problem to solve, and rather than try to come up
with a complete solution right now, in tinkering round the edges
trying to get a better picture of the landscape of the problem. One
area we can map out right now is that of how existing fixed function
pipeline features would map to GLSL shaders. I recall that such a
mapping has been published, but a quick
Re: [osg-users] Switching post-processing on/off
Hi Ken, Roland, would it add more problems if you use 2 cameras (one with postprocessing and another one without) and just switch between those 2 cameras? There exists osg::Switch-node which can do this for you. However I haven't tried to switch cameras, but I think it should work too. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7190#7190 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Can't build libraries under windows
Hi,
I am trying to build the OSG libraries under Windows XP (so I can use them for
c++ development using mingw32 compiler)
I have downloaded and extracted the source zip to Desktop\OpenSceneGraph-2.8.0
then I created a folder OSGBuild on the desktop, as build location.
I checked out the dependencies from svn, to the folder OSGDep (somewhere else
on the system)
I configured OSG using cmake-gui, and set the path to OSGDep as
CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH and CMAKE_PREFIX_PATH.
But when building, it stops when creating mingw_osgdb_jpeg.dll
This is the output:
Code:
Warning: .drectve `/manifestdependency:type='win32' name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
Warning: .drectve `/manifestdependency:type='win32' name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
Warning: .drectve `/manifestdependency:type='win32' name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86' publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
{... lots more of these messages ...}
C:\Documents and Settings\jbijl\My Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x27): undefined reference to `__security_cookie'
C:\Documents and Settings\jbijl\My Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x55): undefined reference to `_impiob_func'
C:\Documents and Settings\jbijl\My Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x70): undefined reference to `...@__security_check_cookie@4'
C:\Documents and Settings\jbijl\My Documents\workspace\OSGDep\lib\libjpeg.lib(jd
marker.obj):(.text+0x707): undefined reference to `__security_cookie'
{... lots more of these messages ...}
follow
collect2: ld returned 1 exit status
mingw32-make[2]: *** [bin/osgPlugins-2.8.0/mingw_osgdb_jpeg.dll] Error 1
mingw32-make[1]: *** [src/osgPlugins/jpeg/CMakeFiles/osgdb_jpeg.dir/all] Error 2
mingw32-make: *** [all] Error 2
Could you please help me by either:
telling me how to solve this
telling me of another way to acquire the win32 mingw libraries I need to
develop software that uses OSG.
thanks
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7191#7191
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Switching post-processing on/off
On Mon, Feb 23, 2009 at 11:18 AM, Art Tevs osgfo...@tevs.eu wrote: would it add more problems if you use 2 cameras (one with postprocessing and another one without) and just switch between those 2 cameras? There exists osg::Switch-node which can do this for you. However I haven't tried to switch cameras, but I think it should work too. I haven't ever tried it, but perhaps you could set the camera's rendering cache to 0, to detect it from any created rendering backend i.e. camera-setRenderingCache(0); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Can't build libraries under windows
Hi Janatan,
I'm not Window users myself, but from reading the list I have picked
up that the VisualStudio binaries aren't compatible with other version
of VS let alone other compilers completely... So my guess is that you
will have to compile the dependencies using Mingw if you wish to use
them.
Robert.
On Mon, Feb 23, 2009 at 11:20 AM, Jonatan osgfo...@tevs.eu wrote:
Hi,
I am trying to build the OSG libraries under Windows XP (so I can use them
for c++ development using mingw32 compiler)
I have downloaded and extracted the source zip to Desktop\OpenSceneGraph-2.8.0
then I created a folder OSGBuild on the desktop, as build location.
I checked out the dependencies from svn, to the folder OSGDep (somewhere else
on the system)
I configured OSG using cmake-gui, and set the path to OSGDep as
CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH and CMAKE_PREFIX_PATH.
But when building, it stops when creating mingw_osgdb_jpeg.dll
This is the output:
Code:
Warning: .drectve `/manifestdependency:type='win32'
name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
Warning: .drectve `/manifestdependency:type='win32'
name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
Warning: .drectve `/manifestdependency:type='win32'
name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
{... lots more of these messages ...}
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x27): undefined reference to `__security_cookie'
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x55): undefined reference to `_impiob_func'
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x70): undefined reference to `...@__security_check_cookie@4'
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(jd
marker.obj):(.text+0x707): undefined reference to `__security_cookie'
{... lots more of these messages ...}
follow
collect2: ld returned 1 exit status
mingw32-make[2]: *** [bin/osgPlugins-2.8.0/mingw_osgdb_jpeg.dll] Error 1
mingw32-make[1]: *** [src/osgPlugins/jpeg/CMakeFiles/osgdb_jpeg.dir/all]
Error 2
mingw32-make: *** [all] Error 2
Could you please help me by either:
telling me how to solve this
telling me of another way to acquire the win32 mingw libraries I need to
develop software that uses OSG.
thanks
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7191#7191
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgViewerSDL linling error
Hi osg-users, when I try to compile latest version from osgViewerSDL example is osg svn version, I have such error : Erreur1error LNK2019: symbole externe non résolu _main référencé dans la fonction ___tmainCRTStartupMSVCRTD.lib Erreur2fatal error LNK1120: 1 externes non résolus C:\Work\Dev\OpenSceneGraph-SVN\VisualStudio\bin\Debug\..\osgviewerSDLd.exe I do not succeed to remove this error, anybody have an idea ? I'm under Vista with MSVC 2005 SP1. Kind regards, -- Alexandre AMALRIC Ingénieur RD === PIXXIM S.A. 73E, rue Perrin-Solliers 13006 Marseille http://www.pixxim.fr ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Can't build libraries under windows
Hi Jonatan,
Agreed with Robert. You can't use Visual Studio dependencies with MinGW, as far
as I know. I don't know if there are MinGW dependencies compiled somewhere. You
may have to manually compile them all. If you acheive this, I suggest you let
the OSG community access your binaries :) That may be useful for MinGW users.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
Le Mon, 23 Feb 2009 12:42:15 +0100, Robert Osfield robert.osfi...@gmail.com a
écrit:
Hi Janatan,
I'm not Window users myself, but from reading the list I have picked
up that the VisualStudio binaries aren't compatible with other version
of VS let alone other compilers completely... So my guess is that you
will have to compile the dependencies using Mingw if you wish to use
them.
Robert.
On Mon, Feb 23, 2009 at 11:20 AM, Jonatan osgfo...@tevs.eu wrote:
Hi,
I am trying to build the OSG libraries under Windows XP (so I can use them
for c++ development using mingw32 compiler)
I have downloaded and extracted the source zip to
Desktop\OpenSceneGraph-2.8.0
then I created a folder OSGBuild on the desktop, as build location.
I checked out the dependencies from svn, to the folder OSGDep (somewhere
else on the system)
I configured OSG using cmake-gui, and set the path to OSGDep as
CMAKE_INCLUDE_PATH, CMAKE_LIBRARY_PATH and CMAKE_PREFIX_PATH.
But when building, it stops when creating mingw_osgdb_jpeg.dll
This is the output:
Code:
Warning: .drectve `/manifestdependency:type='win32'
name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
Warning: .drectve `/manifestdependency:type='win32'
name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
Warning: .drectve `/manifestdependency:type='win32'
name='Microsoft.VC80.CRT' v
ersion='8.0.50727.762' processorArchitecture='x86'
publicKeyToken='1fc8b3b9a1e18
e3b' /DEFAULTLIB:MSVCRT /DEFAULTLIB:OLDNAMES ' unrecognized
{... lots more of these messages ...}
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x27): undefined reference to `__security_cookie'
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x55): undefined reference to `_impiob_func'
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(je
rror.obj):(.text+0x70): undefined reference to
`...@__security_check_cookie@4'
C:\Documents and Settings\jbijl\My
Documents\workspace\OSGDep\lib\libjpeg.lib(jd
marker.obj):(.text+0x707): undefined reference to `__security_cookie'
{... lots more of these messages ...}
follow
collect2: ld returned 1 exit status
mingw32-make[2]: *** [bin/osgPlugins-2.8.0/mingw_osgdb_jpeg.dll] Error 1
mingw32-make[1]: *** [src/osgPlugins/jpeg/CMakeFiles/osgdb_jpeg.dir/all]
Error 2
mingw32-make: *** [all] Error 2
Could you please help me by either:
telling me how to solve this
telling me of another way to acquire the win32 mingw libraries I need to
develop software that uses OSG.
thanks
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7191#7191
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Destroying osgViewer::Viewer leads to strange effects in texturing
Hi Robert, thanks for your fast answer. I used osg 2.7.6. Updating to 2.9 and using releaseGLObjects() on the subgraphs solved the problem. Thank you very much. Katharina -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7198#7198 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg Image and PNG writer
Hi all, I'm working on a post-screenshot pass to apply to my pictures. I searching a way to define a color as transparent. (for png file) osg::Image do not allow this kind of modifications, or I don't know how... Did you do it ? any idea ? thanks, Regards, Vincent. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig: snapshot as numpy array?
Hi Gerwin, thanks for the code! Sadly I can't run it, because my osgViewer.View class has no addSlave method. That puzzles me, I use osg 2.6, which defines this method... Thx, Mathias -Ursprüngliche Nachricht- Von: Gerwin de Haan gerwindeh...@gmail.com Gesendet: 21.02.09 11:51:21 An: OpenSceneGraph Users osg-users@lists.openscenegraph.org Betreff: Re: [osg-users] osgswig: snapshot as numpy array? Hi Mathias, I've used the following python snippet to make hi-res screenshots using a slave camera and an FBO. I'm sure you could (or should) do this with a draw callback, but I started with explicitly calling this function myself to do some experimentation first. I did have some trouble on one machine, where the context (and so the image) would only contain the clear color. You could fill a numpy array from the image I guess. I would be interested in that. regards, Gerwin --- def fboshot(pFileName=screenshot.png, pWidth=1024,pHeight=768): screenshot experiment with a frame buffer object creates a new slave camera, attached to the viewer, draws, saves to image, removes the camera again import osg import osgDB viewer= __main__.viewer cam = viewer.getCamera() #prepare an image, to which a camera can render shot = osg.Image() shot.allocateImage(pWidth,pHeight,1, osg.GL_RGB, osg.GL_UNSIGNED_BYTE) #create a camera with an fbo render target hicam = osg.Camera() hicam.setGraphicsContext(cam.getGraphicsContext()) hicam.setRenderTargetImplementation(osg.Camera.FRAME_BUFFER_OBJECT) hicam.attach(osg.Camera.COLOR_BUFFER,shot) hicam.setViewport(0,0,pWidth,pHeight) #add a slave camera viewer.addSlave(hicam) #render one frame viewer.frame() #store the shot taken osgDB.writeImageFile(shot,pFileName) #remove this camera again viewer.removeSlave(0) ___ Jetzt 1 Monat kostenlos! WEB.DE FreeDSL - Telefonanschluss + DSL für nur 17,95 EURO/mtl.!* http://dsl.web.de/?ac=OM.AD.AD008K15039B7069a ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg swig: crashes with nvidia
Hi, I have a strange problem: when I compile osg 2.4 or 2.6 and osgswig on debian etch everything works fine with intel, ati or mesa graphics but doing the same thing on a virtually identical machine but with nvidia graphics (over a wide range of versions) all I get is this as soon as I import osg in python: *** glibc detected *** free(): invalid pointer: 0xb7cd8674 *** Aborted Anyone got an idea what's going on here? It seems to be unrelated to direct rendering, as this is enabled on both the ati and nvidia machines. Thx! Mathias PS: libc6 version 2.3.6.ds1-13etch7 SWIG Version 1.3.38 osgswig version: last week's svn checkout cmake version 2.4-patch 5 ___ DSL zum Nulltarif + 20 Euro Extraprämie bei Online-Bestellung über die DSL Freundschaftswerbung! http://dsl.web.de/?ac=OM.AD.AD008K15279B7069a ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi, I must admit I had no idea how long something like this would take :/ It is in progress is all I can say. It is something quite new at our company and there is no existing process. It is hard to convince people that open sourcing != giving away secrets/whatever. jp Robert Osfield wrote: Hi J.P, On Tue, Jan 13, 2009 at 6:49 AM, J.P. Delport jpdelp...@csir.co.za wrote: Gerwin ps. I was hoping for some public ffmpeg plugin implementation to pop up on the list, but either I missed it or it's not yet been released. Coming soon..., I hope next week. This would only be one possible implementation, but we are using it with success. Any news about this ffmpeg plugin? Any chance of it being open sourced? ;-) This week I'll be looking into possibility using ffmpeg for reading video, if there already some code out there that does the job then it'll be great to learn form it, enhance and get it integrated into the core OSG. If code isn't possible, then pointers about what you've learnt about what parts of ffmpeg to use would be good too. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using mime-type to select ReaderWriters
Robert et al, I propose that we add a facility to look up plugins by mime-type (in addition to looking up by extension). The existing mechanism works fine for local files. But when accessing data via a URL (with the CURL plugin or by some other means), it is often the case that you can only divine the content type by means of a mime-type in the HTTP Content-Type header, and that no file extension is available. Here's a possible implementation: 1) Add a method Registry::getReaderWriterForMimeType(). 2) Add a method ReaderWriter::supportsMimeType() so that plugins can register their support for various mime-types. 3) Update various plugins to call supportsMimeType() as appropriate. 4) Update the CURL plugin so that it checks the Content-Type HTTP header, calls getReaderWriterForMimeType(), and if that fails then calls getReaderWriterForExtension(). (I might have that backwards.) Thoughts? Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi J.P, On Mon, Feb 23, 2009 at 1:49 PM, J.P. Delport jpdelp...@csir.co.za wrote: I must admit I had no idea how long something like this would take :/ It is in progress is all I can say. It is something quite new at our company and there is no existing process. It is hard to convince people that open sourcing != giving away secrets/whatever. No problem. Can I pick your brains on ffmpeg integration? A quick search for tutorials on ffmpeg came up with: http://www.dranger.com/ffmpeg/tutorial01.html Which seems like a pretty decent place to start. Looks like it'll be quite straight forward. Did you use a particular example/tutorial for inspiration? Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Art, I never wrote a shader so I think I will not learn this afternoon. I was thinking on scanning all pixel, but the real problem is not how to get the pixel, but how to write the png file with the background as transparent color. I don't know if it is possible to do that just modifying A component in a RVBA image ... or something else ? Thanks. Regards, Vincent. 2009/2/23 Art Tevs osgfo...@tevs.eu Hi Vincent, I would propose to change colors in a shader, this would be the simplest way. Just take the osgPPU, with following structure: Processor-UnitInOut (here is your shader) - UnitOutCapture (this will write the .png files). Should be very easy. Other way would be to take the picture of the rendered camera and to apply the shader on it, by rendering screen size aligned quad with appropriate shader (the same what osgPPu does ;) ). And the non-efficientest way would be just to scan through all your pixels on the CPU and just change the colors in the way you need them. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7200#7200 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using mime-type to select ReaderWriters
Hi Glenn, I'm open to these suggestions, but would prefer to keep the changes to a minimum in terms of extra code/API. Could the mime type simply be mapped to a plugin name? If so then all we'd need to do to set up a alias list for mime type in addition to the current extension aliasing that the osgDB::Registry holds. Robert. On Mon, Feb 23, 2009 at 2:00 PM, Glenn Waldron gwald...@gmail.com wrote: Robert et al, I propose that we add a facility to look up plugins by mime-type (in addition to looking up by extension). The existing mechanism works fine for local files. But when accessing data via a URL (with the CURL plugin or by some other means), it is often the case that you can only divine the content type by means of a mime-type in the HTTP Content-Type header, and that no file extension is available. Here's a possible implementation: 1) Add a method Registry::getReaderWriterForMimeType(). 2) Add a method ReaderWriter::supportsMimeType() so that plugins can register their support for various mime-types. 3) Update various plugins to call supportsMimeType() as appropriate. 4) Update the CURL plugin so that it checks the Content-Type HTTP header, calls getReaderWriterForMimeType(), and if that fails then calls getReaderWriterForExtension(). (I might have that backwards.) Thoughts? Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-2.9.0 dev release tagged
Builds fine (as usual! ;) ) with VC8. See the experimental build report ( http://www.cdash.org/CDashPublic/buildSummary.php?buildid=11376 ). Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Mon, 23 Feb 2009 11:57:11 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi All, Another week, another dev release, no massive changes since 2.8.0, but a few bug fixes and minor feature additions that should keep us all happy ;-) Developmer release page: http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases Details: OpenSceneGraph-2.9.0, released on 23rd February 2009. OpenSceneGraph-2.9.0, changes include: o Under VisualStudio builds VisualStudio specific version information now embedded in core libraries and plugins. o Improved support in osgconv for writing out of compressed imagery to .osg or .ive files with external imagery. o Support for using ARB_vertex_program and ARB_fragment_program added to osgforest example. o Points support added to dxf plugin. o Bug fixes to State::reset(), dxf plugin, hdr plugin and draw instanced for ushort and uint versions of osg::DrawElements?. source package : OpenSceneGraph-2.9.0.zip svn tag: svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.9.0 OpenSceneGraph The bug fixes above have also made it into the OSG-2.8 post 2.8.0, so testing the build out for 2.9.0 will be a useful precursor to use make a 2.8.1 stable release. I'll leave going for a 2.8.1 release till next month as this will give us all a bit more time to find further bugs that weren't revealed in the run up to 2.8.0. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Vincent, ok, without shaders this would be easier to implement, however the running time would be just bad. Yes, if you just modify the alpha component of every pixel and then write this image to a .png file, you should get the transparent colors as you want. You can even do the following: setup clear color of your camera, so that it also does clear the alpha color with 0.0. Then render your scene. Then write .png file. Nothing else. Pixels, which are not overrendered by your scene, will be transparent. I have the same effect in my applications, without doing anything ;) Of course your RTT-texture has to be of GL_RGBA format. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7213#7213 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using mime-type to select ReaderWriters
Robert, I considered that, mapping mime-types to extensions, but shied away from the idea that adding a plugin might require mime-types hard coded into Registry. How would you include support for new types, say in a plugin in an external NodeKit? Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 On Mon, Feb 23, 2009 at 9:20 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Glenn, I'm open to these suggestions, but would prefer to keep the changes to a minimum in terms of extra code/API. Could the mime type simply be mapped to a plugin name? If so then all we'd need to do to set up a alias list for mime type in addition to the current extension aliasing that the osgDB::Registry holds. Robert. On Mon, Feb 23, 2009 at 2:00 PM, Glenn Waldron gwald...@gmail.com wrote: Robert et al, I propose that we add a facility to look up plugins by mime-type (in addition to looking up by extension). The existing mechanism works fine for local files. But when accessing data via a URL (with the CURL plugin or by some other means), it is often the case that you can only divine the content type by means of a mime-type in the HTTP Content-Type header, and that no file extension is available. Here's a possible implementation: 1) Add a method Registry::getReaderWriterForMimeType(). 2) Add a method ReaderWriter::supportsMimeType() so that plugins can register their support for various mime-types. 3) Update various plugins to call supportsMimeType() as appropriate. 4) Update the CURL plugin so that it checks the Content-Type HTTP header, calls getReaderWriterForMimeType(), and if that fails then calls getReaderWriterForExtension(). (I might have that backwards.) Thoughts? Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Spam: Re: Loading movie
Hi Robert, J.P., I'm checking with my boss whether we can opensource our FFmpeg plugin. We still haven't implemented the pause() method (and related behaviour), but the rest is pretty stable. T -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday 23 February 2009 13:20 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] Loading movie Hi J.P, On Tue, Jan 13, 2009 at 6:49 AM, J.P. Delport jpdelp...@csir.co.za wrote: Gerwin ps. I was hoping for some public ffmpeg plugin implementation to pop up on the list, but either I missed it or it's not yet been released. Coming soon..., I hope next week. This would only be one possible implementation, but we are using it with success. Any news about this ffmpeg plugin? Any chance of it being open sourced? ;-) This week I'll be looking into possibility using ffmpeg for reading video, if there already some code out there that does the job then it'll be great to learn form it, enhance and get it integrated into the core OSG. If code isn't possible, then pointers about what you've learnt about what parts of ffmpeg to use would be good too. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] How make multi-pass rendering ?
Hello, I am trying to create a special rendering process using OpenSceneGraph. This rendering is composed by two main steps : The first step is a multi-pass rendering based on the lights of the scene. I must find them in the scene graph : For each lights, I draw a plane on the screen surface having a material defined by a fragment shader initialized with the current light parameters. Each rendering must be merged into a FBO. After, I draw the resulting FBO on a screen (second step). If I have 8 light nodes in my scene, I will have to realize 8 rendering in combining them during the first step. Can you help me to find the best solution to make the first step with a combining shader (object to use, to redefine, ...)? My objective is to use graphics card's power in order to make merging and rendering (no CPU). For the moment, I parse the light node (using my own NodeVisitor) but I can't compute my different rendering and combine them into a FBO. I search a easy solution like osgDistortion object (where cameras are directly implemented in this objet and user must just give scene node). Best regards. Romain -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7214#7214 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi Robert, J.P, That's one of the tutorials I've used to implement our plugin; probably the best I could find. It's a good start, but I found their video/audio synchronization to be pretty bad in pratice. I actually rewrote that part from scratch. T -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday 23 February 2009 14:16 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] Loading movie Hi J.P, On Mon, Feb 23, 2009 at 1:49 PM, J.P. Delport jpdelp...@csir.co.za wrote: I must admit I had no idea how long something like this would take :/ It is in progress is all I can say. It is something quite new at our company and there is no existing process. It is hard to convince people that open sourcing != giving away secrets/whatever. No problem. Can I pick your brains on ffmpeg integration? A quick search for tutorials on ffmpeg came up with: http://www.dranger.com/ffmpeg/tutorial01.html Which seems like a pretty decent place to start. Looks like it'll be quite straight forward. Did you use a particular example/tutorial for inspiration? Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
I did a setClearColor(osg::Vec4(0., 0., 0., 1.)); and setClearColor(osg::Vec4(0., 0., 0., 0.)); on my camera, but when writing the file in png... nothing look like an alpha channel... same result each time... I'll try manually scannin each pixel. do you think just setting the alpha component to 1.0 is sufficient ? Thanks. Regards, Vincent. 2009/2/23 Art Tevs osgfo...@tevs.eu Hi Vincent, ok, without shaders this would be easier to implement, however the running time would be just bad. Yes, if you just modify the alpha component of every pixel and then write this image to a .png file, you should get the transparent colors as you want. You can even do the following: setup clear color of your camera, so that it also does clear the alpha color with 0.0. Then render your scene. Then write .png file. Nothing else. Pixels, which are not overrendered by your scene, will be transparent. I have the same effect in my applications, without doing anything ;) Of course your RTT-texture has to be of GL_RGBA format. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7213#7213 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using mime-type to select ReaderWriters
Hi Robert, Glenn, Could the mime type simply be mapped to a plugin name? If so then all we'd need to do to set up a alias list for mime type in addition to the current extension aliasing that the osgDB::Registry holds. I've seen lately, MediaWiki keeps a mapping of MIME type to extension (for security, it checks that the file actually contains what its extension suggests it should). In our case, we could do the same, and when the MIME type is checked, an extension would be returned, and then the plugin for that extension would be used. Where to store the mapping would be an open question though. Hard-coded in a header/cpp somewhere, or as a text file in OpenSceneGraph-Data? But I thought I'd just throw the idea out there. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Talk about timing... I've just got the green light from my boss. Robert, is there a place where I could upload the current plugin implementation, including an example app and the Windows compiled ffmpeg libraries? Cheers, Tanguy -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tanguy Fautre Sent: Monday 23 February 2009 14:52 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] Spam: Re: Loading movie Hi Robert, J.P., I'm checking with my boss whether we can opensource our FFmpeg plugin. We still haven't implemented the pause() method (and related behaviour), but the rest is pretty stable. T -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday 23 February 2009 13:20 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] Loading movie Hi J.P, On Tue, Jan 13, 2009 at 6:49 AM, J.P. Delport jpdelp...@csir.co.za wrote: Gerwin ps. I was hoping for some public ffmpeg plugin implementation to pop up on the list, but either I missed it or it's not yet been released. Coming soon..., I hope next week. This would only be one possible implementation, but we are using it with success. Any news about this ffmpeg plugin? Any chance of it being open sourced? ;-) This week I'll be looking into possibility using ffmpeg for reading video, if there already some code out there that does the job then it'll be great to learn form it, enhance and get it integrated into the core OSG. If code isn't possible, then pointers about what you've learnt about what parts of ffmpeg to use would be good too. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using mime-type to select ReaderWriters
HI Glenn + JS, On Mon, Feb 23, 2009 at 3:00 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, Glenn, Could the mime type simply be mapped to a plugin name? If so then all we'd need to do to set up a alias list for mime type in addition to the current extension aliasing that the osgDB::Registry holds. I've seen lately, MediaWiki keeps a mapping of MIME type to extension (for security, it checks that the file actually contains what its extension suggests it should). In our case, we could do the same, and when the MIME type is checked, an extension would be returned, and then the plugin for that extension would be used. Where to store the mapping would be an open question though. Hard-coded in a header/cpp somewhere, or as a text file in OpenSceneGraph-Data? But I thought I'd just throw the idea out there. Perhaps one could query the plugins and from this generate a configuration file that provides the mapping/functionality that the plugins provide and a .cpp implementation of this configuration file which could be compiled into osgDB. This would allow us to autogenerate and keep up to date the configuration. The mapping would also have a precedence, if a configuration file is manually specified then this over-writes the built in, and finally any plugins that are loaded could patch this configuration file to keep it full up to date. Not quite the minimal approach though... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trac menu
Hi Wiki admins, Sorry to push this topic up, but could someone with appropriate rights add a line to Community/WikiLogIn like: If you wish to update wiki menus, you may have a look to the [wiki:TracNav/list TracNav list]. Thanks guys! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 19 Feb 2009 11:32:30 +0100, Sukender suky0...@free.fr a écrit: Hum, sorry, I didn't know that it was Trac that automatically changes the order of sections. (I *still* find it confusing!) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 19 Feb 2009 11:29:34 +0100, Sukender suky0...@free.fr a écrit: Hi all, I created a TOC list ( http://www.openscenegraph.org/projects/osg/wiki/TracNav/list ) to help maintenance (No page points to it yet). These are maybe dumb questions, but: - Should we create a page about how to maintain the wiki (such as an improved version of Community/WikiLogIn)? - Is this a good idea to add [[TracNav(TracNav/TOCmain)]] (or the TOC of the section) on every page ? - Each TOC puts its section at the begining, changing the order of sections. And I find it confusing. Anyone having an argument for this, or can I change it? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Thu, 19 Feb 2009 10:21:11 +0100, Robert Osfield robert.osfi...@gmail.com a écrit: Hi Sukunder, On Wed, Feb 18, 2009 at 11:47 PM, Sukender suky0...@free.fr wrote: I noticed the menu on the Trac wiki (on the right - yellow background) isn't the same for every page. It there a way to ensure the menu is up-to-date without having to change every page? The menu is manually created, and it not that same for each page. To keep things in sync one has to edit the menu and add the appropriate items. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Can't build libraries under windows
I am trying to compile the binaries myself, and if I succeed I do want to make them available for others. The problem is, that I get compilation errors for mingw_osgdb_jpeg.dll . Does anybody know the solution to these errors? (see my previous post/mail for the exact error messages) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7227#7227 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Vincent, you have to set alpha to 0.0 for transparent pixels. Check if your RTT texture has the right format. In my case setting setClearColor(osg::Vec4(0., 0., 0., 0.)); on the rendering camera always works. Check if there are no slave camera which can overwrite the settings. Check also if you can really see the background, maybe there are no background pixels at all (I mean maybe they are overwritten by some black geometry or so). And finally check also if your image editing program do shows the alpha channel correctly (just for the case). I use gimp for that case. regards, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7228#7228 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Can't build libraries under windows
Hi Janatan, On Mon, Feb 23, 2009 at 3:29 PM, Jonatan osgfo...@tevs.eu wrote: I am trying to compile the binaries myself, and if I succeed I do want to make them available for others. The problem is, that I get compilation errors for mingw_osgdb_jpeg.dll . Does anybody know the solution to these errors? (see my previous post/mail for the exact error messages) I'm afraid I can't help with the errors, but I like to chip in that fact that if you can't easily get all the external dependencies compiled then CMake will be able to automatically detect which ones are and aren't there and decide what parts of the OSG to build accordingly. For most OSG functionality you just need OpenGL and C++, it's the plugins were the numerous external dependencies come in, and each one of these is entirely optional, if you don't have the dependency then the plugin build and the only thing you'll miss is the functionality provide by that specific plugin. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using mime-type to select ReaderWriters
On Mon, Feb 23, 2009 at 10:00 AM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, Glenn, Could the mime type simply be mapped to a plugin name? If so then all we'd need to do to set up a alias list for mime type in addition to the current extension aliasing that the osgDB::Registry holds. I've seen lately, MediaWiki keeps a mapping of MIME type to extension (for security, it checks that the file actually contains what its extension suggests it should). In our case, we could do the same, and when the MIME type is checked, an extension would be returned, and then the plugin for that extension would be used. Where to store the mapping would be an open question though. Hard-coded in a header/cpp somewhere, or as a text file in OpenSceneGraph-Data? But I thought I'd just throw the idea out there. J-S, I'd be happy with this approach. I think hard-coding should be sufficient for now. If there's a compelling reason, we can move to the config file approach later. Here's a sample mime-type list: http://www.w3schools.com/media/media_mimeref.asp Anyway-- once there's a consensus I will be happy to code something up. Glenn Waldron : Pelican Mapping : http://pelicanmapping.com : +1.703.652.4791 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi Tanguy, On Mon, Feb 23, 2009 at 3:01 PM, Tanguy Fautre tang...@aristechnologies.com wrote: Talk about timing... That's why it's always worth doing a syncronization step before coding :-) I've just got the green light from my boss. Excellent news. Means we all save some time, and we all can work on improving the code base. Robert, is there a place where I could upload the current plugin implementation, including an example app and the Windows compiled ffmpeg libraries? You could ftp them to the openscenegraph.org server, I could grab them there and move the pre-compiled binaries to a publically accessible place. To log in to ftp on the server the user name is OSG, password OSG. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Art, I do not use any RTT texture, just use _image-readPixels() to get screen capture. I verified, result-getPixelSizeInBits()/8 remain = 4 so it is a RGBA image. No background or black geometry, ... If I change clear color to white, I have the white background... I use Gimp and Photofiltre to check the transparency I just check/force all camera's clear color... no changes. I'm trying to change pixel value looping on image's data ... but now the png plugin tells me the image is not good for writing... I'm missing some point or making a mistake... Sorry, nothing works... If you have any other idea or some image's data modification code... I'll be grateful. Regards, Vincent. 2009/2/23 Art Tevs osgfo...@tevs.eu Hi Vincent, you have to set alpha to 0.0 for transparent pixels. Check if your RTT texture has the right format. In my case setting setClearColor(osg::Vec4(0., 0., 0., 0.)); on the rendering camera always works. Check if there are no slave camera which can overwrite the settings. Check also if you can really see the background, maybe there are no background pixels at all (I mean maybe they are overwritten by some black geometry or so). And finally check also if your image editing program do shows the alpha channel correctly (just for the case). I use gimp for that case. regards, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7228#7228 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Defining NodeKit
On Sat, 2009-02-21 at 16:02 -0700, Paul Martz wrote: Hi Robert and all -- As I proceed with updating the Quick Start Guide, I encountered the section describing OSG's NodeKits. My first inclination was to update this with a short description of osgAnimation, osgVolume, and osgWidget. OH WOW, cool. :) Don't mention this in the book, obviously, but as soon as my condition allows (the medication I take for my CML really knocks me out; it's like chemo in a pill) I will be working more on osgWidget. I won't be changing the API too much, but I will be reducing a lot of the redundancy and abstracting a few things (such as making Widget an interface rather than the Quad implementation I currently use). However, only osgAnimation appears to have a dot osg plugin. osgVolume and osgWidget apparently do not define any classes that are supported by dot osg. Looking closer, I see that there is no dot osg plugin for osgManipulator or osgGA either. Do we need a new category for OSG-based libraries that aren't NodeKits? Or do I need to change my definition of NodeKit to be more inclusive? Thanks for any suggestions. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Vincent, ah ok, you are not using RTT features. I would suggest to do so, because otherwise pixel which are outside of your viewport are undefined (in most case you will get the window boundaries too ;). With glReadPixels it can happen htat you even capture the mouse pointer, which is sometime not the thing you want, I suppose. Ok, I suppose you then have a proper parameters set to image-readPixels(..., GL_RGBA, ...); ? If you capture your pixel information directly from the framebuffer then you have to setup the framebuffer in the proper way. It should support alpha values too. Check if you setup the display settings properly, here osgViewer::View::getDisplaySettings(), you have to setup proper amount of alpha bits (i.e. 8). In general, I really propose to use FBO with RTT, otherwise you could even capture other windows which overlap with yours if you capture pixels directly from the framebuffer. cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7232#7232 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Rescaling all normals in an .flt file
Hi all, This is not directly OSG related, but since many here know Creator very well I presume, I thought I'd ask. I have a model which the modeler has scaled, and as we can expect it exhibits the classic symptom that the normals were scaled as well - lighting is wrong. In Creator I can click the show normals button and I can see that some normals are markedly shorter than others. I can't seem to find any tool for normalizing the normals in Creator though. There's the Attruibutes - Calculate Shading tool that lets me recalculate the normals, but even this doesn't seem to normalize them. If I use osgconv to convert the model to .osg, and add a stateset with GL_NORMALIZE ON on the root node in the file, then the shading is correct. So I know this is the problem. I'd just like to know what to tell our modeler so he can fix the model directly instead of using GL_NORMALIZE or the osgUtil::SmoothingVisitor (I'd like to avoid extra steps). And it would seem a rather glaring omission if Creator scaled normals when scaling a model, but didn't give you a tool to renormalize them afterwards (or even renormalized them automatically - gasp!). Am I missing something obvious? Thanks in advance, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Precompile GL objects problems...
Hi,
I use 4 screens (running on two nvidia cards).
When I don't precompile the gl objects things look as expected. But when I
precompile stuff, things are shown only on some graphic contexts.
1. I am loading models on my own background thread.
2. This is what I do on the main thread, before the update traversal:
osgUtil::GLObjectsVisitor glov;
glov.setNodeMaskOverride(0x);
osgViewer::Viewer::Contexts graphicContexts;
myViewer-getContexts(graphicContexts);
for (osgViewer::Viewer::Contexts::iterator it =
graphicContexts.begin();
it != graphicContexts.end();
++it)
{
glov.setState((*it)-getState());
glov.apply(*loadedNode);
}
Finally I add loadedNode to the scenegraph.
Is this the wrong approach?
--
Joakim Simonsson
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] Can't build libraries under windows
The fact that cmake try to compile osgdb_jpeg means Your FindJPEG does nopt return NOTFOUND, try to set Advanced view in cmake-gui and look what library/include it has found. If It point to lib that have been built with MSVC, it is very likely it does not work. So either you remove them or try to build jpeg lib from source with your mingw tool chain. Or try to find a pre-built one with mingw. If you dare to try the first solution, I have some cmakified sources that I use with VS71, get them from http://3d.cineca.it/storage/packages/3rdPartySrc_pack.zip and try to see if they compile with mingw (if you manage, send me patches, thanks), unzip the required files in -place as jpeg Regarding pre-build libs, You probably know better how to get pre-built libraries with mingw, Otherwise, you can try to use the ebuild tool from winkde project: http://techbase.kde.org/Getting_Started/Build/KDE4/Windows/emerge I see they have quite a lot of package read for emerge, and mingw is probably better supported than msvc Hope it helps Jonatan ha scritto: I am trying to compile the binaries myself, and if I succeed I do want to make them available for others. The problem is, that I get compilation errors for mingw_osgdb_jpeg.dll . Does anybody know the solution to these errors? (see my previous post/mail for the exact error messages) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7227#7227 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precompile GL objects problems...
HI Joakim,
You can only compile OpenGL objects form the thread with the context
current. The easist way to do this would be to just use the existing
osgViewer::Renderer::setCompileOnNextDraw(true) functionality on all
your active cameras. You can get the renderer by doing:
osgViewer::Viewer::Renderer* rendering =
dynamic_castosgViewer::Renderer*(camera-getRenderer());
The cameras can be got using the viewer.getCameras(cameras) method in
the same way as you've done for getContexts().
Robert.
On Mon, Feb 23, 2009 at 4:31 PM, Joakim Simonsson joa...@autosim.no wrote:
Hi,
I use 4 screens (running on two nvidia cards).
When I don't precompile the gl objects things look as expected. But when I
precompile stuff, things are shown only on some graphic contexts.
1. I am loading models on my own background thread.
2. This is what I do on the main thread, before the update traversal:
osgUtil::GLObjectsVisitor glov;
glov.setNodeMaskOverride(0x);
osgViewer::Viewer::Contexts graphicContexts;
myViewer-getContexts(graphicContexts);
for (osgViewer::Viewer::Contexts::iterator it = graphicContexts.begin();
it != graphicContexts.end();
++it)
{
glov.setState((*it)-getState());
glov.apply(*loadedNode);
}
Finally I add loadedNode to the scenegraph.
Is this the wrong approach?
--
Joakim Simonsson
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precompile GL objects problems...
On Mon, 23 Feb 2009 17:38:35 +0100, Robert Osfield robert.osfi...@gmail.com wrote: You can only compile OpenGL objects form the thread with the context current. The easist way to do this would be to just use the existing osgViewer::Renderer::setCompileOnNextDraw(true) functionality on all your active cameras. You can get the renderer by doing: Thanks for your advice! I looked in the osgViwer::Renderer code. And it seems that the entire sceneview is compiled in osgViewer::Renderer::compile(). In my scenario, I first load a huge database. Then during the simulation, I load smaller objects and add them to my existing scene graph. I was just wondering if it is an overkill to compile the entire sceneview for each smaller object that I load during runtime. Wouldn't it be enough to only compile my added objects, before I add them to my existing scene graph? -- Joakim Simonsson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Art,
I use
_image-readPixels(int(viewport-x()),int(viewport-y()),int(viewport-width()),int(viewport-height()),
GL_RGBA, GL_UNSIGNED_BYTE);
No display setting was set, so I made it
osg::DisplaySettings* ds = new osg::DisplaySettings();
ds-setMinimumNumAlphaBits(8);
view-setDisplaySettings(ds);
No changes...
FBO with RTT sounds like a great solution but I'm afraid I don't have enough
time to have this week, and it will be too late.
So, I try the data modification of the image, but the write file return me
an error.
I do that :
static osg::ref_ptrosg::Image changeBackground(osg::Image* img)
{
osg::ref_ptrosg::Image result = new osg::Image(*img,
osg::CopyOp::DEEP_COPY_ALL);
if(!result-valid())
return NULL;
if(result-getPixelSizeInBits()/8 != 4)
return NULL;
unsigned char* data = (unsigned
char*)calloc(result-s()*result-t()*4, sizeof(unsigned char));
long n = 0;
for(long i = 0; i (result-s()*result-t()) ; i++)
{
data[n] = result-data()[n];
data[n+1] = result-data()[n+1];
data[n+2] = result-data()[n+2];
data[n+3] = 1.0;
n+=4;
}
result-allocateImage(result-s(), result-t(), result-r(),
result-getPixelFormat(), result-getDataType());
result-setImage(result-s(), result-t(), result-r(),
result-getInternalTextureFormat(), result-getPixelFormat(),
result-getDataType(), data, result-getAllocationMode());
return result;
}
Do you see anything strange in it ? because Image seems to be unValid...
Thanks Art, and anyone who can give me some advice/help
Regards,
Vincent.
2009/2/23 Art Tevs osgfo...@tevs.eu
Hi Vincent,
ah ok, you are not using RTT features. I would suggest to do so, because
otherwise pixel which are outside of your viewport are undefined (in most
case you will get the window boundaries too ;). With glReadPixels it can
happen htat you even capture the mouse pointer, which is sometime not the
thing you want, I suppose.
Ok, I suppose you then have a proper parameters set to
image-readPixels(..., GL_RGBA, ...); ?
If you capture your pixel information directly from the framebuffer then
you have to setup the framebuffer in the proper way. It should support alpha
values too. Check if you setup the display settings properly, here
osgViewer::View::getDisplaySettings(), you have to setup proper amount of
alpha bits (i.e. 8).
In general, I really propose to use FBO with RTT, otherwise you could even
capture other windows which overlap with yours if you capture pixels
directly from the framebuffer.
cheers,
art
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=7232#7232
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non emissive ParticleSystem and lighting
Here is the source code of the osgparticle example a bit modify to show the
issue with lighting.
The key is the lighting parameter of the setDefaultParameters() method.
I've created a box reacting both to ambient and diffuse to have a reference on
lighting conditions in the scene.
Diffuse lighting :
In fact, while playing a bit with this sample, it seems that the diffuse
lighting is taken into account when the lightsource is at 'one certain position
relative to the particles'. However, this one is unpredictable (there is no
normal per vertex set onto particles sprites, so how odd ?) and must surely vary
with the manner the particlesystem animation is set/implemented (emitters and
programs).
Ambient lighting :
If you set no diffuse light but an ambient in the scene the particles remain
unvariably black, unreacting to it.
If anybody has an idea of code modification to make it work. I'm highly
interested !
Again, just one of the two kind of lighting (diffuse or ambient) would be enough
for me to be happy ! ;)
Christophe
PS: I'm using myself customized PS subclasses (to ensure deterministic randoms,
and
other things) and a bit more complex lighting conditions model, but the problem
I notice
must be same.
--- Message d'origine ---
De : MEDARD Christophe christophe.med...@oktal.fr
À : OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sujet : Re: [osg-users] Non emissive ParticleSystem and lighting
Date : lun 23 fév 2009 09:56:12 CET
Sukender's post lets me know I'm not the only one having the problem, so I
must do things correctly.
Sure, using the particles systems as emissive and changing on the run
particles
colors would work, but it's a pain (!).
Having a specific set of classes taking care of the internals of the particle
behaviour should allow the programmer to let them live they life whatever the
changing of conditions. Besides, it's what the interface leads to expect, the
emissive and lighting boolean being free to take the 'false' value (actually
I don't understand why it doesn't work - at least concerning the ambient -,
since
in the implementation everything seems to be done to enable LIGHTING onto the
stateset... but I must be missing something).
If useful, I'll try today to find some time to modify the simple sample code
to show the problem.
As I recall, the key is the lighting parameter, the emissive_particles ones
allowing just to have an additive blend func on sprites...
I'm using myself customized PS subclasses (to ensure deterministic randoms,
and other things) and a bit more complex lighting conditions model, but the
anomaly will be same.
Christophe
--- Message d'origine ---
De : Robert Osfield robert.osfi...@gmail.com
À : OpenSceneGraph Users osg-users@lists.openscenegraph.org
Sujet : Re: [osg-users] Non emissive ParticleSystem and lighting
Date : dim 22 fév 2009 11:41:45 CET
Can't you change the particle colour to be appropriate for different
times of day?
Robert.
/* OpenSceneGraph example, osgparticle.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the rights
* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
* copies of the Software, and to permit persons to whom the Software is
* furnished to do so, subject to the following conditions:
*
* THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
* THE SOFTWARE.
*/
#include osgViewer/Viewer
#include osg/Group
#include osg/Geode
#include osg/ShapeDrawable
#include osg/MatrixTransform
#include osg/LightModel
#include osgParticle/Particle
#include osgParticle/ParticleSystem
#include osgParticle/ParticleSystemUpdater
#include osgParticle/ModularEmitter
#include osgParticle/ModularProgram
#include osgParticle/RandomRateCounter
#include osgParticle/SectorPlacer
#include osgParticle/RadialShooter
#include osgParticle/AccelOperator
#include osgParticle/FluidFrictionOperator
//
// CUSTOM OPERATOR CLASS
//
// This class demonstrates Operator subclassing. This way you can create
// custom operators to apply your motion effects to the particles. See docs
// for more details.
class VortexOperator: public osgParticle::Operator {
public:
VortexOperator()
: osgParticle::Operator(), center_(0, 0, 0), axis_(0,
Re: [osg-users] Defining NodeKit
Cool. Jeremy, could you possibly write a couple lines that capture the spirit and intent of osgWidget for inclusion in my revision? If so, thanks in advance. Here's the text I have so far, so you can get a feel for what I'm after: NodeKits extend the concept of Node, Drawable, and StateAttribute objects, and can be thought of as extensions to the osg library in core OSG. NodeKits must do more than derive from an OSG class. They must also provide a dot OSG wrapper (an OSG plugin to support reading from and writing to an .osg file). As a result, a NodeKit is composed of two libraries: the NodeKit itself, and a dot OSG wrapper plugin library. OSG v2.8 has 10 NodeKits. . The osgAnimation library TBD. . The osgFX library-This NodeKit provides additional scene graph nodes for rendering special effects, such as anisotropic lighting, bump mapping, and cartoon shading. . The osgManipulator library-This NodeKit contains several classes for manipulating selected objects in the scene graph. . The osgParticle library-This NodeKit provides particle-based rendering effects, such as explosions, fire, and smoke. . The osgShadow library-This NodeKit provides a framework for supporting shadow rendering techniques. . The osgSim library-This NodeKit supports the special rendering requirements of simulation systems and OpenFlight databases, such as terrain elevation query classes, light point nodes, and DOF transformation nodes. . The osgTerrain library-This NodeKit provides support for rendering height field data. . The osgText library-This NodeKit is a powerful tool for adding text to your scene. It fully supports all TrueType fonts. . The osgVolume library TBD. . The osgWidget library TBD. In addition, the osgGA library provides a cross-platform interface to events and input devices such as window resize, mouse button, mouse motion, and key press events. I appreciate your assistance with filling in the blank. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgManipulator.AntiSquish
Hi, The behavior of osgManipulator::AntiSquish seems to have changed between releases 2.6.1 and 2.8.0. I'm not sure what is happening differently in the matrix math, but you can see the result on the TabBoxDragger by firing up the standard osgManipulator example. The dragger's corner tabs are no longer in the corners. As a test I replaced the v2.8 AntiSquish node with the v2.6.1 AntiSquish in the TabPlaneDragger, and things looked right again. Btw, is this the right place to put a bug report like this? Thanks, -Jonathan Lewis ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precompile GL objects problems...
Hi Joakim. On Mon, Feb 23, 2009 at 4:54 PM, Joakim Simonsson joa...@autosim.no wrote: Thanks for your advice! I looked in the osgViwer::Renderer code. And it seems that the entire sceneview is compiled in osgViewer::Renderer::compile(). In my scenario, I first load a huge database. Then during the simulation, I load smaller objects and add them to my existing scene graph. I was just wondering if it is an overkill to compile the entire sceneview for each smaller object that I load during runtime. Wouldn't it be enough to only compile my added objects, before I add them to my existing scene graph? Yes a complete recompile traversal will be done, but if objects are already compiled they won't be compiled again. If you do want to just compile you new elements then you could a a custom GraphicsOperation to the GraphicsContext's GraphicsThread. Another alternative would be to use a CompileContext to allow you to compile the new subgraph asynchronously. Finally you could look at use the DatabasePager to load and precompile you data. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precompile GL objects problems...
On Mon, 23 Feb 2009 18:31:54 +0100, Robert Osfield robert.osfi...@gmail.com wrote: Yes a complete recompile traversal will be done, but if objects are already compiled they won't be compiled again. If you do want to just compile you new elements then you could a a custom GraphicsOperation to the GraphicsContext's GraphicsThread. Another alternative would be to use a CompileContext to allow you to compile the new subgraph asynchronously. Finally you could look at use the DatabasePager to load and precompile you data. Thanks Robert! -- Joakim Simonsson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Non emissive ParticleSystem and lighting
HI Christophe, Thanks for the example. I am not surprised that their are lighting problems as particles don't have any unique normal, so there is no point providing one. A normal on a particle would only make sense if you were simulating a planer particle, such as a chunk of armour plating, for all other cases a single normal makes no sense, and OpenGL vertex lighting will never produce an all round appropriate behaviour. I think the only way would could add some form of lighting sensitivity into osgParticle would be have a pseudo lighting calculation done for a whole ParicleSystem or perhaps individual Particle, this will come up with a colour modulation of the particle that appears to take into account diffuse and ambient colours in a way that makes sense. Exactly how you'd want it to take account of the light source will depend on the particle type. For instance fire and exposion are definitely something that is emissive, while smoke or debri style particles would be something that does take into account diffuse and ambient lighting. For best results I guess you'd even want to place a light source at the center of an explosion. Robert. On Mon, Feb 23, 2009 at 5:13 PM, MEDARD Christophe christophe.med...@oktal.fr wrote: Here is the source code of the osgparticle example a bit modify to show the issue with lighting. The key is the lighting parameter of the setDefaultParameters() method. I've created a box reacting both to ambient and diffuse to have a reference on lighting conditions in the scene. Diffuse lighting : In fact, while playing a bit with this sample, it seems that the diffuse lighting is taken into account when the lightsource is at 'one certain position relative to the particles'. However, this one is unpredictable (there is no normal per vertex set onto particles sprites, so how odd ?) and must surely vary with the manner the particlesystem animation is set/implemented (emitters and programs). Ambient lighting : If you set no diffuse light but an ambient in the scene the particles remain unvariably black, unreacting to it. If anybody has an idea of code modification to make it work. I'm highly interested ! Again, just one of the two kind of lighting (diffuse or ambient) would be enough for me to be happy ! ;) Christophe PS: I'm using myself customized PS subclasses (to ensure deterministic randoms, and other things) and a bit more complex lighting conditions model, but the problem I notice must be same. --- Message d'origine --- De : MEDARD Christophe christophe.med...@oktal.fr À : OpenSceneGraph Users osg-users@lists.openscenegraph.org Sujet : Re: [osg-users] Non emissive ParticleSystem and lighting Date : lun 23 fév 2009 09:56:12 CET Sukender's post lets me know I'm not the only one having the problem, so I must do things correctly. Sure, using the particles systems as emissive and changing on the run particles colors would work, but it's a pain (!). Having a specific set of classes taking care of the internals of the particle behaviour should allow the programmer to let them live they life whatever the changing of conditions. Besides, it's what the interface leads to expect, the emissive and lighting boolean being free to take the 'false' value (actually I don't understand why it doesn't work - at least concerning the ambient -, since in the implementation everything seems to be done to enable LIGHTING onto the stateset... but I must be missing something). If useful, I'll try today to find some time to modify the simple sample code to show the problem. As I recall, the key is the lighting parameter, the emissive_particles ones allowing just to have an additive blend func on sprites... I'm using myself customized PS subclasses (to ensure deterministic randoms, and other things) and a bit more complex lighting conditions model, but the anomaly will be same. Christophe --- Message d'origine --- De : Robert Osfield robert.osfi...@gmail.com À : OpenSceneGraph Users osg-users@lists.openscenegraph.org Sujet : Re: [osg-users] Non emissive ParticleSystem and lighting Date : dim 22 fév 2009 11:41:45 CET Can't you change the particle colour to be appropriate for different times of day? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Defining NodeKit
Hi Paul, I am a bit busy to help you right now to write on osgAnimation, you can find information about osgAnimation http://www.openscenegraph.org/projects/osg/wiki/Community/NodeKits/osgAnimation It's not complete but will maybe help you to have an idea. Cheers, Cedric Paul Martz wrote: Cool. Jeremy, could you possibly write a couple lines that capture the spirit and intent of osgWidget for inclusion in my revision? If so, thanks in advance. Here's the text I have so far, so you can get a feel for what I'm after: NodeKits extend the concept of *Node,* *Drawable**,* and *StateAttribute* objects, and can be thought of as extensions to the osg library in core OSG. NodeKits must do more than derive from an OSG class. They must also provide a /dot OSG wrapper/ (an OSG plugin to support reading from and writing to an .osg file). As a result, a NodeKit is composed of two libraries: the NodeKit itself, and a dot OSG wrapper plugin library. OSG v2.8 has 10 NodeKits. · The osgAnimation library TBD. · The osgFX library—This NodeKit provides additional scene graph nodes for rendering special effects, such as anisotropic lighting, bump mapping, and cartoon shading. · The osgManipulator library—This NodeKit contains several classes for manipulating selected objects in the scene graph. · The osgParticle library—This NodeKit provides particle-based rendering effects, such as explosions, fire, and smoke. · The osgShadow library—This NodeKit provides a framework for supporting shadow rendering techniques. · The osgSim library—This NodeKit supports the special rendering requirements of simulation systems and OpenFlight databases, such as terrain elevation query classes, light point nodes, and DOF transformation nodes. · The osgTerrain library—This NodeKit provides support for rendering height field data. · The osgText library—This NodeKit is a powerful tool for adding text to your scene. It fully supports all TrueType fonts. · The osgVolume library TBD. · The osgWidget library TBD. In addition, the osgGA library provides a cross-platform interface to events and input devices such as window resize, mouse button, mouse motion, and key press events. I appreciate your assistance with filling in the blank. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- +33 (0) 6 63 20 03 56 Cedric Pinson mailto:morni...@plopbyte.net http://www.plopbyte.net ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgManipulator.AntiSquish
Hi Jonathan, This is correct place to report bugs. I've just ran osgmanipulaor and see the that tabs rendering is indeed wrong. I have briefly looked at the svn logs and haven't spotted the cause of this regression yet. It's end of day here so I'll look into this tomorrow. Robert. On Mon, Feb 23, 2009 at 5:21 PM, Lewis, Jonathan jle...@integrity-apps.com wrote: Hi, The behavior of osgManipulator::AntiSquish seems to have changed between releases 2.6.1 and 2.8.0. I'm not sure what is happening differently in the matrix math, but you can see the result on the TabBoxDragger by firing up the standard osgManipulator example. The dragger's corner tabs are no longer in the corners. As a test I replaced the v2.8 AntiSquish node with the v2.6.1 AntiSquish in the TabPlaneDragger, and things looked right again. Btw, is this the right place to put a bug report like this? Thanks, -Jonathan Lewis ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi Robert, I've uploaded the plugin sources, plus example application and FFmpeg Windows binaries (non-GPL) to the FTP. The file name is osgFFmpeg_20090223.zip. It also contains a README file for further info. I wished the code was a bit more readable, but this is a firt version. Also, FFmpeg API is not very clear in itself. I'm not very happy with the current interface of the plugin, as it forces the user to do a dynamic_cast to access additional methods. I'm sure a better solution can be found (e.g. extending osg::ImageStream and/or adding an osg::AudioStream interface class?). I've found some rare instances where the sound and the audio can get out-of-sync. This is probably the trickiest part of the plugin. Anyway, have a look. I have a bus to catch, otherwise I'll be stuck at the office. ;-) Cheers, T -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Monday 23 February 2009 15:20 To: OpenSceneGraph Users Subject: Spam: Re: [osg-users] Loading movie Hi Tanguy, On Mon, Feb 23, 2009 at 3:01 PM, Tanguy Fautre tang...@aristechnologies.com wrote: Talk about timing... That's why it's always worth doing a syncronization step before coding :-) I've just got the green light from my boss. Excellent news. Means we all save some time, and we all can work on improving the code base. Robert, is there a place where I could upload the current plugin implementation, including an example app and the Windows compiled ffmpeg libraries? You could ftp them to the openscenegraph.org server, I could grab them there and move the pre-compiled binaries to a publically accessible place. To log in to ftp on the server the user name is OSG, password OSG. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg swig: crashes with nvidia
Hi Mathias, I recognize this type of error, but I thought I fixed this. http://code.google.com/p/osgswig/issues/detail?id=17can=1 Could you pls follow the issue's comments and see if it helps you to play with linking order or environment preloader settings? Gerwin On Mon, Feb 23, 2009 at 2:48 PM, Mathias Franzius mathias.franz...@web.de wrote: Hi, I have a strange problem: when I compile osg 2.4 or 2.6 and osgswig on debian etch everything works fine with intel, ati or mesa graphics but doing the same thing on a virtually identical machine but with nvidia graphics (over a wide range of versions) all I get is this as soon as I import osg in python: *** glibc detected *** free(): invalid pointer: 0xb7cd8674 *** Aborted Anyone got an idea what's going on here? It seems to be unrelated to direct rendering, as this is enabled on both the ati and nvidia machines. Thx! Mathias PS: libc6 version 2.3.6.ds1-13etch7 SWIG Version 1.3.38 osgswig version: last week's svn checkout cmake version 2.4-patch 5 ___ DSL zum Nulltarif + 20 Euro Extraprämie bei Online-Bestellung über die DSL Freundschaftswerbung! http://dsl.web.de/?ac=OM.AD.AD008K15279B7069a ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problems with VPB and DTED data.
It seems that VPB (SVN revision 953) won't accept DTED data. Looking at the VPB code, VPB gets a list of GDAL supported extensions (and adds a few that GDAL doesn't report). Looking at GDAL, it fails to report the DTED extensions (.dt0, .dt1, .dt2) via the GetMetadataItem(DMD_EXTENSIONS) method. The result is VPB reports that DTED files are not supported. I don't know if the fix belongs in GDAL or VPB, but as a quick work-around add the following lines to the end of the VPB System constructor (src/vpb/System.cpp): addSupportedExtension(dt0, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 0); addSupportedExtension(dt1, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 1); addSupportedExtension(dt2, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 2); Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [osgPPU] v0.4 tagged (to be used with osg 2.8)
Hi folks, i've just tagged v0.4 of osgPPU (post processing NodeKit for OpenSceneGraph). The new version does support: - full support for osg 2.8 - New Modules: -- UnitInOutModule processing units can now be loaded from .so/.dll modules -- UnitCamera - bring additional cameras into the osgppu pipeline (usefull for multiple cameras being processed by osgPPU) - deprecated class Shader removed (use ShaderAttribute instead) - small build fixes (changed Cmake files) - examples do build now with osgppu_ prefix - support for .so version build extensions (i.e. libosgPPU.so.0.4.0) - new examples: -- ssao - simple screen space ambient occlusion -- glow - simple example shows how to use osgPPU to let certain objects glow) -- cuda - shows how to compile and use CUDA kernels together in ppu pipeline -- CUDA support - bring cuda kernels into osgPPU pipeline, by loading CUDA-kernel through UnitInOutModule unit (CUDA kernels has to be compiled externally into an .so/.dll file) - full support for NodeKit definition ;) Take a look, if you are interested. Best regards, Art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7252#7252 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] basic terrain querstions
hi i would like to get a better understanding of osg's various possibilities in terrain-visualization. currently i'm using osggis/virtualplanetbuilder to display georeferenced, common gis rasterfiles which work wonderful. but as an osg-newbie i also would like to know what are the approaches of basic terrain handling of osggis' underlying osg. what i know/suppose so far: * according to the osgforest example, the most basic method seems to be using osg::Geometry, attach a vertex-/texturecoord array and draw as indiced DrawElement primitiveset. * the other possibility seems to be osg:HeightField, which is less code than the above one, as well i can omit texturecoordinates (at least according to the example) because of its regular grid characteristic. what i would like to know: * are these assumptions right? * are there other terrain related possibilities? * i also have read about osgTerrain, but when i start the osgterrain example with an osgdem (--TERRAIN) generated dataset: osgterrain.exe boston-sample\terrain\out.ive i get the following message: No model created, please specify terrain or master file on command line, so till yet i haven't got an impression what osgTerrain actually is/does. actually it is more important for me to get some information about osgTerrain itself, than to get this example running - but if it happens that someone knows why that application doesn't work it's okay too ;-) * is there an easy way or example on how to load terrain vertices from a dumb raster file (heightmap, like you use in many 3d modelling programs) directly to osg (without osgdem preparation)? thanks in advance, christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7253#7253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] basic terrain querstions
Hi Christian, If you're looking for a way to view terrain data on the fly without VPB preparation, you can check out osgEarth at http://www.osgearth.org. It has a GDAL driver that should read your raster files and display them on the fly. Thanks! Jason On Mon, Feb 23, 2009 at 2:27 PM, Christian Sam osgfo...@tevs.eu wrote: hi i would like to get a better understanding of osg's various possibilities in terrain-visualization. currently i'm using osggis/virtualplanetbuilder to display georeferenced, common gis rasterfiles which work wonderful. but as an osg-newbie i also would like to know what are the approaches of basic terrain handling of osggis' underlying osg. what i know/suppose so far: * according to the osgforest example, the most basic method seems to be using osg::Geometry, attach a vertex-/texturecoord array and draw as indiced DrawElement primitiveset. * the other possibility seems to be osg:HeightField, which is less code than the above one, as well i can omit texturecoordinates (at least according to the example) because of its regular grid characteristic. what i would like to know: * are these assumptions right? * are there other terrain related possibilities? * i also have read about osgTerrain, but when i start the osgterrain example with an osgdem (--TERRAIN) generated dataset: osgterrain.exe boston-sample\terrain\out.ive i get the following message: No model created, please specify terrain or master file on command line, so till yet i haven't got an impression what osgTerrain actually is/does. actually it is more important for me to get some information about osgTerrain itself, than to get this example running - but if it happens that someone knows why that application doesn't work it's okay too ;-) * is there an easy way or example on how to load terrain vertices from a dumb raster file (heightmap, like you use in many 3d modelling programs) directly to osg (without osgdem preparation)? thanks in advance, christian -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7253#7253 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trac menu
Sorry guys, I again push up this topic. There is currently some right/access problems on the trac page. Registered users are not able to add CommunityNews or to do anything with the Blog. Robert, you know that already. However, it seems that Jose Luis overseen this thread. Robert, could you point him again on this issue? Or are there some extra things one need to do to be able to post to community news or to the blog? cheers, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7256#7256 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Vincent, from your code, I do not see what could be wrong there. Maybe try no to copy the image, but to change the given image directly. However, maybe I oversee something... Is your returned result or just don't have valid data in it? Try to play with the for-loop, so to just create the resulting image with only green color for example and to see what happens. It could be that there is a problem with the input image... regards, art -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7258#7258 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Vincent Bourdier wrote: [snip] data[n+3] = 1.0; This isn't your problem with the image not saving but I think it will hit you eventually. data is a char array and you are setting a float. I think you really want to be setting 0xff or 255. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB and imagery without filename extensions.
A lot of the imagery data we use is in ENVI's native format. GDAL does support it and it has worked in previous versions of Virtual Planet Builder. It now fails with the current SVN head (953) because the data doesn't use a filename extension. Typically the ENVI format is composed of two files (sample.hdr and sample, for example). One file has the projection and image info, the other is just the raw data. All the gdal commands want the file without the extension as the argument. Previously, this was not an issue with VPB, but the new method of checking filename extensions on input files is causing problems. Since there is no extension to add to VPB's list, may I suggest a flag for VPB to tell it not to do the filename extensions checking? Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ANN: OSG Training in Washington DC
Hello all -- Is anyone intending to sign up for this training that hasn't done so yet? At this point, we're inclined to cancel the first day Intro course due to low attendance. The Intermediate and Terrain courses will proceed as scheduled. If you intend to register for the Introduction to OSG course, please do so immediately and notify me by direct email, thanks. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 _ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Paul Martz Sent: Wednesday, January 21, 2009 7:14 PM To: 'OpenSceneGraph Users' Subject: [osg-users] ANN: OSG Training in Washington DC Hi all -- I'm pleased to announce that registration is now open for our next public OSG training course, to be held in Washington DC, March 9-12, 2009. To view course information and register online, please visit: http://www.skew-matrix.com/training.html http://www.skew-matrix.com/training.html Register before February 9 for all three courses and receive a $440 discount! Hope to see you in DC. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Packaging distribution under Windows
Hi all Windows users (and others too, I'm not doing discrimination ;) ), Under Linux ( co), packages can have dependencies. Under Windows, we're far to have such an easy system. Question is: how could we redistribute efficiently the OSG binaries (I mean when not linking statically) alongside our apps? Here are my suggestions, please share your thoughts. 1. Manually copy the DLLs in the app's dir. That becomes a pain if you select each DLL by hand, and you may have multiple copies for each app. 2. Say to the user (s)he must download the OSG binaires. Not very user firendly, IMO. 3. Create a nice installer that contains the OSG packages. Thus the installer become obese since we don't need all the DLLs... 4. Create a nice installer that contains partial packages. Not very clean to begin splitting packages I think. 5. Create a nice installer that will download packages on the web. Nice, but what about installing on a machine that has no connection? Should we provide both online and offline installers? And about installers... Should we copy the DLLs to the system dir? What about Vista and its strange policies about having access to system dirs (I simply stayed under XP :D )? Thank you! PS: It seems I'm going to have an installer (or such) ten times bigger than my app... (sigh) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Packaging distribution under Windows
My 2p worth... Since you are considering only a MSVS environment, it looks far more professional to have something like InstallShield. Creating it would seem to be a relatively trivial task (when I watched someone else create one using a VS 2003 InstallShield wizard in about 15 seconds). The only fly in the ointment is deciding on a version that supports VS 7 (2003), 8 (2005) and 9 (2008). As to online and offline installers, I would go for offline everytime because I have worked on simulator sites that will never be connected to the internet. It also means that come the fateful day when the hard disk dies, the complete install is available from a local security backup rather than relying on a hosting website to still be holding the exact version required to restore the system. (This is a long term support issue - when was the last time you tried to buy a 40MB Winchester hard disk??!! -- oops age showing) PhilT -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org]on Behalf Of Sukender Sent: 23 February 2009 23:51 To: OpenSceneGraph Users Subject: [osg-users] Packaging distribution under Windows Hi all Windows users (and others too, I'm not doing discrimination ;) ), Under Linux ( co), packages can have dependencies. Under Windows, we're far to have such an easy system. Question is: how could we redistribute efficiently the OSG binaries (I mean when not linking statically) alongside our apps? Here are my suggestions, please share your thoughts. 1. Manually copy the DLLs in the app's dir. That becomes a pain if you select each DLL by hand, and you may have multiple copies for each app. 2. Say to the user (s)he must download the OSG binaires. Not very user firendly, IMO. 3. Create a nice installer that contains the OSG packages. Thus the installer become obese since we don't need all the DLLs... 4. Create a nice installer that contains partial packages. Not very clean to begin splitting packages I think. 5. Create a nice installer that will download packages on the web. Nice, but what about installing on a machine that has no connection? Should we provide both online and offline installers? And about installers... Should we copy the DLLs to the system dir? What about Vista and its strange policies about having access to system dirs (I simply stayed under XP :D )? Thank you! PS: It seems I'm going to have an installer (or such) ten times bigger than my app... (sigh) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Packaging distribution under Windows
On Mon, Feb 23, 2009 at 6:51 PM, Sukender suky0...@free.fr wrote: Hi all Windows users (and others too, I'm not doing discrimination ;) ), Under Linux ( co), packages can have dependencies. Under Windows, we're far to have such an easy system. Question is: how could we redistribute efficiently the OSG binaries (I mean when not linking statically) alongside our apps? Here are my suggestions, please share your thoughts. 1. Manually copy the DLLs in the app's dir. That becomes a pain if you select each DLL by hand, and you may have multiple copies for each app. 2. Say to the user (s)he must download the OSG binaires. Not very user firendly, IMO. 3. Create a nice installer that contains the OSG packages. Thus the installer become obese since we don't need all the DLLs... 4. Create a nice installer that contains partial packages. Not very clean to begin splitting packages I think. 5. Create a nice installer that will download packages on the web. Nice, but what about installing on a machine that has no connection? Should we provide both online and offline installers? I'm starting a project called CMakePorts that aims to solve some of these goals. The goal would be to build many of the popular dependent libraries as part of the OSG and then since they would be make installed they could simply be picked up by CPack (and/or any installer someone might choose to contribute). http://code.google.com/p/cmakeports/wiki/CMakePortsPlan It's obviously still in the planning phase right now though. And about installers... Should we copy the DLLs to the system dir? What about Vista and its strange policies about having access to system dirs (I simply stayed under XP :D )? Assuming you want an application to be used by non-administrators and non-power users (certainly the case with the OSG, IMHO) you're always going to want the DLLs to at least be available alongside the .EXE files as an option in the installer. -- Philip Lowman ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CMake 2.6.3 brings easier OSG integration out-of-the-box
The release of CMake 2.6.3 includes a new find module which makes using the
OSG from within a project of your own much easier to do. There is also
version support available should you want to specify the minimum (or exact)
version of the OSG that is needed to build your project.
Here's a 6 line hello world example. Replace foo.cpp with the OSG app of
your choice and modify the find_package() line to contain the list of
nodekits/libraries you require.
CMakeLists.txt:
=
project(Foo)
cmake_minimum_required(VERSION 2.6.3)
find_package(OpenSceneGraph 2.8.0 REQUIRED osgUtil osgDB
osgWhateverNodekitsYouNeed)
include_directories(${OPENSCENEGRAPH_INCLUDE_DIRS})
add_executable(foo foo.cpp)
target_link_libraries(foo ${OPENSCENEGRAPH_LIBRARIES})
==
If you need to set cmake_minimum_required to less than 2.6.3 please see the
documentation for FindOpenSceneGraph.cmake as you will need to copy a few
files from the 2.6.3 release of CMake into your CMake module path.
--
Philip Lowman
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with VPB and DTED data.
Hi, what OS are you using? What version of GDAL? On Linux I've not had a problem reading .dt? files. jp Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW wrote: It seems that VPB (SVN revision 953) won't accept DTED data. Looking at the VPB code, VPB gets a list of GDAL supported extensions (and adds a few that GDAL doesn't report). Looking at GDAL, it fails to report the DTED extensions (.dt0, .dt1, .dt2) via the GetMetadataItem(DMD_EXTENSIONS) method. The result is VPB reports that DTED files are not supported. I don't know if the fix belongs in GDAL or VPB, but as a quick work-around add the following lines to the end of the VPB System constructor (src/vpb/System.cpp): addSupportedExtension(dt0, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 0); addSupportedExtension(dt1, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 1); addSupportedExtension(dt2, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 2); Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi, Robert Osfield wrote: Hi J.P, On Mon, Feb 23, 2009 at 1:49 PM, J.P. Delport jpdelp...@csir.co.za wrote: I must admit I had no idea how long something like this would take :/ It is in progress is all I can say. It is something quite new at our company and there is no existing process. It is hard to convince people that open sourcing != giving away secrets/whatever. No problem. Can I pick your brains on ffmpeg integration? A quick search for tutorials on ffmpeg came up with: http://www.dranger.com/ffmpeg/tutorial01.html Which seems like a pretty decent place to start. Looks like it'll be quite straight forward. Did you use a particular example/tutorial for inspiration? I looked at this and also the simple example that comes with the source distribution. jp Robert. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi, Robert Osfield wrote: Hi Tanguy, On Mon, Feb 23, 2009 at 3:01 PM, Tanguy Fautre tang...@aristechnologies.com wrote: Talk about timing... That's why it's always worth doing a syncronization step before coding :-) I've just got the green light from my boss. Excellent news. Means we all save some time, and we all can work on improving the code base. I suggest you use Tanguy's implementation. I'd help where I can. Our code is not a plugin in the OSG sense, but is part of a framework for doing image processing with OSG. I'm trying to get the whole framework released. There might be some existing parts of the framework we can later include, e.g. movie writing. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading movie
Hi Tanguy, Robert, Tanguy Fautre wrote: Hi Robert, I've uploaded the plugin sources, plus example application and FFmpeg Windows binaries (non-GPL) to the FTP. When you say non-GPL what do you mean? I've done some research into the whole FFmpeg GPL vs LGPL issues, since I would like to release our code under LGPL. It is quite easy to build LGPL versions of ffmpeg on Debian/Ubuntu. The standard packages contain GPL code. If you would like to know the gory details, let me know. jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with VPB and DTED data.
Hi, must admit I have not tried the latest OSG version, maybe it's a change in OSG and not VPB? jp J.P. Delport wrote: Hi, what OS are you using? What version of GDAL? On Linux I've not had a problem reading .dt? files. jp Sewell, Kenneth R Civ USAF AFMC AFRL/RYZW wrote: It seems that VPB (SVN revision 953) won't accept DTED data. Looking at the VPB code, VPB gets a list of GDAL supported extensions (and adds a few that GDAL doesn't report). Looking at GDAL, it fails to report the DTED extensions (.dt0, .dt1, .dt2) via the GetMetadataItem(DMD_EXTENSIONS) method. The result is VPB reports that DTED files are not supported. I don't know if the fix belongs in GDAL or VPB, but as a quick work-around add the following lines to the end of the VPB System constructor (src/vpb/System.cpp): addSupportedExtension(dt0, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 0); addSupportedExtension(dt1, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 1); addSupportedExtension(dt2, Source::IMAGE | Source::HEIGHT_FIELD, DTED Level 2); Ken. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VPB trac site
Hi, I can't view the VPB Timeline any more. First error is: Error: Forbidden TIMELINE_VIEW privileges are required to perform this operation When I try to login, I get: Trac Error Authentication information not available. Please refer to the installation documentation. regards jp -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg Image and PNG writer
Hi Paul Nice observation ! I was a little bit tired yesterday evening I think... it is better with 0 to 255 values... Art, the code is good if at the end I just do a result-setImage(result-s(), result-t(), result-r(), result-getInternalTextureFormat(), result-getPixelFormat(), result-getDataType(), data, result-getAllocationMode()); ( and no the whole allocation) Thanks for your help, I can now save png files with alpha channel :-) Regards, Vincent. 2009/2/23 Paul Speed psp...@progeeks.com Vincent Bourdier wrote: [snip] data[n+3] = 1.0; This isn't your problem with the image not saving but I think it will hit you eventually. data is a char array and you are setting a float. I think you really want to be setting 0xff or 255. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
