[osg-users] Yet another poll
Dear OSG Users, I've been in need of some calculation stuff for sometime and now I've realized that I'm writing unnecessary code. Today's issue was polygon inflation/deflation. So I'm going to be smart and ask you people. What library do you use for geometric calculation stuff? If you code your own, please state. Thank you for your time, Can ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Win32 : Gecko Plugin
Hi all, i am looking for a manual how to build the xulrunner under windows (VS 2008) or (VS 2005). There is still a prebuild version for xulrunner 1.9 but we need actually the elder version. i tried to build against this later version, but there are some build errors. has anybody still tried to fix them? or any other suggestions. thanks adrian -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outof rangeinVertexPaletteManager
Hi Paul Robert, I have now done the following: - changed my code to use DrawElements, which was easy in my case - fixed a bug in flt-exporter with the help of Paul, sent this file to paul Thanks for your help, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Cmake-2.6-patch 0 optimisation problems
Hi, I also have -O3 -DNDEBUG for CMAKE_CXX_FLAGS_RELEASE Debian testing/unstable cmake version 2.6.2 installed from official debian package cmake 2.6.2-2 Michael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Request: bool Polytope.contains(another_polytope)
Hi Jefferson, Like Gordon says, if you need the function then the thing to do is implement it and submit it. I'm not hear to take end users feature requests and then go a implement them for free. I have bucket load of work to do, working well over my forty hour week every week, with many of these hours doing project maintenance and support work without financial return, the simply is no scope for doing extra stuff just out of kind heartedness - I do strangely enough have a life outside the OSG. Robert. On Wed, Dec 3, 2008 at 8:10 PM, Jefferson Pinheiro [EMAIL PROTECTED] wrote: Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ 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] setUpdateOperations?
Hi Brad, On Wed, Dec 3, 2008 at 10:23 PM, Brad Colbert [EMAIL PROTECTED] wrote: What are the UpdateOperations used for in the osgViewer::Viewer class? The UpdateOperations list is useful for integrating threaded operations that run con-currently with the main frame loop. For instance you'd create an custom osg::Operation, add this to an osg::OperationThreads and to the viewer, then it's called by both threads, the operation itself will have to deal with its own thread safety. A use might be management of custom paging in the background, or networking integration. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth/Cull question
Hmm just some doubts after a look on OpenGl specifications :
Why turning OFF the culling ? it will just eliminate or not the backface...
so it is not very useful for this problem, isn't it ?
Next, if I use a depth test to (ALWAYS,0,1), renderbindetails is not
necessary...isn't it ?
Last, still have no results...
Just a question now (or two) : If I set the depth test on a node (PAT) or if
I set it on a drawable/geode/... is there some difference ?
Have you any idea of why I have no visible results ?
Thanks,
Vincent.
2008/12/3 Vincent Bourdier [EMAIL PROTECTED]
2008/12/3 Tomlinson, Gordon [EMAIL PROTECTED]
To NOT render a node and all its children simply set is Node mask to 0x0
to stop it being drawn, and set it 0xFFF and any value that results
in true when locial AND'ed cameras mask
As to alsway being drawn
1) Turn OSG culling of on the node
2) Place the node and its children in a render bin with a high number
like 100 or higher than any other you may be using.
This will make sure it is rendered last
node-setRenderBinDetails( 100,LastRenderBin);
3) If you want all of the geometry to be drawn then turn OFF the depth
test of for node and its children as shown below
Hmm, I use this code :
*osg::ref_ptrosg::StateSet state = node-getOrCreateStateSet();
node-setCullingActive(false);
state-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF);
state-setRenderBinDetails(1000, RenderBin);*
and nothing happen...
It is not my lucky day today...
Thanks.
Regards,
Vincent.
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 Ulrich
Hertlein
Sent: Wednesday, December 03, 2008 12:53 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Depth/Cull question
Hi Vincent,
Quoting Vincent Bourdier [EMAIL PROTECTED]:
I just need to set a node to be always rendered (or not).
It needs to not depend on the Zbuffer/culling.
...
*osg::ref_ptrosg::StateSet state = node-getOrCreateStateSet();*
*state-setMode(GL_CULL_FACE, osg::StateAttribute::ON);*
*osg::ref_ptrosg::Depth depth;*
*if(set){*
*depth = new osg::Depth(osg::Depth::ALWAYS, 0.0, 1.0);*
*state-setMode(GL_CULL_FACE,
osg::StateAttribute::OFF);*
*node-setCullingActive(false);*
*}else{*
*depth = new osg::Depth(osg::Depth::LEQUAL, 0.0, 1.0);*
*state-setMode(GL_CULL_FACE, osg::StateAttribute::ON);*
*node-setCullingActive(true);*
*}*
**
*state-setAttributeAndModes(depth.get(),
osg::StateAttribute::ON);*
Seems to me you're actually throwing different concepts into one bag:
- Zbuffer/depth test
- GL face culling
- OSG node culling
If I understand you correctly then you want to make sure a node is
always drawn irrespective of any objects that might be in front of it.
Simply turn of the depth test:
state-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF)
That might expose issues with the order in which objects are drawn - the
solution to that is RenderBins.
When you say always rendered *(or not)* (my emphasis) do you want to
turn it off completely?
Hope this helps,
Cheers,
/ulrich
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
ghttp://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] osgViewer osgCool
Hi, if you're interested in creating particles, you can have a look at Delta3D which is based on Openscenegraph: www.delta3d.org There is a tool for creating particule effects in their utilities (IHM is based on fltk). Pierre. Le jeudi 27 novembre 2008 à 13:46 -0200, Renan Mendes a écrit : My mistake, I thought it was an example but it is only an argument for the application. Either way, I really wanted to learn how that particular particle effect was generated... How can I do it? Thanks, Renan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org Pierre BOURDIN I.M.E.R.I.R. Av. Pascot BP 90443 66004 PERPIGNAN tél: 04 68 56 80 18 fax: 04 68 55 03 86 email: [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Calendar time in FrameStamp
Hi Paul, When I original introduced FrameStamp I thought ahead and saw that it could be useful to have a calender time available via FrameStamp. For instance an ephemeris model could use it. The use of it being in FrameStamp is that it allows apps to decouple the time they use for simulation purposes from the application implementation. Right now the calander time ins't populated, and if you want to use it you'd need to populate it yourself. The way I'd implement it in an app would be by overriding Viewer::advance() that updates the FrameStamp. Robert. On Wed, Dec 3, 2008 at 10:26 PM, Paul Martz [EMAIL PROTECTED] wrote: Hi Robert -- There doesn't appear to be any code in the OSG distribution that sets or gets the calendar time in FrameStamp. Is this purely for application convenience? Applications can store any values they want in the tm struct? (The header comment says, Note the calendar time can be an artificial simulation time or capture the real time of day etc. The comment doesn't go into detail about how those options are set, but to me the comment seems to imply that FrameStamp (or something else in OSG) manages calendar time and can be configured for either of those options. But this is not the case from the code I've seen, so perhaps I'm misinterpreting it.) Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com http://www.skew-matrix.com/ +1 303 859 9466 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 4m 36 seconds!
Hi Ulrich, On Thu, Dec 4, 2008 at 1:32 AM, Ulrich Hertlein [EMAIL PROTECTED] wrote: My take on hyper-threading was always to disable it, if enough (say = 4) cores are available. It's not a separate core after all and there is a certain amount of work involved to make one core look like two. For threads that don't have critical latency like file reading threads hyper threading actually makes a lot of sense as the processor core won't be highly contended - much of the times the paging threads will be stalled waiting for IO. For performance critical threads like cull and draw dispatch one will need to take care about dropping two threads on to a core that will contended at the same time for its resources. Additionally: what is the communities' experience with manually assigning processes to cores? Does it work? Yes, it's pretty important for multi-processor performance gains, even under Linux as an move of the thread from core to core throws invalidates the cache. Thread affinity can make the difference of multi-threaded viewer being faster or slower than a SingleThreaded. Performance I've seen on this machine suggests a bit of mixed bag, with desktop effects on I found that DrawThreadPerContext viewer didn't perform better than SingleThreaded, but with desktop effect off performance was much better with DrawThreadPerContext. This is just with a few limited tests, and no new controls on thread affinity to take account of the hyper-threading, I have much to learn yet about the dynamics yet. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth/Cull question
Jean-Sébastien Guay schrieb: Hi Vincent, Or perhaps your ground is a very very large sphere where no part of the sphere can be culled away, so the far plane is actually behind the Earth (which is very far away relatively to the distance between the airplane and the ground)... J-S I second that. Your background sphere (which is the radius of the earth) takes away all of the Z-Buffer resolution. What you would really need is a two pass rendering: Rendering of the earth sphere as a background with it's own depth range and then the air plane as the front scene. So I'd propose a variant of the HUD approach, but with 3 dimensional geometry for background and front part. regards Ralph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 4m 36 seconds!
Robert Osfield schrieb: Hi Guys, I've been done a few basic benchmarks today and was stunned to find far lower performance than on my older and slower quad core system, the cull and draw traversals being far longer. I've traced the problem back to cmake's release build options being blank on this machine - so release build was build without the usual -O3 option in place. I'm currently doing a rebuild to see what happens with manually putting -O3 in the CMAKE_CXX_FLAGS_RELEASE entry. so what's now your time for the full rebuild with optimization? I guess it's now more than 4m 36? regards Ralph ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Win32 : Gecko Plugin
Hi Adrian, On Thu, Dec 4, 2008 at 8:48 AM, Adrian Egli OpenSceneGraph (3D) [EMAIL PROTECTED] wrote: i am looking for a manual how to build the xulrunner under windows (VS 2008) or (VS 2005). There is still a prebuild version for xulrunner 1.9 but we need actually the elder version. i tried to build against this later version, but there are some build errors. has anybody still tried to fix them? or any other suggestions. UBrowser/LLMozLib that our gecko plugin is based on only works with xulrunner 1.8.x. I exchanged a number of emails with Callum Prentice the author of UBrowser and he said porting to 1.9.x isn't something he was planning to tackle soon, and maybe never as he and he's colleagues are now looking seriously at using webkit or one of it's derivatives. Callum mentioned that gecko engineers were never very open to helping out users that wanted to embedded gecko renderers in custom apps, so developing UBrowser/LLMozLib was rather a struggle, which in tern makes trying to get help finding out what new API's would be appropriate to replace the ones used in 1.8.x is not a welcoming proposition. xulrunner is really poorly documented, combine that with unhelpful support and you can see why Callum and co. and looking elsewhere. It does look like furture of embedded browsers will be webkit based, but alas it's a bleeding edge there too, and documentation is not much better than for xulrunner, but... the code looks better organised, and google engineers that are pushing ahead with webkit also seem far more friendly to outside interaction. So the present gecko is likely to be just a short term fix. xulrunner 1.8.x binaries should be available under windows as when I followed the various online discussions about UBrowser/LLMozLib it looked like Windows users were able to easily pull down and get a custom version of libxulrunner working, it was Linux users that had the troubles. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
Hi Gordon, On Wed, Dec 3, 2008 at 8:01 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: To be honest OGL 3.0 is not on my horizon right now ( I know its there ) A lot of our customers are on base line machines with 7 year old cards such as NVIDIA Quadro4 700 XGL OpenGl 2.1 and 256mb is a luxury :) Out of curiosity what version of OpenGL and extensions does this kit support? VBO's? PBO'S? FBO's? Shaders? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth/Cull question
Hi Jean-Sébastien,
Using a HUD-like system seems to be a extrem solution for me... I am just
looking at a way to set a node always rendered...
For the moment, using the .osg format file to see my stateset, I see that
the culling test still stay ON.
I correct it ; my code is now :
*node-setCullingActive(false);
osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::NEVER, 0.0,
1.0);
node-getOrCreateStateSet()-setAttributeAndModes(depth.get(),
osg::StateAttribute::ON);
node-getOrCreateStateSet()-setMode(GL_DEPTH_TEST,
osg::StateAttribute::OFF);
node-getOrCreateStateSet()-setRenderBinDetails(1000, RenderBin);*
my node is now :
*PositionAttitudeTransform {
UniqueID PositionAttitudeTransform_0
name F-GHOP
nodeMask 0x
cullingActive FALSE
StateSet {
UniqueID StateSet_1
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber 1000
binName RenderBin
GL_DEPTH_TEST OFF
GL_NORMALIZE ON
Depth {
UniqueID Depth_2
function NEVER
writeMask TRUE
range 0 1
}
}
UpdateCallbacks {
NodeCallback {
name planeOverTheFloorCallback
NodeCallback {
name triggerScaleCallback
}
}
}
...
//with LOD children after.*
And the result... still the same : culling make nothing different.
Am I missing something important ?
thanks,
Regards,
Vincent.
2008/12/4 Ralph Kern [EMAIL PROTECTED]
Jean-Sébastien Guay schrieb:
Hi Vincent,
Or perhaps your ground is a very very large sphere where no part of the
sphere can be culled away, so the far plane is actually behind the Earth
(which is very far away relatively to the distance between the airplane
and the ground)...
J-S
I second that. Your background sphere (which is the radius of the earth)
takes away all of the Z-Buffer resolution.
What you would really need is a two pass rendering: Rendering of the
earth sphere as a background with it's own depth range and then the
air plane as the front scene. So I'd propose a variant of the HUD
approach, but with 3 dimensional geometry for background and front part.
regards Ralph
___
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] osgViewer osgCool
Thanks. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth/Cull question
Sorry :
made a mistake
*Depth {
UniqueID Depth_2
function NEVER
writeMask TRUE
range 0 1
}
*is really*
Depth {
UniqueID Depth_2
function ALWAYS
writeMask TRUE
range 0 1
}
*
2008/12/4 Vincent Bourdier [EMAIL PROTECTED]
Hi Jean-Sébastien,
Using a HUD-like system seems to be a extrem solution for me... I am just
looking at a way to set a node always rendered...
For the moment, using the .osg format file to see my stateset, I see that
the culling test still stay ON.
I correct it ; my code is now :
*node-setCullingActive(false);
osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::NEVER, 0.0,
1.0);
node-getOrCreateStateSet()-setAttributeAndModes(depth.get(),
osg::StateAttribute::ON);
node-getOrCreateStateSet()-setMode(GL_DEPTH_TEST,
osg::StateAttribute::OFF);
node-getOrCreateStateSet()-setRenderBinDetails(1000, RenderBin);*
my node is now :
*PositionAttitudeTransform {
UniqueID PositionAttitudeTransform_0
name F-GHOP
nodeMask 0x
cullingActive FALSE
StateSet {
UniqueID StateSet_1
rendering_hint DEFAULT_BIN
renderBinMode USE
binNumber 1000
binName RenderBin
GL_DEPTH_TEST OFF
GL_NORMALIZE ON
Depth {
UniqueID Depth_2
function NEVER
writeMask TRUE
range 0 1
}
}
UpdateCallbacks {
NodeCallback {
name planeOverTheFloorCallback
NodeCallback {
name triggerScaleCallback
}
}
}
...
//with LOD children after.*
And the result... still the same : culling make nothing different.
Am I missing something important ?
thanks,
Regards,
Vincent.
2008/12/4 Ralph Kern [EMAIL PROTECTED]
Jean-Sébastien Guay schrieb:
Hi Vincent,
Or perhaps your ground is a very very large sphere where no part of the
sphere can be culled away, so the far plane is actually behind the Earth
(which is very far away relatively to the distance between the airplane
and the ground)...
J-S
I second that. Your background sphere (which is the radius of the earth)
takes away all of the Z-Buffer resolution.
What you would really need is a two pass rendering: Rendering of the
earth sphere as a background with it's own depth range and then the
air plane as the front scene. So I'd propose a variant of the HUD
approach, but with 3 dimensional geometry for background and front part.
regards Ralph
___
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] Cmake-2.6-patch 0 optimisation problems
Hi J-S, On Wed, Dec 3, 2008 at 8:02 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: We could also show a warning on Configure if we detect that the CMake version is one of those that cause the problem. Looking at the follow up responses it might not be specific CMake version, rather a particular build of it... Perhaps checking valud of the CMAKE_CXX_FLAGS_RELEASE variable to see it's blank would be sufficient. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Math problem relative to OSG
Hi,
First, sorry to post a lot on mailing list, but I have some difficulties,I
do not find any way to solve them, and I didn't find a way to stop time ...
This problem concern mathematical things, based on Quat, PAT, matrices, ...
I implement a new manipulator, with a way to set a node as reference.
The expected effect is that the camera will stay motionless relative to the
node (translation and rotation)
My manipulator is based on a quaternion : _rotation and a vector : _eye.
This quat and this vector are used in the getInverseMatrix().
To move the camera following a node, I use that :
osg::Matrixd mat = _node-asGroup()-getWorldMatrices()[0];//get world
coordinate
_eye -= mat.getTrans() - _oldmat.getTrans();
[...]
_oldmat = mat;
This looks good.
Now, when node rotate, it becomes more difficult : is camera is far/near
from the node, it have to stay motionless.
It imply to compute two things : the rotation, and the translation to apply.
The rotation is computed like that :
qq = pat-getAttitude();
osg::Quat _q_ = qq * _QuatActual.inverse(); // = rotation from QuatActual
to qq
if(!_q_.zeroRotation()) {//apply only if necessary
_rotation *= _q_;
}
_QuatActual = qq;
Last, the translation to put the camera at the same relative place of the
node.
osg::Vec3d vt(mat.getTrans() - getEyePoint()); //getEyePoint return the
current camera position
osg::Vec3d vt2 = _q_ * vt ;
_eye -= vt-vt2;
This is all.
The result ? so complicated too : the camera seems to be not exactly
motionless relative to the node. Can be a lack of precision but* if the
node is moved with two successive rotation, the camera is not at all
motionless and move without any sense...
*
I have tried a lot of things, but the result still stay the same...
I have this problem for months... and no new idea... so, if you have any
suggestion, idea, it would be very great for me!
Thanks for help.
Regards,
Vincent.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 4m 36 seconds!
On Thu, Dec 4, 2008 at 9:31 AM, Ralph Kern [EMAIL PROTECTED] wrote: so what's now your time for the full rebuild with optimization? I guess it's now more than 4m 36? Just did a clean build, now with more of the plugins built as I've pulled in gecko and xine-lib dependencies as well as few others, so it's not quite apples to apples comparisons, but the total time is 6 minutes 5 seconds, this is the first build of the day so the file cache isn't warm. Re-running a clean build results in 5m 32s. The fast build times will certainly help with my submissions work where clean builds are quite common. It'll be interesting to run vpbmaster on the new system too. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] 4m 36 seconds!
I've been looking into thread/process affinity with respect to a dual-GPU setup. This is what I found back then: 2 processes, CPU affinity on different cores, each renders the full scene on a different GPU OSG_THREADING=SingleThreaded (1 core shows heavy use, 2nd core show moderate use, 2 cores idle) Quadro 56008800GTX Multi-GPU / Multi-Processing1615 (fps) OSG_THREADING=ThreadPerContext (CPU Affinity is set but appears to be ignored: 1 core shows heavy use, others idle) Multi-GPU / Multi-Processing1114 (fps) So, yes, it helps if the CPU load is balanced across cores, even for this simple 25M polygon scene that is for 99% GPU. Also, OSG seems to mess up manual settings when set to multi-threading :) Check CPU loads in the performance monitor. Don't let 3 cores stand idle all the time; it's a waste of available processing time, and this will only get worse in the future with more cores. Side note, I finally received my 4GB memory, so I can get this quad core, dual GTX260, pcie 2.0 machine running :) Let's see if it behaves differently from a Quadro+8800 on pcie 1.1. Ulrich Hertlein wrote: Additionally: what is the communities' experience with manually assigning processes to cores? Does it work? It sounds like a good idea but in my experience it's best to leave the scheduling up to the operating system to handle core affinity (except when you're running Windows which has a completely fscked-up round-robin scheduler). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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] 4m 36 seconds!
Robert, I believe this to be a driver issue as well. However, what it does show is that it is probably preferable to have different contexts on different cores, also to eliminate any possible opengl driver overhead. On 2 cores it runs perfectly as expected; same frame rates as stand-alone. On a single core they both drop back a little, probably because the quadro opengl driver is eating up a lot of CPU time for some obscure reason. Even when the opengl implementation is set to multi-threaded, I never see it start using any additional core by itself. This only happens when you set the affinity manually. So fully relying on the OS scheduling may not be the best option. I don't remember the exact stats, and I can't check them now as I don't have the machine here. I think it was something like 0/0/x for the 8800 and 0/y/y for the 5600, with x close to y. Robert Osfield wrote: Hi Ferdi, It sounds like the OpenGL driver is not behaviour well in your case and twisting the results from what you would normally expect. With scene of 25M polygons you are almost certainly GPU/bandwidth limited, and pretty likely that the OpenGL fifo is backing up and playing havoc. Multi-processing is this situation is not really going to make a huge difference in terms of potential gain because the bottleneck is elsewhere - you aren't CPU limited, it shouldn't make things worse, and the fact that it is suggests that the driver is having issues. What are you cull/draw/gpu stats? Robert. On Thu, Dec 4, 2008 at 10:43 AM, Ferdi Smit [EMAIL PROTECTED] wrote: I've been looking into thread/process affinity with respect to a dual-GPU setup. This is what I found back then: 2 processes, CPU affinity on different cores, each renders the full scene on a different GPU OSG_THREADING=SingleThreaded (1 core shows heavy use, 2nd core show moderate use, 2 cores idle) Quadro 56008800GTX Multi-GPU / Multi-Processing1615 (fps) OSG_THREADING=ThreadPerContext (CPU Affinity is set but appears to be ignored: 1 core shows heavy use, others idle) Multi-GPU / Multi-Processing1114 (fps) So, yes, it helps if the CPU load is balanced across cores, even for this simple 25M polygon scene that is for 99% GPU. Also, OSG seems to mess up manual settings when set to multi-threading :) Check CPU loads in the performance monitor. Don't let 3 cores stand idle all the time; it's a waste of available processing time, and this will only get worse in the future with more cores. Side note, I finally received my 4GB memory, so I can get this quad core, dual GTX260, pcie 2.0 machine running :) Let's see if it behaves differently from a Quadro+8800 on pcie 1.1. Ulrich Hertlein wrote: Additionally: what is the communities' experience with manually assigning processes to cores? Does it work? It sounds like a good idea but in my experience it's best to leave the scheduling up to the operating system to handle core affinity (except when you're running Windows which has a completely fscked-up round-robin scheduler). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 -- 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] Math problem relative to OSG
Hi, sounds complicated. You could do the following: You don´t need to do any translations to your camera, you only need to apply the same rotation as to your node, but not to the absolute position of your camera, but to the relative position of your camera. NodePosition: Old Position of node. Camera Position: OldPosition of camera RelativePosition = CameraPosition - NodePosition NewRelativePosition = Rotate(RelativePosition) NewCameraPosition = NewNodePosition + NewRelativePosition Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Hi, Hmm, complicted yes, but... 2008/12/4 Andreas Goebel [EMAIL PROTECTED] Hi, sounds complicated. You could do the following: You don´t need to do any translations to your camera, you only need to apply the same rotation as to your node, but not to the absolute position of your camera, but to the relative position of your camera. NodePosition: Old Position of node. Camera Position: OldPosition of camera RelativePosition = CameraPosition - NodePosition I did : osg::Vec3d vt(mat.getTrans() - getEyePoint()); Notice I do the opposite vector...: NodePosition - CameraPosition NewRelativePosition = Rotate(RelativePosition) osg::Vec3d vt2 = _q_ * vt ; If you know an other way to apply the rotation to a vector... I'll be pleased to learn it NewCameraPosition = NewNodePosition + NewRelativePosition Hmmm... I don't agree with that. If I add the NewRelativePosition, instead of adding the difference between the relative position and the NewRelativePosition, I'll get something very different... (difficult to explain... make a little drawing you will see what I mean) Me, I do that : _eye = _eye - (vt-vt2) equivalent to NewCameraPosition = *CameraPosition *+ (RelativePosition-NewRelativePosition ) An other problem, is that I must add a component to my camera position, and not define it with a sum. Explanations : when i need to move the camera, i modify the _eye vector (eye += mov)... so if i do _eye = a+b ... my move will be erased... I need to make something like _eye += c+d Considering this, I think you proposition is the same what I have done yet. If not, this mean I am so tired or I miss something. Thanks for you help, it can makes me think about other potential bug... Still open to propositions :-) Regards, Vincent. Regards, Andreas ___ 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] Math problem relative to OSG
Vincent Bourdier schrieb: Hi, Hmm, complicted yes, but... 2008/12/4 Andreas Goebel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi, sounds complicated. You could do the following: You don´t need to do any translations to your camera, you only need to apply the same rotation as to your node, but not to the absolute position of your camera, but to the relative position of your camera. NodePosition: Old Position of node. Camera Position: OldPosition of camera RelativePosition = CameraPosition - NodePosition I did : osg::Vec3d vt(mat.getTrans() - getEyePoint()); But mat.getTrans is not the same as your node position, right? This is only the same if the node was at (0,0,0), and then it is only right the first time. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Each frame I do mat = _node-asGroup()-getWorldMatrices()[0]; I don't understand why it can work only one time... and why it would be wrong... My node is a PAT, but can be anything else... I also tried position = _node-getBound().center() * mat Same result... 2008/12/4 Andreas Goebel [EMAIL PROTECTED] Vincent Bourdier schrieb: Hi, Hmm, complicted yes, but... 2008/12/4 Andreas Goebel [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi, sounds complicated. You could do the following: You don´t need to do any translations to your camera, you only need to apply the same rotation as to your node, but not to the absolute position of your camera, but to the relative position of your camera. NodePosition: Old Position of node. Camera Position: OldPosition of camera RelativePosition = CameraPosition - NodePosition I did : osg::Vec3d vt(mat.getTrans() - getEyePoint()); But mat.getTrans is not the same as your node position, right? This is only the same if the node was at (0,0,0), and then it is only right the first time. Regards, Andreas ___ 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] Performance comparison with older OSG versions
Hi All, I have been working on performance issues because after we ported our engine to OSG2.7.6 we lost some performance. In my tests I am using a complex town database which is pretty representative for our applications. I use osgviewer for the tests. I tested with several versions of OSG starting from 0.99 and I observe a gradual degredation of performance from 0.99 to 2.7.6 Most notably, the frame rate I get in 2.7.6 with CullThreadPerCameraDrawThreadPerContex is not any better than one I get from OSG0.99. Other threading modes give even worse results. It is expected that thread syncronization adds some overhead but I was hoping to get overall better performance from new multithreading models. Here are some of my observations: - From SVN revision 7327 to 7328 a significant loss of cull performance is observed. I found out that this is due to the addition of #define OSGUTIL_RENDERBACKEND_USE_REF_PTR I made some tests and measured following for SingleThreaded case: in 7327 cull time is ~1.15 in 7328 cull time is ~1.65 in 7328 where thread safe ref/unref is turned off cull time is ~1.35 - cull time gets even worse from 7328 onward. In latest SVN version I have 1.95 ms in SingleThreaded mode. I couldn't find yet where the performance loss occurs. - A similar performance loss is observable in draw times but I didn't have time yet to look closer at it. Did anybody else compared old OSG versions to newer ones? How was your results? Tugkan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Hi Vincent, The only thing I can offer is that you have to be careful when you check your node position/rotation, and when you apply your manipulator update. For example, if your order is eventTraversal and then updateTraversal, then your manipulator may be one frame out (i.e. changing based on last frame's node position, not this one). You might see this as jitter. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Hi David, I see what you mean, but if I have this problem, I just would see this as jitter as you said, but the camera would not move strangely without shaking... I don't think this is the reason even it was in the past 3 months ago ! Still earing your ideas... Thanks, Regards, Vincent. 2008/12/4 David Spilling [EMAIL PROTECTED] Hi Vincent, The only thing I can offer is that you have to be careful when you check your node position/rotation, and when you apply your manipulator update. For example, if your order is eventTraversal and then updateTraversal, then your manipulator may be one frame out (i.e. changing based on last frame's node position, not this one). You might see this as jitter. David ___ 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] osgAudio/OpenAL/osgAL
Hi Stephan, hi all OSX users, OpenAL-Soft's author will certainly work on a fallback backend for OSes that it does not support yet (Mainly OSX). I'll post something when it's okay. Maybe you could do a quick test then? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ Le Tue, 02 Dec 2008 15:26:06 +0100, Stephan Maximilian Huber [EMAIL PROTECTED] a écrit: Sukender schrieb: Hi all, This is only partially related to OSG, so I'll make it short: In order to make an osgAudio layer and a corresponding plugin based on OpenAL-Soft and osgAL, there is some need for testing and/or development. 1. Anyone that can help testing OpenAL-Soft on following platforms may mail me or openal-devel mailing list ( http://opensource.creative.com/mailman/listinfo/openal-devel ): - Mac OSX (most wanted of all tests) i downloaded OpenAL-Soft, compiled it and ran the sample-app. It couldn't create a context. I did not have time to dig deeper but it seems, OpenAl couldn't create an output device. OpenAL is part of the system-libs, though. cheers, Stephan ___ 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] 4m 36 seconds!
Hi Ferdi, The osgViewer::Viewer by default will open up a separate GraphicsWindow on each graphics card, and will assign a separate GraphicsThread to each of these contexts. One thing I previous found with running two cards on a PC was that the drivers really didn't like driving the two context by two threads concurrently, even though it was two separate GPU these were targeting, paradoxically I found that serializing the draw dispatch produced better performance than letting them run freely. I've previously called for feedback about whether this problem with drivers/hardware existed on other machines/OS's, but haven't yet got the results back that would help decide what the best default would be for the range of platforms that the OSG supports. With the vacum of testing I've had to go with making the draw dispatch serialization the default. You can override the default by setting the env OSG_SERIALIZE_DRAW_DISPATCH to OFF. With my new machine with its dual 16x PCI-Express 2.0, on chip memory controller and bags of memory bandwidth and later NVidia drivers, the situation may be different w.r.t what works best. I haven't done the dual GPU testing yet on this machine, I'll post the results when I have. The draw serialization is one area that I'm looking closely at, as well as thread affinity. Robert. On Thu, Dec 4, 2008 at 11:08 AM, Ferdi Smit [EMAIL PROTECTED] wrote: Robert, I believe this to be a driver issue as well. However, what it does show is that it is probably preferable to have different contexts on different cores, also to eliminate any possible opengl driver overhead. On 2 cores it runs perfectly as expected; same frame rates as stand-alone. On a single core they both drop back a little, probably because the quadro opengl driver is eating up a lot of CPU time for some obscure reason. Even when the opengl implementation is set to multi-threaded, I never see it start using any additional core by itself. This only happens when you set the affinity manually. So fully relying on the OS scheduling may not be the best option. I don't remember the exact stats, and I can't check them now as I don't have the machine here. I think it was something like 0/0/x for the 8800 and 0/y/y for the 5600, with x close to y. Robert Osfield wrote: Hi Ferdi, It sounds like the OpenGL driver is not behaviour well in your case and twisting the results from what you would normally expect. With scene of 25M polygons you are almost certainly GPU/bandwidth limited, and pretty likely that the OpenGL fifo is backing up and playing havoc. Multi-processing is this situation is not really going to make a huge difference in terms of potential gain because the bottleneck is elsewhere - you aren't CPU limited, it shouldn't make things worse, and the fact that it is suggests that the driver is having issues. What are you cull/draw/gpu stats? Robert. On Thu, Dec 4, 2008 at 10:43 AM, Ferdi Smit [EMAIL PROTECTED] wrote: I've been looking into thread/process affinity with respect to a dual-GPU setup. This is what I found back then: 2 processes, CPU affinity on different cores, each renders the full scene on a different GPU OSG_THREADING=SingleThreaded (1 core shows heavy use, 2nd core show moderate use, 2 cores idle) Quadro 56008800GTX Multi-GPU / Multi-Processing1615 (fps) OSG_THREADING=ThreadPerContext (CPU Affinity is set but appears to be ignored: 1 core shows heavy use, others idle) Multi-GPU / Multi-Processing1114 (fps) So, yes, it helps if the CPU load is balanced across cores, even for this simple 25M polygon scene that is for 99% GPU. Also, OSG seems to mess up manual settings when set to multi-threading :) Check CPU loads in the performance monitor. Don't let 3 cores stand idle all the time; it's a waste of available processing time, and this will only get worse in the future with more cores. Side note, I finally received my 4GB memory, so I can get this quad core, dual GTX260, pcie 2.0 machine running :) Let's see if it behaves differently from a Quadro+8800 on pcie 1.1. Ulrich Hertlein wrote: Additionally: what is the communities' experience with manually assigning processes to cores? Does it work? It sounds like a good idea but in my experience it's best to leave the scheduling up to the operating system to handle core affinity (except when you're running Windows which has a completely fscked-up round-robin scheduler). Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Regards, Ferdi Smit INS3 Visualization and 3D Interfaces CWI Amsterdam, The Netherlands ___ osg-users mailing list osg-users@lists.openscenegraph.org
Re: [osg-users] Performance comparison with older OSG versions
Hi Tugkan, My best guess would that your StateStet and Drawables aren't taking advantage of STATIC DataVariance, if the DataVariance isn't STATIC then the DrawTheadPerContext and CullThreadPerCameraDrawTheadPerContext threading models won't provide any frame overlap and won't provide any improvement in performance. Another thing to check up on is compiler optimization - make sure it's enabled. Finally have a look at what type of ref counting has been implemented, ideally cmake should have chosen atomic ref counting. Have a look at the include/OpenThreads/Config file for what type of ref counting has been selected. It does sound like you might be stuck using Mutex based ref counting. Robert. On Thu, Dec 4, 2008 at 12:13 PM, Tugkan Calapoglu [EMAIL PROTECTED] wrote: Hi All, I have been working on performance issues because after we ported our engine to OSG2.7.6 we lost some performance. In my tests I am using a complex town database which is pretty representative for our applications. I use osgviewer for the tests. I tested with several versions of OSG starting from 0.99 and I observe a gradual degredation of performance from 0.99 to 2.7.6 Most notably, the frame rate I get in 2.7.6 with CullThreadPerCameraDrawThreadPerContex is not any better than one I get from OSG0.99. Other threading modes give even worse results. It is expected that thread syncronization adds some overhead but I was hoping to get overall better performance from new multithreading models. Here are some of my observations: - From SVN revision 7327 to 7328 a significant loss of cull performance is observed. I found out that this is due to the addition of #define OSGUTIL_RENDERBACKEND_USE_REF_PTR I made some tests and measured following for SingleThreaded case: in 7327 cull time is ~1.15 in 7328 cull time is ~1.65 in 7328 where thread safe ref/unref is turned off cull time is ~1.35 - cull time gets even worse from 7328 onward. In latest SVN version I have 1.95 ms in SingleThreaded mode. I couldn't find yet where the performance loss occurs. - A similar performance loss is observable in draw times but I didn't have time yet to look closer at it. Did anybody else compared old OSG versions to newer ones? How was your results? Tugkan ___ 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] Depth/Cull question
Hi Vincent, Using a HUD-like system seems to be a extrem solution for me... I am just looking at a way to set a node always rendered... I did not suggest a HUD approach, Ralph did. It's one possible solution, but see below for what I'd suggest. For the moment, using the .osg format file to see my stateset, I see that the culling test still stay ON. Argh... How many times do I need to say that culling is not your problem? It's a z-buffer precision issue. Fix this the right way or you'll always have problems. I'll spell it out for you: Culling will only remove entire nodes / drawables. This is not happening with your airplane, since you can see part of it, but some of it is behind your terrain. This means that part of the object is failing the depth test, which is because your near and far planes are too far apart and thus your z-buffer precision is too small to resolve the airplane correctly over the terrain. The AUTO_COMPUTE_NEAR_FAR mode will automatically push back the near plane to be closest to your airplane, and pull in the far plane to be just behind your terrain, which will make sure that the distance between the near and far planes is minimal, and thus that you have enough precision between them to resolve the airplane above the terrain. Then again, as I mentioned before, if you're using a whole Earth model for your terrain, then the far plane will be behind the Earth and the near plane will be in front of your airplane, which will result in there being more than the diameter of the Earth between the two, which if you use meters as your unit will be too much and you will get low z-buffer precision even with AUTO_COMPUTE_NEAR_FAR enabled. One solution here is to use depth partitioning to render the Earth with one depth partition and the rest (the airplane and anything on the surface) with another. See the osgdepthpartition example. Another solution would be to break up your Earth model into multiple Geodes/Drawables, and use occlusion culling, which would remove the back part of the Earth. Anyways, breaking up the Earth will bring better performance in general because OSG will be able to cull parts of it that are outside of the view frustum. So it's a good idea if you haven't done it already. osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::NEVER, 0.0, 1.0); NEVER means it will NEVER pass the depth test. This is not what you want, you want ALWAYS. http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/depthfunc.html J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] osgviewerQT example
Hi all, I would like to know if in a correctly configured Linux, the osgviewerQT example works with the --QOSGWidget option ? I am asking that because we are currently trying to achieve something similar with WinForms on Linux (using Mono), and we are following the same way than the QT example and the QOSGWidget. The big deal is that we are working with VMWare, without real graphics drivers, and this example crash the same way as our application. That's why we would like to know if it's related to VMWare or not. Thanks in advance ! -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Hi Vincent, I implement a new manipulator, with a way to set a node as reference. The expected effect is that the camera will stay motionless relative to the node (translation and rotation) In other words, it will follow the node? You could try osgGA::NodeTrackerManipulator... osg::ref_ptrosgGA::NodeTrackerManipulator manipulator = new osgGA::NodeTrackerManipulator; manipulator-setTrackerMode(NODE_CENTER_AND_ROTATION); manipulator-setTrackNode(node); Then you can use setHomePosition() to change the offset to the node. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Depth/Cull question
2008/12/4 Jean-Sébastien Guay [EMAIL PROTECTED] Hi Vincent, Using a HUD-like system seems to be a extrem solution for me... I am just looking at a way to set a node always rendered... I did not suggest a HUD approach, Ralph did. It's one possible solution, but see below for what I'd suggest. For the moment, using the .osg format file to see my stateset, I see that the culling test still stay ON. Argh... How many times do I need to say that culling is not your problem? It's a z-buffer precision issue. Fix this the right way or you'll always have problems. I'll spell it out for you: Culling will only remove entire nodes / drawables. This is not happening with your airplane, since you can see part of it, but some of it is behind your terrain. This means that part of the object is failing the depth test, which is because your near and far planes are too far apart and thus your z-buffer precision is too small to resolve the airplane correctly over the terrain. The AUTO_COMPUTE_NEAR_FAR mode will automatically push back the near plane to be closest to your airplane, and pull in the far plane to be just behind your terrain, which will make sure that the distance between the near and far planes is minimal, and thus that you have enough precision between them to resolve the airplane above the terrain. Then again, as I mentioned before, if you're using a whole Earth model for your terrain, then the far plane will be behind the Earth and the near plane will be in front of your airplane, which will result in there being more than the diameter of the Earth between the two, which if you use meters as your unit will be too much and you will get low z-buffer precision even with AUTO_COMPUTE_NEAR_FAR enabled. One solution here is to use depth partitioning to render the Earth with one depth partition and the rest (the airplane and anything on the surface) with another. See the osgdepthpartition example. Another solution would be to break up your Earth model into multiple Geodes/Drawables, and use occlusion culling, which would remove the back part of the Earth. Anyways, breaking up the Earth will bring better performance in general because OSG will be able to cull parts of it that are outside of the view frustum. So it's a good idea if you haven't done it already. osg::ref_ptrosg::Depth depth = new osg::Depth(osg::Depth::NEVER, 0.0, 1.0); NEVER means it will NEVER pass the depth test. This is not what you want, you want ALWAYS. http://www.opengl.org/documentation/specs/man_pages/hardcopy/GL/html/gl/depthfunc.html Yes, it is just a mistake when I paste the code... I am in ALWAYS. Okay for the culling, but when nothing seems to work... I tried everything that can modify anything... My Earth model is already divided into lots of groups/drawables... So when I put the normal COMPUTE_NEAR_FAR_MODE, the plane and the Earth are well renderd... But, the frustum near plane is too far... because, even if I can move in spatial mode... I need to go into the plane too, and for now, the frustum near plan do not allow that... PS : AUTO_COMPUTE_NEAR_FAR do not exist... or I didn't find it. That's why I would prefer to not change the frustum parameters... and to set the plane always rendered, and a callback will adjust this parameter, depending on camera's position. I did it last week, it works well. But after some modifications in my code, nothing seems to work about culling... I use CompositeViewers, each one get one View... this kind of thing can be responsible of this problem ? Sorry to insist... I hear you about frustum and culling, but I know what I expect and what is possible or not with my application structure... and just setting my plane always rendered will be sufficient, and useful. So the problem still stay the same : whatever is my Depth setting, the plane render always the same... Thanks for you precisions. Regards, Vincent. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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
[osg-users] About to reopen the osgNV project?
Hi all, Do you remember a C++ based project named osgNV, which supports for nVIDIA OpenGL extensions and the Cg language? It has been discontinued from 2 years ago, but still a great way to take advantage of modern GPUs. I have just rewritten the osgNV library to fit OSG 2.7.6 and Cg 2.1 on my Core Quad Q6600 and GeForce 9600GT last and this week. And all the examples seem to run well. Now I have a plan to reopen the famous and reliable osgNV project, make it support newest nVIDIA features, like CGFX, CUDA and so on, and even the RenderMonkey of ATI systems in future. The new project will still be released as LGPL. I'm a beginninger of GPU programming myself so it needs some time to add new features. But I will focus on the Cg languages first and leave osgNVSlang and osgNVParse unchanged, for GLSL and vertex programs are already supported by OSG itself. I'd like to know if the new project could be still placed on the sourceforge page of osgNV (http://osgnv.sourceforge.net) or should find a new home? I will also apologize to Marco Jez and other authors of osgNV for my boldness because I did not contact with them first. I would like to share the modified osgNV code if anybody has a similar plan. Any suggestions? Best wishes Wang Rui attachment: osgNV1.JPGattachment: osgNV2.JPG___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
nVidia Quadro4 700XGL 64 MB AGP Video Card General Features: nVidia Quadro4 700XGL chipset 64 MB DDR SDRAM AGP interface 350 MHz RAMDAC 1920 x 1200 @ 76 Hz maximum resolutions (analog monitor) 1600 x 1200 @ 60 Hz maximum resolutions (digital monitor) Lightspeed Memory Architecture II nfiniteFX II engine Accuview high-resolution antialiasing Hardware accelerated real-time shadows DirectX 8 and OpenGL 1.3/4 Supports some very minimal CG based shaders But anything fancy puts it into software path very quickly 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: Thursday, December 04, 2008 4:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, On Wed, Dec 3, 2008 at 8:01 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: To be honest OGL 3.0 is not on my horizon right now ( I know its there ) A lot of our customers are on base line machines with 7 year old cards such as NVIDIA Quadro4 700 XGL OpenGl 2.1 and 256mb is a luxury :) Out of curiosity what version of OpenGL and extensions does this kit support? VBO's? PBO'S? FBO's? Shaders? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgcon and textures ?
Hi, I'm trying to convert an ive file that contains some textures to a collada file, but the textures are not exported at all ? Did I miss an option ? I've also tried to convert it to osg file with the same result... (I'm using openscenegraph 2.6.1) I was supposing the best way to exchange with someone working with sketchup would be collada ? Do you see a better solution ? Is there any plugin to read/write google sketchup file ? Thanks, Pierre. Pierre BOURDIN I.M.E.R.I.R. Av. Pascot BP 90443 66004 PERPIGNAN tél: 04 68 56 80 18 fax: 04 68 55 03 86 email: [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Reading a node file from http
Hi, I am just writing a firefox-plugin for osgViewer, which was surprisingly easy so far. I already have got old bessy in firefox, but it is loaded from a local file. How can I load files from http? I guess that I either have to interact somehow with the firefox plugin-api and stream it somehow to my plugin, or something else that I am not aware of. If someone has done something of the kind, please give me a pointer at where to look for. Regards, Andreas ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager
HI Gordon, Wow, 64Mb of memory... that's quite some constraint. Is there a reason why hardware like this isn't be replaced? A $50 card would exceed it's capabilities and performance by a long way. Robert. On Thu, Dec 4, 2008 at 3:04 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: nVidia Quadro4 700XGL 64 MB AGP Video Card General Features: nVidia Quadro4 700XGL chipset 64 MB DDR SDRAM AGP interface 350 MHz RAMDAC 1920 x 1200 @ 76 Hz maximum resolutions (analog monitor) 1600 x 1200 @ 60 Hz maximum resolutions (digital monitor) Lightspeed Memory Architecture II nfiniteFX II engine Accuview high-resolution antialiasing Hardware accelerated real-time shadows DirectX 8 and OpenGL 1.3/4 Supports some very minimal CG based shaders But anything fancy puts it into software path very quickly 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: Thursday, December 04, 2008 4:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, On Wed, Dec 3, 2008 at 8:01 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: To be honest OGL 3.0 is not on my horizon right now ( I know its there ) A lot of our customers are on base line machines with 7 year old cards such as NVIDIA Quadro4 700 XGL OpenGl 2.1 and 256mb is a luxury :) Out of curiosity what version of OpenGL and extensions does this kit support? VBO's? PBO'S? FBO's? Shaders? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ 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] Math problem relative to OSG
Hi, Exactly ! I will have a look one time more on NodeTrackerManipulator... but last time I read the sources... I do not understand how it works... And my manipulator is too much customized to be replaced by another manipulator... Thanks for help... Still waiting for a mathematical revelation if anyone see a problem in my algorithm... Regards, Vincent. 2008/12/4 Jean-Sébastien Guay [EMAIL PROTECTED] Hi Vincent, I implement a new manipulator, with a way to set a node as reference. The expected effect is that the camera will stay motionless relative to the node (translation and rotation) In other words, it will follow the node? You could try osgGA::NodeTrackerManipulator... osg::ref_ptrosgGA::NodeTrackerManipulator manipulator = new osgGA::NodeTrackerManipulator; manipulator-setTrackerMode(NODE_CENTER_AND_ROTATION); manipulator-setTrackNode(node); Then you can use setHomePosition() to change the offset to the node. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Depth/Cull question
Hi Vincent, My Earth model is already divided into lots of groups/drawables... So when I put the normal COMPUTE_NEAR_FAR_MODE, the plane and the Earth are well renderd... But, the frustum near plane is too far... because, even if I can move in spatial mode... I need to go into the plane too, and for now, the frustum near plan do not allow that... Seriously, try depth partitioning, it's easy to integrate into an engine. Or try to change the nearFarRatio so that your near plane is pushed less far when you're inside the airplane. You may just need different strategies for the two cases, since they're very different situations as far as tyhe z-buffer is concerned. If it works well when outside the plane with the normal ComputeNearFarMode, and it works well outside the plane when you set the near and far distances explicitly and disable ComputeNarFarMode, then just set them that way when you switch from inside your plane to outside! PS : AUTO_COMPUTE_NEAR_FAR do not exist... or I didn't find it. I was going from memory, seeing as the disable case is DO_NOT_COMPUTE_NEAR_FAR. The other options are COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES and COMPUTE_NEAR_FAR_USING_PRIMITIVES. Sorry to insist... I hear you about frustum and culling, but I know what I expect and what is possible or not with my application structure... Everything is possible with any application structure. It's just the willingness to fix the problem that's missing. I think you've already wasted lots of time trying to get your workaround to work that in the end you won't have saved any time at all. and just setting my plane always rendered will be sufficient, and useful. So the problem still stay the same : whatever is my Depth setting, the plane render always the same... There's nothing more we can say about this. It should work, it does work in other applications, so if it doesn't work in yours then you need to find the problem, we can't really help that much since we don't have the app. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] xerces C++, cmarkup, libxml2 or which xml parser ?
Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Depth/Cull question
2008/12/4 Jean-Sébastien Guay [EMAIL PROTECTED] Hi Vincent, My Earth model is already divided into lots of groups/drawables... So when I put the normal COMPUTE_NEAR_FAR_MODE, the plane and the Earth are well renderd... But, the frustum near plane is too far... because, even if I can move in spatial mode... I need to go into the plane too, and for now, the frustum near plan do not allow that... Seriously, try depth partitioning, it's easy to integrate into an engine. Or try to change the nearFarRatio so that your near plane is pushed less far when you're inside the airplane. You may just need different strategies for the two cases, since they're very different situations as far as tyhe z-buffer is concerned. If it works well when outside the plane with the normal ComputeNearFarMode, and it works well outside the plane when you set the near and far distances explicitly and disable ComputeNarFarMode, then just set them that way when you switch from inside your plane to outside! Yes, this is already implemented, but just to ajust the frustum a little. Why ? because when we are in the plane, we can see the sky or Earth far away... so I always need a FAR plane around 5000 ... and a near around 0.5 !! With the plane rendered in Always mode, everything will be good... It is the only thing that causes Z-buffer fighting ... PS : AUTO_COMPUTE_NEAR_FAR do not exist... or I didn't find it. I was going from memory, seeing as the disable case is DO_NOT_COMPUTE_NEAR_FAR. The other options are COMPUTE_NEAR_FAR_USING_BOUNDING_VOLUMES and COMPUTE_NEAR_FAR_USING_PRIMITIVES. Sorry to insist... I hear you about frustum and culling, but I know what I expect and what is possible or not with my application structure... Everything is possible with any application structure. It's just the willingness to fix the problem that's missing. I think you've already wasted lots of time trying to get your workaround to work that in the end you won't have saved any time at all. Of course... But, this was working well weeks ago. So repair the bug is more simple than to rebuilt half the code to adapt it... and just setting my plane always rendered will be sufficient, and useful. So the problem still stay the same : whatever is my Depth setting, the plane render always the same... There's nothing more we can say about this. It should work, it does work in other applications, so if it doesn't work in yours then you need to find the problem, we can't really help that much since we don't have the app. :'( I will get it ! one day Thanks a lot Sorry to take so much of your time... Regards, Vincent. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] xerces C++, cmarkup, libxml2 or which xml parser ?
Hi, You forgot to mention Expat, it's light and easy to use, personnaly it's my favorite XML parser. But you'll need to encapsulate it in C++ classes yourself, I don't know if a C++ binding is freely available. On Thu, Dec 4, 2008 at 4:20 PM, Ümit Uzun [EMAIL PROTECTED] wrote: Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading a node file from http
El Jueves 04 Diciembre 2008ES 16:11:41 Andreas Goebel escribió: How can I load files from http? With the curl plugin? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Math problem relative to OSG
Hi Vincent, I will have a look one time more on NodeTrackerManipulator... but last time I read the sources... I do not understand how it works... The benefit of using a library is that you don't need to understand how it works. You can just use its services. In this case, it looks like you're trying to re-do something that's already done for you. And my manipulator is too much customized to be replaced by another manipulator... You could subclass the NodeTrackerManipulator, let it do its work, and add whatever other functionality you need on the side. That's what we do. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Depth/Cull question
Hi Vincent, But, this was working well weeks ago. So repair the bug is more simple than to rebuilt half the code to adapt it... Do you use source control? If so you can just compare your code from a few weeks ago when it worked to the code now, and see what changed. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] xerces C++, cmarkup, libxml2 or which xml parser ?
I have used Xerces-C and found it to work very well, but be quite bulky (as it is a validating XML parser). I ended up going with another open source project (ezxml) because it was much smaller, though didn't offer any XML validation. The first thing you probably need to do is to decide if you want a validating parser or not. That will help guide your decision. - John -Original Message- From: Ümit Uzun [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:20 AM To: OpenSceneGraph Users Subject: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ? Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ?
I use libxml2 , i dont use c++ stuff on top of xml. I use only
std::mapstd::string, std::string for node properties and xpath to find
nodes in xml tree.
it's the helper i use most of the time
static void getNodeParameters(xmlNodePtr
node,std::mapstd::string,std::string map)
{
map.clear();
xmlAttr* attribute;
for(attribute = node-properties; attribute; attribute =
attribute-next) {
const char* value = (const
char*)xmlNodeGetContent((xmlNode*)attribute);
const char* variable = (const char*)attribute-name;
map[variable] = value;
xmlFree((void*)value);
}
}
Cheers,
Cedric
Ümit Uzun wrote:
Hi All,
I need a xml parser library which should be powerful and easier for
now and future usability. I have searched mail list and found
following libraries;
1 - http://xmlsoft.org/ LIBXML2
2 - http://www.firstobject.com/ CMARKUP
3 - http://xerces.apache.org/xerces-c/index.html XERCES C++
I am waiting advices who had experience any of these or another library?
Best Regards.
--
Ümit Uzun
___
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] Depth/Cull question
Hi Jean-Sébastien, Of course I compared my current version and the last one... If I keep the last one... nothing changes compared to new... The big changed I did is to switch for osgViewer to composite Viewer... I'll have a look on that... because I will become mad looking my code still not working whatever I do... Thanks Vincent. 2008/12/4 Jean-Sébastien Guay [EMAIL PROTECTED] Hi Vincent, But, this was working well weeks ago. So repair the bug is more simple than to rebuilt half the code to adapt it... Do you use source control? If so you can just compare your code from a few weeks ago when it worked to the code now, and see what changed. J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] Reading a node file from http
Andreas Goebel ha scritto: Hi, I am just writing a firefox-plugin for osgViewer, which was surprisingly easy so far. I already have got old bessy in firefox, but it is loaded from a local file. How can I load files from http? I guess that I either have to interact somehow with the firefox plugin-api and stream it somehow to my plugin, or something else that I am not aware of. If someone has done something of the kind, please give me a pointer at where to look for. Not sure if I understood: you are putting osgviewer inside firefox like http://3d.cineca.it/storage/demo_vrome_ajax/virtualrome_3d.html (windows onlysic) or the other way around? If it is the first case, we used curl osg built in functionality to get ive and osg from the web, just pass url to ReadNodeFile I know that it should be possible to ask for firefox a url and get back like a stream, but we decided to go the easiest way. On which platform are you working on? There are several projects for putting osg inside browser and It would be really nice if we coud share efforts. If your release plan is open source (like our), please let we know, we are more than willing to cooperate. We found that most of the trouble comes when you scale both data as well as deploymentplatforms. Our stuff is relatively stable on NVidia recent HW but fails on old ATI and on some intel. Regards Luigi ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ?
Hi Umit, I use libxml2 in Present3D and it works nicely and it really straight forward to use. Robert. On Thu, Dec 4, 2008 at 3:20 PM, Ümit Uzun [EMAIL PROTECTED] wrote: Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ 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] Reading a node file from http
Hi Andreas, If you have the libcurl plugin built it should be just read the files directly, osgDB::Registry should automatically find load the curl plugin for http:// requests. Any chance of you open sourcing your firefox plugin? How did you go about implementing it? What platforms would it work on? Robert. On Thu, Dec 4, 2008 at 3:11 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi, I am just writing a firefox-plugin for osgViewer, which was surprisingly easy so far. I already have got old bessy in firefox, but it is loaded from a local file. How can I load files from http? I guess that I either have to interact somehow with the firefox plugin-api and stream it somehow to my plugin, or something else that I am not aware of. If someone has done something of the kind, please give me a pointer at where to look for. Regards, Andreas ___ 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] flt-exporter: Index outofrangeinVertexPaletteManager
A lot of the our customers are part of highly controlled programs that dictate what software and hardware they have on their desks and most are running as restricted user with no admin what so ever, even trying to get driver updates pushed in to the specs is very very hard. This is currently the worst spec we have to deal with. And on top of every thing else were don't run on our own, our 3d controls are modules to out main product RemoteView product which in its self is a resource memory hungry blighter. And worse many also have programs like ArcView/Map running which again resource memory hungry blighter So we have fun :) 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: Thursday, December 04, 2008 10:12 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager HI Gordon, Wow, 64Mb of memory... that's quite some constraint. Is there a reason why hardware like this isn't be replaced? A $50 card would exceed it's capabilities and performance by a long way. Robert. On Thu, Dec 4, 2008 at 3:04 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: nVidia Quadro4 700XGL 64 MB AGP Video Card General Features: nVidia Quadro4 700XGL chipset 64 MB DDR SDRAM AGP interface 350 MHz RAMDAC 1920 x 1200 @ 76 Hz maximum resolutions (analog monitor) 1600 x 1200 @ 60 Hz maximum resolutions (digital monitor) Lightspeed Memory Architecture II nfiniteFX II engine Accuview high-resolution antialiasing Hardware accelerated real-time shadows DirectX 8 and OpenGL 1.3/4 Supports some very minimal CG based shaders But anything fancy puts it into software path very quickly 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: Thursday, December 04, 2008 4:45 AM To: OpenSceneGraph Users Subject: Re: [osg-users] flt-exporter: Index outofrangeinVertexPaletteManager Hi Gordon, On Wed, Dec 3, 2008 at 8:01 PM, Tomlinson, Gordon [EMAIL PROTECTED] wrote: To be honest OGL 3.0 is not on my horizon right now ( I know its there ) A lot of our customers are on base line machines with 7 year old cards such as NVIDIA Quadro4 700 XGL OpenGl 2.1 and 256mb is a luxury :) Out of curiosity what version of OpenGL and extensions does this kit support? VBO's? PBO'S? FBO's? Shaders? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph. or g ___ 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.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ?
Hi All, You forgot to mention Expat, it's light and easy to use, personnaly it's my favorite XML parser. Actually I didn't forget expat' I used a bit and don't like very as much as you :) The first thing you probably need to do is to decide if you want a validating parser or not. No I don't need validation for xml format. I only save and read required data and a bit much of them. I use libxml2 , i dont use c++ stuff on top of xml. I use only std::mapstd::string, std::string for node properties and xpath to find nodes in xml tree. That is another good operation. It may helps. I use libxml2 in Present3D and it works nicely and it really straight forward to use. Himmm, I forgot Present3D :) I used and loved it very much. It's good starting point. Robert can I ask another question' if you need xml library to use in OSG releases in the future do you prefer libxml2 again? Thanks folks. 2008/12/4 Farrier, John E CTR USAF AFMC ASC/XRA [EMAIL PROTECTED] I have used Xerces-C and found it to work very well, but be quite bulky (as it is a validating XML parser). I ended up going with another open source project (ezxml) because it was much smaller, though didn't offer any XML validation. The first thing you probably need to do is to decide if you want a validating parser or not. That will help guide your decision. - John -Original Message- From: Ümit Uzun [mailto:[EMAIL PROTECTED] Sent: Thursday, December 04, 2008 10:20 AM To: OpenSceneGraph Users Subject: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ? Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ?
Going in the direction of simplicity I use TinyXML http://www.grinninglizard.com/tinyxml/ Minimal, but works very well, if you don't need to do too much. Ciao! mario Ümit Uzun wrote: Hi All, You forgot to mention Expat, it's light and easy to use, personnaly it's my favorite XML parser. Actually I didn't forget expat' I used a bit and don't like very as much as you :) The first thing you probably need to do is to decide if you want a validating parser or not. No I don't need validation for xml format. I only save and read required data and a bit much of them. I use libxml2 , i dont use c++ stuff on top of xml. I use only std::mapstd::string, std::string for node properties and xpath to find nodes in xml tree. That is another good operation. It may helps. I use libxml2 in Present3D and it works nicely and it really straight forward to use. Himmm, I forgot Present3D :) I used and loved it very much. It's good starting point. Robert can I ask another question' if you need xml library to use in OSG releases in the future do you prefer libxml2 again? Thanks folks. 2008/12/4 Farrier, John E CTR USAF AFMC ASC/XRA [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] I have used Xerces-C and found it to work very well, but be quite bulky (as it is a validating XML parser). I ended up going with another open source project (ezxml) because it was much smaller, though didn't offer any XML validation. The first thing you probably need to do is to decide if you want a validating parser or not. That will help guide your decision. - John -Original Message- From: Ümit Uzun [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Thursday, December 04, 2008 10:20 AM To: OpenSceneGraph Users Subject: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ? Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ 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 -- Ümit Uzun ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Ing. Mario Valle Data Analysis Group | http://www.cscs.ch/~mvalle Swiss National Supercomputing Centre (CSCS) | Tel: +41 (91) 610.82.60 v. Cantonale Galleria 2, 6928 Manno, Switzerland | Fax: +41 (91) 610.82.82 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] computeIntersections Bug + Fix (was View::computeIntersections with a node path)
Hi, I think I found the bug. Fixed implementation attached. If you look at the implementation of the function osgViewer::View::computeIntersections() taking the nodepath argument, you'll see that it compute the LocalToWorld transformation using the complete given path. But this is incorrect if the last node of the path is a transformation. In which case the last transformation is applied twice before computing any intersections. I've currently copy/pasted the current implementation and changed it to a standalone function so that I could test and use it as a fixed version without modifying OSG code. See attachment. The two important lines are: const osg::NodePath shortPath(nodePath.begin(), nodePath.end() - 1); osg::Matrix matrix = osg::computeLocalToWorld(shortPath) * camera-getViewMatrix() * camera-getProjectionMatrix(); Robert, if you agree with these modifications, what should I do for them to be integrated back into the trunk? Cheers, Tanguy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanguy Fautre Sent: Friday 28 November 2008 15:21 To: osg-users@lists.openscenegraph.org Cc: Neil Groves Subject: Spam: [osg-users] View::computeIntersections with a node path Hi, Has anyone been able to successfully use osgViewer::View::computeIntersections() taking a node path argument on a non-trivial scenegraph? I currently have a fairly complex scenegraph, but I only want a small part of it to collide with computeIntersections. When I use computeIntersections without the nodepath, everything works perfectly. But as soon as I use the overload with the node path, I get an empty intersection set. I'm pretty sure the node path I'm giving is correct. Looking at the implementation of computeIntersections() with the node path, the only thing that puzzles me is the use of osg::computeWorldToLocal(nodePath) before computing the matrix inverse, I'm not sure I fully understand why this is the case. It seems to me the whole operation should be LocalToWorldMatrix * ViewMatrix * ProjectionMatrix instead. In any case, if anyone has a working example (which would show computeIntersections() with a node path is working correctly, or help finding the mistake I'm doing), it would be appreciated. Regards, Tanguy ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org computeIntersections.cpp Description: computeIntersections.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xerces C++, cmarkup, libxml2 or which xml parser ?
I use CMarkup. Regards, Can 2008/12/4 Ümit Uzun [EMAIL PROTECTED] Hi All, I need a xml parser library which should be powerful and easier for now and future usability. I have searched mail list and found following libraries; 1 - http://xmlsoft.org/ LIBXML2 2 - http://www.firstobject.com/ CMARKUP 3 - http://xerces.apache.org/xerces-c/index.html XERCES C++ I am waiting advices who had experience any of these or another library? Best Regards. -- Ümit Uzun ___ 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] xerces C++, cmarkup, libxml2 or which xml parser ?
Hi Umit, On Thu, Dec 4, 2008 at 3:57 PM, Ümit Uzun [EMAIL PROTECTED] wrote: Himmm, I forgot Present3D :) I used and loved it very much. It's good starting point. Robert can I ask another question' if you need xml library to use in OSG releases in the future do you prefer libxml2 again? Like everyone else I tend to prefer things that I'm familiar with, so libxml2 would be a front runner for sure, but if needs take us along some other route in the future so be it. I don't have any current plans for integration of XML support into the core OSG, so don't have an plans with making choices about XML parsing. It it comes to the project crossing this particular bridge then we'll decide on the what to use when we get to it, the software world can change so much it's not worth putting to much effort into predicting the little details. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading a node file from http
Hi Andreas, It is working now (see picture below), and I will be OpenSourcing it. I just need to add a way to pass filenames to the plugin. Nice work, though using the URL in the image doesn't work for me (I guess because you didn't put the plugin online so that it can be automatically downloaded by Firefox...) :-) Let us know when it's available, it's a nice thing to have on a web site! J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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] flt-exporter:Index outof rangeinVertexPaletteManager
- fixed a bug in flt-exporter with the help of Paul, sent this file to paul I'll review this and submit it with your credit. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGQSG: Error
page 63, fig 2-9 The State example scene graph displayed in osgviewer TBD move TBD move? ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KDTree Picking (at an angle)
Robert,
I think I know why things go bad in KDTree,
I'm using KDTree to spoof the location of some actual geometry, which is
transformed in a vertex/geometry shader.
So, I compute a bounding box for where the geometry ought to be, and create
a dummy geometry from that - I then compute the KDTree for this dummy
geometry, and assign it to the actual geometry that will be sent down the
pipe, which is at the scene origin, not its final location.
When the line-segment intersector goes to pick, it first checks to see if
the line segment intersects the bounding box of the drawable, which as far
as I can tell is computed against the actual geometry (in this case the
geometry at the origin) and not the KDTree's bounding box. When it doesn't
properly intersect, the line-segment intersector returns without hitting the
KDTree.
I think what is needed is to test against the KDTree bounding box, rather
than the geometry bounding box, if a KDTree is assigned.
Does this make any sense?
sean
On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED] wrote:
Robert,
I will see if I can repro the problem with osgpick and send you the osg
file. It may take me a week or two though as I've got a lot on my plate ;-)
cheers,
sean
On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]wrote:
Hi Sean,
This sounds like a bug, but without a dataset and example that
reproduces the problem it's next to impossible to home in on a fix.
Would it be possible for you to provide a problem dataset that
illustrates the problem? If it can be reproduced with one of the
existing examples like osgpick then this will make it easier to track
down.
Robert.
On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
wrote:
Hi Gang,
I'm working on improving picking performance via KDTree, but I'm hitting
an
issue that is driving me nuts: If I pick a node from directly above
(e.g. +
Z axis) everything works great, and picking is *very* fast. If I pick
at an
angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate -
nodes
to the left, right, top, or bottom get picked instead of what I'm after.
Here is my KDTree Build function:
#ifdef USE_KDTREE
// Update the KDTree
osg::KdTree::BuildOptions kdTreeBuildOptions;
osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
if(kdTree-build(kdTreeBuildOptions, geometry))
{
geometry-setShape(kdTree.get());
}
else
{
LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.;
}
#endif
Any suggestions?
cheers,
sean
___
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] Request: bool Polytope.contains(another_polytope)
I understand. About my other question then, there is currently no workaround to test collision between two polytopes? I tried polytope.contains(polytope2.getReferenceVertexList()) but it doesn't seems to work either (always returning false). Any other ideas? On Thu, Dec 4, 2008 at 7:05 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Jefferson, Like Gordon says, if you need the function then the thing to do is implement it and submit it. I'm not hear to take end users feature requests and then go a implement them for free. I have bucket load of work to do, working well over my forty hour week every week, with many of these hours doing project maintenance and support work without financial return, the simply is no scope for doing extra stuff just out of kind heartedness - I do strangely enough have a life outside the OSG. Robert. On Wed, Dec 3, 2008 at 8:10 PM, Jefferson Pinheiro [EMAIL PROTECTED] wrote: Hello Robert, Can you please implement a function, in class Polytope, that checks if the current polytope intersects another polytope? Or is there another way to do that, and I'm not seeing? Thanks, -- Jefferson Pinheiro ___ 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 -- Jefferson Pinheiro (51) 9192 3535 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] gecko plugin working for windows?
Hi, Is that true that gecko plugin so far only work under linux? I download win32 gecko sdk but cannot fine xul library file, also mozjs library file. How to make it working? Thanks Hui ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KDTree Picking (at an angle)
Hi Sean,
Yes this makes sense. There is a mechanism in Drawable that allows
you to define an inital bound that is used in the compute of the
geometry position, this was done quite a few years ago at begining of
the journey in the land of vertex shader. These days I think a better
solution would be to just allow users to manually define it and
disable the automatic compute of the bounding volume.
So try using
geometry-setInitialBound(bb);
Where bb is the max size you expect the goemetry to get to/or the
bound that you used for the KdTree.
If that works OK I can look at cleaning up the overriding of the computed bound.
Robert.
On Thu, Dec 4, 2008 at 6:30 PM, Sean Spicer [EMAIL PROTECTED] wrote:
Robert,
I think I know why things go bad in KDTree,
I'm using KDTree to spoof the location of some actual geometry, which is
transformed in a vertex/geometry shader.
So, I compute a bounding box for where the geometry ought to be, and create
a dummy geometry from that - I then compute the KDTree for this dummy
geometry, and assign it to the actual geometry that will be sent down the
pipe, which is at the scene origin, not its final location.
When the line-segment intersector goes to pick, it first checks to see if
the line segment intersects the bounding box of the drawable, which as far
as I can tell is computed against the actual geometry (in this case the
geometry at the origin) and not the KDTree's bounding box. When it doesn't
properly intersect, the line-segment intersector returns without hitting the
KDTree.
I think what is needed is to test against the KDTree bounding box, rather
than the geometry bounding box, if a KDTree is assigned.
Does this make any sense?
sean
On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED] wrote:
Robert,
I will see if I can repro the problem with osgpick and send you the osg
file. It may take me a week or two though as I've got a lot on my plate ;-)
cheers,
sean
On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield [EMAIL PROTECTED]
wrote:
Hi Sean,
This sounds like a bug, but without a dataset and example that
reproduces the problem it's next to impossible to home in on a fix.
Would it be possible for you to provide a problem dataset that
illustrates the problem? If it can be reproduced with one of the
existing examples like osgpick then this will make it easier to track
down.
Robert.
On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
wrote:
Hi Gang,
I'm working on improving picking performance via KDTree, but I'm
hitting an
issue that is driving me nuts: If I pick a node from directly above
(e.g. +
Z axis) everything works great, and picking is *very* fast. If I pick
at an
angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate -
nodes
to the left, right, top, or bottom get picked instead of what I'm
after.
Here is my KDTree Build function:
#ifdef USE_KDTREE
// Update the KDTree
osg::KdTree::BuildOptions kdTreeBuildOptions;
osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
if(kdTree-build(kdTreeBuildOptions, geometry))
{
geometry-setShape(kdTree.get());
}
else
{
LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.;
}
#endif
Any suggestions?
cheers,
sean
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] KDTree Picking (at an angle)
Will do, and I'll report back...
sean
On Thu, Dec 4, 2008 at 1:07 PM, Robert Osfield [EMAIL PROTECTED]wrote:
Hi Sean,
Yes this makes sense. There is a mechanism in Drawable that allows
you to define an inital bound that is used in the compute of the
geometry position, this was done quite a few years ago at begining of
the journey in the land of vertex shader. These days I think a better
solution would be to just allow users to manually define it and
disable the automatic compute of the bounding volume.
So try using
geometry-setInitialBound(bb);
Where bb is the max size you expect the goemetry to get to/or the
bound that you used for the KdTree.
If that works OK I can look at cleaning up the overriding of the computed
bound.
Robert.
On Thu, Dec 4, 2008 at 6:30 PM, Sean Spicer [EMAIL PROTECTED]
wrote:
Robert,
I think I know why things go bad in KDTree,
I'm using KDTree to spoof the location of some actual geometry, which
is
transformed in a vertex/geometry shader.
So, I compute a bounding box for where the geometry ought to be, and
create
a dummy geometry from that - I then compute the KDTree for this dummy
geometry, and assign it to the actual geometry that will be sent down the
pipe, which is at the scene origin, not its final location.
When the line-segment intersector goes to pick, it first checks to see if
the line segment intersects the bounding box of the drawable, which as
far
as I can tell is computed against the actual geometry (in this case the
geometry at the origin) and not the KDTree's bounding box. When it
doesn't
properly intersect, the line-segment intersector returns without hitting
the
KDTree.
I think what is needed is to test against the KDTree bounding box, rather
than the geometry bounding box, if a KDTree is assigned.
Does this make any sense?
sean
On Wed, Dec 3, 2008 at 10:05 AM, Sean Spicer [EMAIL PROTECTED]
wrote:
Robert,
I will see if I can repro the problem with osgpick and send you the osg
file. It may take me a week or two though as I've got a lot on my plate
;-)
cheers,
sean
On Wed, Dec 3, 2008 at 3:28 AM, Robert Osfield
[EMAIL PROTECTED]
wrote:
Hi Sean,
This sounds like a bug, but without a dataset and example that
reproduces the problem it's next to impossible to home in on a fix.
Would it be possible for you to provide a problem dataset that
illustrates the problem? If it can be reproduced with one of the
existing examples like osgpick then this will make it easier to track
down.
Robert.
On Wed, Dec 3, 2008 at 12:00 AM, Sean Spicer [EMAIL PROTECTED]
wrote:
Hi Gang,
I'm working on improving picking performance via KDTree, but I'm
hitting an
issue that is driving me nuts: If I pick a node from directly above
(e.g. +
Z axis) everything works great, and picking is *very* fast. If I
pick
at an
angle, (e.g. from eye(1,1,1)) then picking is fast, but not accurate
-
nodes
to the left, right, top, or bottom get picked instead of what I'm
after.
Here is my KDTree Build function:
#ifdef USE_KDTREE
// Update the KDTree
osg::KdTree::BuildOptions kdTreeBuildOptions;
osg::ref_ptrosg::KdTree kdTree = new osg::KdTree();
if(kdTree-build(kdTreeBuildOptions, geometry))
{
geometry-setShape(kdTree.get());
}
else
{
LOG_MSG(logERROR) osg::KdTree::build() unsuccessful.;
}
#endif
Any suggestions?
cheers,
sean
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Reading a node file from http
Hi Andreas, I'm super interested in this work too, keep us posted;) J On Thu, Dec 4, 2008 at 12:19 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hi Andreas, It is working now (see picture below), and I will be OpenSourcing it. I just need to add a way to pass filenames to the plugin. Nice work, though using the URL in the image doesn't work for me (I guess because you didn't put the plugin online so that it can be automatically downloaded by Firefox...) :-) Let us know when it's available, it's a nice thing to have on a web site! J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] 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
[osg-users] Very simple Firefox-Plugin to display osg-files
Hi all,
as posted above in the thread reading a node file from http, I have
assembled a small firefox-plugin to display osg-files.
It is not yet packed, I will have to carefully read the documentation
on how to do this (I would like the plugin to be downloaded
automatically when a user does not have it).
If someone would like to try it:
- it´s windows only, firefox 3.04 only (newer versions should work)
- you must have osg2.7.6 installed, bin-dir in your path. The plugin is
compiled with VC 2005, so maybe only this will work
- download the plugin here:
http://raumgeometrie.de/testplugin/npbasic.dll (it´s so small, not even
worth zipping)
- testpages here: http://www.raumgeometrie.de/testplugin/gallery.html
I attach the source to the plugin. But be aware of the fact, that the
most time-consuming step of building this plugin was to get the
basic-example I started with to compile. I will send a zip with
project-file later on.
Note that the sample-plugins shipped with the firefox-source do use
completely different function-names than those described in the
plugin-api that can be read on the firefox-dev site. I sticked to the
functions named in the sample (and had to research with google for some
things). I don´t know if their own samples are outdated, or if the
api-documentation is outdated or whatever.
The thing that does not (!) work is to put several instances of the
plugin on one page. Maybe robert can jump in and explain how the
window = viewer-setUpViewerAsEmbeddedInWindow(100,100,800,600);
viewer-setSceneData(loadedModel.get());
(which works like next to magic for me)
does find it´s OpenGL-context. Probably this is not so easy when there
is more than one context.
But even if this won´t work, it´s quite a nice plugin so far. Read the
source as an inspiration on how very easy this was - hopefully someone
can jump in and do this for linux and mac.
Regards,
Andreas
/*OpenSceneGraph Firefox-plugin
*License: GPL 2.0
*Based on Work by Mozilla.org and OpenSceneGraph osgviewerGLUT-sample by Robert Osfield
*(c) Andreas Goebel 2008
*/
#include windows.h
#include windowsx.h
#include plugin.h
#include gl/gl.h
#include osgViewer/Viewer
#include osgViewer/ViewerEventHandlers
#include osgGA/TrackballManipulator
#include osgDB/ReadFile
//Global Variables
osg::ref_ptrosgViewer::Viewer viewer;
osg::observer_ptrosgViewer::GraphicsWindow window;
char* filename;
//Functions that translate the Windows Mouse-Events to osg-events
void mousebutton( int button, int state, int x, int y )
{
if (window.valid())
{
if (state==0) window-getEventQueue()-mouseButtonPress( x, y, button+1 );
else window-getEventQueue()-mouseButtonRelease( x, y, button+1 );
}
}
void mousemove( int x, int y )
{
if (window.valid())
{
window-getEventQueue()-mouseMotion( x, y );
}
}
//
//
// general initialization and shutdown
//
NPError NS_PluginInitialize()
{
return NPERR_NO_ERROR;
}
void NS_PluginShutdown()
{
}
/
//
// construction and destruction of our plugin instance object
//
nsPluginInstanceBase * NS_NewPluginInstance(nsPluginCreateData * aCreateDataStruct)
{
if(!aCreateDataStruct)
return NULL;
nsPluginInstance * plugin = new nsPluginInstance(aCreateDataStruct-instance);
filename = aCreateDataStruct-argv[0]; //This structs holds tha value passed to the plugin with embed
return plugin;
}
void NS_DestroyPluginInstance(nsPluginInstanceBase * aPlugin)
{
if(aPlugin)
delete (nsPluginInstance *)aPlugin;
}
//
// nsPluginInstance class implementation
//
nsPluginInstance::nsPluginInstance(NPP aInstance) : nsPluginInstanceBase(),
mInstance(aInstance),
mInitialized(FALSE)
{
mhWnd = NULL;
}
nsPluginInstance::~nsPluginInstance()
{
}
static LRESULT CALLBACK PluginWinProc(HWND, UINT, WPARAM, LPARAM);
static WNDPROC lpOldProc = NULL;
void EnableOpenGL(HWND hWnd, HDC * hDC, HGLRC * hRC);
void DisableOpenGL(HWND hWnd, HDC hDC, HGLRC hRC);
HDC hDC;
HGLRC hRC;
NPBool nsPluginInstance::init(NPWindow* aWindow)
{
if(aWindow == NULL)
return FALSE;
mhWnd = (HWND)aWindow-window;
if(mhWnd == NULL)
return FALSE;
// subclass window so we can intercept window messages and
// do our drawing to it
lpOldProc = SubclassWindow(mhWnd, (WNDPROC)PluginWinProc);
// associate window with our nsPluginInstance object so we can access
// it in the window procedure
SetWindowLong(mhWnd, GWL_USERDATA, (LONG)this);
//we add EnableOpenGL and SetTimer
EnableOpenGL( mhWnd, hDC, hRC );
SetTimer(mhWnd, 0, 1, (TIMERPROC) NULL); // no timer callback
//osg-related code:
//Node-file is read via http by libcurl:
osg::ref_ptrosg::Node loadedModel = osgDB::readNodeFile(filename);
viewer = new osgViewer::Viewer;
window = viewer-setUpViewerAsEmbeddedInWindow(100,100,800,600);
viewer-setSceneData(loadedModel.get());
viewer-setCameraManipulator(new
[osg-users] OSGviewerMFC example issues
Hi, I was looking to use the OSG in what is basically a MFC class for a final project. I downloaded the example from the website but it does not compile properly. The largest issue is the message that is added to make sure the other windows keeps rendering. I get an error that says: error C2665: 'AfxMessageBox' : none of the 2 overloads could convert all the argument types the other error is: error C2664: 'cOSG::InitOSG' : cannot convert parameter 1 from 'const wchar_t *' to 'std::string' I saw a posting a year ago about the second error but no solution was given. I could not find anything mentioning the AfxMessageBox error. I am using visual studios 8 and running OSG 2.2. If anyone could help me with the problem I would be extremely grateful. Thanks in advance, Chris ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSGviewerMFC example issues
Christopher Back wrote on Thursday, December 04, 2008 3:34 PM: Hi, I was looking to use the OSG in what is basically a MFC class for a final project. I downloaded the example from the website but it does not compile properly. The largest issue is the message that is added to make sure the other windows keeps rendering. I get an error that says: error C2665: 'AfxMessageBox' : none of the 2 overloads could convert all the argument types the other error is: error C2664: 'cOSG::InitOSG' : cannot convert parameter 1 from 'const wchar_t *' to 'std::string' I saw a posting a year ago about the second error but no solution was given. I could not find anything mentioning the AfxMessageBox error. I am using visual studios 8 and running OSG 2.2. If anyone could help me with the problem I would be extremely grateful. Thanks in advance, Chris It seems likely that the two are related; probably you need to set the Character Set configuration property (under General) in your Visual Studio project to Not Set; it looks like you're having a clash between multi-character strings and standard C strings. HTH, -- Bryan Thrall FlightSafety International [EMAIL PROTECTED] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenVRML and Windows
Hello, Your version is outdated. Here is an announcement on the latest version from the openvrml mailing list. OpenVRML 0.17.9 is now available. The distribution can be obtained from http://downloads.sourceforge.net/openvrml/openvrml-0.17.9.tar.gz OpenVRML is a C++ runtime library for VRML97 and X3D worlds. It is capable of reading and displaying VRML/X3D; it can be used for creating loaders, file converters, and VRML/X3D browsers. OpenVRML includes an out-of-process viewer component for use in X11 environments along with hosts for this component in the form of a Mozilla browser plug-in and a stand-alone player. You can find OpenVRML on the Web at http://openvrml.org http://openvrml.org/ New in OpenVRML 0.17.9: -Use D-Bus for communication with the OpenVRML XEmbed control. John F. Richardson _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Serge Lages Sent: Monday, December 01, 2008 5:40 AM To: OpenSceneGraph Users Subject: [osg-users] OpenVRML and Windows Hi all, I am currently trying to build the OSG VRML plugin under Windows, so I've downloaded the 0.14.3 version of OpenVRML and tried to build it with VS8 SP1, and it's a real pain... :/ Maybe I've missed something but this version really seems to be broken with modern compilers. That's why I would like to know if anyone already have a compiled version of this lib (build with VS8 SP1) ? Or at least a modified version of the sources which build fine ? Thanks for your help ! -- Serge Lages http://www.tharsis-software.com ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Hi, I have reviewed my own code and realized that, of course, the global variables were no good idea. I was not aware of the fact, that a plugin (the dll) is loaded only once, and each time the plugin is embedded, a new instance of the plugin-class is created. The global variables that live in the dll exist only once, thus it was not possible to display more than one model on a page. I have refactored this, now one can display several models on one page. There are some more issues, but I will work on that tomorrow. Regards, Andreas Screenshot: Two models on one page. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Removing all identical children from a node
Hello, I implemented a dynamic hud manager in c++ whose public member functions are bound to lua. From a lua interface, the user is able to create hud elements, and hud element groups; in addition controls are given to disable both groups and individual hud elements. This logic works fine, however a problem comes in when trying to enable an element or group that is already in the scene--two copies now exist. It seems like quite a bit of overhead to track whether or not each individual group and element is in the scene; is there some way to remove -all- children that share the same reference pointer? By executing removeChild( ptr ), it only removes the most recent addition. Thanks in advance, Dusten ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Very simple Firefox-Plugin to display osg-files
Thanks for your contributions! I'm really eager to see what projects will use this plugin of yours. It would be a great way of attracting new developers to OSG if they could check out demos online :) On Thu, Dec 4, 2008 at 4:08 PM, Andreas Goebel [EMAIL PROTECTED] wrote: Hi, I have reviewed my own code and realized that, of course, the global variables were no good idea. I was not aware of the fact, that a plugin (the dll) is loaded only once, and each time the plugin is embedded, a new instance of the plugin-class is created. The global variables that live in the dll exist only once, thus it was not possible to display more than one model on a page. I have refactored this, now one can display several models on one page. There are some more issues, but I will work on that tomorrow. Regards, Andreas Screenshot: Two models on one page. ___ 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编程入门指南》
For the curious (I was) these charts are interesting: http://www2.ignatius.edu/faculty/turner/worldlang.htm The power of google... the I wonder how different the numbers really are... questions can be answered with no effort. :) -Paul Ümit Uzun wrote: Hi Rui. You are right :) I would learn most spoken Language all over the World which is Chinese! But at the mean time I think that, it's so easier writing this book in my own language Turkish than learning Chinese :) However thanks so much for your advice ;) Regards. 2008/12/2 Wang Rui [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi Ümit, Why not start to learn Chinese. I believe there are many Getting Started with Chinese books. :-D Best Wishes Wang Rui 2008/12/2 Ümit Uzun [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Hi FlySky, I tried to look website but unfortunately I don't understand any word :) I think there is only Chinese edition. And I believe that, Chinese edition can be read by much more people than English all over the world :) But we can't ;( Regards. ___ 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 -- Ümit Uzun ___ 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] OpenVRML and Windows
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John F. Richardson wrote: Hello, Your version is outdated. Here is an announcement on the latest version from the openvrml mailing list. OpenVRML 0.17.9 is now available. The distribution can be obtained from Hello, The OpenVRML plugin will not build with anything later than 0.14.3 due to changed API and dependency on Boost. This is intentional. Upgrading to 0.17.9 will *not* help. The compilation issues with 0.14.3 are described here (minor updates for modern compilers): http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/Linux It is described for Linux, but that patch should make OpenVRML compile fine. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJOGSkn11XseNj94gRAusxAJ96ZatpgKjQK0YROtV32oHb2koVugCg7fZq P17ecXWiDA2OAyXC0Ljp+fk= =IRoo -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] osgviewerQT example
The osgviewerQT example with the --QOSGWidget option has exposed some problems at the juction of OSG and the windowing system. I was aware of a problem running this on Mac OS X for a couple of weeks, but didn't pay much attention to it. I spent some time testing on a variey of Linux systems and found a problem there too. Please note I'm running OSG version 2.6.0. On Mac OS X osgviewerQT crashes after getting a BadWindow error from XGetWindowAttributes when called by osgViewer::GraphicsWindowX11::setWindow. The window attributes are garbage values. More curious, I tested two nearly identical systems and the example run OK on one and crashed on the other. $ osgviewerQT cow.osg --QOSGWidget --CompositeViewer --- OK on system 1 --- Fedora w/2.6.9-5.ELsmp kernel OpenGL renderer string: Quadro FX 3450/4000 SDI/PCI/SSE2 OpenGL version string: 2.1.1 NVIDIA 100.14.19 --- Crashes on system 2 --- Fedora w/2.6.9-5.ELsmp kernel OpenGL renderer string: Quadro FX 3450/4000 SDI/PCI/SSE2 OpenGL version string: 2.0.0 NVIDIA 76.76 Program received signal SIGABRT, Aborted. 0x004417a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 (gdb) where #0 0x004417a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x00a6d955 in raise () from /lib/tls/libc.so.6 #2 0x00a6f319 in abort () from /lib/tls/libc.so.6 #3 0x0054d557 in __cxa_call_unexpected () from /usr/lib/libstdc++.so.5 #4 0x0054d5a4 in std::terminate () from /usr/lib/libstdc++.so.5 #5 0x0054d716 in __cxa_throw () from /usr/lib/libstdc++.so.5 #6 0x00503e33 in std::__throw_logic_error () from /usr/lib/libstdc++.so.5 #7 0x00540fc2 in std::string::_M_replace_safechar const* () from /usr/lib/libstdc++.so.5 #8 0x0053d894 in std::basic_stringchar, std::char_traitschar, std::allocatorchar ::basic_string () from #/usr/lib/libstdc++.so.5 #9 0x00fdf661 in osg::getGLVersionNumber () at /usr/osg/OpenSceneGraph-2.6.0/src/osg/GLExtensions.cpp:47 #10 0x010adf34 in osg::State::initializeExtensionProcs (this=0x9196ce8) at #/usr/osg/OpenSceneGraph-2.6.0/src/osg/State.cpp:757 #11 0x00961c1f in osgUtil::SceneView::draw (this=0x919d898) at #/usr/osg/OpenSceneGraph-2.6.0/src/osgUtil/SceneView.cpp:988 #12 0x0063dd6a in osgViewer::Renderer::cull_draw (this=0x919d6d8) at #/usr/osg/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:535 #13 0x0063e83f in osgViewer::Renderer::operator() (this=0x919d6d8, context=0x90e79f8) at #/usr/osg/OpenSceneGraph-2.6.0/src/osgViewer/Renderer.cpp:636 #14 0x01028521 in osg::GraphicsContext::runOperations (this=0x90e79f8) at #/usr/osg/OpenSceneGraph-2.6.0/src/osg/GraphicsContext.cpp:688 #15 0x00685289 in osgViewer::ViewerBase::renderingTraversals (this=0x90e6b88) at #/usr/osg/OpenSceneGraph-2.6.0/src/osgViewer/ViewerBase.cpp:694 #16 0x00684a80 in osgViewer::ViewerBase::frame (this=0x90e6b88, simulationTime=1.7976931348623157e+308) at #/usr/osg/OpenSceneGraph-2.6.0/src/osgViewer/ViewerBase.cpp:592 #17 0x0805b4c7 in CompositeViewerQOSG::paintEvent (this=0x90e6b88, event=0xbff758c0) at #/usr/osg/OpenSceneGraph-2.6.0/examples/osgviewerQT/QOSGWidget.cpp:296 #18 0x0350c0bc in QWidget::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #19 0x034778f9 in QApplication::internalNotify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #20 0x03477a8a in QApplication::notify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #21 0x03445f4c in QWidget::repaint () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #22 0x03507e0b in QWidget::repaint () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #23 0x0380ac13 in QWidget::qt_invoke () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #24 0x034d6450 in QObject::activate_signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #25 0x034d6b2a in QObject::activate_signal () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #26 0x0380929d in QTimer::timeout () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #27 0x034f615c in QTimer::event () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #28 0x034778f9 in QApplication::internalNotify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #29 0x03477a8a in QApplication::notify () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #30 0x0346bc6e in QEventLoop::activateTimers () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #31 0x03427c2e in QEventLoop::processEvents () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #32 0x0348cf25 in QEventLoop::enterLoop () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #33 0x0348ce7e in QEventLoop::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #34 0x03476afb in QApplication::exec () from /usr/lib/qt-3.3/lib/libqt-mt.so.3 #35 0x08058ac3 in mainQOSGWidget ([EMAIL PROTECTED], [EMAIL PROTECTED]) at #/usr/osg/OpenSceneGraph-2.6.0/examples/osgviewerQT/QOSGWidget.cpp:383 #36 0x0805e927 in main (argc=2, argv=0xbff76184) at #/usr/osg/OpenSceneGraph-2.6.0/examples/osgviewerQT/osgviewerQT.cpp:51 (gdb) Is the driver on system 2 known to be buggy? I saw the thread on the affect of the locale setting on getGLVersionNumber, but I don't think that's the problem here. Local is LC_ALL=C on both of these systems. I'll be glad to provide more
[osg-users] dynamic LOD
Quick question: is there an (out-of-the-box) osg program/nodekit that does dynamic level-of-detail? I just want to run some comparisons on image quality, so all it has to do is dynamically decimate a very large single-object model (possibly with a preprocessed tree structure, of course), as opposed to do doing it statically beforehand and then choosing one. I know osg can do that based on distance etc, but that's not what I'm after. -- 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] Attaching Nodes (Characters Objects)
Well i have to admit i'm embarrassed here. I've been loading animated models without bones to experiment with controlling the animation. In light of this, i've only been using osgDB::readNodeFile(). Now that I need to load a model with bones i need osgAnimation support (at least this is my understanding). However, with the current svn build i have, the dynamic cast osgAnimation::AnimationManager *am = dynamic_castosgAnimation::AnimationManager*(osgDB::readNodeFile(file.osg)); doesn't work. am comes back as a null object. what am i doing wrong? this is driving me crazy! Thanks again for everyone's help. On Tue, Dec 2, 2008 at 3:00 PM, Ryan Morris [EMAIL PROTECTED] wrote: It's a skinned mesh with bones. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Attaching Nodes (Characters Objects)
Hy Ryan Of course do not use dynamic_cast directly, because you model is not an AnimationManager node. You may have a look at the osganimation* examples to gain concepts of the new osgAnimation library. The latest SVN version of OSG accepts .bvh file for constructing bones, but you should add each part of your model as bones' children yourself. There is no easy way to create animated skeleton models at present. Regards, Wang Rui 2008/12/5 Ryan Morris [EMAIL PROTECTED] Well i have to admit i'm embarrassed here. I've been loading animated models without bones to experiment with controlling the animation. In light of this, i've only been using osgDB::readNodeFile(). Now that I need to load a model with bones i need osgAnimation support (at least this is my understanding). However, with the current svn build i have, the dynamic cast osgAnimation::AnimationManager *am = dynamic_castosgAnimation::AnimationManager*(osgDB::readNodeFile(file.osg)); doesn't work. am comes back as a null object. what am i doing wrong? this is driving me crazy! Thanks again for everyone's help. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] computeIntersections Bug + Fix (was View::computeIntersections with a node path)
Hi, could you please send the complete file to osg-submissions. See here http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol jp Tanguy Fautre wrote: Hi, I think I found the bug. Fixed implementation attached. If you look at the implementation of the function osgViewer::View::computeIntersections() taking the nodepath argument, you'll see that it compute the LocalToWorld transformation using the complete given path. But this is incorrect if the last node of the path is a transformation. In which case the last transformation is applied twice before computing any intersections. I've currently copy/pasted the current implementation and changed it to a standalone function so that I could test and use it as a fixed version without modifying OSG code. See attachment. The two important lines are: const osg::NodePath shortPath(nodePath.begin(), nodePath.end() - 1); osg::Matrix matrix = osg::computeLocalToWorld(shortPath) * camera-getViewMatrix() * camera-getProjectionMatrix(); Robert, if you agree with these modifications, what should I do for them to be integrated back into the trunk? Cheers, Tanguy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tanguy Fautre Sent: Friday 28 November 2008 15:21 To: osg-users@lists.openscenegraph.org Cc: Neil Groves Subject: Spam: [osg-users] View::computeIntersections with a node path Hi, Has anyone been able to successfully use osgViewer::View::computeIntersections() taking a node path argument on a non-trivial scenegraph? I currently have a fairly complex scenegraph, but I only want a small part of it to collide with computeIntersections. When I use computeIntersections without the nodepath, everything works perfectly. But as soon as I use the overload with the node path, I get an empty intersection set. I'm pretty sure the node path I'm giving is correct. Looking at the implementation of computeIntersections() with the node path, the only thing that puzzles me is the use of osg::computeWorldToLocal(nodePath) before computing the matrix inverse, I'm not sure I fully understand why this is the case. It seems to me the whole operation should be LocalToWorldMatrix * ViewMatrix * ProjectionMatrix instead. In any case, if anyone has a working example (which would show computeIntersections() with a node path is working correctly, or help finding the mistake I'm doing), it would be appreciated. Regards, Tanguy ___ 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 -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
