Re: [osg-users] Little ray-tracing example using the KD-tree
Very tidy I like it! Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: 15 July 2008 22:51 To: OpenSceneGraph Users Subject: [osg-users] Little ray-tracing example using the KD-tree Hi all, Here's a small thingy that (ab)uses the new intersection code to do ray tracing, for a single viewpoint (i.e. not interactive) with shadows. See the attached screenshots for normal OSG rendering versus ray-traced rendering. See the source for a few instructions on use. Bye, Paul* To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html *___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem setting a skydome
David, thank you very much for your help so far. What you say sounds sensible, however I think my implementation still has bugs, because it behaves differently on several computers (one works, the other don't). What I have so far is: // root - camera - clearnode - skydome // |-- rest_of_scene osg::Camera *camera = new osg::Camera; osg::ClearNode* clearNode = new osg::ClearNode; clearNode-setRequiresClear(false); clearNode-addChild(SkydomeSubgraphNode.get()); camera-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR); camera-addChild(clearNode); camera-setRenderOrder(osg::Camera::PRE_RENDER); root-addChild(camera); osg::StateSet* stateset = SkydomeSubgraphNode-getOrCreateStateSet(); osg::TexEnv* te = new osg::TexEnv; te-setMode(osg::TexEnv::REPLACE); stateset-setTextureAttributeAndModes(0, te, osg::StateAttribute::ON); stateset-setMode( GL_LIGHTING, osg::StateAttribute::OFF ); stateset-setMode( GL_CULL_FACE, osg::StateAttribute::ON ); osg::Depth* depth = new osg::Depth; depth-setFunction(osg::Depth::ALWAYS); depth-setRange(1.0,1.0); stateset-setAttributeAndModes(depth, osg::StateAttribute::ON ); does something look weird to you? Thank you, Alberto El Martes 15 Julio 2008ES 10:32:55 David Spilling escribió: Alberto, skydome-setComputeNearFarMode(osg::CullSettings::DO_NOT_COMPUTE_NEAR_FAR ). a class osg::Camera inherits from Sorry - missed a step. Put a Camera in above your skydome. A solution that comes to my mind is to use a pair of cameras, one rendering the skydome with the setting you said, DO_NOT_COMPUTE_NEAR_FAR, and the other rendering the rest of the scene. Exactly. That's what I do (although I control a bunch of other stuff in the camera, like projection matrix, in order to avoid the later issues). David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Little ray-tracing example using the KD-tree
Hi, get the code i wrote (kdTree challenge...) , then you will have also shadows :-) and multi-thread support :-) /regards adrian 2008/7/16 Kim C Bale [EMAIL PROTECTED]: Very tidy I like it! Kim. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Paul Melis Sent: 15 July 2008 22:51 To: OpenSceneGraph Users Subject: [osg-users] Little ray-tracing example using the KD-tree Hi all, Here's a small thingy that (ab)uses the new intersection code to do ray tracing, for a single viewpoint (i.e. not interactive) with shadows. See the attached screenshots for normal OSG rendering versus ray-traced rendering. See the source for a few instructions on use. Bye, Paul * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug Resolution List for 2.6 [Was: osgWidget now checked into OSG SVN trunk]
Hi all,
We have a BugResolution page on the wiki, I'd suggest putting
outstanding bugs on here, we can then work out which ones will be
possible to resolve before 2.6 and what ones will have to be tackled
after. Later this evening I'll add general OSG bugs that I haven't
resolved yet.
http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/BugResolution
One bug that I'd like to see fixed before the 2.6 release is that
osgSim::ShapeAttributeList is _not_ serialized in .ive files, only for
.osg files.
Steps to reproduce bug using attached sample file:
% cat ShapeAttributeListSample.osg
Geode {
name ShapeAttributeListSample.osg
UserData {
osgSim::ShapeAttributeList {
string cntry_name New Zealand
intcolormap 6
string curr_code NZD
string curr_type NZ Dollar
string fips_cntry NZ
string gmi_cntry NZL
string iso_2digit NZ
string iso_3digit NZL
string landlocked N
string long_name New Zealand
intpop_cntry 3528197
string sovereign New Zealand
double sqkm 268341
double sqmi 103606
}
}
nodeMask 0x
cullingActive TRUE
num_drawables 0
}
% osgconv ShapeAttributeListSample.osg faulty.ive
% osgconv faulty.ive faulty.osg
% cat faulty.osg
Geode {
name ShapeAttributeListSample.osg
nodeMask 0x
cullingActive TRUE
num_drawables 0
}
Best regards,
John Larring
Robert Osfield wrote:
Hi Jeremy,
On Tue, Jul 15, 2008 at 7:46 PM, Jeremy Moles [EMAIL PROTECTED] wrote:
There are some remaining focus list bugs I'm working on...
We have a BugResolution page on the wiki, I'd suggest putting
outstanding bugs on here, we can then work out which ones will be
possible to resolve before 2.6 and what ones will have to be tackled
after. Later this evening I'll add general OSG bugs that I haven't
resolved yet.
http://www.openscenegraph.org/projects/osg/wiki/Community/Tasks/BugResolution
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Best regards,
John
WeatherOne
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Geode {
name ShapeAttributeListSample.osg
UserData {
osgSim::ShapeAttributeList {
string cntry_name New Zealand
intcolormap 6
string curr_code NZD
string curr_type NZ Dollar
string fips_cntry NZ
string gmi_cntry NZL
string iso_2digit NZ
string iso_3digit NZL
string landlocked N
string long_name New Zealand
intpop_cntry 3528197
string sovereign New Zealand
double sqkm 268341
double sqmi 103606
}
}
nodeMask 0x
cullingActive TRUE
num_drawables 0
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading a 3D texture with osgDB::ReadFile method
Hi Franclin, You simple do: osg::ref_ptrosg::Image image = osgDB::readImageFile(my3dtexture.dds); Then apply this image to your osg::Texture3D as you would any other texture. Robert. On Wed, Jul 16, 2008 at 2:15 PM, Franclin Foping [EMAIL PROTECTED] wrote: Dear All, I am just wondering if it is possible to load a 3D texture with the osgDB::ReadFile method? I would like to be able to use the Data() method of the Image class to retrieve the data of the 3D texture for each stack of the texture. Is it possible? Or is there is any way around it? I am looking forward to hearing from you. Regards, Franclin. _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr ___ 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] Little ray-tracing example using the KD-tree
Adrian Egli OpenSceneGraph (3D) wrote: Hi, get the code i wrote (kdTree challenge...) , then you will have also shadows :-) and multi-thread support :-) I didn't notice your challenge was about ray-tracing. Interesting way of transitioning from OSG rendering to raytraced rendering. It looks like you put in a lot of effort to handle materials and such correctly, so that the raytraced version comes close to realtime rendering. Or am I misunderstanding the two modes of rendering and is the one during interaction also raytraced, but without shadows and only simple shading? Paul /regards adrian 2008/7/16 Kim C Bale [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Very tidy I like it! Kim. -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] On Behalf Of Paul Melis Sent: 15 July 2008 22:51 To: OpenSceneGraph Users Subject: [osg-users] Little ray-tracing example using the KD-tree Hi all, Here's a small thingy that (ab)uses the new intersection code to do ray tracing, for a single viewpoint (i.e. not interactive) with shadows. See the attached screenshots for normal OSG rendering versus ray-traced rendering. See the source for a few instructions on use. Bye, Paul * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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 -- Adrian Egli ___ 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] Further Design Question: KDTree
Hi Robert,
I understand your comment really well, and w.r.t. to building performance
this is true. for all paged database the building performance is much more
important then the intersection check. Especially for terrain rendering.
The question is how we can design the kdTree build for most application
working
with max performance. Either we reimplement a second, third, .. kdTree class
or we use the
BuildOptions for the decision how the tree should be constructed.
For each application it can be different, event for different geometries we
can have different builds.
Actually we have a new member in osgDB::Registry to define the KdTreeBuilder
with it's option and
the kdTree prototype. If we assume that each user can has he's own kdTree,
then the option
would no longer be needed, because we can handle the different techniques in
the kdTree
subclasses. So should we think this way, or should we think in combination.
We could
use our own inherited kdTree classes for own modifications, and we could
implement in the default
kdTree class some common building techniques. May the user can handle the
building by a simple enumeration
in the buidling option, like { FAST_BUILD , CENTER_TOPOLOGY_ALIGNED ,
..., SAH , .. }
or what would be best design ?
i am aware of the real time openGL rendering, and for what we use the line
intersection check. and i am also aware
that each kdTree tuning is 'overhead' for current applications. but may for
collision checks, and so on, we can get
better performance linearly to the kdTree perf win in each optimisation we
do.
/adrian
2008/7/16 Robert Osfield [EMAIL PROTECTED]:
Hi Adrian,
I have just done a review of your latest KdTree, and now understand
the optimization - it's actually one I considered too, but didn't
implement out of concern of build performance. Your results suggest
the the new bb compute code adds a further 50% in build time over the
previous technique, you don't mention the performance figures. A 50%
hit on build time is not good news for people who are paging
databases. The performance improvement on intersection also needs to
be put in the context of how the
IntersectionVisitor/
LineSegmenetIntersector are used typically, as the
costs of scene graph traversal typically swap that of KdTree traversal
so a 50% improvement in KdTree might only give us 5% improvement, alas
the build time is far less swamped by scene graph traversal.
I think the best one could do to try and balance things for different
usages - would be to either have different KdTree subclasses or have
different build/intersect algorithms that are chosen by KdTree
options. Note, we already have a KdTree::BuildOptions object that is
passed into the build option already - this could be used to provide
hints on whether quick builds vs slower builds that optimize
intersections should be preferred.
Robert.
On Wed, Jul 16, 2008 at 8:46 AM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] wrote:
Hi Robert,
This morning i was about 1hour in train, and reviewed again the kdTree
implementation. Yesterday i wrote that the kdTree has some strange
behaviour
when triangles have equal center points. yes this is still true, and we
can
(as you told) ignore such bad geometries. but one thing i worked out is
that
the kdTree isn't oriented to the geometry topology, assume we have a
torus
like box, then the bounding boxes are far away from a optional
kdTree-based
bounding box hierarchy. for line intersection checks this is not as bad
as
it sounds, but for further more complex checks, like polytop
intersection,
haptic rendering this will turn in a more expensive overhead. so i
propose
to use the latest code, with the ADRIAN_DIVIDE_BB_FIX define switch on.
to compare the kdTree, performance, nodes, leafs, i added some statistics
to
the code: #define VERBOSE_OUTPUT_TREE_INFO
the building time still fast enough, but of course no for free :-(, the
tree
is smaller. he is not just smaller, it's more correct w.r.t kdTree
spatial
datastructure / bounding hierarchy.
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] Little ray-tracing example using the KD-tree
Hi Paul i just read back (z-Buffer) and trace for each pixel in the final frame a ray into the scene for shadow trace. :-) then i blend the shadow map and the frame buffer (color) for the final rendering :-) /adrian 2008/7/16 Paul Melis [EMAIL PROTECTED]: Adrian Egli OpenSceneGraph (3D) wrote: Hi, get the code i wrote (kdTree challenge...) , then you will have also shadows :-) and multi-thread support :-) I didn't notice your challenge was about ray-tracing. Interesting way of transitioning from OSG rendering to raytraced rendering. It looks like you put in a lot of effort to handle materials and such correctly, so that the raytraced version comes close to realtime rendering. Or am I misunderstanding the two modes of rendering and is the one during interaction also raytraced, but without shadows and only simple shading? Paul /regards adrian 2008/7/16 Kim C Bale [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Very tidy I like it! Kim. -Original Message- From: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] On Behalf Of Paul Melis Sent: 15 July 2008 22:51 To: OpenSceneGraph Users Subject: [osg-users] Little ray-tracing example using the KD-tree Hi all, Here's a small thingy that (ab)uses the new intersection code to do ray tracing, for a single viewpoint (i.e. not interactive) with shadows. See the attached screenshots for normal OSG rendering versus ray-traced rendering. See the source for a few instructions on use. Bye, Paul * To view the terms under which this email is distributed, please go to http://www.hull.ac.uk/legal/email_disclaimer.html * ___ 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 -- Adrian Egli ___ 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 -- Adrian Egli ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Configure error on Sun Solaris machine
Hello Robert; I have found the error, and after correcting it, I now have OSG 2.4 configured and built on a Solaris 10 machine, after making a few edits in the socket plugins. The problem stemmed from the fact that there were a few linux wxWidgets binaries in my path, which were causing the configure to fail. I removed them from the path, and re-configured. I am using cmake 2.6, patch 0 on the Solaris machine with no issues. OSG configured fine. After the configure had generated the makefiles, I had a few problems in the source code for the net plugins. I had to edit src/osgPlugins/net/sockinet.cpp and src/osgPlugins/net/sockstream.cpp to go around the #define that was renaming socklen_t to int. After the edits were made, I tried a build, and now have OSG 2.4 up and running on a Solaris 10 Sparc machine. Thanks to Jean-Sebastien and yourself for all of the help. Lenny -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, July 14, 2008 4:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Configure error on Sun Solaris machine HI Leonard, Could you try the SVN or 2.5.4 developer version of the OSG 2.4 and before doesn't work with CMake 2.6 due to small incompatibilities between the 2.4.x and 2.6 releases and the OSG's previous CMake files. Robert. On Mon, Jul 14, 2008 at 5:29 PM, Smith, Leonard C [EMAIL PROTECTED] wrote: Dear Jean-Sebastien; I myself haven't seen this error when building on Linux. I am using Cmake version 2.6 on a Sun box. I will look into the CMakeModules directory, and see if this helps, thank you. I agree that it would be very helpful if Cmake were a little more verbose while processing. I have worked a lot with gmake and GNUmakefiles over the years, and have on occasion found gmake -dnp to be the only way to diagnose a problem. Thank you again for your help, Lenny Smith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, July 14, 2008 11:13 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Configure error on Sun Solaris machine Hello Leonard, There is no FOREACH statement in my CMakeLists.txt file. Where does this error come from? I do not use Solaris, so I can only suggest a few paths for you to investigate. First of all, what version of CMake are you using? The FOREACH statements are probably coming from the files included from the CMakeModules subdirectory. As to where the erroneous FOREACH statement is coming from, it would be useful if CMake would tell you which macro or function it was processing when it got the error... In any case, I haven't seen that error when generating build files for OSG (neither on Windows nor on Linux) which is why I suspect it's a CMake version problem. 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 ___ 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] osgLua and my own classes
Hi all, I want to use my own C++ classes in addition to those of OSG in my Lua scripts and I read in the README of OsgLua : osgLua can also be used to access your own reflected classes (with osgWrapper) but I am wondering how to do that, there is no example. Must I parse my classes with genparser ? And after ? Thanks you. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Further Design Question: KDTree
Hi Adrian,
If the alternate KdTree algorithms can be easily managed as an enum
for build and intersections then this would be a relatively easy way
to go, but... it's more intrusive w.r.t the core KdTree
implementation, which means there needs to be more interaction with
myself to get things tested and merged.
The extensible approach I've taken with osg::KdTree is meant to help
alternate implementations are easy to develop separately from the core
OSG, and then later merged if appropriate/once the implementation
settles down.
I'd suggest one takes advantage of the extensibility when developing
new KdTree build/intersection algorithms, then when an implementation
looks like its well worth merging with the core we can add an enum
into core KdTree implementation.
With a stable release imminent it's important that I focus on this,
rather than get drawn in protected discussions about a single
particular topic - the KdTree extensibility offers the opportunity for
these alternate versions to be developed without dragging me into all
the details.
Robert.
On Wed, Jul 16, 2008 at 3:40 PM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] wrote:
Hi Robert,
I understand your comment really well, and w.r.t. to building performance
this is true. for all paged database the building performance is much more
important then the intersection check. Especially for terrain rendering.
The question is how we can design the kdTree build for most application
working
with max performance. Either we reimplement a second, third, .. kdTree class
or we use the
BuildOptions for the decision how the tree should be constructed.
For each application it can be different, event for different geometries we
can have different builds.
Actually we have a new member in osgDB::Registry to define the KdTreeBuilder
with it's option and
the kdTree prototype. If we assume that each user can has he's own kdTree,
then the option
would no longer be needed, because we can handle the different techniques in
the kdTree
subclasses. So should we think this way, or should we think in combination.
We could
use our own inherited kdTree classes for own modifications, and we could
implement in the default
kdTree class some common building techniques. May the user can handle the
building by a simple enumeration
in the buidling option, like { FAST_BUILD , CENTER_TOPOLOGY_ALIGNED ,
..., SAH , .. }
or what would be best design ?
i am aware of the real time openGL rendering, and for what we use the line
intersection check. and i am also aware
that each kdTree tuning is 'overhead' for current applications. but may for
collision checks, and so on, we can get
better performance linearly to the kdTree perf win in each optimisation we
do.
/adrian
2008/7/16 Robert Osfield [EMAIL PROTECTED]:
Hi Adrian,
I have just done a review of your latest KdTree, and now understand
the optimization - it's actually one I considered too, but didn't
implement out of concern of build performance. Your results suggest
the the new bb compute code adds a further 50% in build time over the
previous technique, you don't mention the performance figures. A 50%
hit on build time is not good news for people who are paging
databases. The performance improvement on intersection also needs to
be put in the context of how the
IntersectionVisitor/
LineSegmenetIntersector are used typically, as the
costs of scene graph traversal typically swap that of KdTree traversal
so a 50% improvement in KdTree might only give us 5% improvement, alas
the build time is far less swamped by scene graph traversal.
I think the best one could do to try and balance things for different
usages - would be to either have different KdTree subclasses or have
different build/intersect algorithms that are chosen by KdTree
options. Note, we already have a KdTree::BuildOptions object that is
passed into the build option already - this could be used to provide
hints on whether quick builds vs slower builds that optimize
intersections should be preferred.
Robert.
On Wed, Jul 16, 2008 at 8:46 AM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] wrote:
Hi Robert,
This morning i was about 1hour in train, and reviewed again the kdTree
implementation. Yesterday i wrote that the kdTree has some strange
behaviour
when triangles have equal center points. yes this is still true, and we
can
(as you told) ignore such bad geometries. but one thing i worked out is
that
the kdTree isn't oriented to the geometry topology, assume we have a
torus
like box, then the bounding boxes are far away from a optional
kdTree-based
bounding box hierarchy. for line intersection checks this is not as bad
as
it sounds, but for further more complex checks, like polytop
intersection,
haptic rendering this will turn in a more expensive overhead. so i
propose
to use the latest code, with the ADRIAN_DIVIDE_BB_FIX define switch on.
to
Re: [osg-users] Further Design Question: KDTree
Just a note on this topic...
Adrian Egli OpenSceneGraph (3D) wrote:
I understand your comment really well, and w.r.t. to building performance
this is true. for all paged database the building performance is much more
important then the intersection check. Especially for terrain rendering.
I haven't looked in detail what splitting method the current KD-tree
implementation uses, but the binning algorithm in section 3 of [1]
seems to provide quite a good trade-off between tree quality and build
time, while being fairly simple to implement. They basically use a
clever coarse-grained SAH evaluation for the upper part of the tree and
switch to full SAH for nodes with a small number of primitives. The
parallel in the title does not apply to that section, although the
authors have gone quite far in doing parallel tree building.
And if low build times is really the main goal for the intersection
structure, especially for paged databases, then an alternative structure
to a KD-tree might be worth exploring. Bounding volume hierarchies are
awefully fast to construct, at the cost of having some problems with
models containing wildly different sized primitives. But even for the
latter problem solutions are beginning to emerge, e.g. the edge volume
heuristic ([2]).
[1] Highly parallel fast kd-tree construction for interactive ray
tracing of dynamic scenes (kesen.huang.googlepages.com/Intel-EG07.pdf)
[2] The Edge Volume Heuristic - Robust Triangle Subdivision for
Improved BVH Performance
In case any students are looking for an interesting topic, I suspect
trying out the different options would make for a great master's thesis...
Paul
The question is how we can design the kdTree build for most
application working
with max performance. Either we reimplement a second, third, .. kdTree
class or we use the
BuildOptions for the decision how the tree should be constructed.
For each application it can be different, event for different
geometries we can have different builds.
Actually we have a new member in osgDB::Registry to define the
KdTreeBuilder with it's option and
the kdTree prototype. If we assume that each user can has he's own
kdTree, then the option
would no longer be needed, because we can handle the different
techniques in the kdTree
subclasses. So should we think this way, or should we think in
combination. We could
use our own inherited kdTree classes for own modifications, and we
could implement in the default
kdTree class some common building techniques. May the user can handle
the building by a simple enumeration
in the buidling option, like { FAST_BUILD , CENTER_TOPOLOGY_ALIGNED
, ..., SAH , .. }
or what would be best design ?
i am aware of the real time openGL rendering, and for what we use the
line intersection check. and i am also aware
that each kdTree tuning is 'overhead' for current applications. but
may for collision checks, and so on, we can get
better performance linearly to the kdTree perf win in each
optimisation we do.
/adrian
2008/7/16 Robert Osfield [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Hi Adrian,
I have just done a review of your latest KdTree, and now understand
the optimization - it's actually one I considered too, but didn't
implement out of concern of build performance. Your results suggest
the the new bb compute code adds a further 50% in build time over the
previous technique, you don't mention the performance figures. A 50%
hit on build time is not good news for people who are paging
databases. The performance improvement on intersection also needs to
be put in the context of how the
IntersectionVisitor/
LineSegmenetIntersector are used typically, as the
costs of scene graph traversal typically swap that of KdTree traversal
so a 50% improvement in KdTree might only give us 5% improvement, alas
the build time is far less swamped by scene graph traversal.
I think the best one could do to try and balance things for different
usages - would be to either have different KdTree subclasses or have
different build/intersect algorithms that are chosen by KdTree
options. Note, we already have a KdTree::BuildOptions object that is
passed into the build option already - this could be used to provide
hints on whether quick builds vs slower builds that optimize
intersections should be preferred.
Robert.
On Wed, Jul 16, 2008 at 8:46 AM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hi Robert,
This morning i was about 1hour in train, and reviewed again the
kdTree
implementation. Yesterday i wrote that the kdTree has some
strange behaviour
when triangles have equal center points. yes this is still true,
and we can
(as you told) ignore such bad geometries. but one thing i worked
out is that
the kdTree isn't oriented to the geometry topology, assume we
have a torus
like box, then the
Re: [osg-users] Further Design Question: KDTree
By the way, I just took a quick look at the current KD-tree implementation.
Am I seeing misreading the code or do tree nodes currently store a full
bounding box instead of just the appropriate split plane and its value
on the split axis?
Intersection also seems to do a test against a bounding box...
Paul
Paul Melis wrote:
Just a note on this topic...
Adrian Egli OpenSceneGraph (3D) wrote:
I understand your comment really well, and w.r.t. to building
performance
this is true. for all paged database the building performance is much
more
important then the intersection check. Especially for terrain rendering.
I haven't looked in detail what splitting method the current KD-tree
implementation uses, but the binning algorithm in section 3 of [1]
seems to provide quite a good trade-off between tree quality and build
time, while being fairly simple to implement. They basically use a
clever coarse-grained SAH evaluation for the upper part of the tree
and switch to full SAH for nodes with a small number of primitives.
The parallel in the title does not apply to that section, although
the authors have gone quite far in doing parallel tree building.
And if low build times is really the main goal for the intersection
structure, especially for paged databases, then an alternative
structure to a KD-tree might be worth exploring. Bounding volume
hierarchies are awefully fast to construct, at the cost of having some
problems with models containing wildly different sized primitives. But
even for the latter problem solutions are beginning to emerge, e.g.
the edge volume heuristic ([2]).
[1] Highly parallel fast kd-tree construction for interactive ray
tracing of dynamic scenes (kesen.huang.googlepages.com/Intel-EG07.pdf)
[2] The Edge Volume Heuristic - Robust Triangle Subdivision for
Improved BVH Performance
In case any students are looking for an interesting topic, I suspect
trying out the different options would make for a great master's
thesis...
Paul
The question is how we can design the kdTree build for most
application working
with max performance. Either we reimplement a second, third, ..
kdTree class or we use the
BuildOptions for the decision how the tree should be constructed.
For each application it can be different, event for different
geometries we can have different builds.
Actually we have a new member in osgDB::Registry to define the
KdTreeBuilder with it's option and
the kdTree prototype. If we assume that each user can has he's own
kdTree, then the option
would no longer be needed, because we can handle the different
techniques in the kdTree
subclasses. So should we think this way, or should we think in
combination. We could
use our own inherited kdTree classes for own modifications, and we
could implement in the default
kdTree class some common building techniques. May the user can handle
the building by a simple enumeration
in the buidling option, like { FAST_BUILD ,
CENTER_TOPOLOGY_ALIGNED , ..., SAH , .. }
or what would be best design ?
i am aware of the real time openGL rendering, and for what we use the
line intersection check. and i am also aware
that each kdTree tuning is 'overhead' for current applications. but
may for collision checks, and so on, we can get
better performance linearly to the kdTree perf win in each
optimisation we do.
/adrian
2008/7/16 Robert Osfield [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]:
Hi Adrian,
I have just done a review of your latest KdTree, and now understand
the optimization - it's actually one I considered too, but didn't
implement out of concern of build performance. Your results suggest
the the new bb compute code adds a further 50% in build time over the
previous technique, you don't mention the performance figures. A 50%
hit on build time is not good news for people who are paging
databases. The performance improvement on intersection also needs to
be put in the context of how the
IntersectionVisitor/
LineSegmenetIntersector are used typically, as the
costs of scene graph traversal typically swap that of KdTree
traversal
so a 50% improvement in KdTree might only give us 5% improvement,
alas
the build time is far less swamped by scene graph traversal.
I think the best one could do to try and balance things for
different
usages - would be to either have different KdTree subclasses or have
different build/intersect algorithms that are chosen by KdTree
options. Note, we already have a KdTree::BuildOptions object
that is
passed into the build option already - this could be used to provide
hints on whether quick builds vs slower builds that optimize
intersections should be preferred.
Robert.
On Wed, Jul 16, 2008 at 8:46 AM, Adrian Egli OpenSceneGraph (3D)
[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote:
Hi Robert,
This morning i was about 1hour in train, and reviewed again the
kdTree
implementation.
Re: [osg-users] Further Design Question: KDTree
On Wed, Jul 16, 2008 at 4:37 PM, Paul Melis [EMAIL PROTECTED] wrote: By the way, I just took a quick look at the current KD-tree implementation. Am I seeing misreading the code or do tree nodes currently store a full bounding box instead of just the appropriate split plane and its value on the split axis? Intersection also seems to do a test against a bounding box... It stores a full bounding box. I did experiment with just testing the central splits but didn't get any conclusive improvement, and in quite a few cases worse performance. Storing full bounding box does effectively mean that its binary BVH. I do expect we'll be do better than the current implementation in SVN, as we all learn more about optimizing this type of operation. Consider what we have as flag in sand marking out territory, but the fort is far from complete yet. Context is absolutely crucial as well. Optimizing KdTree further will be up against a law of diminishing returns, as the main bottleneck that most users will see is the intersection traversal cost/intersection hit recording, focusing on KdTree implementation is ignoring what is now the biggest bottleneck in getting further significant performance improvement. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Processing vertices in a subtree
On Wed, Jul 16, 2008 at 4:54 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, I've tried to write a NodeVisitor to grab all the vertices in a subtree. I'm trying to push those vertices into DelaunayTriangulator. The problem is that my NodeVisitor ends up seeing each vertex like 5 times in the subtree. Is there a way to get a set of all vertices with no repeats at the Geode/Drawable/Geometry/Primitive level? How many times things are shared is all down to your scene graph, and how you manage your scene graph in your visitor is entirely down to your code. I'd personally use a std::set or similar to keep track of what elements I've processed already but this really just a C++ programming issue, not at all something that is OSG specific. Robert/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Hi All, I've been doing merges and bug fixes today, and now I'm ready to tag the 2.5.5, but first I need feedback on how well things hang together across platforms. This is the first dev release with osgWidget as part of the core OSG so this means that we really do need to test across as many platforms as possible, as it's the code first wide exposure. Another area that could potentially cause problem is that I've now moved the old .net out trunk and into the deprecated annex of the OSG svn (alongside the old flt plugin.) If you still need it you can grab it from : http://www.openscenegraph.org/svn/osg/OpenSceneGraph/deprecated/src/osgPlugins/net/ I have hand modified the old Xcode projects to reflect this move of the .net plugin out of the core OSG too, but since Xcode projects are a mess it'd be easy for me to mess this up, so Xcode projects will certainly need checking on this count. Why move the .net plugin out? We'll parts of it are GPL'd, so it doesn't fit well with the OSG's more relaxed OSGPL (LGPL style) license, and the socket code in it can cause problems with builds across platforms. Since the new libcurl plugin is OSGPL, and has more functionality and is better future proofed, this is route to for http access going forward. Thanks in advance for your help in testing. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Processing vertices in a subtree
Don't know where I'd be without ya, pal. Thanks, that's a great idea. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, July 16, 2008 12:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Processing vertices in a subtree On Wed, Jul 16, 2008 at 4:54 PM, Argentieri, John-P63223 [EMAIL PROTECTED] wrote: Robert, I've tried to write a NodeVisitor to grab all the vertices in a subtree. I'm trying to push those vertices into DelaunayTriangulator. The problem is that my NodeVisitor ends up seeing each vertex like 5 times in the subtree. Is there a way to get a set of all vertices with no repeats at the Geode/Drawable/Geometry/Primitive level? How many times things are shared is all down to your scene graph, and how you manage your scene graph in your visitor is entirely down to your code. I'd personally use a std::set or similar to keep track of what elements I've processed already but this really just a C++ programming issue, not at all something that is OSG specific. 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
Re: [osg-users] Render to Texture
Paul, FYI, the HDR (Radiance format) plugin also supports writing 32Fs, which can be viewed with a number of applications. I think I also saw a recent submission that allowed the TIFF plugin to write floats, but I might be mistaken. David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 devrelease
Hello Robert; This is slightly off topic, but somewhat relevant, my apologies if there is a better list to submit this request under. In another thread, I mentioned that I have a slightly modified version of OSG compiling on a Solaris 10 Sparc architecture, using cmake 2.6. What I would like to know is what the mechanism is for submitting the source code changes I made for review and submission into the OSG source code base. Thanks, Lenny -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, July 16, 2008 12:08 PM To: OpenSceneGraph Users Subject: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 devrelease Hi All, I've been doing merges and bug fixes today, and now I'm ready to tag the 2.5.5, but first I need feedback on how well things hang together across platforms. This is the first dev release with osgWidget as part of the core OSG so this means that we really do need to test across as many platforms as possible, as it's the code first wide exposure. Another area that could potentially cause problem is that I've now moved the old .net out trunk and into the deprecated annex of the OSG svn (alongside the old flt plugin.) If you still need it you can grab it from : http://www.openscenegraph.org/svn/osg/OpenSceneGraph/deprecated/src/osgP lugins/net/ I have hand modified the old Xcode projects to reflect this move of the .net plugin out of the core OSG too, but since Xcode projects are a mess it'd be easy for me to mess this up, so Xcode projects will certainly need checking on this count. Why move the .net plugin out? We'll parts of it are GPL'd, so it doesn't fit well with the OSG's more relaxed OSGPL (LGPL style) license, and the socket code in it can cause problems with builds across platforms. Since the new libcurl plugin is OSGPL, and has more functionality and is better future proofed, this is route to for http access going forward. Thanks in advance for your help in testing. 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
Re: [osg-users] Configure error on Sun Solaris machine
Hello Peter; Would you like the complete set of binaries and libraries I have, or would you prefer to try the source code modifications that I have on your OSG distribution? The source code modifications were very minor. Thanks, Lenny -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pete Carss Sent: Wednesday, July 16, 2008 12:30 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Configure error on Sun Solaris machine I'd be very interested in a Binary... Pete Smith, Leonard C wrote: Hello Robert; I have found the error, and after correcting it, I now have OSG 2.4 configured and built on a Solaris 10 machine, after making a few edits in the socket plugins. The problem stemmed from the fact that there were a few linux wxWidgets binaries in my path, which were causing the configure to fail. I removed them from the path, and re-configured. I am using cmake 2.6, patch 0 on the Solaris machine with no issues. OSG configured fine. After the configure had generated the makefiles, I had a few problems in the source code for the net plugins. I had to edit src/osgPlugins/net/sockinet.cpp and src/osgPlugins/net/sockstream.cpp to go around the #define that was renaming socklen_t to int. After the edits were made, I tried a build, and now have OSG 2.4 up and running on a Solaris 10 Sparc machine. Thanks to Jean-Sebastien and yourself for all of the help. Lenny -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Monday, July 14, 2008 4:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Configure error on Sun Solaris machine HI Leonard, Could you try the SVN or 2.5.4 developer version of the OSG 2.4 and before doesn't work with CMake 2.6 due to small incompatibilities between the 2.4.x and 2.6 releases and the OSG's previous CMake files. Robert. On Mon, Jul 14, 2008 at 5:29 PM, Smith, Leonard C [EMAIL PROTECTED] wrote: Dear Jean-Sebastien; I myself haven't seen this error when building on Linux. I am using Cmake version 2.6 on a Sun box. I will look into the CMakeModules directory, and see if this helps, thank you. I agree that it would be very helpful if Cmake were a little more verbose while processing. I have worked a lot with gmake and GNUmakefiles over the years, and have on occasion found gmake -dnp to be the only way to diagnose a problem. Thank you again for your help, Lenny Smith -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, July 14, 2008 11:13 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Configure error on Sun Solaris machine Hello Leonard, There is no FOREACH statement in my CMakeLists.txt file. Where does this error come from? I do not use Solaris, so I can only suggest a few paths for you to investigate. First of all, what version of CMake are you using? The FOREACH statements are probably coming from the files included from the CMakeModules subdirectory. As to where the erroneous FOREACH statement is coming from, it would be useful if CMake would tell you which macro or function it was processing when it got the error... In any case, I haven't seen that error when generating build files for OSG (neither on Windows nor on Linux) which is why I suspect it's a CMake version problem. 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 ___ 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] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Hi Robert, Robert Osfield schrieb: I have hand modified the old Xcode projects to reflect this move of the .net plugin out of the core OSG too, but since Xcode projects are a mess it'd be easy for me to mess this up, so Xcode projects will certainly need checking on this count. The xcode-projects are ok, I added the osgWidget-library as a framework-target, but no examples, I hope to add one or two the end of this week. I'll try the cmake build the next days on Mac OS X .. Stephan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 devrelease
Hi Lenny, For submissions with have a separate osg-submissions list : http://www.openscenegraph.org/projects/osg/wiki/MailingLists And the related SubmissionsProtocol page on the wiki provide info on the best form that submissions should take. http://www.openscenegraph.org/projects/osg/wiki/MailingLists/SubmissionsProtocol As for Solaris fixes, there have been several since 2.4, so please make sure you have the latest SVN or dev release as your base, otherwise you might be fixing things that are already fixed, or changing a file that has other changes made to it that might conflict with yours. Also note, the .net plugin is no longer part of the OSG trunk so errors in this plugin won't affect you any more. Robert. On Wed, Jul 16, 2008 at 6:23 PM, Smith, Leonard C [EMAIL PROTECTED] wrote: Hello Robert; This is slightly off topic, but somewhat relevant, my apologies if there is a better list to submit this request under. In another thread, I mentioned that I have a slightly modified version of OSG compiling on a Solaris 10 Sparc architecture, using cmake 2.6. What I would like to know is what the mechanism is for submitting the source code changes I made for review and submission into the OSG source code base. Thanks, Lenny -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Osfield Sent: Wednesday, July 16, 2008 12:08 PM To: OpenSceneGraph Users Subject: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 devrelease Hi All, I've been doing merges and bug fixes today, and now I'm ready to tag the 2.5.5, but first I need feedback on how well things hang together across platforms. This is the first dev release with osgWidget as part of the core OSG so this means that we really do need to test across as many platforms as possible, as it's the code first wide exposure. Another area that could potentially cause problem is that I've now moved the old .net out trunk and into the deprecated annex of the OSG svn (alongside the old flt plugin.) If you still need it you can grab it from : http://www.openscenegraph.org/svn/osg/OpenSceneGraph/deprecated/src/osgP lugins/net/ I have hand modified the old Xcode projects to reflect this move of the .net plugin out of the core OSG too, but since Xcode projects are a mess it'd be easy for me to mess this up, so Xcode projects will certainly need checking on this count. Why move the .net plugin out? We'll parts of it are GPL'd, so it doesn't fit well with the OSG's more relaxed OSGPL (LGPL style) license, and the socket code in it can cause problems with builds across platforms. Since the new libcurl plugin is OSGPL, and has more functionality and is better future proofed, this is route to for http access going forward. Thanks in advance for your help in testing. 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] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Robert Osfield wrote: Hi All, I've been doing merges and bug fixes today, and now I'm ready to tag the 2.5.5, but first I need feedback on how well things hang together across platforms. This is the first dev release with osgWidget as part of the core OSG so this means that we really do need to test across as many platforms as possible, as it's the code first wide exposure. Just a small thingy: the osgwidget examples try to load a font fonts/Vera.ttf, which I don't see in the latest data distribution or SVN. Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
On Wed, Jul 16, 2008 at 7:35 PM, Paul Melis [EMAIL PROTECTED] wrote: Just a small thingy: the osgwidget examples try to load a font fonts/Vera.ttf, which I don't see in the latest data distribution or SVN. Sorry about this, missing checkin to OpenSceneGraph-Data svn/trunk. Could you do an svn update of OpenSceneGraph-Data and let me know how you get on. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Hello Robert, I've been doing merges and bug fixes today, and now I'm ready to tag the 2.5.5, but first I need feedback on how well things hang together across platforms. This is the first dev release with osgWidget as part of the core OSG so this means that we really do need to test across as many platforms as possible, as it's the code first wide exposure. Builds fine on Vista, VS8. 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] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Robert Osfield wrote: On Wed, Jul 16, 2008 at 7:35 PM, Paul Melis [EMAIL PROTECTED] wrote: Just a small thingy: the osgwidget examples try to load a font fonts/Vera.ttf, which I don't see in the latest data distribution or SVN. Sorry about this, missing checkin to OpenSceneGraph-Data svn/trunk. Could you do an svn update of OpenSceneGraph-Data and let me know how you get on. Ok, got it. I'm not sure what the expected output of the multitude of osgwidgets tests is supposed to be, but most seem to be doing something sensable... Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
On Wed, 2008-07-16 at 20:46 +0200, Paul Melis wrote: Robert Osfield wrote: On Wed, Jul 16, 2008 at 7:35 PM, Paul Melis [EMAIL PROTECTED] wrote: Just a small thingy: the osgwidget examples try to load a font fonts/Vera.ttf, which I don't see in the latest data distribution or SVN. Sorry about this, missing checkin to OpenSceneGraph-Data svn/trunk. Could you do an svn update of OpenSceneGraph-Data and let me know how you get on. Ok, got it. I'm not sure what the expected output of the multitude of osgwidgets tests is supposed to be, but most seem to be doing something sensable... Maybe I need to make it more clear what should be happening; would this be best in the form of console output (bad on windows) or perhaps a Label in the scene itself that can be clicked off somehow? Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Calling Wojciech Lewandowski - osgShadow improvements (LiSPSM)
Hello, I have asked in another thread (OpenSceneGraph-2.5.4 developer release tagged) if Wojtek's osgShadow additions/improvements could be integrated in time for 2.6. I'm talking about the additions mentioned in this post: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/28683 Wojtek has not yet replied, so I thought I'd send a message with a clearer title in case it just went under his radar... Wojtek, I would really like to see this in 2.6, and am available to do any testing required. Would it be possible to submit the improvements to Robert for inclusion? Thanks, 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] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Hi Jeremy, On Wed, Jul 16, 2008 at 7:51 PM, Jeremy Moles [EMAIL PROTECTED] wrote: Maybe I need to make it more clear what should be happening; would this be best in the form of console output (bad on windows) or perhaps a Label in the scene itself that can be clicked off somehow? Perhaps your videos would work well for this? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problem setting a skydome
Alberto, I presume that your skydome has some sort of camera centred transform over it (as per osghangglide's example use); your code doesn't show it. osg::ClearNode* clearNode = new osg::ClearNode; clearNode-setRequiresClear(false); This is odd. If your camera is the first thing to draw (implied by PRE_RENDER) then something needs to be clearing the colour and depth buffer. In any case, you can use camera's setClearMask method to control this without needing a clearNode. For example camera-setClearMask(GL_DEPTH_BUFFER_BIT | GL_COLOR_BUFFER_BIT) clears everyhing, setClearMask(0) clears nothing. osg::TexEnv* te = new osg::TexEnv; te-setMode(osg::TexEnv::REPLACE); stateset-setTextureAttributeAndModes(0, te, osg::StateAttribute::ON); Slightly surprised to see this, but if your skydome needs it, then OK. stateset-setMode( GL_CULL_FACE, osg::StateAttribute::ON ); osg::Depth* depth = new osg::Depth; depth-setFunction(osg::Depth::ALWAYS); depth-setRange(1.0,1.0); stateset-setAttributeAndModes(depth, osg::StateAttribute::ON ); Again, not wrong (as the depth testing is always passed) but not really necessary, as you are ensuring that your skydome is drawn first. I would tend to prevent depth writing with osg::Depth* depth = new osg::Depth; depth-setWriteMask(false); // don't bother writing the depth buffer stateset-setAttributeAndModes(depth, osg::StateAttribute::ON ); and also disable depth testing with stateSet-setMode(GL_DEPTH_TEST, osg::StateAttribute::OFF) I looked at my code and noticed that I also do camera-setCullingMode(osg::CullSettings::NO_CULLING), but can't remember at the moment whether it's relevant. Lastly, what OSG version are you using? Hope that helps, David ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how to get input from force feedback joysticks?
It seems the DirectInput can get the inputs of force feedback joysticks. How can I integrate DirectInput into my project? Is there any other way to get the joystick input? Thanks ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Calling Wojciech Lewandowski - osgShadow improvements(LiSPSM)
Hi J-S and All, I have been quite busy recently but I am still open to do this. Since a number of submitted files would be rather large and I have not done such contribution before I expected that Robert may do some short preview of the preliminary code I sent earlier and make suggestions how it should be refactored/wrapped to fit into osg. My code goes beyond some osgShadow concepts and I would feel more comfortable if I had some feedback before doing further rearrangements. In the meantime I was tweaking and cleaning ConvexHull (CustomPolytope) math code. The ConvexHull math was bit numerically unstable, it was really painfull to trace down the issues but I think I managed to fix that. I may create another code snapshot for the users to review with this new ConvexHull class (I have not decided on its name yet, maybe I will change it to ConvexPolyhdron because ConvexHull class already exists in osg). Cheers,Wojtek -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Jean-Sebastien Guay Sent: Wednesday, July 16, 2008 8:51 PM To: OpenSceneGraph Users Subject: [osg-users] Calling Wojciech Lewandowski - osgShadow improvements(LiSPSM) Hello, I have asked in another thread (OpenSceneGraph-2.5.4 developer release tagged) if Wojtek's osgShadow additions/improvements could be integrated in time for 2.6. I'm talking about the additions mentioned in this post: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/28683 Wojtek has not yet replied, so I thought I'd send a message with a clearer title in case it just went under his radar... Wojtek, I would really like to see this in 2.6, and am available to do any testing required. Would it be possible to submit the improvements to Robert for inclusion? Thanks, 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] binding a shader uniform to a matrix transform node
i have further looked for a solution getting the vegetation meshes reusable (the geodes including the stateset). but i found no way to bind the uniform in a way that the meshes keep reusable in the scenegraph. making the meshes reusable saves up much performance (there can be up to 500 meshes in the scene which stem from about 40 unique meshes). robert: do you have any idea how to manage that? it would help us much creating bigger islands for vrc. if it helps, i can provide osg files in order to better understand the problem. thanks for any help boto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] RE : Re: Loading a 3D texture with osgDB::ReadFile method
Dear Robert, Thank for your reply. Unfortunately that is not what I want to do. I was wondering if there is a way to extract each slice in a 3D texture. For instance, if I have a 3D texture made of 256 slices of 2D textures. My question was to be able to retrieve these 2D textures and apply them on a geometry. I hope to have clarify the matter. Waiting for your reply. Franclin. Robert Osfield [EMAIL PROTECTED] a écrit : Hi Franclin, You simple do: osg::ref_ptr image = osgDB::readImageFile(my3dtexture.dds); Then apply this image to your osg::Texture3D as you would any other texture. Robert. On Wed, Jul 16, 2008 at 2:15 PM, Franclin Foping wrote: Dear All, I am just wondering if it is possible to load a 3D texture with the osgDB::ReadFile method? I would like to be able to use the Data() method of the Image class to retrieve the data of the 3D texture for each stack of the texture. Is it possible? Or is there is any way around it? I am looking forward to hearing from you. Regards, Franclin. _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr ___ 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 - Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] RE : Re: Loading a 3D texture with osgDB::ReadFile method
Hi Franclin, Please look at the osgtexture3D example, it textures polygon using a 3D texture, but treated like a 2D texture. Robert. On Wed, Jul 16, 2008 at 10:57 PM, Franclin Foping [EMAIL PROTECTED] wrote: Dear Robert, Thank for your reply. Unfortunately that is not what I want to do. I was wondering if there is a way to extract each slice in a 3D texture. For instance, if I have a 3D texture made of 256 slices of 2D textures. My question was to be able to retrieve these 2D textures and apply them on a geometry. I hope to have clarify the matter. Waiting for your reply. Franclin. Robert Osfield [EMAIL PROTECTED] a écrit : Hi Franclin, You simple do: osg::ref_ptr image = osgDB::readImageFile(my3dtexture.dds); Then apply this image to your osg::Texture3D as you would any other texture. Robert. On Wed, Jul 16, 2008 at 2:15 PM, Franclin Foping wrote: Dear All, I am just wondering if it is possible to load a 3D texture with the osgDB::ReadFile method? I would like to be able to use the Data() method of the Image class to retrieve the data of the 3D texture for each stack of the texture. Is it possible? Or is there is any way around it? I am looking forward to hearing from you. Regards, Franclin. _ Envoyez avec Yahoo! Mail. Une boite mail plus intelligente http://mail.yahoo.fr ___ 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 Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ___ 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] Retrieving geometry information about a loaded model
Dear all, I would like to know how I can work out geometry information of a given loaded model. More specifically, I am looking for the following: 1 - The list of all vertices contained in the model. 2 - The normal at each vertex of the node 3 - The list of triangles of the model 4 - The topology of the model that is how the triangles obtained in 3 are connected. I am anxiously waiting for your reply. Best wishes, Franclin. - Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Retrieving geometry information about a loaded model
Hi, That is an extremely general question. The essense of OSG is accessing and manipulating that information: it's used for dispatching OpenGL rendering commands, and for reading/writing a scenegraph to basically any file format. Have a look at the query methods of osg::Geometry and how an osgDB::ReaderWriter serializes it to a file. Use a NodeVisitor to find the Geometrys in the scene. -- mew On Wed, Jul 16, 2008 at 5:47 PM, Franclin Foping [EMAIL PROTECTED] wrote: Dear all, I would like to know how I can work out geometry information of a given loaded model. More specifically, I am looking for the following: 1 - The list of all vertices contained in the model. 2 - The normal at each vertex of the node 3 - The list of triangles of the model 4 - The topology of the model that is how the triangles obtained in 3 are connected. I am anxiously waiting for your reply. Best wishes, Franclin. Envoyé avec Yahoo! Mail. Une boite mail plus intelligente. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Freetype Plugin on Windows.
Hi All, I appologise for bringing this up again :-( but I am stuck getting the freetype plugin to work under windows. I found this thread ( http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2007-December/005562.html)in the mail archive, but not being a CMake expert I don't understand what I need to do to make the freetype project appear in VS9.0.2 (vs2008). I have all the other plugins successfully working. I played with the CMake freetype options to see if I could make it work, but failed misserably. To help I have the following directory structure: osg | Build | 3rdParty (svn from https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1/ ) | Include | Freetype | Config | Internal | lib | Rest of svn repo | Rest of OSG svn repo. I appologise again for bringing it up, thank you for your help, James ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Please test SVN of OpenSceneGraph in prep for 2.5.5 dev release
Paul Melis wrote: Ok, got it. I'm not sure what the expected output of the multitude of osgwidgets tests is supposed to be, but most seem to be doing something sensable... SVN builds fine on MacOS X 10.5.4 with cmake 2.6. However when running osgwidgetframe I'm getting errors from the image loader: osgwidgetframe(4187) malloc: *** error for object 0xbfffc3d8: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug Error reading file osgWidget/border-left.tga : GraphicsImportGetNaturalBounds failed osgWidget: Widget [BorderLeft] cannot use a NULL image. osgwidgetframe(4187) malloc: *** error for object 0xbfffc3d8: Non-aligned pointer being freed *** set a breakpoint in malloc_error_break to debug Error reading file osgWidget/border-right.tga : GraphicsImportGetNaturalBounds failed ... This apparently is an error in the Quicktime loader that's used for a number of image formats on OS X. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to get input from force feedback joysticks?
Hi Xinyu, You can take a look at this: http://thread.gmane.org/gmane.comp.graphics.openscenegraph.user/11543 Hope it helps :) Regards, Cg Date: Wed, 16 Jul 2008 13:44:24 -0700From: [EMAIL PROTECTED]: [EMAIL PROTECTED]: [osg-users] how to get input from force feedback joysticks? It seems the DirectInput can get the inputs of force feedback joysticks. How can I integrate DirectInput into my project?Is there any other way to get the joystick input?Thanks _ Easily edit your photos like a pro with Photo Gallery. http://get.live.com/photogallery/overview___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
