Re: [osg-users] [3rdparty] osg::image / Create a 3d image
Hi Thomas,
On 16/12/09 3:23 AM, Thomas Canipel wrote:
//creation of the data
int height=100;
int width=100;
int length=100;
const long size = width*height*length;
For RGB this needs to be (w*h*l)*3, ie. number-of-pixels * channels-per-pixel.
unsigned short* data = (unsigned short*)calloc(size, sizeof(unsigned short));
for(long i=0; i size ; i+= 3) {
data[i]=255;//red
data[i+1]=0;//green
data[i+2]=0;//blue
}
For unsigned short the maximum is 2^16-1 ie. 65535, not 255.
// declaration and allocation of the 3d image (size : 100,100,100)
osg::ref_ptrosg::Image image = new osg::Image;
image-allocateImage(width, height, length, GL_RGB, GL_UNSIGNED_SHORT);
image-setOrigin(osg::Image::BOTTOM_LEFT);
image-setImage(width, height, length,GL_RGB,GL_RGB,GL_UNSIGNED_SHORT,
(unsigned char*)data,osg::Image::NO_DELETE);
I don't believe the 'allocateImage' call is necessary, 'setImage' will
overwrite that.
HTH,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [vpb] adding optional datasets to existing db
Hi all, A quick comment first, it has been a couple of years since I have used osgdem, and it is great to see it is going so well (as VPB). Thanks Robert. I have been experimenting with the various options for patching an existing db. One of things I need to be able to is to add more optional data sets. When I tried to do this vpbmaster complained that the new options were not compatible with the existing db. I couldn't see why what I was trying to do shouldn't work so I simply commented out the check on optional layers in the BuildOptions#compatible method. Once this was done, I could successfully add new optional layer sets with no obvious issues. Is my 'fix' something that can be included or I am missing something that could lead to problems if this functionality is allowed? I have also changed the code to allow changing layer inheritance for a new optional sets. I haven't experimented with this much yet, but it seems to work ok. Should I expect problems with this? Cheers, Brad DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [vpb] dynamic overlays on geocentric db, any suggestions?
Hi All, I need to implement a dynamic 'drawing' overlay that is rendered onto a model created using vpb. Has anyone tackled this so far? My first thought is to use the osgSim Overlay as I have used this to do the same thing on a flat world. Should this work for a geocentric model? My first attempts at using it failed, but I am now pretty sure this was due to the MultitextureControl turning off my texture unit, so I will try again. Any thoughts on whether the osgSim Overlay is the best approach / if it will work? I will also need to select objects on this layer. My plan is to intersect with the 3D model, get the lat lons, then convert this into the reference frame used to render the overlay, and do a second intersect operation from there. I think this will be fine but seems a little complex. Does anyone have a suggestion for a better approach? Cheers, Brad DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
Hi Teodor, I'm not sure if this is a common problem, but in the company I work for we have never been able to get quad buffered stereo to work in a window in Vista (fullscreen is fine). We've come to the conclusion that it is a driver issue and reported it to nVidia, but thus far there there hasn't been a resolution. It would be interested to know if there are many people on the list having this issue actually since there seems to be a lot of bods working with stereo here. Regards, Kim. 2009/12/15 Teodor Hanchevici calin.hanchev...@gmail.com: Hi, I have a 3D stereo application that runs fine in anaglyph mode on Windows XP, however when changing the mode to QUAD_BUFFER and switching to Windows Vista it stops working. Basically using the NVIDIA vision glasses and a Quadro FX 3700, the stereo effect is not present. I am using driver 191.66 for Windows Vista, and the operating system is 32 bit ultimate. The application is a QT application using the QOSGWidget and the composite viewer classes provided as example. the OSG example (osgstereoimage) works fine, so I wonder if anyone has experienced such problems. Thank you! Cheers, Teodor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21545#21545 ___ 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] Text Crash On Main Thread While DB Pager Unrefs Font From Temp Object Cache
More generally I'm not convinced that we need to deprecate the none ref versions. I'd be inclined towards just documenting that multi-threaded reads should use the Ref versions. It might not be convincing to have to go back to the code base and remove these unsafe sections of code, but by having a set of documentation is really not going to help eighty or ninety percent of the OSG community. I rarely look at the documentation. My documentation is really just the source code that is provided. With multiple cores available on the cheap and new and old applications requiring database support, I feel that it is in the best interest of OSG to have these functions removed. It will save for headaches in the long run for you, as you will not have to explain each and every time to use the ref version instead of the other. The cache flipping trick used is not good needs to be removed. I'd be inclined towards use osgDB::Options to store the cache, and have an in memory ObjectCache to mirror the current FileCache. Such an approach would allow you to override the default ObjectCache to a single read call, such as ones done from the DatabasePager and avoid the need to cache flipping completely. Are there plans for this to be addressed for a future release? If so, can you detail which release you are trying to target? Thanks, Ryan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21553#21553 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question regarding Culling issue in the SceneView
Hi J-S, Viewer::updateTraversal() and CompositeViewer::updateTraversal() both traverse the scene graph and explictly camera's update callbacks. What these updateTraversal() methods do is switch of the traversal of the camera's subgraph when the camera subgraphs are traversed, so the children won't be traversed. This is done so that the scene graphs aren't traversed multiple times per frame, but... I believe in your case were the Camera has the subgraph attached that isn't attached as a View's scene, won't get called. To make sure subgraphs of Camera's that aren't part of the any View's scene graph get traversed we'll need to make the camera update callback calling code in *::updateTraversal() a little more intelligent. Perhaps a set of scene graphs that have been traversed on each frame, or perhaps even just checking to see if a Camera has a View associated with it would be enough to determine if the subgraph should be traversed or not. Does any of this make sense in the context of what you are seeing? Robert. On Tue, Dec 15, 2009 at 7:10 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Robert, As Paul suggests CullVisitor::apply(osg::Camera) handles in scene graph camera's, so will not handle the viewer level scene graph correctly so _camera-accept(*cullVisitor) won't behave correctly. Perhaps you could try replacing the for loop with _camera-traverse(*cullVisitor) as this will call the cull callback and avoid the CullVisitor::applyOsg::Camera) method. If this works fine let me know as I can make this change to SceneView.cpp. I had a similar question about update callbacks. Reading the code (can't recall where, but I suspect it's in SceneView.cpp as well) the update visitor is being passed to the Scene objects, and not to the cameras. The effect of this is that update callbacks on cameras are not called, and more importantly, update callbacks on nodes that are children of the camera but not part of the view's SceneData will not be called either. We frequently add nodes directly under a camera (instead of under a scene root that's the scene data of a given view) so that the nodes are only visible to that camera. But with the present behavior, update callbacks on those nodes are never called. If, instead of passing the update visitor to the scene data's root, we passed it to the camera's children, then we're sure all visible nodes would be visited, even those in the scene data... Thanks, J-S -- __ Jean-Sebastien Guay jean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG QT
Hi Samuel, On Tue, Dec 15, 2009 at 9:00 PM, Samuel Grant gr...@novatechnologies.net wrote: Getting unresolved reference errors when trying to build OSG into QT. All stemming from the OSG libs? Any thoughts? Are you linking your app to the OSG??? Go check there aren't errors about not finding the OSG libs. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] OSG Volume / Transfer Function
Hi Thomas, On Tue, Dec 15, 2009 at 7:58 PM, Thomas Canipel thomas.cani...@gmail.com wrote: I am actually trying to understand the OSG Volume Example, The alpha coefficient allow me to play with the extinction coefficient, but have problem to use the transfer function. What does represent the first parameter when we set a new Color ? The transfer function first value relates the intensity value of the 3D image. On the GPU the intensity value will be read from the 3D texture, then used to look up the RGBA value from the transfer function's 1D texture (that is created automatically from the osg::TransferFunction values). transferFunction-setColor(value, osg::Vec4(1.0,1.0,1.0,apha)); this line permit normally to set a transferControl point I think... in this case does the function will color all the vortex between ? and my value with this color and the opacity in parameter ? I'm not clear what you mean here. The values between the different colours you assign to the TransferFunction will be interpolated. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
On Tue, Dec 15, 2009 at 11:23 PM, Jan Pečiva pec...@fit.vutbr.cz wrote: I like Coin (Open Inventor clone, OSG competitor) since: 1. it has intuitive consistent API and excellent design IMHO, Inventor has a terrible design for a scene graph, the state system breaks the ability to have a high performance cull traversal. For me Inventor is good example of object composition gone mad, seemingly a good idea, but in practice it breaks what should be the key asset of a scene graph - performance. 2. if there is something where SGI experts failed the design, the place is well documented with examples and explanations of specialties of the design You can't fix the state system in Inventor, it's broken. The only way to fix it is to dump it and adopt parental inheritance rather than sibling inheritance. It's worth noting that Performer and Inventor existed side by side because neither could solve the full range of problems that scene graph users wanted to tackle. Inventor might be been more OO inspired, but Performers parent inheritance scheme made it far more suitable for high performance, something that Inventor could never attain and SGI knew it. The OSG is far more inspired by the example of Performer than Inventor, but is has strong OO routes, which enables it to be extensible whilst still retaining the performance. I wish OSG to constantly improve and to become even better with powerful and intuitive API. To name the strengths of OSG: - it follows the latest technology and design patterns - there is a working mailing list, patches and discussions There are political and technical reasons why Inventor has been on life support, and the OSG is alive and healthy. [...] for the specific purpose of one user [...] Maybe two? But we understand, you are the authority deciding how it will be... Reference for other people: By the alias extension, people would not lose anything of the current plugin features - all the current extension protection would still work as well as it is working just now. They would just get one additional feature for OSG. Your suggestion on forcing aliases onto plugins will break existing plugins. For instance take the the quicktime plugin which handles many different formats - it requires the extension to have a specific mapping to file format to enable it to know which format to use. Are we to tell Apple to adopt your scheme for re-interpreting extension names? Clearly your suggestion can't be applied to all plugins, just ones that are agnostic about their extensions. I have given already given two ways you can already do this - even one telling you how to implement the scheme you want - injecting aliasing directly into the plugin, just doing it manually. Please re-read my posts. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [vpb] dynamic overlays on geocentric db, any suggestions?
Hi Brad, osgSim::OverlayNode does work for whole earth databases. Have a look at the osgsimulation example for an example of this in action. Robert. On Wed, Dec 16, 2009 at 9:19 AM, Christiansen, Brad brad.christian...@thalesgroup.com.au wrote: Hi All, I need to implement a dynamic 'drawing' overlay that is rendered onto a model created using vpb. Has anyone tackled this so far? My first thought is to use the osgSim Overlay as I have used this to do the same thing on a flat world. Should this work for a geocentric model? My first attempts at using it failed, but I am now pretty sure this was due to the MultitextureControl turning off my texture unit, so I will try again. Any thoughts on whether the osgSim Overlay is the best approach / if it will work? I will also need to select objects on this layer. My plan is to intersect with the 3D model, get the lat lons, then convert this into the reference frame used to render the overlay, and do a second intersect operation from there. I think this will be fine but seems a little complex. Does anyone have a suggestion for a better approach? Cheers, Brad DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. -- ___ 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] Text Crash On Main Thread While DB Pager Unrefs Font From Temp Object Cache
Hi Ryan, On Wed, Dec 16, 2009 at 9:43 AM, Ryan H. Kawicki ryan.h.kawi...@boeing.com wrote: It might not be convincing to have to go back to the code base and remove these unsafe sections of code, but by having a set of documentation is really not going to help eighty or ninety percent of the OSG community. I rarely look at the documentation. My documentation is really just the source code that is provided. With multiple cores available on the cheap and new and old applications requiring database support, I feel that it is in the best interest of OSG to have these functions removed. It will save for headaches in the long run for you, as you will not have to explain each and every time to use the ref version instead of the other. I understand the principle of short term pain for long term gain... but... In the current case I'm looking towards getting the OSG users moving on to the upcoming 3.0, during this transition their will inevitably be some refactor work required by users due to the wider changes such as GLES/GL3 support, but the more pain there is the slower the uptake will be and the slower we'll sort out all the bugs/issues. In this context I want to minimize how much more pain we might introduce. The less pain the quicker people will try out and move to OSG 3.x and the quicker it's quality will improve. So right now I don't want to add any further backwards compatibility breakages if I can avoid it. The cache flipping trick used is not good needs to be removed. I'd be inclined towards use osgDB::Options to store the cache, and have an in memory ObjectCache to mirror the current FileCache. Such an approach would allow you to override the default ObjectCache to a single read call, such as ones done from the DatabasePager and avoid the need to cache flipping completely. Are there plans for this to be addressed for a future release? If so, can you detail which release you are trying to target? I don't have any specific version for this. It's an issue right now and should be fixed a soon as I or others have time to tackle it. I would guess that it's a day or two's work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009-12-16 10:28, Kim Bale wrote: It would be interested to know if there are many people on the list having this issue actually since there seems to be a lot of bods working with stereo here. Yep, but not all are such masochists as to use Vista for graphics work :) That problem looks like a driver issue, indeed. However, I vaguely recall that in Windows the stereo had to be enabled in two places - first checkbox turned on the quad buffer support and the other stereo or something like that (yay for usability engineering, Nvidia!). But even in XP the stereo was pretty spotty - sometimes the driver didn't want to turn the emitters on for no obvious reason until the machine was rebooted or driver reinstalled. I have seen also everything apparently working, but the stereo frusta were messed up and similar problems. Quite a pain if you need a stable and predictable system to run demonstrations on. That is the primary reason why everything stereo-related here is running in Linux now - set it up once and it works. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLKMOnn11XseNj94gRAp5WAKDrr3N8a2klWFM99COaqQwrhdOQgQCg0sD7 50pzkOeevR2XGMtj1O9uESU= =+n5A -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgSim problem
Hi, I start to study openscenegraph. I try to do tutorials. On Basic Tutorials 7 that Finding and Manipulating a Switch and DOF Node I couldn't run the codes wihich I download from the site. Winding Nodes worked but Manipulating a Switch and DOF Node didn't work. I think mistake about osgSim. Because I took 3 error that contain linker problem with osgSim:DofTransform and osgSim:MultiSwitch. So, How can I correct these errors. Thank you! Cheers, İsmail -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21559#21559 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
Jan Ciger wrote: Yep, but not all are such masochists as to use Vista for graphics work :) That problem looks like a driver issue, indeed. However, I vaguely recall that in Windows the stereo had to be enabled in two places - first checkbox turned on the quad buffer support and the other stereo or something like that (yay for usability engineering, Nvidia!). Actually, to enable openGL stereo display you have turn off the 3D stereoscopic Driver... (see Display Settings on http://www.nvidia.com/object/quadro_pro_graphics_boards.html) Usability you said ? jcl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Robert Osfield wrote: On Tue, Dec 15, 2009 at 11:23 PM, Jan Pečiva pec...@fit.vutbr.cz wrote: I like Coin (Open Inventor clone, OSG competitor) since: 1. it has intuitive consistent API and excellent design IMHO, Inventor has a terrible design for a scene graph, the state system breaks the ability to have a high performance cull traversal. For me Inventor is good example of object composition gone mad, seemingly a good idea, but in practice it breaks what should be the key asset of a scene graph - performance. We can never agree in the discussion. Inventor became de-facto standard for visualization and simulations for its design that was revolutionary in 90's. Its design followed OpenGL state design, and if scene graph is well designed - no cull traversal is needed - you render it directly while getting highest possible performance. But you are right, SGI turned to OpenGL Performer with this cull overhead that can win other benefits. With poorly conditioned scene graphs, OSG will perform probably much better. But well designed model - it completely does not matter which one you are using - the traversal time is negligible - at least that is what I usually reach with Open Inventor. I hope, you are reaching the same with OSG. Howg. No more comments from me. But please, go forward with OSG. I like the parent state inheritance. I am also interested in other things and functionalities, not performance only. Always eager for new features. Your suggestion on forcing aliases onto plugins will break existing plugins. For instance take the the quicktime plugin which handles many different formats - it requires the extension to have a specific mapping to file format to enable it to know which format to use. Are we to tell Apple to adopt your scheme for re-interpreting extension names? You probably do not understand me. I do not want to re-interpret anything. Plugin is going to get the same file name as before. Plugin gets loaded the same way as before. The whole discussion was just about content of ReaderWriter::_supportedExtensions . But please, let it be for now. Thanks for providing us by OSG, John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009-12-16 12:44, Jean-Christophe Lombardo wrote: Actually, to enable openGL stereo display you have turn off the 3D stereoscopic Driver... (see Display Settings on http://www.nvidia.com/object/quadro_pro_graphics_boards.html) Usability you said ? Ah yes, this is the new proprietary Nvidia system. I do not have experience with these glasses, only the older CrystalEyes-like hardware and the Cyviz converters. Considering the rip-off pricing for the Nvidia equipment, one would expect a more reasonable interface to the drivers ... Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLKNg1n11XseNj94gRAuKSAJ9EjppzQA/Y8cBzhIiEwGTzycav1QCgoqRE l8MUBDCFkRTyC71plkd1uSY= =BPsA -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
Thank you all for your insight. I have followed all the instructions on NVIDIA page to enable the stereo, and then I have tried the osgstereoimage with --window option and it worked fine in a 800x800 window. Cheers, Teodor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21569#21569 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG QT
Yeah, as far as I can tell, the OSG libs are on the link path... This happens even when trying to compile the 'QOSGWidget' without any mods (other than making sure it points to my OSG dir). --Sam -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21570#21570 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG QT
Hi Sam, did you use moc to generate QT code from header files? Cheers, Teodor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21571#21571 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Hi John, On Wed, Dec 16, 2009 at 12:15 PM, Jan Pečiva pec...@fit.vutbr.cz wrote: We can never agree in the discussion. Inventor became de-facto standard for visualization and simulations for its design that was revolutionary in 90's. Inventor was the defacto standard in the 90's for scientific visualization, while Performer became defacto standard for visual simulation. It was design that was so revolutionary no modern scene graph has adopted it. Its design followed OpenGL state design, and if scene graph is well designed - no cull traversal is needed - you render it directly while getting highest possible performance. This is so wrong I don't know where to start. State storting and view furstum culling are the two essentials for efficient graphics, send graphics brute force to OpenGL is absolutely not the most efficient way. OpenGL on it's own doesn't do any state sorting or culling it relies upon the calling application to do this all and without it you will not get the best performance from your system. But you are right, SGI turned to OpenGL Performer with this cull overhead that can win other benefits. With poorly conditioned scene graphs, OSG will perform probably much better. But well designed model - it completely does not matter which one you are using - the traversal time is negligible - at least that is what I usually reach with Open Inventor. Inventor might be familiar to you, but it certainly isn't anywhere near the OSG or Performer for performance even with the best conditioned scene graph imaginable. The only time Inventor might come close is when there is no view frustum culling because the whole scene is on screen and the state set up is very straight forward that the traversal isn't complicated. You probably do not understand me. I do not want to re-interpret anything. Plugin is going to get the same file name as before. Plugin gets loaded the same way as before. The whole discussion was just about content of ReaderWriter::_supportedExtensions . But please, let it be for now. To be clear automatically setting ReaderWriter::_supportedExtensions from osgDB won't be generally be safe. For specific plugins it might be possible to use it, and for these I would recommend you try loading the plugin and then adding the extra extension directly as I've suggested in my last two post. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG QT
calin wrote: Hi Sam, did you use moc to generate QT code from header files? Cheers, Teodor In examining the output from the compile, it appears that the header files get moc'ed. Also I get a few moc-prefixed CPP files in my source dir from some of the QOSGWidget headers. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21573#21573 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
Hi there, OK, after some fiddling around I was able to make the application run by setting the following in the environment: OSG_STEREO ON OSG_STEREO_MODE QUAD_BUFFER In my code I have the following: osg::DisplaySettings::instance()-setStereo(true); osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::StereoMode::QUAD_BUFFER); but it seems it is not enough. My application is showing only one component. Are there any other things to be set in the code to enable the quad buffer rendering? Using the QTViewer, even with the environment variables set, I cannot render stereo, so this makes me wonder if the issue is QT related. Cheers, Teodor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21574#21574 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question regarding Culling issue in the SceneView
Hi Colin,
I tried adding an update callback to the top level camera and that did
work. I checked the code and it does call accept:
346:
_camera-accept(*_updateVisitor.get());
So it should work correctly (as of 2.8.2)
Sorry, I was mistaken in saying that the cameras did not get the update
visitor. They do as you point out.
I did some checking, and what I was talking about is in
src/osgviewer/Viewer.cpp
void Viewer::updateTraversal()
{
// ...
_scene-updateSceneGraph(*_updateVisitor);
//...
_scene is the scene graph that's passed to the view when you call
setSceneData(). A bit lower, you can see where the update visitor is
passed to the cameras too, but it does not traverse to its children.
That means that anything that's a child of the cameras but not in the
scene data will not be traversed in the update traversal. That's what I
was talking about.
I really wonder why the camera can't just let the update visitor
traverse its children, instead of traversing the _scene separately as
above. The _scene's nodes are under the camera anyways, or else they
would not be visible...
J-S
--
__
Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com
http://www.cm-labs.com/
http://whitestar02.webhop.org/
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question regarding Culling issue in the SceneView
Hi Robert, What these updateTraversal() methods do is switch of the traversal of the camera's subgraph when the camera subgraphs are traversed, so the children won't be traversed. This is done so that the scene graphs aren't traversed multiple times per frame, but... I believe in your case were the Camera has the subgraph attached that isn't attached as a View's scene, won't get called. Yes, that's exactly what I'm saying. So you're saying that as opposed to the cull traversal, which will of course traverse the camera's subgraph once per view each frame, the update traversal needs to traverse all nodes only once. If I have the same scene graph attached to multiple cameras, just traversing the cameras' subgraphs would result in the scene being traversed multiple times. Makes sense. To make sure subgraphs of Camera's that aren't part of the any View's scene graph get traversed we'll need to make the camera update callback calling code in *::updateTraversal() a little more intelligent. Perhaps a set of scene graphs that have been traversed on each frame, or perhaps even just checking to see if a Camera has a View associated with it would be enough to determine if the subgraph should be traversed or not. Well in my case, the camera can have a view. It can be the view's main camera. i.e. a node can be added as a direct child of the view's main camera and its update callback will not be called. I'd have to look into the code in Viewer/CompositeViewer::updateTraversal() to see if I can spot a solution. The set of subgraphs that have been traversed seems like it would work, but it's perhaps too time-consuming to check? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 2.8.2 compile error...
Thanks Alberto! This helped. More specifically, disabling this option helped to allow osgUtil to build. (building osg 2.9.6) -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21577#21577 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009-12-16 14:56, Teodor Hanchevici wrote: Hi there, OK, after some fiddling around I was able to make the application run by setting the following in the environment: OSG_STEREOON OSG_STEREO_MODE QUAD_BUFFER In my code I have the following: osg::DisplaySettings::instance()-setStereo(true); osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::StereoMode::QUAD_BUFFER); You do not need to set both - setting the environment variables has the same effect as the code. The osg::DisplaySettings are, I believe, used only when you create a window, so if you have used that command after a window has been opened, it is not taken into account. but it seems it is not enough. My application is showing only one component. Are there any other things to be set in the code to enable the quad buffer rendering? Using the QTViewer, even with the environment variables set, I cannot render stereo, so this makes me wonder if the issue is QT related. Does stereo work if you set the environment variables and use normal osgviewer executable to view some model? If that doesn't work too, then the problem is most likely with either the configuration of your driver or your hardware. Check if any error messages are printed out when you run the program from command line - if quad buffer visual is not available, you will get a stream of OpenGL errors in the terminal. The application may continue to run, but it will be without stereo. Qt is not really likely to be the culprit, because it does not interfere with OpenGL rendering. Qt only provides a window into which an OpenGL context is attached and it knows nothing about quad buffering being enabled or disabled. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLKPRnn11XseNj94gRAsEzAJ90Or+R4/yMzJClJ6DaP7J0CfcWiQCggYBe RJffOOZRPojXJvZJPen86wI= =aqgW -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
Hi Jan, I commented off the line osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::StereoMode::QUAD_BUFFER); and unset OSG_STEREO in the environment, leaving only OSG_STEREO_MODE as QUAD_BUFFER. This generated a lot of OpenGL errors and the app did not render stereo. however, if I set both OSG_STEREO and OSG_STEREO_MODE then the application works fine. I will have to see if the display settings is updated after the window is created. Cheers, Teodor -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21580#21580 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] QUAD_BUFFER Stereo on Vista
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2009-12-16 16:18, Teodor Hanchevici wrote: Hi Jan, I commented off the line osg::DisplaySettings::instance()-setStereoMode(osg::DisplaySettings::StereoMode::QUAD_BUFFER); and unset OSG_STEREO in the environment, leaving only OSG_STEREO_MODE as QUAD_BUFFER. This generated a lot of OpenGL errors and the app did not render stereo. You need OSG_STEREO set to ON and OSG_STEREO_MODE set to QUAD_BUFFER (both need to be set). I will have to see if the display settings is updated after the window is created. I do not think they are, but I may be wrong here. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFLKP57n11XseNj94gRApSnAKC+e2x/qoQsdh/LnJ9il8grHqlSDACdECfj Lae3HOkyaDM5svLWAgB0ozM= =4a1x -END PGP SIGNATURE- ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] file extension alias
Hi John et. al, On Wed, Dec 16, 2009 at 1:34 PM, Robert Osfield robert.osfi...@gmail.com wrote: To be clear automatically setting ReaderWriter::_supportedExtensions from osgDB won't be generally be safe. For specific plugins it might be possible to use it, and for these I would recommend you try loading the plugin and then adding the extra extension directly as I've suggested in my last two post. I've just realized that since the ReaderWriter::supportsExtension() method is protected it isn't possible inject additions extensions into a plugin. Changing this and associated methods to be be public would open the door to it, although given it's not generally safe documenting. To this end I've just checked in the change of these methods to public scope, and added docs explain their usual usage. /** Specify fmt string as a supported protocol. * Please note, this method should usually only be used internally by subclasses of ReaderWriter, Only in special cases * will a ReaderWriter implementation be able to handle a protocol format that is wasn't original designed for. * To know whether it's safe to inject a new protocol format to an existing ReaderWriter you will need to review * the source code and dependencies of that ReaderWriter. */ void supportsProtocol(const std::string fmt, const std::string description); /** Specify ext string as a supported file extension. * Please note, this method should usually only be used internally by subclasses of ReaderWriter. Only in special cases * will a ReaderWriter implementation be able to handle a file extension that is wasn't original designed for. * To know whether it's safe to inject a new file extension to an existing ReaderWriter you will need to review the * the source code and dependencies of that ReaderWriter. */ void supportsExtension(const std::string ext, const std::string description); /** Specify option string as a supported option string. * Please note, this should usually only be used internally by subclasses of ReaderWriter. */ void supportsOption(const std::string opt, const std::string description); Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question regarding Culling issue in the SceneView
Hi Colin,
Your analysis of the what is required is spot on, the only little
change I've made to it is to remove the (osg::Node node =
*_camera.get()); as one can simple use the _camera ref pointer
directly thus:
// traverse the scene graph to generate the rendergraph.
// If the camera has a cullCallback execute the callback which has the
// requirement that it must traverse the camera's children.
{
osg::NodeCallback* callback = _camera-getCullCallback();
if (callback) (*callback)(_camera.get(), cullVisitor);
else _cullVisitor-traverse(*_camera);
}
I'm currently awaiting a clean build and test before checking this in.
Cheers,
Robert.
On Wed, Dec 16, 2009 at 3:54 PM, Colin Branch cbra...@mak.com wrote:
Robert,
Unfortunately camera-traverse does not handle any callbacks, it only calls
'accept' on every child.
Sadly it is impossible to exactly achieve the desired behavior with the
existing functions. You can get close using CullVisitor::accept(Group*)
however it pushes an additional StateSet.
Ideally the function wanted is
CullVisitor::handle_cull_callbacks_and_traverse however that is protected.
So here what I believe is the best code to use. I have tested it and it has
the desired effects of executing cull callbacks on the camera node, or doing
traverse which is 100% identical to the for loop in the current source code.
// traverse the scene graph to generate the rendergraph.
// If the camera has a cullCallback execute the callback which has the
// requirement that it must traverse the camera's children.
{
osg::Node node = *(_camera.get());
osg::NodeCallback* callback = node.getCullCallback();
if (callback) (*callback)(node,cullVisitor);
else cullVisitor-traverse(node);
}
The only potential issue this change might introduce to existing code bases
is where a cull callback which was added to the camera that did not traverse
would cause culling of the scene to not occur. However since previously the
callback was never executed in the first place I believe that would be
highly unlikely to happen and since cull callbacks are expected to normally
traverse the children this should be an extremely rare (possibly
nonexistent) case in current code bases. In either case I believe a bug
would have existed in the original code, and the new behavior is entirely
consistent with std OSG behavior regarding culling.
We will be building OSG with the above code, and we would be very pleased if
it can be integrated into the main branch. I've attached the modified file.
Going even further into the future it might be desirable to be able to
simply make normal Camera's accept cull visitor on the main camera. It
appears that the SceneView goes doesn't strictly follow the principle of
encapsulation as it is doing much of the same functionality 'to' the
CullVisitor externally, that is normally done internally in the apply
method.
Thank you,
Colin Branch
On 12/15/2009 1:53 PM, Robert Osfield wrote:
Hi Colin,
As Paul suggests CullVisitor::apply(osg::Camera) handles in scene
graph camera's, so will not handle the viewer level scene graph
correctly so _camera-accept(*cullVisitor) won't behave correctly.
Perhaps you could try replacing the for loop with
_camera-traverse(*cullVisitor) as this will call the cull callback
and avoid the CullVisitor::applyOsg::Camera) method. If this works
fine let me know as I can make this change to SceneView.cpp.
Robert.
On Tue, Dec 15, 2009 at 6:22 PM, Colin Branchcbra...@mak.com wrote:
Greetings All,
I added a CullCallback to the camera of a view. I found it was not
getting
hit. After much searching I believe it is due to the implementation in
the
SceneView:
Specifically at line 957:
// traverse the scene graph to generate the rendergraph.
for(unsigned int childNo=0;
childNo_camera-getNumChildren();
++childNo)
{
_camera-getChild(childNo)-accept(*cullVisitor);
}
Is there a reason that it is simply not replace that whole section of
code
with the following?
_camera-accept(*cullVisitor);
Shouldn't the main camera be culled?
I'm somewhat inclined to think so.
I'd appreciate any feedback on why this may not be the case.
-Regards,
Colin Branch
--
Colin Branch
VT MAK
work: (617) 876-8085 Ext. 159
email: cbra...@mak.com
--
Colin Branch
VT MAK
work: (617) 876-8085 Ext. 159
email: cbra...@mak.com
___
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
--
Colin Branch
VT MAK
work: (617) 876-8085 Ext. 159
email: cbra...@mak.com
___
osg-users mailing list
Re: [osg-users] Frustum/Culling issue with PagedLod
Hi, No more idea ? because the only way I found is to remove the little sphere... and this is a real bad way to solve the problem... Thanks a lot. Regards, Vincent Vincent Bourdier a écrit : Hi Robert, Sorry, the camera manipulator is my own one, and the position is hard coded for the home position. I spend 3h yesterday night to find any explanation without success Thanks. Regards, Vincent. Robert Osfield a écrit : Hi Vincent, Could it be that your home position is changing with changes in the sphere's dimensions/poistion, and the home position is affecting the LOD selection. Robert. On Thu, Dec 10, 2009 at 8:15 PM, Vincent Bourdier vincent.bourd...@gmail.com wrote: Hi all, I just get something very strange I cannot really understand : In my scene, there is a graph will hundred of PagedLOD nodes, and no geodes. I manually set the frustum of the viewer : / view-getCamera()-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR ); float divider = (float)(zNear/config-frustumNearPlan); view-getCamera()-setProjectionMatrixAsFrustum (left/divider, right/divider,bottom/divider, top/divider, zNear/divider, config-frustumFarPlan);/ (near is 2 and far is 2e+07) The scene render normally... there is no problem... BUT When I add a little Sphere (osg::Sphere) on the scene (center 0,0,0 radius 1) before the render loop starts, the LODs never loads anything and nothing but the Sphere is visible... Because I set the frustum myself with the same values each time, I do not understand why I didn't see the LODs nodes The StatsHandler do not show the databasePager stats, which means there is no cull on the LOD ? This is a real question I am not yet a osg master... To conclude, when I add the Sphere with a radius upper than 5000, the LODs are visible... It really seems to be a wrong far plan frustum value... but I verified it is always the same and never change from 2e+06 ... Any idea or suggestion could help me a lot :-) Thanks. Regards, Vincent. __ Information from ESET NOD32 Antivirus, version of virus signature database 4677 (20091210) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org __ Information from ESET NOD32 Antivirus, version of virus signature database 4677 (20091210) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __ Information from ESET NOD32 Antivirus, version of virus signature database 4693 (20091216) __ The message was checked by ESET NOD32 Antivirus. http://www.eset.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osg::image / Create a 3d image
yes the allocate Image is not necessary it is override by the setImage(), I was missing the size of the channel ;) Thank you! Cheers, Thomas -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21588#21588 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] osg::image / Create a 3d image
In order to use a limit of 255, I needed to use GL_UNSIGNED_BYTE (char)
Code:
int height=100;
int width=100;
int length=100;
const long size = width*height*length*3;
unsigned char* data = (unsigned char*)calloc(size,sizeof(unsigned
char));
for(long i=0; i size ; i+= 3)
{
data[i] = 255;//red
data[i+1] = 0;//green
data[i+2] = 0;//blue
}
osg::ref_ptrosg::Image image = new osg::Image;
image-allocateImage(width, height, length, GL_RGB, GL_UNSIGNED_BYTE);
image-setOrigin(osg::Image::BOTTOM_LEFT);//start countingpixels on the
Bottom left of the picture
image-setImage(width, height, length , GL_RGB, GL_RGB,
GL_UNSIGNED_BYTE,data, osg::Image::NO_DELETE);
osgDB::writeImageFile(*image, test.jpg);
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=21589#21589
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Load file from URL link
Hi, Is there any way to read node file using osgDB::readNodeFile method from URL? For example http://localhost/1.3DS Thank you! Cheers, Danny -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21590#21590 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Problem with using static initializers to preload plugins
Hi Robert and all -- As you know, I have a private nodekit that uses the .osgb extension. In order to avoid collisions with the upcoming new OSG binary format, I've added a static initializer to the nodekit to force load my .osgb plugin. As we've discussed previously, this is what I need to do to avoid forcing client apps to do this explicitly, right? My nodekit depends on osgWorks, which contains a plugin that supports the .skel extension. So, just to be safe and avoid possible future collisions with the .skel extension, I also added a static initializer to osgWorks to force loading the .skel plugin. The net effect is that whenever my .osgb plugin gets loaded, my osgWorks .skel plugin also gets loaded. This is correct and expected behavior. Unfortunately, this breaks osgconv --format osgb. Issuing that command incorrectly displays output for both my .osgb and .skel plugins. It should display only output for the .osgb plugin. The root cause appears to be flawed login in osgDB::queryPlugin(). This function is passed a plugin filename, which it loads, and then assumes that any plugins that got loaded must be appropriate to query. This is a false assumption in the presence of static initializers, as I describe above. My personal preference would be to enhance Registry to handle multiple plugins that support multiple formats with the same extension, thus avoiding the need to preload plugins, as I have mentioned in other posts. But if this is still off the table, then my fallback solution would be to change pluginQuery so that it takes an extension as a parameter, and only queries a loaded plugin if it accepts the extension. Do either of these sound acceptable? If so, let me know which one and I'll code it up. -- Paul Martz Skew Matrix Software LLC _http://www.skew-matrix.com_ http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimal Rendering setup
I've generated 2 textures, (started using osgprerender) and I can get those two textures and blend them together (although not using a shader), just a textenv: Code: osg::StateSet* pTextureState= new osg::StateSet; osg::TexEnv *texenv = new osg::TexEnv(osg::TexEnv::ADD); pTextureState-setTextureAttributeAndModes(0, pTextureUnCulled,osg::StateAttribute::ON); pTextureState-setTextureAttributeAndModes(0, texenv, osg::StateAttribute::ON); pTextureState-setTextureAttributeAndModes(1, pTextureCulled, osg::StateAttribute::ON); pTextureState-setTextureAttributeAndModes(1, new osg::TexEnv(*texenv) , osg::StateAttribute::ON); However I'm not sure how to get past the 2D look that the flag has. I'm trying to render the 2 textures and then blend them onto a polygon (similar to the flag in the example), but what I end up with is a flat/thin image that the mouse can change the coordinate view of. Very similar to the flag in the example program. What I really wanted to have was a 3d model that had some pieces that came and went, revealing the interior of the object like a Star Trek transport in use. (ok, that analogy is not quite as perfect as I would like it to be). So as you move about the model, you still see a 3D shape, but its translucency of some sides varies. How do I? Generate two textures, then use a shader to combine the two images. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21592#21592 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Python users
Hi Jean-Sébastien, thanks! running the latest notes from the wiki main page all works fine. now i'm exploring the example code. a question : have you never tried to add a python osgviewer inside a PyQt4 (or wx-python) gui ? thanks, Massimo. Il giorno 15/dic/2009, alle ore 18.47, Jean-Sébastien Guay ha scritto: Hi Massimo, Sorry, my first reply went to you directly... I don't know why, sometimes reply replies straight to the sender, even though the mailing list should be changing the headers so that replies go back to the mailing list... i'm running osgboostpython http://code.google.com/p/osgboostpython/ on mac osx 10.6 (osg svn, 64-bit) boost+python support from source (1.41) Please note that I've never tried to build it on Mac OS X, so your input will be valuable (as below). now i'm tring to runs some examles, but i have problems using the code from the main page : In [12]: s.setTextureAttributeAndModes(0, t, osg.StateAttribute.Values.ON) Traceback (most recent call last): File ipython console, line 1, in module AttributeError: type object 'Values' has no attribute 'ON' any clue on what's wrong? Yes, the enums were changed to const members to fit better with the C++ style but I didn't change the code on the front page :-( Try to use osg.StateAttribute.ON instead (without the .Values)... See http://code.google.com/p/osgboostpython/source/browse/trunk/osgBoostPython/lib/osg/__init__.py I've updated the front page now. Sorry about that. ... tring to build osgboostpython http://code.google.com/p/osgboostpython/ , seems that it don't recognize the .dylb files so i had to simlink *.dylb to *.so. You could possibly change the jam files so that it uses .dylib files instead, but I have no clue how to do that. Perhaps the bjam / jam / boost.build documentation can help you. Thanks, J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Python users
Hello Massimo, running the latest notes from the wiki main page all works fine. now i'm exploring the example code. Good to know you're getting better success now. have you never tried to add a python osgviewer inside a PyQt4 (or wx-python) gui ? No, sorry. If you try it let me know, I would be very interested to know if it works well. Also if you could contribute a small example of that in action I would gladly add it to the osgBoostPython examples. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [3rdparty] OSG Composer released
Hi, ... i am trying to animate a solidworks model based on real position translation data and was looking at osg composer to do this, is there anyway of moving a part from a solidworks assembly using a script? i.e. to move leg 10cm in x plane, 5 in y and 0 in z Thank you! Cheers, j -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21499#21499 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgSim problem
Hi İsmail, Are you linking against osgSim.lib or osgSimd.lib as well as core osg? In Visual Studio you should be able to find them in you project's properties under Linker-Input-Additional Dependancies. Cheers, Brendan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21595#21595 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] dynamic QuadTree on spherical terrain
Hi, How is it possible to manage forest in osgEarth, i haven't found any clue at it's project page. Can you give me a hint? Thank you! Cheers, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21597#21597 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
