Re: [osg-users] osgswig cmake problem
Hi, El Viernes 14 Noviembre 2008ES 19:12:17 Patrick Bouffard escribió: I know I *should* be able to compile it from source but I'd like to avoid going down that rabbit-hole.. Hardy ships with 2.2.0: http://packages.ubuntu.com/hardy/openscenegraph Compiling it from source, specially on Ubuntu is far easier than satisfying all the dependencies that a 2.4.0 package extracted from, say Intrepid, would require. Just a few apt-gets cmake make :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] set the position of a model
El Viernes 14 Noviembre 2008ES 21:04:01 Francisco Rodríguez Villagómez escribió: Hi guys, I hope anyone could help me, I'm new to osg an Im making an application in wich I have to point at some models with an arrow model to specify wich of this models the user has selected, so my problem is how can I set the position of the arrow if I dont know where the oder models are set in the scene? I wish anyone could give me a hand with these. Francisco, see the osgpick example. There you will learn how to compute the location of the selection the user has made. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to define my own geometry in osgswig?
Linh, Currently in osgswig you cannot directly override osg.Drawables in the target scripting language. This is partly because we have not enabled SWIG directors for this class, which are responsible for such cross-language inheritance. Also, Drawables are pure virtual/abstract which doesn't play nice with our directors. As an alternative, you might want to try and enable Directors for Geometry in osg.i: %feature(director) osg::Geometry; I'll consider this a feature request, will try this and see what the consequences on performance are. See the pyramid.py example for defining your own geometry without subclassing. Gerwin On Mon, Nov 17, 2008 at 8:43 AM, Phan, Linh H [EMAIL PROTECTED] wrote: Hi, I was wondering if it's possible to draw my own geometry in osgswig, eg something like: import osg, osgViewer class MyCube(osg.Drawable): def __init__(self): osg.Drawable.__init__(self); # AttributeError: No constructor defined def drawImplementation(self, state): # draw some geometry glutWireCube (1.0) def computeBound(self): bbox = osg.BoundingBox() bbox.set(-2,-2,-2,2,2,2) return bbox geode = osg.Geode() geode.addDrawable(MyCube()) viewer = osgViewer.Viewer() viewer.setSceneData(geode) viewer.run() I get AttributeError: No constructor defined when I run it. Is there a way to draw my own geometry? Thank you, Linh ___ 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] CompositeViewer with one Window
Hi Tommy, Good to hear you are getting a better understanding of osgViewer, but please don't use GLUT, it really is awful for anything more than single threaded, single window basic OpenGL demos. osgViewer has inbuilt into it far far more powerful and flexible cross platform windowing support. Robert. On Mon, Nov 17, 2008 at 1:26 AM, Tommy Persson [EMAIL PROTECTED] wrote: OK, I think I undertand it better now conceptually. What confused me was that two different cameras draw on the same area if both were enabled. I only thought one camera could be enbled at the time for the same area. Just a quick question (I will test more systematically tomorrow). I tried to use the code in osgcompositeviewer that run with flag -1 and use it in my GLUT application (just using one view). But the events does not seem to get to the trackball manipulator. So do I have to do something special to get this to work for GLUT (it seems I have done the same thing as in the example code but it does not work...). So if I have more than one camera active will the mouse events go to all the cameras? If just one camera is active will the events only go to that camera? Robert Osfield [EMAIL PROTECTED] writes: Hi Tommy, Sharing a single window between multiple views is demonstated in the osgcompositeviewer example - you simply assign the same GraphicsWindow to the Camera's in each of the Views. You change views you can stop the viewer threads and then add/remove views you need then restart the threading, this will drop a few frames though due to stopping/start of threads. The other way is to switch off the rendering of the view by setting its Camera's NodeMask to 0x0 to disable it. Robert. On Sun, Nov 16, 2008 at 12:27 AM, Tommy Persson [EMAIL PROTECTED] wrote: I would like to have one Window (with possibility to use more) and be able to switch between different views. One shoud be a trackball manipulator. And there is also a set of NodeTrackerManipulators wich follows different helicopters. I tried to do this with just Viewer but had trouble to remember the state of the NodeTrackerManipulators and the TrackballManipulators. So I thought the CompositeViewer was the right approach but I cannot find how to use it with one Window and switching between views. So am I on the wrong track or have I just missed som dokumentation or code example? What I am looking for is an example of how to set up CompositeView using one Window (using Glut) and creating a set of views with different camera maipulators. -- /Tommy Persson ___ 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 -- /Tommy Persson ___ 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] Question about views, contexts and threading
I'm looking to do the following in OSG, and I wonder if I'm on the right track (before wasting time needlessly): have two render processes run in parallel on two different GPUs, have one render a scene to texture and let this texture be read by the other process and mapped to an object in a different scene. Problem, the rendering of the first scene to texture is very slow and the rendering of the second scene is very fast. I intend to solve it in the following way in pseudo-code: - new CompositeViewer - Add two Views - Construct two contexts, one on localhost:0.0, one on localhost:0.1 - Attach contexts to cameras of corresponding Views - Set composite viewer threading mode to thread-per-context --- First process - Set view camera mode to FBO and pre-render - Add post-draw callback and render textures - Download texture to host memory in post-draw callback - (possibly add post-render camera to render textured screen quad as output) --- Second process - Add update-callback and regular texture - Upload host memory to texture in update callback (if available, non-blocking) The downloading and uploading of textures uses multiple slots and regular threaded locking, so to ensure we never read or write the same memory at the same time. The second process doesn't block if no new texture is available, it just continues using the old one then. Some questions. Will the two processes now run at independent frame rates, or will the composite viewer synchronize them? I need them to run independently. I read OSG does not support multi-threaded updating of the scene graph. However, if I use two distinct scene graphs with two contexts, I can _pull_ updates in an update callback from another thread, right? What I can not do is push updates at arbitrary times; that would make sense. How do I make the TrackballManipulator work for only the first process? It seems that as soon as I set that camera to FBO it just doesn't respond to events (or maybe something else is wrong... I added another orthogonal camera to the view1-getCamera() that renders the screenquad in post-render mode). Also, the second process camera is affected when I move the mouse in the first process window. Is it sufficient to call view2-getCamera()-setAllowEventFocus(false); to disable this behavior? Finally, can I do this the same way with a shared context on a single GPU (i.e. both on :0.0) sharing texture data directly on the GPU in different textures? Ignoring the slow context switching issues for the time being. Am I one the right track here, or should this be done differently? I know all this is possible because I have the manual OpenGL code for it working, both using shared contexts and with up/downloading of texture data. -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about views, contexts and threading
Hi Ferdi, osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. So for you case where you want them to run async, this isn't supported. Supporting within CompositeViewer would really complicate the API so it's not something I gone for. What you will be able to do is use two separate Viewer's. You are likely to want to run two threads for each of the viewers frame loops as well. To get the render to image result to the second viewer all you need to do is assign the same osg::Image to the first viewer's Camera for it to copy to, and then attach the same osg::Image to a texture in the scene of the second viewer. The OSG should automatically do the glReadPixels to the image data, dirty the Image, and then automatically the texture will update in the second viewer. You could potentially optimize things by using an PBO but the off the shelf osg::PixelBufferObject isn't suitable for read in this way so you'll need to roll you own support for this. It's worth noting that I've never written a app like the above, so you are rather working on the bleeding edge. I think it should work, or at least I can't spot any major problems that might appear. Robert. On Mon, Nov 17, 2008 at 9:37 AM, Ferdi Smit [EMAIL PROTECTED] wrote: I'm looking to do the following in OSG, and I wonder if I'm on the right track (before wasting time needlessly): have two render processes run in parallel on two different GPUs, have one render a scene to texture and let this texture be read by the other process and mapped to an object in a different scene. Problem, the rendering of the first scene to texture is very slow and the rendering of the second scene is very fast. I intend to solve it in the following way in pseudo-code: - new CompositeViewer - Add two Views - Construct two contexts, one on localhost:0.0, one on localhost:0.1 - Attach contexts to cameras of corresponding Views - Set composite viewer threading mode to thread-per-context --- First process - Set view camera mode to FBO and pre-render - Add post-draw callback and render textures - Download texture to host memory in post-draw callback - (possibly add post-render camera to render textured screen quad as output) --- Second process - Add update-callback and regular texture - Upload host memory to texture in update callback (if available, non-blocking) The downloading and uploading of textures uses multiple slots and regular threaded locking, so to ensure we never read or write the same memory at the same time. The second process doesn't block if no new texture is available, it just continues using the old one then. Some questions. Will the two processes now run at independent frame rates, or will the composite viewer synchronize them? I need them to run independently. I read OSG does not support multi-threaded updating of the scene graph. However, if I use two distinct scene graphs with two contexts, I can _pull_ updates in an update callback from another thread, right? What I can not do is push updates at arbitrary times; that would make sense. How do I make the TrackballManipulator work for only the first process? It seems that as soon as I set that camera to FBO it just doesn't respond to events (or maybe something else is wrong... I added another orthogonal camera to the view1-getCamera() that renders the screenquad in post-render mode). Also, the second process camera is affected when I move the mouse in the first process window. Is it sufficient to call view2-getCamera()-setAllowEventFocus(false); to disable this behavior? Finally, can I do this the same way with a shared context on a single GPU (i.e. both on :0.0) sharing texture data directly on the GPU in different textures? Ignoring the slow context switching issues for the time being. Am I one the right track here, or should this be done differently? I know all this is possible because I have the manual OpenGL code for it working, both using shared contexts and with up/downloading of texture data. -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ 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] Problem with default lighting
Hi Eduard, The description of the problem sounds to me like the normals of the geometries aren't of unit length so messing up the lighting model, this can happen if there are transforms that scale the scene. You can enable GL_NORMALIZE or GL_RESCALE_NORMAL modes on the scene to fix the lengths of the normals. See the include/osg/Transform header for docs on this issue. Robert. On Mon, Nov 17, 2008 at 9:58 AM, Eduard Trulls [EMAIL PROTECTED] wrote: Hi, I'm running into a little issue using osgviewer's default lighting scheme (headlight) in my application, in that some surfaces go from a rather bright white/gray to pitch black *very* suddenly when viewed at a relatively sharp angle. Other surfaces viewed at a similar angle may remain lightened, and the drop-off happens for all parallel surfaces at the same time, regardless of view position. It all sounds rather convoluted but it's quite simple; I attach a simple test model you may open with osgviewer and a screenshot. The surface normals seem correctly defined (I use sketchup for design, export as .obj and convert to .osg, then tinker a little bit with the output). Maybe my understanding of the lighting scheme isn't up to par. Is this the expected behaviour? Thanks in advance for any help! E. ___ 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] Problem with default lighting
Hi Eduard, if you look at Geodes Mesh6 Model and Mesh7 Model you'll notice that they don't have any normals whatsoever. I'd suspect they're just picking up normals from one of the previous nodes. /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg_gen
I have done all, but I can not find the file. I donwloaded the OSG and VPB from the version svn related. I did everything but I do not know why, the cmake does not fill that correspondence(osg_gen) and I have to do by hand. Could you tell me where is osg_gen file? 2008/11/16 Robert Osfield [EMAIL PROTECTED] HI Adaya, Do you do an out of source build on the OSG? Have you installed the OSG? How did you tell VPB about the placement of the OSG? In theory it should pick up on the include directories automatically, but perhaps you usage combination has not been handled by the VirtualPlanetBuilder/CMakeModules/FindOSG.cmake script. Robert. On Sun, Nov 16, 2008 at 1:53 PM, Adaya Lorenzo [EMAIL PROTECTED] wrote: Hello. I have tried to compile Virtual Planet Builder v0.9.9 using OSG 2.7.4 and I have a dependence 'osg_gen' but I do not find it in any place. Specifically when I use cmake with vpb, it searches osg_gen_include_dir but I do not find the file. Thanks for answering -- Adaya Lorenzo ___ 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 -- Adaya Lorenzo Leon ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Terrain Creation Method for using Ocean Effect?
Hi All, I have researched for creating Ocean rendering on GPU by GLSL for about 2 weeks. I have read lots of article, thesis and document about it and much of them using different mathematical model ( FastFouriefTransformation, Navier-Stokes Equation, Gerstner Waves, Choppy Waves, Perlin Noise based Waves, Bumb Mapping based waves and etc. ) to simulate Ocean environment on created different terrain surfaces ( LOD, CLOD, Projected Grid Terrain, Simple Quad and etc ) with simulating different underwater and topwater effects ( caustics, godrays, refrection, reflaction, frestnel equation for them, foam, spray, etc. ) After all, I have lost on these all methods and I can't start to implement because of I confused how should I start to create my ocean effects. Firstly I would create some formatted terrain but how should I create my terrain? To avoid unnecessary operations on the GPU I would only send the related part of terrain to the GPU. To do this operation which method save my GPU time? And could I use LOD terrain generator api like VirtualPlanetBuilder or another or created terrain models reduces my GPU operation time as manuel created LOD terrain? Sorry I have asked too much question but I have confused and need some answer to feel myself ready. -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Multi-threading bug related to Registry
There is a nasty multi-threading bug related to osgDB::DatabasePager and the _objectCache in osgDB::Registry. This is the situation. * Thread 2 stack (DatabasePager thread): ReaderWriter::ReadResult Registry::readImplementation ReaderWriter::ReadResult Registry::readImageImplementation ReaderWriter::ReadResult Registry::readImage osg::Image* osgDB::readImageFile osg::Image* DataInputStream::readImage(std::string filename) osg::Image* DataInputStream::readImage(IncludeImageMode mode) osg::Image* DataInputStream::readImage() void Texture2D::read(DataInputStream* in) .. - After reading in the file in Registry::readImplementation the refCount of the new Image is 1 (ReadResult contains a ref_ptr). - This Image is then inserted into Registry::_objectCache with the default timestamp (0.0), which increments the recCount to 2. - The ReadResult object is returned, so no net change in refCount, until the stack is unwound up to osgDB::readImageFile. - osgDB::readImageFile takes a normal pointer to the Image, which does not change the refCount. When osgDB::readImageFile returns, the ReadResult object goes out of scope, deleting a reference to the Image. refCount is now 1. - Stack unwinds until back in Texture2D::read at which point the normal Image* is passed into Texture2D::setImage which assigns the Image* to the internal ref_ptr. At this moment the refCount is increased back to 2. Imagine that somewhere during the stack unwind between osgDB::readImageFile and Texture2D::read a thread switch takes place. * Thread 1: The main thread then reaches DatabasePager::removeExpiredSubgraphs which does the following at the end of the function. - Calls Registry::updateTimeStampOfObjectsInCacheWithExternalReferences, which goes through the objects and increments the timestamp if the refCount1 (this is not true for just loaded Image, so timestamp remains 0.0). - Calls Registry::removeExpiredObjectsInCache, which goes through all the objects and compares the timestamp with the expiry time. Because the Image was added with timestamp 0.0 (and the timestamp was not updated), it is added to objectsToRemove. - Registry::removeExpiredObjectsInCache then removes all the objects in objectsToRemove from Registry::_objectCache. This causes the refCount on the Image to decrement to 0, causing the actual Image object to be freed. At this point Thread 2 has an Image* to freed memory, but does not realize the object has been freed. In our case this eventually led to crashes. There are two solutions to this: - Instead of using the default timestamp of 0.0, set the time explicitly to the current time. This makes sure the item is not immediately discarded from the Registry. Even if not all loads are finished before the new item times out, the item will have been acquired by some other place in the code, so the refCount will be larger than 1 when the timeout occurs. This requires the current time to be passed into readImplementation. A proper solution would be to pass in the timestamp of the DatabaseRequest into the read* functions. That requires modification of a lot of functions though. - Changing the return types of the sequence above so there aren't any normal osg::Image* passed around, but only ref_ptr. This makes sure that refCount never goes to during the loading process. This option also requires the modification of a large number of functions. We chose a slightly less proper solution following the first option. We've added a function to set the time in Registry once a frame, and call that just before DatabasePager::updateSceneGraph (which calls DatabasePager::removeExpiredSubgraphs). Please feel free to contact me for more info as needed, Rick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PNG and Collada
I have looked at bit harder at the code now and I now realise that I
only partially fixed Sketchup's broken Collada stuff.
Sketchup is putting the texture image sampler reference into the
Collada diffuse parameter and sets the transparent
parameter to a fixed opaque white colour. The plugin assumes assumes
that when tranparency processing is active (the spec says this is when
either transparent or transparency is present) the
colour information should come from the transparent parameter
which is either a fixed colour or a texture sampler. So as things are
as the moment the plugin will not use ONE_MINUS_SRC_ALPHA as the blend
function unless transparent is a image sampler rather than a
fixed colour.
As far as I can see this is a grey area in the Collada spec. I think
our current interpretation is reasonable as I cannot see another way to
distinguish between from the Collada document when to use
ONE_MINUS_CONSTANT_ALPHA and ONE_MINUS_SRC_ALPHA as the OpenGL blend
function. Any one got any thoughts on this?
Sketchup and Google Earth are two of the biggest users of Collada, so
sheer weight of numbers makes it difficult to argue against their
interpretation of the spec. If only we really knew what it was!
I asked a similar question when I originally submitted the changes a
year go and got no replies. So once again. Does anyone have any further
information about how this should be interpreted? Also any information
on how the major players intepret it would be useful!
Roger
Roger James wrote:
Alessandro,
I put the GoogleMode flag into the dae writer in December 2007 after
examing the dae files ouput by Sketchup at that time. Here is the
comment from the SVN log.
8. User can supply an experimental GoogleMode option on output. The
plugin
will try to emulate the way Sketchup specifies transparency (i.e. the
inverse of what it should be!). I am still struggling to get GE to
understand transparency, anyone know what it expects?
Sketchup at that time wrote dae files that did not conform to the
Collada specification. It may or may not still do so, I have not
checked recently. At around the same time I put a check into the dae
reader code to set a flag if the authoring tool field in the collada
header contained the words "Google Sketchup". Have a look at
daeRMaterials.cpp and search for m_AuthoringTool and you will see how
the current reader handles transparency settings it thinks come from
Sketchup. Looking at your osg file below it looks like whatever the the
transparency value was in the incoming dae file the material is
actually being treated as opaque (transparency * constant colour alpha
0.99) and not put in the transparent bin. This may not be correct
behaviour any more.
Roger
aalessandro terenzi wrote:
I'm experiencing some problem with collada models and
transparency texture maps. I saw that in May someone had the same
problem but finally I couldn't find a solution. I tried with osg2.2.0
and 2.6.0 and it looks like that transparency doesn't work with collada
models and png texture maps.
I checked Robert's suggestion and converted to .osg to check
if
GL_BLEND function was enabled or not and it looks like it is... here
follow a piece of the converted .osg file.
Geode {
name "material10"
nodeMask 0x
cullingActive TRUE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_BLEND ON
Material {
ColorMode OFF
ambientColor 0 0 0 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0.33 0.33 0.33 1
emissionColor 0 0 0 1
shininess 20
}
BlendFunc {
source CONSTANT_ALPHA
destination ONE_MINUS_CONSTANT_ALPHA
}
BlendColor {
constantColor 1 1 1 1
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
file "images/texture9.png"
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter NEAREST_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
}
}
[...gemoterty data follow here...]
Is there something wrong with this file?
Someone talked about a problem in Sketchup with png files,
actually the models I'm dealing with come from Sketchup...is there
really a problem with Sketchup? Someone talked about a 'GoogleMode' in
the collada plugin butit looks like it is an option used for writing
collada files not for reading.
Thank you for any advice or direction.
Alessandro
___
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
Re: [osg-users] PNG and Collada
I have just looked at the latest Collada spec (1.5.1) and they have
changed the default for the opaque attribute of the transparent from
A_ONE (1 is opaque) to A_ZERO (0 is opaque). This would will fix some
of the Sketchup inconsistencies as and when Skertchup gets round to
specifying version 1.5.1 in the documnet header. Well I guess the big
guys can change basic defaults whenever they fell like it. It means we
will have to check for schema versions in the plugin now!
Roger
Roger James wrote:
I have looked at bit harder at the code now and I now realise that I
only partially fixed Sketchup's broken Collada stuff.
Sketchup is putting the texture image sampler reference into the
Collada diffuse parameter and sets the transparent
parameter to a fixed opaque white colour. The plugin assumes assumes
that when tranparency processing is active (the spec says this is when
either transparent or transparency is present) the
colour information should come from the transparent parameter
which is either a fixed colour or a texture sampler. So as things are
as the moment the plugin will not use ONE_MINUS_SRC_ALPHA as the blend
function unless transparent is a image sampler rather than a
fixed colour.
As far as I can see this is a grey area in the Collada spec. I think
our current interpretation is reasonable as I cannot see another way to
distinguish between from the Collada document when to use
ONE_MINUS_CONSTANT_ALPHA and ONE_MINUS_SRC_ALPHA as the OpenGL blend
function. Any one got any thoughts on this?
Sketchup and Google Earth are two of the biggest users of Collada, so
sheer weight of numbers makes it difficult to argue against their
interpretation of the spec. If only we really knew what it was!
I asked a similar question when I originally submitted the changes a
year go and got no replies. So once again. Does anyone have any further
information about how this should be interpreted? Also any information
on how the major players intepret it would be useful!
Roger
Roger James wrote:
Alessandro,
I put the GoogleMode flag into the dae writer in December 2007 after
examing the dae files ouput by Sketchup at that time. Here is the
comment from the SVN log.
8. User can supply an experimental GoogleMode option on output. The
plugin
will try to emulate the way Sketchup specifies transparency (i.e. the
inverse of what it should be!). I am still struggling to get GE to
understand transparency, anyone know what it expects?
Sketchup at that time wrote dae files that did not conform to the
Collada specification. It may or may not still do so, I have not
checked recently. At around the same time I put a check into the dae
reader code to set a flag if the authoring tool field in the collada
header contained the words "Google Sketchup". Have a look at
daeRMaterials.cpp and search for m_AuthoringTool and you will see how
the current reader handles transparency settings it thinks come from
Sketchup. Looking at your osg file below it looks like whatever the the
transparency value was in the incoming dae file the material is
actually being treated as opaque (transparency * constant colour alpha
0.99) and not put in the transparent bin. This may not be correct
behaviour any more.
Roger
aalessandro terenzi wrote:
I'm experiencing some problem with collada models and
transparency texture maps. I saw that in May someone had the same
problem but finally I couldn't find a solution. I tried with osg2.2.0
and 2.6.0 and it looks like that transparency doesn't work with collada
models and png texture maps.
I checked Robert's suggestion and converted to .osg to check
if
GL_BLEND function was enabled or not and it looks like it is... here
follow a piece of the converted .osg file.
Geode {
name "material10"
nodeMask 0x
cullingActive TRUE
StateSet {
DataVariance STATIC
rendering_hint DEFAULT_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_BLEND ON
Material {
ColorMode OFF
ambientColor 0 0 0 1
diffuseColor 0.8 0.8 0.8 1
specularColor 0.33 0.33 0.33 1
emissionColor 0 0 0 1
shininess 20
}
BlendFunc {
source CONSTANT_ALPHA
destination ONE_MINUS_CONSTANT_ALPHA
}
BlendColor {
constantColor 1 1 1 1
}
textureUnit 0 {
GL_TEXTURE_2D ON
Texture2D {
file "images/texture9.png"
wrap_s REPEAT
wrap_t REPEAT
wrap_r CLAMP
min_filter NEAREST_MIPMAP_LINEAR
mag_filter LINEAR
maxAnisotropy 1
borderColor 0 0 0 0
borderWidth 0
useHardwareMipMapGeneration TRUE
unRefImageDataAfterApply TRUE
internalFormatMode USE_IMAGE_DATA_FORMAT
resizeNonPowerOfTwo TRUE
}
}
}
[...gemoterty data follow here...]
Is there something wrong with this file?
Someone talked about a problem in Sketchup with png files,
actually the models I'm dealing with come from Sketchup...is there
really a problem with Sketchup? Someone talked about a 'GoogleMode' in
the collada plugin butit looks like it is an option
Re: [osg-users] CompositeViewer with one Window
Robert Osfield [EMAIL PROTECTED] writes: Hi Tommy, Good to hear you are getting a better understanding of osgViewer, but please don't use GLUT, it really is awful for anything more than single threaded, single window basic OpenGL demos. osgViewer has inbuilt into it far far more powerful and flexible cross platform windowing support. Thanks for that advice. I just converted to using only osgViewer and my problem with events to trackball disappearred. -- /Tommy Persson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem with 2D scene
I have commented out those lines in svn revision: 9171. The problem with
2D scenes I reported is gone and everything else seems to work as it did
before.
If you would like, I would be happy to write a regression test.
Frank
On Sun, Nov 16, 2008 at 11:41:10AM +, Robert Osfield wrote:
Hi Frank,
Good detective work. I hadn't thought about this tiny little
optimization in the updateCalculatedNearFar. This optimization only
makes sense of perspective projections, and if fact could probably be
safely removed completely for all types of projection matrices.
Could you comment out the lines:
if (d_far0.0)
{
// whole object behind the eye point so discard
return false;
}
From CullVisitor::updateCalculatedNearFar and see how you get on. If
that works fine then we'll need to look at a fix in svn.
Robert.
On Fri, Nov 14, 2008 at 9:05 PM, [EMAIL PROTECTED] wrote:
osgUtil/CullVisitor.cpp line 644-645:
// whole object behind the eye point so discard
return false;
Perhaps its not called culling in this case but my code hits this return
statement and as a result, the drawable is not added to the StateGraphList
in
RenderBin. OpenGL is never given a chance to clip.
Frank
On Fri, Nov 14, 2008 at 08:22:31PM +, Robert Osfield wrote:
Hi Frank,
If culling is switched off then culling is off, the eye point will
make no difference.
What difference you moving the eye point will be in the clipping due
to the position of near/far plane.
Robert.
On Fri, Nov 14, 2008 at 8:09 PM, [EMAIL PROTECTED] wrote:
I think I figured it out. It looks like even with culling turned off,
nodes that are behind the eye point are culled. See
osgUtil/CullVisitor.cpp line 645.
I now calculate the view matrix as follows.
osg::Matrixd matrix = osg::Matrixd::translate( -center );
matrix.postMultRotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 ) ) );
matrix.postMultTranslate( osg::Vec3d( 0.0, 0.0, -0.5 ) );
Adding the last translation transform to push the nodes away from the
eye point made the problem go away.
Is this a bug?
Frank
On Thu, Nov 13, 2008 at 11:38:14AM -0500, [EMAIL PROTECTED] wrote:
Hi Robert,
Thanks for the quick response. That was a good suggestion. However it
looks like that is not the problem. All of my nodes live on the z=0.0
plane and my projection matrix is
osg::Matrixd::ortho( -aspectRatio, aspectRatio, -1.0, 1.0, -1.0, 1.0 )
I have attached a small code sample that exhibits the problem.
Frank
On Thu, Nov 13, 2008 at 04:24:37PM +, Robert Osfield wrote:
Hi Frank,
My best guess is that your projection matrix isn't wide enough to
encompass your scene and near/far clipping is clipping out the
fragments. This may well look like culling, often users do mistake
clipping with culling so chase up the wrong part of the pipeline.
Robert.
On Thu, Nov 13, 2008 at 4:18 PM, [EMAIL PROTECTED] wrote:
Greetings osg community,
I'm have written a custom MatrixManipulator for a 2D scene and I am
experiencing a strange problem. As I pan and zoom around, some of
the
nodes in the scene disappear abruptly as if they are being culled
inappropriately. However, disabling culling has no effect.
The behavior is erratic and unpredictable which smells to me like
I'm on
the border of a floating point inequality. I have discovered two
ways
that seem to make the problem go away.
One:
One of the transformations I use to construct the view matrix is
osg::Matrixd::rotate( osg::Quat( PI, osg::Vec3d( 1.0, 0.0, 0.0 )
) )
If I replace that with
osg::Matrixd::scale( osg::Vec3d( 1.0, -1.0, 1.0 ) )
the problem seems to go away.
Two:
All of the nodes in my seen that exhibit this problem have a 2D
bounding box. i.e.
osg::BoundingBox const bb = pGeode-getBoundingBox();
assert( bb.zMax() - bb.zMin() 1e-5 );
If I give the nodes some depth so that the above assert would fail,
the problem seems to go away.
I suspect that these are not actual solutions. In any case, I would
like
to understand what is happening under the covers. Any ideas?
Frank
___
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
#include osg/Geode
#include osg/Geometry
#include osgViewer/Viewer
#include iostream
#include cassert
osg::ref_ptr
Re: [osg-users] You have three guess...
Hmm, just some screenshot as texture on two quads ? Seems too simple... 2008/11/17 Robert Osfield [EMAIL PROTECTED] For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... 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] You have three guess...
Hi, 1. OSG based 3D screen saver 2. Framework for OSG based 3D desktop/browser 3. Two quads with texture mapping Have fun...:-) On Mon, Nov 17, 2008 at 11:08 AM, Robert Osfield [EMAIL PROTECTED]wrote: For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... 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] You have three guess...
El Lunes 17 Noviembre 2008ES 17:08:47 Robert Osfield escribió: For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... Robert That explains the references to mozilla libs... Did you write the email from the application ? WOW!! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
1) OSG announces challenge to Windows Exploder,Firefox Et-el, with announcement of the new OSGBrowz web browsers development node kit 2) I thought it was '2 Turtle Doves' not 2 pdf documents in OSG 3) Was that a bottle of 12 year or 18 year single malt ;) Gordon __ Gordon Tomlinson Product Manager 3D Email : gtomlinson @ overwatch.textron.com __ (C): (+1) 571-265-2612 (W): (+1) 703-437-7651 Self defence is not a function of learning tricks but is a function of how quickly and intensely one can arouse one's instinct for survival - Master Tambo Tetsura -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, November 17, 2008 11:09 AM To: OpenSceneGraph Users Subject: [osg-users] You have three guess... For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... Robert ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
On the left is a screenshot of the OSG website. On the right is a screenshot of the OpenGL website. Both appear to be texture mapped to a quad, which are tilted back a bit from vertical. the background is blue...well blue-ish, somewhat purple. Sorry...that's the best I can do until I finish my first cup of coffee... :) Seriously, I don't know, and I don't keep up to much with what's going on in the OSG development circles, but I must say, I am curious. Ed Robert Osfield wrote: For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... 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] You have three guess...
1. Could it be the VNC client plugin? On Mon, 17 Nov 2008 17:08:47 +0100, Robert Osfield [EMAIL PROTECTED] wrote: For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... 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] You have three guess...
Wow, didn't long for guess that were right on the money ;-) The screenshot was from me running a new OSG example checked in svn/trunk, the command line was: osgbrower openscenegraph.org opengl.org And as guessed the actual email I sent it from was : osgbrowser gmail.com The osgbrower code is based on UBrowser/llmozlib2 which is a gecko based embedded renderer that uses xul-runner 1.8.x. I've opted for a less efficient browser but using an unmodified version of xul-runner, there is a more efficient version of llmozlib2 but this requires modifications of xul-runner. The example right now only works under Linux, but with a few improvements to CMakeLists.txt and the source it should also work under Windows and OSX. My attempt earlier today to get the html rendering done in a background thread failed, so the currently version very crudely updates renders imagery in the main thread, and also re-renders on every frame as there is no mechanism for lazily updating without modifying xul-runner. The fact that the rendering happens in main thread is severly gating performance, so I'm typically seeing around 10fps, which is fine for an interactive browser but not in any way acceptable for a 3D graphics application. So my next task is get the rendering down in a background thread, but it might require a bit of contortion as gecko and llmozlib are not not thread safe, so I'll have to do all calls to it from a single thread, there are also a few oddities like xul-runner under Linux being dependant on a dummy gtk window and events that you must create to get xul-runner working. Basically it's a bit hacky... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer with one Window
Hi Tommy,
On Mon, Nov 17, 2008 at 4:47 PM, Tommy Persson [EMAIL PROTECTED] wrote:
I got this working disabling a camera by setting the nodemask and it
works if the viewports are non-overlapping. But if I create two view
with the same viewport and then disable the camera in the second view
then the mouse events does not arrive at the first view's camera. It
seems that the mouse events only goes to the second view's camera
which is disabled so nothing happens.
So how do I solve this problem?
osg::Camera has a method:
/** Set whether this camera allows events to be generated by
the associated graphics window to be associated with this camera.*/
void setAllowEventFocus(bool focus) { _allowEventFocus = focus; }
Use this to disable the events being passed in. The
CompositeViewer::eventTraversal() method itself probably should check
the Camera NodeMask as well to catch your usage model. Feel free to
add such a check into CompositeViewer and submit this to me.
Do I have to use the method with having just one view in the viewer
and replace it by my saved views? Can I change the view before the
call to frame without stopping the treads or do I have to stop them?
It would be best to just toggle between two Views, or add/remove them.
And how do I stop and start the threads? I found the method
getAllThreads but I have greped on Threads but cannot find where it is
defined...
You're going to kick yourself :-)
viewer.stopThreading();
viewer.startThreading();
These methods are defined in ViewerBase that Viewer and
CompositeViewer derive from.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] CompositeViewer with one Window
Robert Osfield [EMAIL PROTECTED] writes: Hi Tommy, Sharing a single window between multiple views is demonstated in the osgcompositeviewer example - you simply assign the same GraphicsWindow to the Camera's in each of the Views. You change views you can stop the viewer threads and then add/remove views you need then restart the threading, this will drop a few frames though due to stopping/start of threads. The other way is to switch off the rendering of the view by setting its Camera's NodeMask to 0x0 to disable it. I got this working disabling a camera by setting the nodemask and it works if the viewports are non-overlapping. But if I create two view with the same viewport and then disable the camera in the second view then the mouse events does not arrive at the first view's camera. It seems that the mouse events only goes to the second view's camera which is disabled so nothing happens. So how do I solve this problem? Do I have to use the method with having just one view in the viewer and replace it by my saved views? Can I change the view before the call to frame without stopping the treads or do I have to stop them? And how do I stop and start the threads? I found the method getAllThreads but I have greped on Threads but cannot find where it is defined... -- /Tommy Persson ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
El Lunes 17 Noviembre 2008ES 17:18:23 Alberto Luaces escribió: El Lunes 17 Noviembre 2008ES 17:08:47 Robert Osfield escribió: For a bit of fun see if you can explain the attached screenshot... If if you get that right your next challange is explain exactly how I went about writing this email... Robert That explains the references to mozilla libs... Did you write the email from the application ? WOW!! By the way, I can't compile the recent additions to the library (PDF support, the browser, etc.) Seems that my CMake lacks of the necessary modules for finding the libraries: $ cmake . -- checking for module 'librsvg-2.0' -- package 'librsvg-2.0' not found -- checking for module 'poppler-glib' -- package 'poppler-glib' not found -- checking for modules 'xulrunner-xpcom;xulrunner-nspr;xulrunner-nss;xulrunner-plugin;xulrunner-js' -- package 'xulrunner-xpcom' not found -- package 'xulrunner-plugin' not found -- package 'xulrunner-js' not found I couldn't find those modules in my system's CMake or the CVS version of CMake. Maybe they have to be checked on the repository? Thanks, Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgswig on OSX (python bindings)
Hi finally i'm able to build on osx (10.5.5 xcode-3.1): OSG (svn 2.7) OsGis (svn) and VPB (svn 0.9.1) now i'm tring to have osgswig compiled (to have python bindings) i tried to configure the cmake to : www.geofemengineering.it/osgswig_cmake_settings.txt but the make give me these error : www.geofemengineering.it/osgswig_build_log.txt myabe something is wrong in my python libraries or need i to change something in the cmake setting :-/ please, thanks for any help! Massimo Di Stefano. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about views, contexts and threading
Thanks Robert. I did a quick test with two viewers from two threads and it appears to be working. Btw, from my experience, PBO doesn't seem to be any faster (and on some hardware much slower) for downloading textures to host than glReadPixels, while for uploads it is almost consistently faster. Anyway, that should not be a problem, even to code it manually. One question about the OpenGL driver, are you by any chance aware of any threading issues? Is it completely re-entrant from two different contexts and threads? With this two-thread setup, I see some occasional erratic fluctuation in drawing time in the osg performance hud for a completely still scene. The GPU performance is very stable, regardless of the load on the other card, but the drawing time (software) sometimes goes from something like 0.4 to 2.6 or 1.5 for a couple of frames. I do not notice this, or not as much, when using two separate processes instead of two threads. The only difference I can think of here is that the OpenGL driver part is in the same address space and maybe internally locks occasionally? Or is this nonsense? Anyway, the osg part seems to be fairly straightforward and simple like this. Thanks. Robert Osfield wrote: Hi Ferdi, osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. So for you case where you want them to run async, this isn't supported. Supporting within CompositeViewer would really complicate the API so it's not something I gone for. What you will be able to do is use two separate Viewer's. You are likely to want to run two threads for each of the viewers frame loops as well. To get the render to image result to the second viewer all you need to do is assign the same osg::Image to the first viewer's Camera for it to copy to, and then attach the same osg::Image to a texture in the scene of the second viewer. The OSG should automatically do the glReadPixels to the image data, dirty the Image, and then automatically the texture will update in the second viewer. You could potentially optimize things by using an PBO but the off the shelf osg::PixelBufferObject isn't suitable for read in this way so you'll need to roll you own support for this. It's worth noting that I've never written a app like the above, so you are rather working on the bleeding edge. I think it should work, or at least I can't spot any major problems that might appear. Robert. On Mon, Nov 17, 2008 at 9:37 AM, Ferdi Smit [EMAIL PROTECTED] wrote: I'm looking to do the following in OSG, and I wonder if I'm on the right track (before wasting time needlessly): have two render processes run in parallel on two different GPUs, have one render a scene to texture and let this texture be read by the other process and mapped to an object in a different scene. Problem, the rendering of the first scene to texture is very slow and the rendering of the second scene is very fast. I intend to solve it in the following way in pseudo-code: - new CompositeViewer - Add two Views - Construct two contexts, one on localhost:0.0, one on localhost:0.1 - Attach contexts to cameras of corresponding Views - Set composite viewer threading mode to thread-per-context --- First process - Set view camera mode to FBO and pre-render - Add post-draw callback and render textures - Download texture to host memory in post-draw callback - (possibly add post-render camera to render textured screen quad as output) --- Second process - Add update-callback and regular texture - Upload host memory to texture in update callback (if available, non-blocking) The downloading and uploading of textures uses multiple slots and regular threaded locking, so to ensure we never read or write the same memory at the same time. The second process doesn't block if no new texture is available, it just continues using the old one then. Some questions. Will the two processes now run at independent frame rates, or will the composite viewer synchronize them? I need them to run independently. I read OSG does not support multi-threaded updating of the scene graph. However, if I use two distinct scene graphs with two contexts, I can _pull_ updates in an update callback from another thread, right? What I can not do is push updates at arbitrary times; that would make sense. How do I make the TrackballManipulator work for only the first process? It seems that as soon as I set that camera to FBO it just doesn't respond to events (or maybe something else is wrong... I added another orthogonal camera to the view1-getCamera() that renders the screenquad in post-render mode). Also, the second process camera is affected when I move the mouse in the first process window. Is it sufficient to call view2-getCamera()-setAllowEventFocus(false); to disable this behavior? Finally, can I do this the same way with a shared context on a single GPU (i.e. both on :0.0) sharing texture data
Re: [osg-users] You have three guess...
Hi Alberto, On Mon, Nov 17, 2008 at 5:25 PM, Alberto Luaces [EMAIL PROTECTED] wrote: By the way, I can't compile the recent additions to the library (PDF support, the browser, etc.) Seems that my CMake lacks of the necessary modules for finding the libraries: $ cmake . -- checking for module 'librsvg-2.0' -- package 'librsvg-2.0' not found -- checking for module 'poppler-glib' -- package 'poppler-glib' not found -- checking for modules 'xulrunner-xpcom;xulrunner-nspr;xulrunner-nss;xulrunner-plugin;xulrunner-js' -- package 'xulrunner-xpcom' not found -- package 'xulrunner-plugin' not found -- package 'xulrunner-js' not found These are all external dependencies that various existing plugins and the new apps like osgbrowser and osgpdf require. You'll need to download and install these. If you use a linux then there is a good chance that these dependencies are just a click away. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about views, contexts and threading
Hi Ferdi, W.r.t performance and stability of multi-threading the graphics, as long as you have two GPU's the most efficient way to drive them should be multi-threaded - there is a caveat though, hardware and drivers aren't always up to scratch, and even then they should be able to manage the multi-threads and multi-gpus seemless they fail too. I'm poised to build a new machine based on the new Intel iCore7 and X58 motherboard, it'll be interesting to see how well is scales. W.r.t PBO readback - it's very very sensitive to the pixel formats you use. See the osgscreencapture example. Robert. On Mon, Nov 17, 2008 at 5:31 PM, Ferdi Smit [EMAIL PROTECTED] wrote: Thanks Robert. I did a quick test with two viewers from two threads and it appears to be working. Btw, from my experience, PBO doesn't seem to be any faster (and on some hardware much slower) for downloading textures to host than glReadPixels, while for uploads it is almost consistently faster. Anyway, that should not be a problem, even to code it manually. One question about the OpenGL driver, are you by any chance aware of any threading issues? Is it completely re-entrant from two different contexts and threads? With this two-thread setup, I see some occasional erratic fluctuation in drawing time in the osg performance hud for a completely still scene. The GPU performance is very stable, regardless of the load on the other card, but the drawing time (software) sometimes goes from something like 0.4 to 2.6 or 1.5 for a couple of frames. I do not notice this, or not as much, when using two separate processes instead of two threads. The only difference I can think of here is that the OpenGL driver part is in the same address space and maybe internally locks occasionally? Or is this nonsense? Anyway, the osg part seems to be fairly straightforward and simple like this. Thanks. Robert Osfield wrote: Hi Ferdi, osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. So for you case where you want them to run async, this isn't supported. Supporting within CompositeViewer would really complicate the API so it's not something I gone for. What you will be able to do is use two separate Viewer's. You are likely to want to run two threads for each of the viewers frame loops as well. To get the render to image result to the second viewer all you need to do is assign the same osg::Image to the first viewer's Camera for it to copy to, and then attach the same osg::Image to a texture in the scene of the second viewer. The OSG should automatically do the glReadPixels to the image data, dirty the Image, and then automatically the texture will update in the second viewer. You could potentially optimize things by using an PBO but the off the shelf osg::PixelBufferObject isn't suitable for read in this way so you'll need to roll you own support for this. It's worth noting that I've never written a app like the above, so you are rather working on the bleeding edge. I think it should work, or at least I can't spot any major problems that might appear. Robert. On Mon, Nov 17, 2008 at 9:37 AM, Ferdi Smit [EMAIL PROTECTED] wrote: I'm looking to do the following in OSG, and I wonder if I'm on the right track (before wasting time needlessly): have two render processes run in parallel on two different GPUs, have one render a scene to texture and let this texture be read by the other process and mapped to an object in a different scene. Problem, the rendering of the first scene to texture is very slow and the rendering of the second scene is very fast. I intend to solve it in the following way in pseudo-code: - new CompositeViewer - Add two Views - Construct two contexts, one on localhost:0.0, one on localhost:0.1 - Attach contexts to cameras of corresponding Views - Set composite viewer threading mode to thread-per-context --- First process - Set view camera mode to FBO and pre-render - Add post-draw callback and render textures - Download texture to host memory in post-draw callback - (possibly add post-render camera to render textured screen quad as output) --- Second process - Add update-callback and regular texture - Upload host memory to texture in update callback (if available, non-blocking) The downloading and uploading of textures uses multiple slots and regular threaded locking, so to ensure we never read or write the same memory at the same time. The second process doesn't block if no new texture is available, it just continues using the old one then. Some questions. Will the two processes now run at independent frame rates, or will the composite viewer synchronize them? I need them to run independently. I read OSG does not support multi-threaded updating of the scene graph. However, if I use two distinct scene graphs with two contexts, I can _pull_ updates in an update
Re: [osg-users] Compile error - ConvertUTF on osgDB in Cygwin
Brian Keener wrote: I did notice and seems I have noticed this before - from osgLauncher some of the processes (burning cessna, particles) end up hidden behind the osgLauncher screen. Some work fine but a few of these end up hidden and you think you have problem until you find them and sometimes they are hard to get to come to the front. Might be just Cygwin but thought I would mention it in case others have noticed. Not sure what is going on with the above but when I first compiled right after applying Alberto's patch I was able to use osgLauncher and it would run several of the examples and as documented above several ended up hidden and were difficult to get to come to the top so they could be closed. Then when I compiled with Roberts revised patch then it seemed that none of the examples were running from osgLauncher but in fact they were running but they are either not coming to the front or they are not the window is not being built. When I finally break out of them - like osggeometry I can see the calculation on the window but I never saw the actual osggeometry screen. This is only from osglauncher - osggeometry by itself from the command line - works fine. I have since compiled (full make uninstall, make clean, delete all obj files, ccmake and then make) again with Alberto's patch and with Roberts patch and still cannot get back to the first run of many of the osglauncher run apps working (visible). I have not had a chance to try to debug but I did compile a debug version and we need a patch there because osglauncher doesn't recognize the debug version of the files so I can the message osganimate could not be found instead of osganimated could not be found. At any rate - any thoughts on the above - why this change in results might be happening. thanks bk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? Ed Robert Osfield wrote: Wow, didn't long for guess that were right on the money ;-) The screenshot was from me running a new OSG example checked in svn/trunk, the command line was: osgbrower openscenegraph.org opengl.org And as guessed the actual email I sent it from was : osgbrowser gmail.com The osgbrower code is based on UBrowser/llmozlib2 which is a gecko based embedded renderer that uses xul-runner 1.8.x. I've opted for a less efficient browser but using an unmodified version of xul-runner, there is a more efficient version of llmozlib2 but this requires modifications of xul-runner. The example right now only works under Linux, but with a few improvements to CMakeLists.txt and the source it should also work under Windows and OSX. My attempt earlier today to get the html rendering done in a background thread failed, so the currently version very crudely updates renders imagery in the main thread, and also re-renders on every frame as there is no mechanism for lazily updating without modifying xul-runner. The fact that the rendering happens in main thread is severly gating performance, so I'm typically seeing around 10fps, which is fine for an interactive browser but not in any way acceptable for a 3D graphics application. So my next task is get the rendering down in a background thread, but it might require a bit of contortion as gecko and llmozlib are not not thread safe, so I'll have to do all calls to it from a single thread, there are also a few oddities like xul-runner under Linux being dependant on a dummy gtk window and events that you must create to get xul-runner working. Basically it's a bit hacky... 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] You have three guess...
That's my question too. Such capabilities are quite cool but seems far away from the name OpenSceneGraph... Are we going to see OSG based operation system eventually? On Mon, Nov 17, 2008 at 1:03 PM, Ed [EMAIL PROTECTED] wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? Ed Robert Osfield wrote: Wow, didn't long for guess that were right on the money ;-) The screenshot was from me running a new OSG example checked in svn/trunk, the command line was: osgbrower openscenegraph.org opengl.org And as guessed the actual email I sent it from was : osgbrowser gmail.com The osgbrower code is based on UBrowser/llmozlib2 which is a gecko based embedded renderer that uses xul-runner 1.8.x. I've opted for a less efficient browser but using an unmodified version of xul-runner, there is a more efficient version of llmozlib2 but this requires modifications of xul-runner. The example right now only works under Linux, but with a few improvements to CMakeLists.txt and the source it should also work under Windows and OSX. My attempt earlier today to get the html rendering done in a background thread failed, so the currently version very crudely updates renders imagery in the main thread, and also re-renders on every frame as there is no mechanism for lazily updating without modifying xul-runner. The fact that the rendering happens in main thread is severly gating performance, so I'm typically seeing around 10fps, which is fine for an interactive browser but not in any way acceptable for a 3D graphics application. So my next task is get the rendering down in a background thread, but it might require a bit of contortion as gecko and llmozlib are not not thread safe, so I'll have to do all calls to it from a single thread, there are also a few oddities like xul-runner under Linux being dependant on a dummy gtk window and events that you must create to get xul-runner working. Basically it's a bit hacky... 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] You have three guess...
On Monday 17 November 2008 11:03:05 Ed wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? Ed Perhaps this would be a convenient way of providing online help to users of a game? Maybe a way to generate ad revenue from a game? This may not be something that everyone rushes to include in their OSG application, but I have little doubt that someone will do something creative with this ... probably something I would never imagine until I see it and say Why didn't I think of that? :-) It's another tool in the tool belt that is OSG! Justin ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
If you could hook into the javascript engine then you could use it for user interface development. Judd Tracy Assistant in Simulation Institute for Simulation and Training University of Central Florida Phone: (407) 384-5507 [EMAIL PROTECTED] KSpam wrote: On Monday 17 November 2008 11:03:05 Ed wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? Ed Perhaps this would be a convenient way of providing online help to users of a game? Maybe a way to generate ad revenue from a game? This may not be something that everyone rushes to include in their OSG application, but I have little doubt that someone will do something creative with this ... probably something I would never imagine until I see it and say Why didn't I think of that? :-) It's another tool in the tool belt that is OSG! Justin ___ 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] Trackball
Thank you Paul. I appreciate your response. What confuses me is that TrackballManipulator seems to be defaulting to Y up and not z. I believe the setHomePosition is very similar to the setViewMatrixLookAt and I do not believe that either function call will properly set the Z orientation for the scene. But I could be totally wrong. I've not tried this yet. However, I am trying to find the setCoordinateFrameCallback() function and determine how to use it w/o having to subclass TrackballManipulator if I can help it. Thanks for the tips. I'll also see if I can find a getCoordinateFrame() function to tell me what the up vector really is in my scene. Message: 9 Date: Fri, 14 Nov 2008 11:39:08 -0700 From: Paul Martz [EMAIL PROTECTED] Subject: Re: [osg-users] Question: Does the osgGA::TrackballManipulator re-orient the xyz axes to be y Up, and z positive into the screen? To: 'OpenSceneGraph Users' osg-users@lists.openscenegraph.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii See the setCoordinateFrameCallback() and possible the setHomePosition() methods. The TrackballManipulator defaults to z up, but you can set it to be whatever you wish. -Paul Hi. Does anyone know if the osgGA::TrackballManipulator re-orient the xyz axes to be y Up, and z positive into the screen? Through the use of some sort of hidden projection? I can't find any documentation on this at all but when I get the manipulator's view matrix, pull out the translation vector and add to the Z value and finally put the rotation matrix the updated translation vector back together, my scene moves up or down and NOT into or away from the scene. When I alter the Y value, I move into or away from the scene. X works as expected. This is very confusing for a newbie. Thx!!! ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile error - ConvertUTF on osgDB in Cygwin
Hi Brian, You shouldn't need to apply Alberto's patch, my changed avoided the need for Alberto's patch. svn/trunk should compile fine. I'm kinda surprised by the observed relationship with osglauncher behaviour. Did osglauncher work OK prior to these changes? Robert. On Mon, Nov 17, 2008 at 5:47 PM, Brian Keener [EMAIL PROTECTED] wrote: Brian Keener wrote: I did notice and seems I have noticed this before - from osgLauncher some of the processes (burning cessna, particles) end up hidden behind the osgLauncher screen. Some work fine but a few of these end up hidden and you think you have problem until you find them and sometimes they are hard to get to come to the front. Might be just Cygwin but thought I would mention it in case others have noticed. Not sure what is going on with the above but when I first compiled right after applying Alberto's patch I was able to use osgLauncher and it would run several of the examples and as documented above several ended up hidden and were difficult to get to come to the top so they could be closed. Then when I compiled with Roberts revised patch then it seemed that none of the examples were running from osgLauncher but in fact they were running but they are either not coming to the front or they are not the window is not being built. When I finally break out of them - like osggeometry I can see the calculation on the window but I never saw the actual osggeometry screen. This is only from osglauncher - osggeometry by itself from the command line - works fine. I have since compiled (full make uninstall, make clean, delete all obj files, ccmake and then make) again with Alberto's patch and with Roberts patch and still cannot get back to the first run of many of the osglauncher run apps working (visible). I have not had a chance to try to debug but I did compile a debug version and we need a patch there because osglauncher doesn't recognize the debug version of the files so I can the message osganimate could not be found instead of osganimated could not be found. At any rate - any thoughts on the above - why this change in results might be happening. thanks bk ___ 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] You have three guess...
Hi Ed, On Mon, Nov 17, 2008 at 6:03 PM, Ed [EMAIL PROTECTED] wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? You could use it from help to leverage internet based services - such as googlemaps. The browser widget needn't look at browser at all - it'll just be a widget that just happens to render html and associated services. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
Hi Judd, On Mon, Nov 17, 2008 at 6:35 PM, Judd Tracy [EMAIL PROTECTED] wrote: If you could hook into the javascript engine then you could use it for user interface development. Ubrowser does have support for javascript, and given the number of websites that render just fine (gmail included) it does look like it's already working. How you'd go about creating user interface with it is something I comment on as I've never tried this type of thing, it's also my motivation for developer this support in this instance - others are welcome to dive in and expand it's functionality. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
Hi Robert, Nice work, it sound that it become possible to make and browse web in opengl. Interesting for game :) Cheers, Cedric Robert Osfield wrote: Hi Ed, On Mon, Nov 17, 2008 at 6:03 PM, Ed [EMAIL PROTECTED] wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? You could use it from help to leverage internet based services - such as googlemaps. The browser widget needn't look at browser at all - it'll just be a widget that just happens to render html and associated services. Robert. ___ 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:[EMAIL PROTECTED] 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] You have three guess...
Le Mon, 17 Nov 2008 20:04:52 +0100, Robert Osfield [EMAIL PROTECTED] a écrit: Hi Ed, On Mon, Nov 17, 2008 at 6:03 PM, Ed [EMAIL PROTECTED] wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? You could use it from help to leverage internet based services - such as googlemaps. The browser widget needn't look at browser at all - it'll just be a widget that just happens to render html and associated services. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Very interesting. I never thought about such an idea. That's really great; it will now be easy to: - Add content to an app by simply updating a web page. - Give the user the ability to download the newest version of your app or plugins directly in it. - Use goo... a search engine to find clues/help in a reflexion game - See groups/teams/players, chat with them, see online scores... - and much more... Really, really exciting! Thanks for you work! -- 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] PSSM and Blend
Hello List, it's been a while. I have just a short question regarding the usage of the PSSM shadow technique and alpha blending. For some reason when using both, the shadow casting objects (an sphere, for instance) looks somewhat transparent on some parts. When turning Alpha Blending off, this gets fixed. I was just wondering if this was some sort of known bug or whether it shouldn't be happening to me at all. I'm using OSG 2.6 on Debian GNU/Linux. Thanks in advance, Alejandro.- -- [EMAIL PROTECTED] http://varrojo.linuxuruguay.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] CompositeViewer addView threading issue on Windows?
Hi all,
We're currently creating a new app where we need to be able to create
new views, each of which needs to have a separate graphics context
(because they need to be attached to Qt windows - so each needs to get a
unique window handle).
When adding views, I'm hitting what seems to be a threading issue
(deadlock or something like that). It'll happen after adding 2, 3 or 4
views, not always the same number, but I can rarely get more than 5
total. On the call stack, I can see one thread per context is in
GraphicsWindowWin32::makeCurrentImpl() (this is DrawThreadPerContext, so
that's ok), and a third one is in ViewerBase::renderingTraversals() on a
conditionalWait, and they all seem to be stalled there. I'll copy the
stack traces below.
I've reproduced the problem even without Qt, by modifying osgviewer.cpp,
adding an event handler that just creates a new view, calls
setUpViewInWindow() and sets the scene root on it to the same as the
first view. I've tried surrounding the addView call with stopThreading()
and startThreading(), but it doesn't seem to change anything.
I've attached my modified osgviewer.cpp. If someone's inclined to try it
out, just start it with cow.osg for example, and press 'a' to add a view
(note that the 'a' key will only work on the first window).
Is there anything else I need to be careful of when adding views at run
time? Anything I need to do to make this work?
Thanks in advance,
J-S
Stack traces:
Thread 1
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() + 0x84 bytes
[EMAIL PROTECTED]() + 0x12 bytes
ot11-OpenThreadsd.dll!OpenThreads::cooperativeWait(void *
waitHandle=0x0318, unsigned long timeout=4294967295) Line 55 +
0x10 bytes C++
ot11-OpenThreadsd.dll!OpenThreads::Win32ConditionPrivateData::wait(OpenThreads::Mutex
external_mutex={...}, long timeout_ms=-1) Line 109 + 0x1d bytes C++
ot11-OpenThreadsd.dll!OpenThreads::Condition::wait(OpenThreads::Mutex
* mutex=0x0237c1e4) Line 63 C++
osg50-osgViewerd.dll!OpenThreads::BlockCount::block() Line 133 +
0x17 bytes C++
osg50-osgViewerd.dll!osgViewer::ViewerBase::renderingTraversals()
Line 753 C++
osg50-osgViewerd.dll!osgViewer::ViewerBase::frame(double
simulationTime=1.7976931348623157e+308) Line 608 + 0xf bytes C++
osg50-osgViewerd.dll!osgViewer::ViewerBase::run() Line 580 + 0x1b
bytes C++
osg50-osgViewerd.dll!osgViewer::CompositeViewer::run() Line 219
C++
AddView.exe!main(int argc=2, char * * argv=0x0229c828) Line 177 +
0xe bytes C++
AddView.exe!__tmainCRTStartup() Line 597 + 0x19 bytes C
AddView.exe!mainCRTStartup() Line 414 C
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 2
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() - 0x51 bytes
[EMAIL PROTECTED]() + 0xd7 bytes
[EMAIL PROTECTED]() + 0x1f bytes
nvoglv32.dll!6970f597()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 3
=
[EMAIL PROTECTED]()
[EMAIL PROTECTED]() + 0xc bytes
[EMAIL PROTECTED]() + 0x84 bytes
[EMAIL PROTECTED]() + 0x12 bytes
nvoglv32.dll!69705b31()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
nvoglv32.dll!696215b0()
nvoglv32.dll!69621f14()
nvoglv32.dll!697057a9()
[EMAIL PROTECTED]@12() + 0x12 bytes
[EMAIL PROTECTED]() + 0x27 bytes
[EMAIL PROTECTED]() + 0x1b bytes
Thread 4
=
nvoglv32.dll!69621881()
[Frames below may be incorrect and/or missing, no symbols loaded
for nvoglv32.dll]
nvoglv32.dll!69714ba0()
nvoglv32.dll!6970416c()
[EMAIL PROTECTED]() + 0x3b bytes
[EMAIL PROTECTED]() + 0xd5 bytes
[EMAIL PROTECTED]() + 0x8e bytes
osg50-osgViewerd.dll!osgViewer::GraphicsWindowWin32::makeCurrentImplementation()
Line 1701 + 0x1c bytes C++
osg50-osgd.dll!osg::GraphicsContext::makeCurrent() Line 512 + 0xf
bytes C++
osg50-osgd.dll!osg::GraphicsThread::run() Line 35 C++
ot11-OpenThreadsd.dll!OpenThreads::ThreadPrivateActions::StartThread(void
* data=0x0232e97c)
Re: [osg-users] osgswig binary release?
Luigi Calori wrote: Hi Gerwin, I subscribed to SWIG list and read that response too, I' ll try to do some test on that because I really want to be able to run my python app code on more recent OSG I' ll let you know if any success, I' m also applying some mod to make the latest svn compile under msvc 7.1. If you have any suggestion, please let me know. Is someone still working on osgSwig? Yes, still working on it :) - I am actually hiring somebody to work on a new build system Cheers, H Thanks Luigi Gerwin de Haan ha scritto: Luigi, As far as the wrapping of osg::MixinVectors goes to support osg 2.6 and on with osgswig, I did get a response from the swig maintainer William Fulton on how to go about on this: ... The easiest is probably to run SWIG -E on std_vector.i and copy paste and change std to osg and vector to MixinVector. You'll see that there is a lot of code developed for some of these target languages and you could provide a much simpler cut down api, something similar to the Java approach, see Lib/java/std_vector.i. I'm not sure I find a timeslot to do this anytime soon. Gerwin On Fri, Nov 14, 2008 at 12:12 PM, Luigi Calori [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Here http://virtualrome.googlecode.com/svn/trunk/py_code/py25_apps/PyPackages/osg.zip you can find an osgSwig (from some month ago, with some patches) I has been built with Visual Stusio 7.1 against OSG 2.5 (included with the zip) It has been tested with python 2.5 win32 binary, you can test by adding the folder where you extract the zip to the PYTHONPATH env variable I'm trying to build osgSwig svn with OSG 2.6 (Viual Studio compiler)buth there is a still unsolved problem, reported in http://code.google.com/p/osgswig/issues/detail?id=12#c3 due to substitution of std::vector with osg::MixinVectors (this low level change prevents wrapper access to functions for building arrays) I also had to make some changes to build as reported in http://code.google.com/p/osgswig/issues/detail?id=13 If interested, let me know Luigi Phan, Linh H ha scritto: Hi, I'm having a real hard time compiling osgswig (gotten from osgswig svn) for OpenSceneGraph 2.3.4 on Windows using MinGW or cygwin. The README said that it has been tested with OpenSceneGraph 2.3.4. http://2.3.4. Does anyone have a pre-built Windows binary for osgswig that they can make available? I would really appreciate it. Thank you, Linh ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org mailto: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 -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig on OSX (python bindings)
the head of osgSWIG svn only compiles with the OSG 2.6.x H Massimo Di Stefano wrote: Hi finally i'm able to build on osx (10.5.5 xcode-3.1): OSG (svn 2.7) OsGis (svn) and VPB (svn 0.9.1) now i'm tring to have osgswig compiled (to have python bindings) i tried to configure the cmake to : www.geofemengineering.it/osgswig_cmake_settings.txt but the make give me these error : www.geofemengineering.it/osgswig_build_log.txt myabe something is wrong in my python libraries or need i to change something in the cmake setting :-/ please, thanks for any help! Massimo Di Stefano. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Compile error - ConvertUTF on osgDB in Cygwin
Robert Osfield wrote: You shouldn't need to apply Alberto's patch, my changed avoided the need for Alberto's patch. svn/trunk should compile fine. Sorry - my run on sentences were confusing again. :-). I didn't use both your patches at the same time. I had used his and as I reported previously that got OSG to compile and then osglauncher worked fine (with a couple exceptions - documented here and private email to you). When I got your patch I rolled his back and applied yours. At this time I developed the symptoms where it seemed as if none of the examples from osglauncher were running or at least no screens were being displayed since after I escaped to terminate I would see the output (like th geometry calculations and such on the window where I started the task. I did this several times first rolling back your patch and trying his and then roll his back and try yours even tried a power off and a reboot. Same symptoms. Then I built a debug version and as I mentioned I had not had a chance to debug but osglauncher would not run the examples now as it was looking for osganimate and not osganimated. My initial attempt seemed to show they were still showing up behind the osglauncher screen but I modified osg.conf so it referenced the debug versions instead of the release version and then when I tried osglauncher did EVERYTHING perfectly. No idea :-( I'm kinda surprised by the observed relationship with osglauncher behaviour. Did osglauncher work OK prior to these changes? So was I and now I do not believe it is related - the timing was coincidental but I have no idea what caused it or if it will happen again. Since the Debug version seemed to work, I plan to do a full cleanup and then a new cmake configure and build a release again and see what happens. 2 thoughts cross my mind from all this: 1) I am wondering if I was confused on click vs double-click since based on my test today I realized the apps would run with a click and I may have been doing a double-click thus starting the app but then bringing osglauncher back to the foreground. 2) the only other thing I can thing of is the parameter for the USE_3RD _PARTY_BIN (references Mike in the help) as I know I tried with it ON and with it OFF thinking I did not need it. Not sure if that had anything to do with it but the current Debug is built with it ON and in some of the previous it was OFF. bk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig on OSX (python bindings)
Hi, as suggested i downloaded and compiled Osg from the svn 2.6.1 instead of the 2.7 version i previously installed. but tring to build osgswig the error seems to be the same, i uploaded the complete build-log from a fresh osgswig. it is here : www.geofemengineering.it/osgswig_osx_log.txt thanks a lot for your help! regards, Massimo. On Nov 17, 2008, at 10:52 PM, Hartmut Seichter wrote: the head of osgSWIG svn only compiles with the OSG 2.6.x H Massimo Di Stefano wrote: Hi finally i'm able to build on osx (10.5.5 xcode-3.1): OSG (svn 2.7) OsGis (svn) and VPB (svn 0.9.1) now i'm tring to have osgswig compiled (to have python bindings) i tried to configure the cmake to : www.geofemengineering.it/osgswig_cmake_settings.txt but the make give me these error : www.geofemengineering.it/osgswig_build_log.txt myabe something is wrong in my python libraries or need i to change something in the cmake setting :-/ please, thanks for any help! Massimo Di Stefano. Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Hartmut Seichter, PhD (HKU), Dipl-Ing.(BUW), Postdoctoral Fellow, HITLabNZ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Chiacchiera con i tuoi amici in tempo reale! http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgswig binary release?
Hartmut Seichter ha scritto: Luigi Calori wrote: Hi Gerwin, I subscribed to SWIG list and read that response too, I' ll try to do some test on that because I really want to be able to run my python app code on more recent OSG I' ll let you know if any success, I' m also applying some mod to make the latest svn compile under msvc 7.1. If you have any suggestion, please let me know. Is someone still working on osgSwig? Yes, still working on it :) - I am actually hiring somebody to work on a new build system Good to hear! The new build system will still be based on CMake? Do you have a preview? like a branch in svn or like? In that case,please let we know, I'm confident the number of people willing to help is 0 :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Dual screen support on Linux using TwinView
Hi I am developing a program using OpenSceneGraph as the renderer. This program needs support for dual screens; I am using composite viewer to setup different views into the scenegraph, with each view appearing on a separate screen (the outputs will be driving projectors). My X configuration is setup using TwinView; so as far as X is concerned there is only one screen. Can OpenSceneGraph do what I need to do with this configuration (ie get screen info from xinerama) or do I need to configure X so that each monitor is on a different Xscreen? I'd rather not reconfigure X if possible. Cheers Michael Marner ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Shaders and multitextures
Hello:
I built a terrain with two textures to test osgmultitexturecontrol. It
fade between both textures. Now, for the effect I am looking for in
another scene, the use of shaders would be convenient. I want to
reproduce in osg the example from chapter 10.3 of the orange book
(Multitexturing Example). The shaders are available in the book's site
http://3dshaders.com/home/index.php?page=shop.product_detailsflypage=shop.flypageproduct_id=12category_id=1manufacturer_id=0option=com_virtuemartItemid=3
The reason this shader is suitable is that it uses a daytime or a
nightime image of Earth, and uses on the sphere the corresponding
texture to the position of the sun. Actually I want to control not two
but four areas on the sphere (also the polar circles). Perhaps this
can be done with subtextures, but the shaders seems to be good for the
job.
The problem, as usual, is the lack of documentation. Currently I am
able to texture the daytime image and the clouds cover, but not the
nightime image. What is the purpouse of the second parameter (int) of
the Uniform constructor. A reference for the texture unit or something
else?
osg::Uniform* terrainTextureSampler = new osg::Uniform(EarthDay, 0);
This is the first time I use shaders with osg, so please be patient. I
am pasting the shaders and texture functions. I will appreciate any
hint.
Best regards,
-- A.
static void shaders(osg::StateSet* stateset)
{
osg::Vec3 LightPosition = osg::Vec3( 0.0f, 1.0f, 0.0f );
// uniform sampler2D EarthTexture;
osg::Uniform* LightPositionUniform = new
osg::Uniform(LightPosition, LightPosition);
stateset-addUniform(LightPositionUniform);
osg::Uniform* terrainTextureSampler = new osg::Uniform(EarthDay, 0);
stateset-addUniform(terrainTextureSampler);
osg::Uniform* terrainTextureSampler2 = new osg::Uniform(EarthNight, 1);
stateset-addUniform(terrainTextureSampler2);
osg::Uniform* terrainTextureSampler3 = new osg::Uniform(EarthCloudGloss, 1);
stateset-addUniform(terrainTextureSampler3);
osg::Program* program = new osg::Program;
stateset-setAttribute(program);
program-addShader(osg::Shader::readShaderFile(osg::Shader::VERTEX,
CH10-earth-3tex.vert));
program-addShader(osg::Shader::readShaderFile(osg::Shader::FRAGMENT,
CH10-earth-3tex.frag));
}
void Estaciones::textura()
{
estado = geonodo-getOrCreateStateSet();
osg::ref_ptrosg::Image imagen1 = osgDB::readImageFile(dia.jpg);
osg::ref_ptrosg::Texture2D textura1(new osg::Texture2D);
textura1-setImage(imagen1.get());
estado-setTextureAttributeAndModes(0,
textura1.get(),osg::StateAttribute::ON);
osg::ref_ptrosg::Image imagen2 = osgDB::readImageFile(noche.jpg);
osg::ref_ptrosg::Texture2D textura2(new osg::Texture2D);
textura2-setImage(imagen2.get());
estado-setTextureAttributeAndModes(1,
textura2.get(),osg::StateAttribute::ON);
osg::ref_ptrosg::Image imagen3 = osgDB::readImageFile(nubes.jpg);
osg::ref_ptrosg::Texture2D textura3(new osg::Texture2D);
textura2-setImage(imagen3.get());
estado-setTextureAttributeAndModes(2,
textura3.get(),osg::StateAttribute::ON);
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] You have three guess...
Hi Robert, fantastic what you are working on all the long time, what would come when we have winter nights is there a windows library, manual ,etc to get osgpdf and osgbrowser running ? adrian 2008/11/17 Sukender [EMAIL PROTECTED] Le Mon, 17 Nov 2008 20:04:52 +0100, Robert Osfield [EMAIL PROTECTED] a écrit: Hi Ed, On Mon, Nov 17, 2008 at 6:03 PM, Ed [EMAIL PROTECTED] wrote: I may sound ignorant by asking this, but it won't be the first time, so... What are the uses of this capability? You could use it from help to leverage internet based services - such as googlemaps. The browser widget needn't look at browser at all - it'll just be a widget that just happens to render html and associated services. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Very interesting. I never thought about such an idea. That's really great; it will now be easy to: - Add content to an app by simply updating a web page. - Give the user the ability to download the newest version of your app or plugins directly in it. - Use goo... a search engine to find clues/help in a reflexion game - See groups/teams/players, chat with them, see online scores... - and much more... Really, really exciting! Thanks for you work! -- 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to define my own geometry in osgswig?
Hi Gerwin, it would be nice if this feature would work since if I have legacy c++ code that draws an asteroid, for instance, I would like to be able to just wrap that c++ code up in python and use it in osgswig. I tried putting %feature(director) osg::Geometry; in osg.i, and I got alot of errors: cd /C/cygwin-1.7/usr/local/src/buildosgswig/src/python /c/MinGW/bin/g++.exe -D_osg_EXPORTS -g -I/c/Program Files/OpenSceneGraph2.4/include -I/C/cygwin-1.7/home/phan/projs/osgswig-read-only/include -I/c/Python25/include -o CMakeFiles/_osg.dir/osgPYTHON_wrap.obj -c /C/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.cxx In file included from c:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.cxx:6679: C:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.h:104: error: `PrimitiveFunctor' has not been declared C:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.h:104: error: ISO C++ forbids declaration of `arg0' with no type C:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.h:105: error: ISO C++ forbids declaration of `pf' with no type C:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.h:106: error: `PrimitiveIndexFunctor' has not been declared C:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.h:106: error: `virtual bool SwigDirector_Geometry::supports(int) const' and `virtual bool SwigDirector_Geometry::supports(int) const' cannot be overloaded C:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.h:107: error: `virtual void SwigDirector_Geometry::accept(int) const' and `virtual void SwigDirector_Geometry::accept(int) const' cannot be overloaded c:/cygwin-1.7/usr/local/src/buildosgswig/src/python/osgPYTHON_wrap.cxx:7569: error: `bool SwigDirector_Geometry::supports' is not a static member of `class SwigDirector_Geometry' ... Thank you Gerwin, Linh -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerwin de Haan Sent: Monday, November 17, 2008 12:17 AM To: OpenSceneGraph Users Subject: Re: [osg-users] How to define my own geometry in osgswig? Linh, Currently in osgswig you cannot directly override osg.Drawables in the target scripting language. This is partly because we have not enabled SWIG directors for this class, which are responsible for such cross-language inheritance. Also, Drawables are pure virtual/abstract which doesn't play nice with our directors. As an alternative, you might want to try and enable Directors for Geometry in osg.i: %feature(director) osg::Geometry; I'll consider this a feature request, will try this and see what the consequences on performance are. See the pyramid.py example for defining your own geometry without subclassing. Gerwin On Mon, Nov 17, 2008 at 8:43 AM, Phan, Linh H [EMAIL PROTECTED] wrote: Hi, I was wondering if it's possible to draw my own geometry in osgswig, eg something like: import osg, osgViewer class MyCube(osg.Drawable): def __init__(self): osg.Drawable.__init__(self); # AttributeError: No constructor defined def drawImplementation(self, state): # draw some geometry glutWireCube (1.0) def computeBound(self): bbox = osg.BoundingBox() bbox.set(-2,-2,-2,2,2,2) return bbox geode = osg.Geode() geode.addDrawable(MyCube()) viewer = osgViewer.Viewer() viewer.setSceneData(geode) viewer.run() I get AttributeError: No constructor defined when I run it. Is there a way to draw my own geometry? Thank you, Linh ___ 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
